第 18 章以 Google 为基准理解搜索引擎与站长工具

18.1 学习目标：知道该向谁提交，又该相信哪一层证据

本章主要教你用 Google Search Console 建立一套能重复执行的发现、索引与诊断流程，再理解 Bing、百度及其他引擎有哪些不能照搬的地方。学完以后，你应当能够判断一个工具显示的“成功”究竟是提交成功、抓取成功，还是已经进入索引；能选择适合业务的引擎；能在官方资料不足时保留未知，而不是用旧经验补造最新规则。

先拆开一个常见想法：“网站做好以后，把网址提交给搜索引擎就行。”搜索引擎需要先发现 URL，再决定何时抓取、如何处理内容、是否纳入索引，最后根据具体查询决定展现。提交最多帮助前面某些环节，不会自动完成后面所有判断。即使两个平台都把按钮叫作提交，它们接收的数据、适用内容和反馈含义也可能不同。

对以 Google 为主要目标的站点，优先把 Google 的观察链条做完整。你需要可靠的公开页面、可抓取的导航、准确的站点地图，以及能查看索引与表现的工具。等这些基础能够解释问题，再为其他引擎补充专用接口。否则每增加一个后台，只会增加截图数量，不能增加判断能力。

18.2 Google Search Console 的作用和边界

Search Console 是 Google 提供的搜索表现与问题检查工具。网站不需要先加入这个工具才有资格出现在 Google 搜索中；它的价值在于让管理者了解 Google 如何发现和处理自己的站点。[E33] 因此，验证成功不等于取得排名许可，看到绿色状态也不等于商业增长。

建议把它当作一组不同用途的观察窗口。效果报告回答搜索中发生了哪些展现和点击；页面索引报告解释一批 URL 的处理状态；URL 检查回答某个具体页面的情况；安全问题和手动处置报告处理另外的风险。窗口之间有关联，但不是同一个数据库的实时镜像，也不能随意拿总数互相相减。

例如，一个教程今天发布，站内分析已经有朋友访问，但 Search Console 还没有查询数据。这并不矛盾：直接访问不是搜索点击，工具报表也可能有处理延迟。又如，一个商品页有展现却没有站内会话，可能涉及不同统计口径、同意机制或页面加载问题。先核对时间区间、页面地址和渠道，才能解释差异。

Search Console 也不替代服务器日志。日志能够告诉你服务端收到了什么请求、返回了什么状态；搜索工具能够告诉你搜索系统报告的处理结果。浏览器检查则告诉你人看到的页面。三者放在一起，才有机会发现“服务器返回成功，但页面主体加载失败”这种单一仪表盘无法解释的问题。

18.3 先把资产和权限建对

Google 的网站资产主要包括网域资产与网址前缀资产。网域资产覆盖相应域名范围内的协议和子域，通常通过 DNS 证明控制权；网址前缀资产则按输入的协议、主机和路径范围限定。[E30] 你应先决定想观察的范围，再选择验证方式，而不是看到哪个按钮简单就点哪个。

假设正式站点是 https://example.com，开发文档位于 docs.example.com，旧站仍有 http 地址。只验证 https://example.com/ 的前缀，并不能自动让这个前缀报告代表所有子域和协议。相反，一个大型组织即使拥有网域资产，也可能另外建立路径级观察范围，方便不同团队查看自己负责的内容。两种观察需求可以并存。

域名所有权应保留在组织能够长期管理的账户中。不要让离职员工、外包公司或临时搭建者成为唯一知道验证方式的人。Google 区分所有者和不同级别的用户权限。[E34] 工程管理上，应给协作者完成任务所需的最小权限，并记录谁负责移交、撤销和检查验证令牌。这里的建议是资产治理，不表示授予更多权限会提高排名。

验证文件和 DNS 记录需要进入运维清单。网站换托管商时，团队经常只迁移业务记录，忘记工具验证。这样网页仍能访问，但关键人员可能无法继续查看报告。迁移检查应包含域名、证书、分析工具和站长资产，而不是只确认首页能打开。

