找不到的公开文档应显示清晰的说明，并返回适当的 HTTP 状态码，通常为 404。在 Mac 上，你可以在 Chrome 中检查这两项，找出不一致之处，并向发布系统提供准确的修正要求。

本工作流程适用于维护公开文档页面的人员：指南、参考笔记或简单的说明单页。其目的是让请求的地址、服务器的响应和显示的消息保持一致。以下所有示例路径均为虚构路径。

找不到文档时应返回什么响应？

首先，确定访问文档地址时应发生什么。页面已迁移与页面已不存在，需要不同的处理方式。更改缺失页面设计之前，请使用此决策表。

文档状态 预期响应 读者应看到的内容
文档位于请求的地址 200 OK 完整文档
文档有明确的永久替代版本 301 重定向 位于新地址的替代文档
找不到文档，也没有等效替代版本 404 Not Found 有用的文档缺失说明
文档被主动删除，且很可能永久不再提供 适合使用 410 Gone 清楚的移除说明和实用导航

HTTP 定义了 404，但没有说明缺失是暂时还是永久的。对于可能永久不可用的资源，HTTP 定义了 410；如果无法确定是否永久，则使用 404。这些含义见 RFC 9110 第 15.5.5 和 15.5.11 节。

Google 建议，在文档已迁移或有明确替代版本时使用永久重定向。如果文档已删除且没有类似的替代版本，Google 建议使用 404 或 410。参见 Google 关于处理内容缺失响应的指南。

例如，假设 /documents/paper-folding-notes 已变为 /documents/paper-folding-guide，且两者提供的说明基本相同。这种情况适合使用永久重定向。如果这些笔记已被删除且没有替代版本，则应在原地址保留文档缺失响应。你可以在该页面提供指向通用文档目录的链接。

为什么仅有令人信服的缺失页面设计还不够

页面上可以清楚地写着 Document not found，但服务器返回的却是 200。Google 将此类不一致称为软 404；空白页面或没有主要内容的页面也可能被归为软 404。请阅读 Google 对软 404 错误的说明。

状态码属于 HTTP 响应的一部分，与说明内容相互独立。因此，更改标题或添加醒目的 404 标签，并不能确定响应代码。判断问题是否已修复之前，请检查实际的文档请求。RFC 9110 介绍了响应状态码的作用。

如何在 Mac 上检查文档响应？

使用 Chrome 内置工具进行检查。准备一个已知可正常使用的文档地址，以及同一公开网站下一个特意设置为不存在的路径。例如，缺失路径可以是 /documents/missing-paper-example-731。选择一个你确认没有已发布文档的地址。

  1. 在 Chrome 中打开公开页面。
  2. 按 Command + Option + I 打开 DevTools。
  3. 选择 Network 面板。
  4. 保持 DevTools 打开，在地址栏中输入测试地址并加载。

Chrome 在打开 Chrome DevTools中说明了 Mac 快捷键。DevTools 打开时会记录网络活动，详见 Network 面板概览。

  1. 选择 Disable cache，避免此次检查依赖浏览器缓存的响应。
  2. 如果需要跟踪重定向过程，请启用 Preserve log。
  3. 重新加载测试地址。
  4. 选择主要文档请求，然后打开 Headers。在 General 下查看请求地址和状态码。

Chrome 的 Network 功能参考介绍了这些控件以及状态信息的位置。

仔细检查文档请求。日志中还包含脚本、样式和其他资源的请求。辅助文件缺失，并不能证明文档本身返回了 404。Chrome 的请求表会在 Status 中显示 HTTP 代码，并在 Type 中显示资源类别；请参阅检查网络活动。

现在将三项观察结果进行比较：最初请求的地址、该文档的响应代码，以及加载后显示的页面。把它们记录在一起。如果导航更改了地址，请检查原始请求和目标地址，不要只记录最终页面。

如何根据观察结果提出修正要求？

以下诊断表是根据 HTTP 含义和 Google 的故障排查指南整理而成的实用归纳。它是辅助决策的工具，并非实测结果。

观察结果 应调查的内容 预期修正
200，页面显示文档缺失消息 缺失路由处理程序或回退机制 返回 404，并显示说明
404，页面显示预期文档 分配给现有路由的响应 使用 200 成功提供该文档
重定向到通用目录 是否存在等效替代版本 重定向到等效文档，或显示缺失页面
200，页面空白或内容不完整 内容加载和呈现 如果文档仍然存在，则恢复预期内容
404，页面显示有用的缺失说明 该地址是否确实没有内容 如果预期就是缺失，则保留此行为

Google 的故障排查文档明确区分了不可用的文档、已迁移的文档，以及仍然存在但无法正确加载的文档。此区分可避免将内容不完整的正常页面误认为已被主动删除。请参阅排查 Google 搜索抓取错误。

交接时可以这样写：“对于虚构的缺失路径 /documents/missing-paper-example-731，请返回 404，并在该地址显示自定义的文档缺失页面。确保现有文档路径仍可正常访问。仅在确认存在等效替代版本时才应用永久重定向。”补充你检查时观察到的状态码和可见消息。

