权重域名

　1、W3C标准的“网页结构、表现、行为分离，互不干涉抢功”理念
　　且不说SEO，其实按照这个理念建设起来的网站，网页打开速度会明显的加快。因为按照这个理念，网页将会分成html、css、js三种类型的文件，而css、js又是可以缓存的，所以浏览一个这样的网页其实就是下载html代码就行了，速度当然变快啦。
　　W3C标准不能滥用标签，代码冗余，所有不会出现表格那样多层嵌套的问题。
　　SEO作用有五：
　　之间的代码不会很多；
　　网页META标签会添加的比较齐全，如keywords、description、robots；
　　被搜引擎抓取的内容，代码比较精简，非内容代码大大减少，文件小；
　　文本会比较靠前。几乎都在200字内就可以搜索到正文，重要内容；
　　不会出现表格那样多层嵌套的问题。
　　2、修饰性图片文本替换，js、flash文字图片还原
　　有些网站为了追求炫眼效果，采用了图片按钮，图片新闻flash切换，文本的js跑到效果……这样大大将原本属于图片，文字链接的代码变成了搜索引擎读不懂的js代码、flash，或者是直接插入原本不是内容的修饰性图片替换了文字。如果这些刚好又包含了热门关键字，那么搜索收录量将损失很大。
　　对此按照W3C标准做的话，就可以避免以上问题：
　　修饰性图片文本替换：就是说将不是内容而是修饰的图片变成底图显示，不干扰搜索引擎，让它忽略它。而有增加文字，之后使用css隐藏掉，这样也增加了可以搜索的文字。常见使用于logo，按钮，菜单。js、flash文字图片还原：这是我近来提出来的一个思路，还没有广泛给大家知道的方法(呵呵，大家接不接受还是个问题)：将js，flash显示的内容转为html，之后使用js读取html，传递参数启动原来的效果、并且隐藏html，只是比原来增加了几个步骤。详细可以参考我写的文章：如何减少JS对搜索的负面影响。
　　3、W3C要求必须添加链接标签的title、图片标签的alt属性
　　这样的话，所有的a标签都会规范的添加有title文本，img有alt文本。而不是等到要优化的时候临时的把几个含有关键字的链接(描文本)添加上title，图片加好alt。W3C标准不是为了SEO优化而添加title、alt，而是为了网页亲和力添加它们。
　　4、合理安排使用
　　本加粗，斜体，下划线
　　这是语义化标签都必须做到的一步。所以做到了W3C标准，这个问题也会在不知不觉中做到了。
　　5、网页标准可以随时将重要的内容调前，之后使用css重新定位。
　　例如页面效果图中中间的文字比较重要，可以先把重要的内容放在左边的代码的前面，方便搜索引擎，之后使用css将它调会到效果图的位置。
　　6、网页标准提到的好处
　　更少的代码和组件，容易维护
　　带宽要求降低(代码更简洁)，成本降低。更容易被搜寻引擎搜索到
　　改版方便，不需要变动页面内容
　　提供打印版本而不需要复制内容
　　提高网站易用性。
　　SEO的另一半工作是编辑，编程
　　编辑涉及的工作有：频道栏目的设计、取名，页面的布局(关键词的位置安排)，创建栏目时，录稿时，文件夹，文件的取名；关键词管理，了解当前使用的关键词流行度，竞争度；专题、当前热门的关注；录稿时关键词的提炼、图片alt的插入习惯；与同类型网站的交流，交换链接……
　　编程涉及的工作有：页面实现静态化；URL实现伪静态，使用re_write重写技术；本站系统搜索中关键词的搜索功能，实现网站各个页面的关键词网；维护服务器，稳定服务器。评论的广告过滤；自动将关键词加粗、添加含有title关键字的链接；避免网站过多死链接，提供死链接自动删除或修复功能；相关文章取文章链接格式：先是关键词相同的关连，二关键字与标题的关连，文章内容与关键词关连。……
　　所以制作完成符合W3C标准的网页后，你只是完成了50%的SEO工作，还有另一半需要编辑，编程共同完成。其它的作弊，或者是刻意重复关键词，body之间代码的开始或结束增加关键词出现机会……是没有必要。
　　制作、编程是SEO的“打地基”
　　网站的制作、编程与编辑：就好比建设一座大厦，网站制作、编程是“建筑工程师”、“建筑设计师”，编辑就是使用大厦的老板。工程师按照老板的需求，做好地基，楼架，之后的美化，装修就看老板了。
　　没有好的制作，符合搜索优化的代码结构，那么无论编辑的水平怎么样，搜索引擎也不会有好效果。但也可以看到：“地基”打好以后，随着时间的增长，编辑的作用效果就会原来越明显，因为地基不需要经常变动的。一动就是伤筋骨的“大工程了”。
　　不符合标准的网站，赶紧网站重构吧.
　　Christopher Schmitt
　　更方便搜索引擎的搜索。用只包含结构化内容的HTML代替嵌套的标签，搜索引擎将更有效地搜索到你的内容，并可能给你一个较高的评价(ranking)。 

    作为一个身处 2008 年末的 Web 设计师，你是否好意思承认自己的代码中使用了 Table，如果是，你是一个有勇气的人，Web 设计是个奇怪的行业，你可以将自己的网站设计得像晚报的分类广告，或者楼道里的开锁广告，但千万别让人知道你使用了 Table，在你的源代码中发现 Table 就像一个销售被人掀起裤脚发现穿了白袜子一样。
        Table 是如此丑陋，臃肿，哪怕只显示一段简单的内容，你也需要 <table><tr><td> 这三个基本的标签，每个标签里面还要加上一堆乱七八糟的属性，不像<div>， 既简单，又整洁，又时尚，它和 CSS 珠联璧合，琴瑟和谐，它们构成最完美的 Box 模型，他们象现实中的箱子，你把东西放进去，然后，很自由地对他们进行排列，厌烦了一种布局，没关系，简单地改动一下 CSS 定义，一种全新的布局便诞生了；不象 Table，Table 像食堂里的餐具柜，一排排，一列列，土里土气，油腻腻的，象我们的父辈，邋遢，什么都往家里拿，胡乱堆在角落里，如果 Div 是小资，Table 就是老三届，他们不属于这个时代。
        也就是近几年的事，至多不过三五年，W3C是一个人人都认为重要但人人都不喜欢的组织，他们的官方网站十分丑陋，我敢说平生没见过这么丑陋的网站， 但他们的网站是为数不多的可以通过全部W3C标准验证的网站，这意味着，他们的网站在语法上，在结构上，在可访问性上是完美的，虽然依旧十分丑陋。不过这 是笑谈，W3C非常重要，否则微软会把全体 Web 开发工程师带到万劫不复的境地，还好，Netscape 死后，涅磐出 Firefox，而 Opera 在 Firefox 横空出世之后虽然没得到任何好处，至少得到了精神上的支持，看到没，终于有大哥出来收拾你。乔布斯复出后，苹果重返昔日的光芒，这时人们才知道世界上还有 一个叫做 Safari 的浏览器，所有这一切加在一起，让 W3C 真正有了存在的必要。
        W3C 说，Table 可以用来容纳文字，格式文字，图片，链接，表单，以及其它 Table ... 但是，Table 不应该单纯用来做网页布局（Tables should not be used purely as a means to layout document content），理由是，当 Web 被非可视化设备渲染的时候，Table 会出现问题，他们指定是屏幕阅读器以及盲文浏览器，另外，Table 在大型显示设备上会强迫用户左右滚动，因此，Web 设计者应该使用 CSS 而不是 Table。参见 W3C HTML 4.01 关于 Table 的定义。 W3C 说这段话的时候，是1999年12月24日，那时尽管 CSS 早已诞生，但并没有多少人使用，最初的 Web 像一个在线版的文档，并没有成为现在这样的平台，不需要过多过多地考虑布局问题，随着互联网第一次泡沫的形成，涌现出大量的门户网站，门户网站是 Table 布局的始作俑者，因为他们的首页比一整份报纸的所有版面拼接在一起还复杂，Table 在这方面十分顺手，结合 colspan 和 rolspan，你几乎能够实现任何复杂的版面。
        这种布局风格在2000年代初，一直到中期仍然十分流行，尤其国内，在大为美的潜意识下，人们把所有能塞到一个页面的东西都塞进了首页，Table 就像一个旧时代的管家，把所有东西虽不能井井有序，但至少是一样不少地编排起来。然而这样的 Web 终于到了让人厌恶的地步，随着搜索，RSS 订阅，以及以博客为代表的个性化 Web 的出现，人们有更多渠道获得信息，而不必去访问那几个让人几乎要晕过去的门户的首页，于是出现了一种清新的，轻量的 Web 风，使用更简单的布局，更明快的配色，大图标，大 Banner，以及更容易阅读的大字体，同时，在这个时候，CSS 已经非常成熟，而 Firefox, Opera, Safari 为代表的浏览器，在遵守 W3C 标准方面要远远好过 IE，人们终于认识到 CSS 的威力。因为 CSS 在布局上，其核心是一个 Box 模型，人们必须为 CSS 找一个可以依附的容器对象。
        Div 成为幸运者一方面因为它天生就是 Box 的最佳原型，在语义上，Div 代表页面的一个区域，在外形上，它四四方方，更重要的是，它不像 <P> 或 <a> 那样事先已经被赋予特殊的语义（虽然它们也能用于 Box 模型）；另一方面，则出于人们对 Table 统治一个臃肿时代的憎恶，一个时代的结束，继任者都会努力抹去旧时代的痕迹，那些旧时代的象征或代表的命运多半如此，人们并不是简单地忘却它们，而是断然 划清界限。
        Table 的一切不公平待遇就此开始。为什么说不公平，W3C 不建议 Table 布局的时候，只说应使用 CSS 代替，这是什么意思，Table 不支持 CSS 吗？当然支持，而且，由于 Table 作为老牌的 HTML 对象，它的地位曾如此重要，任何浏览器都对 Table 提供了最完美的支持，包括 CSS 支持。当人们拥抱 Div 的时候，似乎忘记了 Table 也是 Box，而且是一个拥有多个内格的 Box，Table 作为一个整体，和 Div 在 Box 模型方面没有任何区别，而它的内格，除了 Margin 之外，仍然是一个 Box，内格不含 Margin 概念这是应该理解的。Div 很优秀这不必说，然而当人们说 Div + CSS 的时候，似乎暗示着 Table 无法 CSS，这是天大的误会。
        Div 支持的所有CSS 属性，Table 全部支持，事实上，在Div 大红大紫之前，那些 Div 的早期采用者曾信心不足地表示，Table 能做到，Div 都能，而他们也为自己的话付出了代价，企图在 Div 中实现垂直居中的人明白我的意思，企图在 IE6 中不经 CSS Hack 而实现 100% Div 布局的人更明白我的意思。100% Height 问题，几个 Div 之间的宽度自适应问题，相信任何从事 Div + CSS 设计的人会遇到。Table 在这方面的优势并不是因为它本身多么优秀，而是因为它老牌，没有浏览器敢忽视，也因为它的特性原本如此，人们发明表格，是因为希望数据显示得整齐，就这么 简单。然而，为什么 Table 后来背上那么多的恶名？Div 拥护者对 Table 的责难不外乎以下几条。