实际操作时应确认域名属于你或已获授权，避免把不相关网站加入账户，也不要向不明所谓“收录服务”提供管理员权限或私钥。检查搜索表现不需要把整个生产系统的控制权交出去。

18.4 用一个 URL 建立完整的观察链条

Google 的 URL 检查工具既可以显示已索引版本的信息，也可以发起实时测试。两者回答的问题不同：前者反映 Google 已处理的版本，后者检查当前页面的一部分可访问与索引条件；实时通过并不保证最终进入索引或展现。[E31]

可以拿安装教程作为练习。先输入你希望用户最终访问的正式地址，保存检查日期、Google 报告的规范网址、抓取时间和索引结论。然后在浏览器打开同一个 URL，确认最终落点、页面正文和语言。最后在服务端检查相应路径的响应与重定向规则。不要输入了一个带追踪参数的分享地址，却拿干净地址的截图来比较。

假设报告显示的抓取时间早于你昨晚的修复，那份索引信息就不能证明修复失败。你可以用实时测试检查现状，再等待搜索系统重新处理。反过来，实时测试成功也不能抹掉历史问题：如果很多重要页面长期没有被发现，你仍需修复导航与站点地图，而不是只测试一个幸运页面。

对于 JavaScript 页面，检查不能停在 HTTP 200。看抓取和渲染后的正文是否包含产品名称、主要说明和有效链接；确认不是只有加载动画或登录提示。不同测试工具可能使用不同环境，失败时保存具体响应和资源错误，交给工程人员定位。笼统写“SEO 分数低”无法转化成可执行修复。

报告中的规范网址尤其值得看。用户声明的 canonical 和 Google 选择的 canonical 不一致时，先检查页面相似度、内部链接、重定向和站点地图，而不要认定平台出错。若你的页面实际是同一商品的参数副本，被合并可能是合理结果。若中文和英语真实版本被错误合并，则需要回到语言内容与信号一致性的排查。

18.5 索引报告怎样变成待办事项

页面索引报告会展示未索引原因，但未索引并不全部是错误。Google 的帮助资料明确区分应当进入索引的页面与有意排除的页面，并提醒站点不需要让所有已发现 URL 都被索引。[E32] 购物车、站内搜索、筛选参数、废弃内容和重复地址，都可能不应成为独立搜索入口。

因此先建立“预期可索引集合”。它可以来自内容数据库中已发布、公开、规范且有独立价值的页面，而不是从服务器曾经返回过的所有路径生成。然后把搜索报告与这个集合比较。只有你希望索引的页面受影响，或者排除策略本身有问题，才产生待办。

这里有一个假设例子：网站生成了一千个 URL，其中三百个是正式教程和产品页，七百个是排序和筛选组合。报告显示只有二百八十个已索引，不能立即得出“收录率只有百分之二十八，网站很差”。首先应查那二十个预期页面，另外七百个是否被合理处理。如果把无价值组合全部开放索引，数字可能变好看，搜索体验反而变差。

处理待办时按照原因合并。三十个页面的错误如果都来自同一模板误加 noindex，应修模板并验证代表页；只有一个页面因内容删空而返回软错误，就单独处理内容和状态码。优先级同时考虑业务重要性、影响范围和修复成本。刚改版的定价页无法访问，通常比多年无人使用的标签页更值得先查。

不要把报告标签当成完整病因。某个页面被发现却未处理，你可以检查站内连接、服务器稳定性和内容价值，但不能仅凭标签宣布“Google 惩罚了我”。判断严重处罚应有相应证据；对普通索引选择，保留多个解释，并逐步排除。

18.6 Google 的提交渠道及其限制

