什么是软 404？

Scrapeless Agent Browser 运行受管理的浏览器会话，可以检查动态网站上已渲染的内容。

软 404 是指某个页面在行为上像是缺失或空资源，但其 HTTP 响应却未能正确传达这一状态，通常会返回成功状态码。搜索系统也可以在页面主要内容缺失时，将渲染后的页面归类为软 404。诊断任务是对比 URL、响应以及页面的实际含义。

为什么一个成功的响应仍然可能代表一个缺失的页面

软 404 描述的是页面向用户和爬虫传达的含义。服务器可以返回成功响应，而响应主体却说明所请求的文章不可用。客户端应用可以为每个路由返回相同的外壳，然后再渲染一条错误消息。传输虽然完成了，但请求的资源并未被提供。

Google 的软 404 诊断 将缺失和空的主要内容描述为与此分类相关的信号。报告是关于 Google 遇到的页面的证据，因此要将报告中的 URL 与其当前的响应和渲染输出进行比较。该分类并不是一种每个爬虫程序都会以相同方式应用的通用文本模式。

对于网页数据采集，只有在先定义其含义之后，才将“软 404”用作一个操作性类别。爬虫可能会将一个缺失的产品页面（虽然返回成功状态）归类为软 404。这种本地分类与 Google 的索引决策是分开的。对该类别进行清晰命名，可以防止将一次内部内容检查误当成经过确认的 Search Console 发现来呈现。

一次成功的网络交换回答的是某个表述是否已经到达。内容验证则回答它是否是你请求的那个表述。过早地将这两个问题合并，会让一篇缺失的文章看起来像是一篇成功获取但没有正文的文章。随后下游系统就会失去“源头缺失”和“采集失败”之间的区别。

将请求的 URL 与最终资源进行比较

最终 URL 是软 404 证据的一部分。 URI 语法和参考模型 区分用于标识资源的各个组件。缺少路径可能会在原始 URL 返回错误模板，或重定向到通用登录页。这两种情况都会误导只要最终响应成功就接受、而不检查资源身份的采集器。

在判断最终页面含义之前，先检查完整的重定向历史。跳转到资源实际的替代页面是有用的；跳转到一个通用主页则对所请求内容的说明要少得多。将原始 URL 和最终 URL 一并记录下来，尤其是在某个流程将原始 URL 用作文档标识符时。

The HTTP 状态码和重定向语义 在不依赖你的解析器的情况下单独定义响应含义。对于已删除页面，“未找到”状态可能是正确的行为。对于确实有替代内容的页面，永久重定向可能是正确的行为。在这两种情况下，都不应该通过强制每个请求都返回成功响应来进行“修复”。

对于自有站点，请根据资源状态选择响应方式。如果内容仍然存在，则提供有用内容并修复其加载路径。若内容已移动，则将用户引导至相应的替代页面。若内容已消失且没有等价替代，则需明确说明其缺失情况。友好的错误页面仍然可以使用合适的“未找到”响应。

空应用外壳和缺失的主要内容

渲染后的页面可能与其最初的 HTML 响应不同。现代应用程序可能会从后续的数据请求中加载其主要内容。如果该请求失败，浏览器可能仍然会显示导航、品牌标识和页脚，而文章或产品内容却从未出现。仅依据正文长度的检查可能会接受这些外围的页面框架，却忽略了缺失的核心资源。

比较初始标记与渲染后的文档。识别应包含请求内容的组件以及为其提供内容的数据依赖。检查脚本加载错误、失败的 API 响应和应用程序错误状态。当某个 URL 在已登录浏览器中可以正常工作，而在干净会话中却只看到几乎空白的页面时，这种比较尤其有用。

良好的内容检查需要与资源相关的特定身份信息。对于一篇文章，比较其预期的标题和主体文本区域。对于一个产品，比较产品标识符和产品详细信息部分。检查应尽量避免脆弱的措辞，但仍需具备足够的特异性，以便将目标与通用模板区分开来。