此要求描述了所需行为，无需猜测发布系统中的菜单名称。具体实现在负责生成响应的托管配置、应用程序路由或发布系统中完成。Google 在其 HTTP 状态码文档中解释，HTTP 状态码由托管服务器生成。

如果编辑器只允许更改页面内容，该怎么办？

能够更改文本或文档元数据的编辑器可能无法控制 HTTP 响应。WHATWG HTML 标准定义了使用 http-equiv 的 meta 指令的具体行为；设置 HTTP 响应状态并不在其中。因此，添加 http-equiv="status" 并非创建 404 的受支持方式。请参阅 HTML 标准：Pragma 指令。

如果编辑器没有响应控制功能，请使用托管或应用程序层有文档说明的缺失页面机制。确认该机制是否会在请求的缺失地址以 404 提供自定义内容。仅能选择错误页面版式的设置无法回答这个问题；请使用浏览器工作流程验证实际结果。

Netlify 静态页面的有文档说明示例

对于 Netlify 上现有的静态网站，有文档说明的机制是创建名为 404.html 的文件。对于无法解析为静态文件的失败路径，Netlify 会自动使用此文件。这是特定于服务提供商的示例，适用前提是：你可以访问网站构建完成后的输出，并且网站已经构建了静态页面。Netlify 介绍了自定义 404 处理方式。

  1. 使用网站现有的页面模板创建缺失文档页面。
  2. 确保构建完成后的输出在发布目录根目录中包含 404.html。
  3. 检查是否有更早执行的路由规则将未知地址发送到其他页面。
  4. 修订后的输出在公开地址上线后，检查一个缺失路径和一个正常工作的文档。

路由检查很重要，因为 Netlify 会先处理路由，然后才处理静态文件和最终的缺失页面。已由前序规则处理的请求不会到达最终处理程序。Request Chain 文档介绍了处理顺序。此示例说明一种修正方式，并不表示任何网站已被修改。

浏览器端路由应用的限制

有些应用只有在 JavaScript 运行后才能发现文档不存在。Google 承认，在客户端路由中返回有意义的状态码可能不切实际。其文档中介绍的替代方案包括：通过 JavaScript 重定向到服务器返回 404 的地址，或在错误页面中添加 noindex 元数据。请参阅 Google 的 JavaScript SEO 指南。

这些替代方案的结果各不相同。重定向会跳转到一个新地址，该地址会返回真正的缺失页面响应。元数据方案针对的是索引问题，原始 HTTP 状态码则保持不变。如果要求保留原始文档地址，并让该地址返回 404，则托管或应用程序响应必须支持这种行为。

缺失文档页面应显示什么内容？

使用简短明确的消息，例如 This document could not be found.。随后提供一个有用的下一步操作：链接到文档目录或其他已经确认有效的导航目的地。保持网站熟悉的导航和外观。Google 建议自定义缺失页面使用清晰的语言、一致的设计和有用的链接，详见自定义缺失页面。

对于虚构的折纸示例，合适的文案可以是：We couldn’t find this paper-folding document. Browse the document directory to choose another guide.。只有在确认文档已被永久删除时，才这样描述。应清楚显示说明，不要立即将所有缺失地址都重定向到其他地方。

如何验证响应与页面内容是否一致？

用一组简短的对照用例重复检查。以下预期结果是示例验收标准，并非报告的测试结果。

测试用例 预期响应和页面内容
已知可正常使用的文档 200，并显示完整文档
特意设置为不存在的路径 404，并显示文档缺失说明
已删除且没有替代版本的文档 404，或在适当情况下使用 410，并显示准确说明
已迁移且有等效替代版本的文档 永久重定向，然后成功返回替代文档

重新输入每个地址并直接加载，包括通常通过页面内导航访问的文档，然后再次检查。这可以验证新发起的文档请求收到的响应。将地址、代码和可见结果记录在一起，以免成功的目标页面掩盖导航前序响应中的错误。

如果旧结果仍然存在，请区分浏览器缓存和其他缓存。停用 Chrome 缓存只影响浏览器缓存。HTTP 缓存也可能存储 404 等负面响应，因此如果缺失响应过时，可能需要检查发布系统中有文档说明的缓存行为。RFC 9111 介绍了可缓存的负面结果。

对于 Google 搜索，真正的缺失响应会带来预期后果：Google 不会将返回 404 或 410 的网址编入索引，并会随着处理这些响应而移除先前已编入索引的网址。即使返回成功的 200 响应，也不保证会被编入索引。请参阅HTTP 状态码对 Google 抓取工具的影响。

当每个测试地址的情况都一致时，即可完成检查：可用文档成功加载，已迁移的文档指向其替代版本，不存在的文档返回适当的缺失响应并提供实用导航。这样，你就能在 Mac 上进行具体且可重复的发布检查。

来源