对于少量新建或重要修订页面，可以使用 URL 检查中的请求方式；对于大量 URL，应维护站点地图。Google 明确说明请求抓取不保证立即或最终进入搜索结果，对同一地址反复请求也不会因此更快。[E07] 所以提交动作应该是发布流程的补充，不应成为每天手动刷按钮的工作。

一个实用流程是：内容发布后先执行页面测试，通过后更新站点地图与站内导航；对于少数紧急、重要且已修复的页面，再使用相应请求工具；之后记录状态，等到有新的抓取或报告证据再判断。若页面仍被访问控制挡住，提交再多次也不会代替修复。

还要区别 Search Console API、URL 检查 API 和 Indexing API。名称中有 indexing，不代表它是普通文章的万能入库接口。Google 当前文档把 Indexing API 的内容范围限定为带 JobPosting 的招聘页，以及在 VideoObject 内嵌 BroadcastEvent 的直播视频页，并要求按其流程使用。[E08] 普通博客、SaaS 功能页或电商分类页不能因为想更快收录，就伪装成招聘或直播。

如果服务商声称“我们有 Google 官方接口，可以强制收录所有页面”，要求对方给出接口文档、适用内容、响应含义和验证方法。成功接收请求与成功索引的差别必须写进验收标准。避免购买无法核验的所谓内部通道，也不要为了测试接口而提交客户私有地址、预览链接或含令牌的 URL。

18.7 Bing 与 IndexNow：通知变化，不承诺排名

当 Google 的基础流程稳定以后，再考虑 Bing Webmaster Tools。Bing 官方指南强调可发现链接、站点地图、内容清晰度和索引基础，并把这些基础与其不同搜索体验联系起来。[E09] 本次研究中，这个帮助页面的直接打开只返回需要 JavaScript 的提示，相关概述来自官方域名搜索结果；因此不据此声称核验了账户里的全部现行功能。

能够完整读取的 IndexNow 协议给出了更明确的证据。它允许网站向参与引擎通知新增、修改和删除的 URL；成功响应代表收到通知，参与者之间可共享提交数据。[E10] 它不是 Google 的通用提交接口，也不是所有搜索引擎都自动支持的互联网标准入口。实际接入前应核对当前参与者与自己的平台实现。

对于会编程的读者，合理的接入点是内容状态变化事件。教程发布、商品页面重要信息变化、页面删除，都可以产生一条通知任务。任务进入队列后，进行主机校验、地址规范化、去重和有限重试，再记录响应。不要把每次用户浏览页面都当成内容更新，也不要在队列故障后无限高速重发。

Bing 的接入说明提供了密钥文件验证和提交操作路径。[E11] 在工程设计中，应由受控发布流程维护相关文件，并让开发者知道它证明哪一个主机的控制权。不要把第三方地址混入本站批量请求，也不要假设根域验证一定覆盖所有不同主机。对响应的分类应遵循当下协议，不要把任意二百段响应都翻译成“已收录”。

删除也值得通知，但源页面仍需正确处理。假设一个产品永久下架且没有替代品，网站应提供合适的状态和用户说明；通知服务只能帮助引擎知道发生变化。它不能让仍公开返回旧商品的页面凭空消失。对于暂时缺货，是否保留页面应依据真实业务，而不是为了减少通知数量。

IndexNow 的常见问题页面也说明提交和抓取、索引之间没有保证关系。[E29] 接入验收因此要分两层：技术层验证通知被正确发送和接收；搜索层观察相关页面是否被重新处理。两层都值得监测，但不能互相冒充。

18.8 百度：知道哪些资料没有被核验

如果你的产品实际服务中国大陆用户，百度可能是需要评估的渠道之一，但投入程度应由目标客户和实际转化决定。本章不引用未经核验的市场份额，也不把所有中文搜索需求都归给单一引擎。中文内容可以面向许多地区，同一个地区的用户也可能使用不同搜索入口。