不要假设每个篇幅很短的页面都是软 404。一个小型工具页面可能就是完整的，而一个空的搜索结果页面也可能只是正确地说明查询没有匹配结果。相反，一个很长的错误页面可能包含数百字的导航和推荐链接。页面的角色和预期内容比任何通用的字数阈值都更重要。

软 404、硬 404、有效空页面和访问失败

软 404 属于一种能够保留相邻结果的分类方案。需要做出的有用判断是：该资源是缺失的、不可访问的、不完整的，还是以空结果的形式存在。

一个有效的空搜索结果应包含预期的搜索界面、所请求的查询上下文，以及一个明确的“无结果”状态。一个缺失的产品页面没有对应的产品表征。一次访问质询意味着采集器没有到达该资源，因此不应将其视为产品已被移除的证据。

如果来源返回维护或服务故障响应，应保留该响应类别。把每个不可用页面都重标记为“未找到”会导致监控系统过早移除记录。当证据仍然模糊时，应保持一个带有原始响应和捕获条件的审核状态。

为采集器构建内容接收规则

内容接收规则应同时验证传输完成情况和来源标识。从最终响应和 URL 开始，然后确认预期的内容区域是否存在。检查页面是否包含与该资源相关的明确错误状态。将这些信号结合使用，而不是让某一句话独自决定结果。

围绕少数具有代表性的页面设计规则：一个正常工作的目标页面、一个刻意缺失的路径，以及如果站点支持的话，一个有效的空结果案例。它们是对比案例，而不是可以证明未来每个错误都长得一样的训练数据。页面模板和本地化可能会变化，因此要记录下你的规则所依赖的特征。

当文本因语言而异时，在可行的情况下使用稳定的资源标识和结构性证据。对于一个多语言站点，仅凭英文的“not found”短语是一个很差的单一分类器。同样的短语也可能出现在讨论错误的文章中。确认这段文字出现在哪里，以及预期资源是否存在。

该 Scrapeless Agent Browser 渲染环境 在初始 HTML 不足以检查动态页面时很有用。浏览器会话提供已渲染的证据；你的管线仍需判断这些证据是否代表了所请求的资源。托管渲染无法恢复发布方已移除的内容。

在不改变含义的前提下诊断自有页面

修复疑似软 404 要从预期资源本身开始。确认 CMS 记录是否存在，以及公共路由是否应当暴露它。后端中的草稿记录并不能证明公共文章已经存在。在调查渲染器之前，先检查发布状态和路由映射。

对于应当公开的资源，同时检查数据响应和页面组件。缺失的数据库记录、错误的路由键或内容获取失败，都可能让页面外壳缺少预期正文。在可行时为应用提供一个正确的缺失状态响应，并通过正常的渲染路径让现有内容可访问。

对于 Search Console 诊断，使用可用的检查工具查看已捕获页面和当前渲染页面。一次当前的成功访问无法展示早期抓取时遇到的情况。在内部调查中记录观察时间和部署环境，然后在报告更新后评估已修正的公共页面。

对于第三方采集，保留原始来源 URL 和捕获被拒绝的原因。 proxy connectivity testing workflow 为把网络传输检查与内容接收区分开来提供了上下文。 Scrapeless Agent Browser 可以提供渲染层； current Scrapeless plans 帮助你为此做预算，而不是假定每个 URL 都需要浏览器。

将资源含义视作成功的一部分

当响应与可见的资源状态相一致时，软 404 就被解决了。现有内容应作为正确的资源加载；移动的内容应指向其真正的替代；被移除的内容应传达缺失信息。仅仅增加页面长度或隐藏错误文本并不能证明资源存在。

对采集器而言，持久的结果是一个分类，它能区分已接收内容、有效空结果、缺失资源和未解决的捕获。为每个决策保留证据，这样来源的变更就不会悄然演变为数据丢失。