代码臃肿：你至少需要写下 <table><tr><td>这三个标签之后，才能开始真正的内容，另外，Table 的各种标签中还包含了复杂的属性定义，而 Div 只需 <div>一个标签。
页面渲染性能问题：浏览器需要将整个表格完全读完后才会开始渲染。
不利于搜索引擎优化：搜索引擎喜欢内容与修饰分开。
可访问性差：屏幕朗读软件和盲文浏览器无法很好地理解 Table 中的内容。
不够语义（Semantic）：我们需要语义的 Web。
        第1条：代码臃肿
        首先，Table 里面唯一无法用 CSS 定义的属性只有 Cellspacing, Cellpadding 几个，其它属性都可以并且应当使用 CSS，这样，剩下的，就是 <table><tr><td> 和 <div> 的对决，我相信一个动辄几十K大小的网页，即使使用了几十个 Table，因此多出来的代码也可以忽略不计，那些埋怨 Table 代码臃肿的人其实该检查自己的编码习惯，能将 Table 写得十分臃肿的人，写 Div 相比也未必会简洁到哪里。
        第2条：页面渲染性能问题
        我使用一台2004年的笔记本电脑，1.6G 的 CPU 与 1G 内存，这种配置下，看不出 Table 布局和 Div 布局在页面渲染上有任何速度差别，其实这点差别即使有，相对网络本身的延迟也可以忽略。
        第3条：不利于搜索引擎优化
        如果你尽可能使用 CSS 而不是 Table 的属性，前面说了，产生的代码和 Div 的差别也不会很大，搜索引擎会歧视 <table> 标签吗，这种说法的依据我至今并没有找到。
        第4条：可访问性差
        这是Table 固有的缺陷，不过多数 Div + CSS 的拥趸似乎并不是基于这个原因才排斥 Table。
        第5条：不够语义
        语义Web 的含义要深远得多，并不是仅仅在 Table 和 Div 上纠缠，即使 W3C，也并没有规定 Table 只能用来显示表格数据，很多在 Table 的语义上进行纠缠的人，其实不妨再等等 HTML 5，那才是真正的语义。
        本文的目的不是让你丢弃 Div 投身 Table，相反，如果 Div 能满足你的设计需要，Div 仍是首选，但没必要避讳 Table，否则会走入另外一个极端。很多使用 Div 无法简单实现的设计，仍可以使用 Table，当然，不管使用什么，都应该用 CSS 将内容与修饰分离。Div + CSS 和 Table + CSS 都是合法的设计，谁更简单就用谁。根据我的经验，当你能预见你的内容的格式，对你即将加入的内容有能力完全控制其显示格式时，应当使用 Div + CSS；当你即将加入的内容是不固定的，你无法预见其格式，如果不想让页面坍塌，使用 Table + CSS 是一种保险的做法。