让 doctype 与页面一致 Validator 实际上能够最大限度地检测出您的页面是 什么，即使结果可能与此页面内的现有 doctype 不匹配。所以如果您已经获得声称是 XHTML 1.0 严格版的 doctype，而此页面实际上是 HTML 4.01 过渡版，Validator 将会告诉您这些。只需采用 Validator 猜想的结果，而不要试图与任意的 doctype 相匹配（也许是一个过分热心的 Web设计者输入的？）。这是最有效的方法，可以让您快速获得可维护的有效站点。
Validator 也报告错误除了判断您的页面是 什么，Validator 还会根据此判断报告错误。几乎每一种情况 — 尤其是如果您将要继承站点，同时也不能确定摆放在您面前的页面如何 — 您将得到错误（图 3 显示图 2 不可见的几种错误）。
图 3. Validation 错误 现在，我将再次给您一个难以遵循的忠告：不要开始修复这些错误！我知道，我知道……您迫切地想这样做。但事实是：如果 Web 站点乱作一团 — CSS 和 HTML 没有分开，到处都是换行符 (<br>) — 那么不管如何修复，您的一切努力工作都将改变。您已经 将 CSS 从 HTML 中分离出来了，那为什么现在要修复由此导致的错误呢？进行分离，然后 返回来处理验证问题。
此阶段的目标是确定自己的目标。如果您的页面定位于 XHTML 1.0，也许可以轻易将其返回到 XHTML 1.0。 我也做一个假设：设计者也许选择 XHTML 1.0 有一定的原因，即使您不知道原因，也一定要坚持此决定。
如果您的站点返回到 HTML 4.01 过渡版 — 这基本上是最松散的可能选择 — 那么不管怎么样您都是好的，因为您要进入的是一个低门栏。此处的想法是找到通向坚固站点的最短的可能路径 — 不管是在设计还是在实现上 — 满足原始设计师给定的任何要求。有时您不知道这些要求是什么，因此验证是对其进行逆向工程的一种方式。
但是我有 1,000 页！ 迄今为止，我们的假设是您通过 Validator 手动运行站点中的每个页面。本质上，这是确保捕获每个页面上的每个错误的最佳 方法，并给予每个页面适当的关注。当处理了前几个页面之后，您通常会更改应用于整个站点（例如，可以通过大量的搜索和替换重新设计一个标题区段来），从而使后面的页面更容易处理。
然而，因为重点在于效率，所以可以选择批处理验证。在这些情况下，您将需要超越 W3C Validator，使用像 WDG HTML Validator（允许在文本框中输入多个 URL — 更好，尽管不是最好）或者 CSE HTML Validator（一个便宜的批处理程序）这样的工具。（在 一节中可以找到二者的链接。）批验证的问题是，尽管节省了执行的时间，但很容易漏掉细节，因为在大型站点中，您通常面对的是数百 — 即使不是数千 — 行错误。
为什么要验证？ 如果您像 Web 开发领域的其余大部分人一样，验证充其量只是有点讨厌，最坏也不过是一场情节丰富的噩梦。第一次通过 Validator 运行页面时，会看到数百个的红色阴影的错误消息，简直就是势不可挡。但您可以从验证中获得一些好处，这些好处使您对页面的验证非常值得。
第一个且最重要的是，有效页面将会正确显示。无效页面通常缺少结束标记，HTML 标记嵌套不正确，甚至 CSS 样式标记的问题。这些都不是 “乐意拥有” 的项目；它们是您希望其行为与预期一样的站点的本质。一个 b 或 h1 标记位置不当或闭合，突然整个页面都变成了粗体……，用户成群结队离开您的站点。所以验证是将页面标记为 “可预测” 的一种方式。如果正确使用标记，则页面将结构良好且易于使用和浏览。
此外，验证还提供了一个基准功能，可以始终检查页面的更改和升级。如果您对页面进行验证，然后它停止 验证，那么您就会知道所做的更改确实破坏了站点的结构，甚至表示。 因此验证可以作为一种检查 — 有点像每次更改代码之后进行编译一样。如果编译（或验证）失败，那么一定有一些事情出错了。
最后，针对有效的页面是否更容易被 Google、Yahoo! 和MSN 等搜索引擎索引，存在着激烈的争论。这些搜索引擎使用的算法的都是高度保密的，并不断更改，因此您将发现一些资料说验证很重要，然后说它并不重要，接着说没必要，但会增加您的搜索分数或索引。总体来说，除了每个公司的极少数人（我们不知道）之外，确定无疑的是结构和表示正确（验证帮助做的事情）的页面将会被更多的访问、更多的索引，最终在任何搜索顺序中的等级都会更高。 |