本次检索找到百度官方搜索资源平台，以及发布于二〇二〇年的工具说明。官方搜索结果提及主动提交、站点地图和抓取工具，并说明提交不能保证收录或展现。[E12] 但平台首页打开超时，旧文章跳转到新的官方地址后无法读取正文。这些情况必须与“已经登录并核验现行后台”区分开。

所以，本章不提供假定仍有效的百度配额、申请资格、接口参数或按钮位置。需要执行时，应由有权限的站长打开当前官方后台，核对域名验证、可用提交方式、状态码、配额说明和规则日期。若某项历史功能已移除，就把它从发布流程中撤掉，而不是到第三方博客寻找所谓绕过方式。

可以跨引擎保留的工作主要是页面质量、可访问性、真实导航和清晰内容。不能直接移植的则是具体工具权益、结构化展示资格和页面处理细则。即便两个引擎都使用站点地图，也应分别核对当前支持范围。官方内容读不到时，最专业的写法是说明缺口，并告诉执行者如何补齐证据。

18.9 其他引擎只在用户确实需要时进入计划

DuckDuckGo 官方说明，它组合多种来源，并拥有自己的抓取器和索引；传统链接和图片很大部分来自 Bing。[E13] 由此可以推断，Bing 的基础可发现性值得关注，但不能推断两个产品每次结果完全相同，也不能把 DuckDuckGo 简化成没有自身处理的镜像。评估时仍要看用户实际进入的页面和来源。

Naver 提供 Search Advisor，官方抓取请求说明把提交视为向抓取系统传递线索，抓取成功也不保证搜索展现。[E14] 它还提供 RSS 与站点地图说明。[E15] 如果目标客户确实使用韩语相关搜索渠道，可以把这套工具纳入研究；不能仅因为上线韩语译文，就自动承诺某种平台曝光。

Yandex 官方网站地区说明提供了地区设置和相关信息来源，并说明地区并非排除其他地区展现的绝对边界。[E16] 这与“同一配置在所有引擎含义相同”的想象不同。若产品有明确的相应用户，应阅读它自己的当前文档，并验证地区与页面内容匹配；不应从 Google 的规则直接推导它的细节。

还有很多垂直入口，例如地图、视频平台、商品搜索与专业社区。它们有时带来与搜索相似的发现过程，但账户资格、内容形式和排序机制各不相同。对于小团队，先问“目标客户用它完成什么任务”“我们能提供什么可靠内容”“能否衡量结果”，再决定是否维护。开了很多账号却没有负责人，并不等于建立了分发能力。

18.10 不同引擎的数据不能直接比赛

假设 Google 显示五万次展现，另一个平台显示五千次，不能据此说前者对你的网站重视十倍。不同产品的页面形式、展现定义、地域覆盖和数据保留可能不同。正确比较应落到同一业务结果，例如合格询盘、成功安装或完成购买，并保留各自的统计限制。

先统一页面和时间。把重定向后的规范地址作为分析维度，记录统计区间的时区，区分品牌查询与非品牌查询，再根据语言和地区拆分。对于多语言 SaaS，英文安装文档可能获得很多学习型访问，而中文定价页获得少量高意向访问；简单比较点击总数会误判内容价值。

如果需要估计市场机会，可以使用有方法说明的第三方数据作为线索，但要写明国家、设备、时间和样本来源。全球总份额不能直接代表你的专业客户群，桌面数据不能自动代表移动使用，浏览器统计也不能覆盖所有应用内搜索。本章不提供市场份额数字，避免给一张会快速过期且可能与读者无关的排行榜。

排名检查也必须保持条件一致。固定查询、语言、地区、设备和观察日期，记录搜索结果中的不同模块。手工搜索是排查线索，不是普遍真相。个人登录状态和位置可能影响看到的内容，单次观察更不应被当成惩罚证据。若使用第三方排名工具，应先理解它如何模拟位置、如何计算不同结果类型。

最有用的比较往往不是“哪家引擎好”，而是“哪一种页面在什么入口完成了什么任务”。一个技术教程可能吸引研究者，一个本地位置页可能产生电话，一个商品页可能带来购买。引擎策略应跟着这些任务走，不能只追求仪表盘数字都上涨。

18.11 原创案例：同一站点为什么在两个引擎表现不同

设想一个假设工具站，有三十个公开教程、一个价格页和大量需要登录的个人报告。团队发现 Google 能看到多数教程，Bing 的一些 URL 尚未展现。第一反应不应是再造一套关键词页面，而是检查两者是否面对相同的公开内容。

团队先从内部发布清单抽出正式教程，核对站点地图、导航链接和状态码。发现十篇教程只从个人仪表盘链接，普通访问者需要登录才看见入口。此时，修复公开文档导航属于共同基础；Google 已发现部分页面并不能证明导航没有问题，它可能通过其他链接找到过这些地址。

之后分别查看工具反馈。Google 某篇页面的已索引信息仍指向旧版路径；Bing 的通知队列则因主机校验错误没有发送。一个问题需要修复迁移映射和等待重新处理，另一个需要修复提交实现。它们不能合并成“引擎算法偏好不同”。只有排除了可访问性、发现路径、索引资格和明显配置差异，才值得讨论内容选择与排序差异。

接着检查业务结果。即使一个引擎点击较少，也可能吸引更符合产品条件的用户。团队应观察真实安装与使用，而不是急着改写所有标题迎合一个未经证实的偏好。对于小样本，只记录线索，继续积累数据；不以几次转化构造“某引擎用户更有购买力”的地区或人群结论。

这个案例的交付物不是一张漂亮对比图，而是一份可复查记录：预期页面集合、各平台检查时间、抓取证据、修复动作和后续状态。下一次出现问题时，团队能从记录判断到底是旧问题复发，还是新的内容或平台变化。

18.12 练习与工具使用清单

练习一：你提交了一百个页面，接口全部返回成功，服务商据此宣布收录率百分之百。哪里有问题？参考解答是验收层级错误。先核实响应代表接收、验证还是处理，再用相关站长工具检查索引状态。即使页面进入索引，也不能推导必有展现、点击和转化。

练习二：Google 报告大量未索引 URL，但大部分是排序参数页。是否应该全部请求索引？应先定义预期索引集合；没有独立搜索价值的组合不应为了降低报表数字而开放。把有限的检查时间用于真正重要却受阻的页面。

练习三：一篇旧博客说某引擎每天可提交固定数量地址，当前官方后台找不到对应功能。参考解答是把旧文列为待核验线索，核对官方日期和当前账户能力；不能把旧限额写进新系统，更不能据此购买声称拥有特殊权益的服务。

开始维护一个站点时，按这个顺序检查：确认域名与资产控制权；确认公开页面和正式 URL 集合；建立 Google 的索引与效果基线；检查关键页面实际响应；再配置适合内容的提交方式；最后按目标客户需要增加其他平台。每个账号保留负责人，每条自动提交记录保存响应含义，每个结论留下可回到的证据。这样工具越多，判断仍然能够保持清楚。

本章参考来源

第 18 章 以 Google 为基准理解搜索引擎与站长工具 ​

18.1 学习目标：知道该向谁提交，又该相信哪一层证据 ​

18.2 Google Search Console 的作用和边界 ​

18.3 先把资产和权限建对 ​

18.4 用一个 URL 建立完整的观察链条 ​

18.5 索引报告怎样变成待办事项 ​

18.6 Google 的提交渠道及其限制 ​

18.7 Bing 与 IndexNow：通知变化，不承诺排名 ​

18.8 百度：知道哪些资料没有被核验 ​

18.9 其他引擎只在用户确实需要时进入计划 ​

18.10 不同引擎的数据不能直接比赛 ​

18.11 原创案例：同一站点为什么在两个引擎表现不同 ​

18.12 练习与工具使用清单 ​

本章参考来源 ​