主题
第 13 章 抓取与索引控制：让正确页面进入正确队列
13.1 页面能打开，为什么还是搜不到？
一篇文章已经发布，浏览器里也能正常打开，搜索引擎却迟迟没有收录。此时该检查服务器，修改 robots.txt，还是继续申请索引？如果还没分清问题发生在哪一步，这些操作很容易互相抵消。
本章沿着这个问题往下查：先看搜索引擎能否取得页面，再看网站有没有要求它排除页面，最后检查重复内容应该使用哪个地址。读完后，你应能为商品、文章、站内搜索和登录页面选择合适的控制方式，并找出 robots.txt、noindex、canonical、重定向与站点地图之间的冲突。
先把容易混在一起的三件事分开：
| 要问的问题 | 主要检查什么 | 通过后仍不能证明什么 |
|---|---|---|
| 访客能不能访问？ | 服务器响应、登录与权限 | 爬虫一定会来访问 |
| 爬虫能不能取得内容？ | 发现入口、抓取规则、服务器容量 | 页面一定会进入索引 |
| 页面是否被索引并展示？ | 索引指令、规范地址及搜索引擎的后续处理 | 某个关键词一定有好排名 |
例如，页面返回 200，也没有任何禁止标记，只说明技术障碍较少。搜索引擎是否选择收录，还需要继续观察。能够访问、允许索引、实际被索引，是三种不同的状态。
在动配置之前，先写下每类页面的用途。以假设的 Go 工具 SaaS 为例：公开工具介绍和帮助文章希望被找到；带用户输入的临时结果不希望公开；账户页必须登录；打印视图与原文相同，希望合并；旧文档被新地址替代，希望永久迁移。
这张“页面意图表”会决定后面选哪一种工具。否则，报告里所有“未索引”看起来都像故障，你可能花时间修复了本来就该排除的页面。
13.2 robots.txt：告诉爬虫哪些路径不要抓取
robots.txt 是站点根路径下的文本文件，例如 https://example.com/robots.txt。它向遵守协议的爬虫声明允许和禁止抓取的路径。Google 明确指出，禁止抓取的 URL 仍可能因为外部链接等信号出现在搜索结果中；因此，robots.txt 不等同于阻止索引，更不是访问鉴权。[D01] 协议本身由 RFC 9309 描述，它是一套爬虫应遵循的约定，不构成服务器访问控制。[D24]
以下是教学示范，未对真实站点执行或验证：
text
User-agent: *
Disallow: /internal-search/
Disallow: /temporary-export/
Sitemap: https://example.com/sitemap-index.xml这段规则有两个前提：站内搜索生成的组合没有独立搜索价值，临时导出文件也不需要被搜索引擎发现。在这两个前提成立时，可以告诉爬虫不要抓取这些路径。
但文件能否被别人下载，是另一个问题。假如导出文件包含客户数据，就要做身份验证、授权检查，并设置有效期。robots.txt 本身是公开可读的，把目录名写进去并不能保护它。
编写规则需要用具体 URL 逐条测试。/product/ 与 /products/ 不是同一段路径；查询参数顺序变化可能让过于简单的匹配漏掉地址；大小写、尾斜杠和编码也可能改变服务器解释。不要因为爬虫识别某个语法，就假定所有搜索引擎都相同。Google 专用规则、通配规则和其他爬虫规则要分别验收，无法核实支持情况的扩展字段不应作为关键控制。
Google 的具体匹配规则还需要记住几点：路径区分大小写，星号匹配零个或多个字符，美元符号限定结尾；同一适用规则组中，更具体的路径规则优先，同等具体程度发生冲突时采用较宽松规则。爬虫专用组也不能想当然地继承通配组的全部限制；Google 不支持 crawl-delay。[D47]
下面是独立的教学示范，未运行，不能与前一段配置不加检查地合并：
text
User-agent: *
Disallow: /archive/
Allow: /archive/public/
Disallow: /*?print=1$这份配置希望允许公开归档子目录，同时禁止其余归档路径，并匹配以指定打印参数结尾的地址。验收至少应比较 /archive/a、/archive/public/a、/a?print=1 与 /a?print=1&lang=zh。最后一个地址不能仅凭外观就假定命中带结尾限定的规则。这也是为什么测试应使用实际 URL 样本，而不能只检查文件看起来是否整齐。
规则写对了，还要确认部署出去的确实是这一份。测试环境的 Disallow: / 被带到正式站、发布脚本生成了空响应、CDN 缓存了另一主机的文件，都会让线上行为偏离你的预期。
因此，建议把 robots.txt 纳入版本控制，并在部署检查中明确断言“生产关键页面不得被屏蔽”。样本除了首页，还要包含商品、文章、图片和渲染所需脚本。只放行网页、却挡住核心脚本，仍可能让爬虫看不到完整内容。
robots.txt 本身的错误响应还会影响全站抓取：Google 将除 429 外的 4xx 视为没有该文件、没有抓取限制；遇到 5xx 则会先暂停抓取，之后的处理取决于已缓存规则、故障持续时间和站点可用性。不要把“文件打不开”理解成“全部禁止”，也不要把它与普通内容页的 404 混为一谈。[D47]
robots.txt 的作用范围应按实际协议、主机与端口核对。不要修改 www 主机后，就默认另一个子域已经同步。部署验收时列出所有对外主机，分别访问其根路径文件，记录响应码、内容、缓存头和检测时间。内容分发网络、反向代理和应用程序可能各自产生一个版本，浏览器看到的版本未必代表所有边缘节点。
13.3 noindex：要排除页面，先让爬虫读到指令
上一节的 robots.txt 控制抓取。假如一个页面仍然允许公众访问，只是不想让它出现在搜索结果里，就需要了解 noindex。它通常写在 HTML 的 robots 元标记，或 HTTP 的 X-Robots-Tag 响应头中，用来要求支持该指令的搜索引擎排除这个资源。
这里有一个很容易忽略的前提：爬虫必须先读到指令。如果你同时用 robots.txt 禁止抓取，爬虫便无法取得页面，也就看不到新加的 noindex。把 noindex 改写到 robots.txt 里也不行，Google 不支持这个字段。[D02]
以下两段是不同资源类型的教学示范，不是应同时复制到所有页面的模板：
html
<!-- 用于仍允许公开访问、但不希望进入索引的 HTML 页面 -->
<meta name="robots" content="noindex">text
HTTP/1.1 200 OK
Content-Type: application/pdf
X-Robots-Tag: noindex第一段通常放在 HTML 的 <head> 中，可用于没有搜索价值的公开筛选结果；Google 也会遵循正文中的 robots 元标记，因此排错时不能只搜 <head>。第二段的 X-Robots-Tag 是服务器实际发送的响应头，不能当作一行文字贴到 PDF 或网页正文里。[D26] 给公开价格手册加 noindex 与保护内部合同是不同需求。前者可能只是不希望它独立展示，后者应首先限制访问。
“我已经加了 index，怎么仍不收录？”先检查应用、CMS、代理和 CDN 是否共同发出了另一条 noindex。Google 对冲突的机器人指令采用更严格的有效规则；一个宽松标签并不会自动抵消另一个限制。[D26] 建议在审计中分别保存原始响应头、原始 HTML 和渲染后的 HTML，而不是只搜索模板文件。模板是意图，线上响应才是证据。
你可能还会看到与 noindex 并列出现的 nofollow。前者涉及当前资源是否索引，后者涉及页面中链接的处理。排除一张临时结果页，并不意味着一定要同时限制所有链接的处理。
页面入口也要单独考虑。重要内容如果只能从这张临时页面找到，就不宜长期依赖它作为唯一的发现路径。更稳妥的结构是从公开分类页或帮助中心提供清晰链接。
需要从搜索中移除已经公开的敏感信息时，不能只等一个标签慢慢生效。应先在源站切断未经授权的访问，检查缓存、共享链接和其他副本，再按相关搜索引擎的移除流程处理。索引控制的目标是搜索展现，数据泄露的目标是访问边界，不能混淆。
只限制摘要时，不必排除整页
若页面仍希望出现在搜索中，只是不想让某段公开文字进入摘要，可在相应的 span、div 或 section 上使用 data-nosnippet。nosnippet 则限制整页的文字摘要和视频预览，max-snippet:120 表达文字摘要最多 120 个字符；这些都不同于 noindex。[D26]
html
<!-- 可放在正文中的教学示例，内容仍对访客公开 -->
<p>查看部署步骤与适用版本。</p>
<div data-nosnippet>本段公开的活动说明不用于搜索文字摘要。</div>发布后检查实际 HTML，确认属性包住了正确范围，并允许 Google 再次抓取。它不隐藏页面内容，也不阻止他人复制；结构化数据中主动提供的信息还需另外检查，不能假定这些摘要设置会一并封住富结果字段。真正的私人信息应先限制访问，而不是使用摘要控制。
13.4 canonical：为重复内容选择代表地址
规范网址标记 canonical 用于表达重复或非常相似页面的首选地址。它是信号而非强制命令。Google 将重定向与 canonical 视为较强的规范化信号，将站点地图收录视为较弱信号；多个一致信号可以共同表达偏好。[D03] 教学示范如下：
html
<link rel="canonical" href="https://example.com/tools/json-format">这个 HTML 链接标签必须位于有效的 <head> 中。PDF 等非 HTML 资源可由服务器发送 Link: <https://example.com/preferred>; rel="canonical" 响应头表达首选地址；目标仍须是真正对应的重复内容，不能任意指定。[D03]
设想 /tools/json-format、/tools/json-format?utm_source=newsletter 和 /tools/json-format?view=compact 展示同一个工具、说明与示例，只是跟踪或排版不同，那么把后两者指向干净地址通常容易解释。相反，/tools/json-format 与 /tools/xml-format 是两种工具，即使布局一样，也不应为“集中权重”强行合并。
怎样判断两个地址是否适合合并？可以依次问：用户来完成的任务是否相同，主体内容是否基本相同，目标地址能否长期访问，站内导航是否也使用这个地址。标题相似，并不能替代这些检查。
鞋子的红色和蓝色变体就需要具体判断。如果它们各有图片、库存和搜索需求，独立索引可能有意义；如果只是同一内容的不同入口，情况又不同。决定应来自产品和内容，不能只看 URL 里有没有参数。
自引用 canonical 表示页面把自己的正式地址声明为首选。即使采用这种写法，也要检查生成结果：绝对地址、协议、主机、大小写和路径是否正确，有没有指向测试域名、404 页面、重定向中间站或被禁止索引的目标。
分页尤其容易被误合并。列表第二页装着另一批产品，与第一页的主体内容不同。仅仅因为担心“第二页抢排名”，就把它的 canonical 指向第一页，并不符合重复内容规范化的目的。
如果你确实不再需要旧地址，重定向通常比保留两页再规范化更贴合用户体验；如果两个地址都必须可访问，且内容确实近似，canonical 才更合适。不要同时向搜索引擎表达“请合并到甲”和“请删除乙”并假设必然按你的理想顺序执行。尤其是 noindex 与 canonical 混用，应回到业务目标选择清楚策略，而不是把所有控制叠加。
13.5 站点地图：列出希望被发现的正式地址
XML 站点地图 sitemap 是给搜索引擎提供 URL 及相关更新信息的机器可读目录。它有助发现，不保证抓取、索引或排名。Google 文档列出的单文件限制是未压缩体积不超过 50MB、URL 不超过 50,000；较大集合应拆分，并可由站点地图索引组织。Google 忽略 priority 与 changefreq 字段，因此不要为这两个数值耗费运营时间。[D04]
以下是教学示范，日期只是示例数据：
xml
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.com/guides/go-json</loc>
<lastmod>2026-10-01</lastmod>
</url>
</urlset>地图里的 URL 从哪里来，比文件写得多漂亮更重要。建议从已发布、允许索引的规范内容记录生成，而不要把数据库中每个路由都导出。为此，内容记录需要明确的发布状态、主 URL、更新时间和删除状态。
生成后先检查 XML 格式、绝对 URL、字符转义、重复项和文件大小，再抽样请求其中的线上地址。语法正确只能证明文件能被解析，不能证明它列出的页面真的可用；当然，也不必每次都重新抓取全站。
lastmod 应反映有意义的内容变化，而不是站点地图重建时间。假设一篇文章只被重新部署，正文和结构没有变化，不必伪装成今天更新；商品价格、库存或重要说明改变则应按实际生成机制判断。工程上最好让更新时间来自内容记录或明确的内容变更事件，避免由服务器当前时间统一覆盖。
拆分地图还可以服务诊断。内容站可按文章、栏目拆分；电商可按商品、品类拆分；多语言站可按语言或业务单元拆分。目的不是人为制造更多地图，而是让“哪类预期页面出现异常”更快可见。已经删除、重定向、明确 noindex 的 URL 若长期留在地图里，会使信号和审计口径互相矛盾。
文件准备好后，按下面的顺序发布并检查：
- 放到可公开读取的稳定地址，通常使用站点根目录。访问该地址，确认返回 XML，而非登录页或错误页。
- 在已验证的网站 Search Console 资源中打开“站点地图”报告，提交地图或地图索引的地址。也可以通过 robots.txt 中的
Sitemap:行告知位置。 - 查看上次读取时间、处理状态和具体错误。报告显示“成功”，说明地图处理成功，不能据此认定所有 URL 都已进入索引。[D04]
13.6 HTTP 状态码要表达真实业务状态
HTTP 状态码是服务器对一次请求的机器可读结果。工程师容易把“浏览器展示了好看的页面”等同于成功，但对客户端而言，200、301、404 和 503 的含义不同。RFC 9110 是 HTTP 语义的一手标准；在做重定向时，尤其要理解 307、308 保留请求方法等协议差异，而不能把 SEO 处理上的相近等同于协议完全相同。[D30]
选择状态码时，先描述资源实际发生了什么：
| 真实情况 | 响应应表达的含义 | 容易误做的地方 |
|---|---|---|
| 资源存在，正常提供正文 | 成功 | 仅凭模板能显示就认定内容正常 |
| 永久换了地址 | 永久重定向 | 新旧地址长期互相跳转 |
| 暂时换了地址 | 临时重定向 | 把临时安排当作永久迁移 |
| 没有这个资源 | 不存在 | 显示“找不到”，却仍返回成功 |
| 系统暂时无法提供服务 | 服务不可用 | 把数据库超时当成文章已删除 |
报表是否变绿，不应改变这些业务事实。
Google 对多数 4xx 响应不使用其内容，429 则作为过载信号处理；持续的 5xx 或 429 会影响抓取，长期故障也会影响索引。[D06] 因此，别用 403 当作通用抓取节流手段。若防火墙把正常爬虫误判为攻击，应定位规则、验证请求身份并恢复正常访问，而不是把所有拒绝响应改成空白 200。
软 404 是一种常见误配：服务器返回 200，但正文说明“页面不存在”，或只剩一个无实际内容的错误壳。它常出现在前端路由兜底、商品接口失败和错误的批量跳首页逻辑中。正确修复要区分资源不存在与请求暂时失败。数据库超时不代表文章被删除，直接返回永久不存在可能把一次系统故障转化成索引问题。
缺货商品也不一定该删除。如果商品会补货且页面仍提供型号、参数、说明和替代选择，可以维持真实的商品页并明确库存状态。永久停售且有明确等价替代时，可评估跳转；没有相关替代、没有继续保存价值时，再考虑返回不存在。不要把几千个完全不同的停售品全部跳到首页，因为首页通常不能完成原用户任务。
13.7 抓取预算：先证明存在瓶颈
抓取预算 crawl budget 可以理解为搜索引擎在站点上投入抓取的资源范围。Google 的说明将它与抓取容量限制和抓取需求联系起来，并强调这主要是大型或更新非常频繁站点的问题；文档中的规模数字只是粗略参考。[D05] 一个几十页的个人站没有收录，不应先寻找“提高预算秘籍”。先查是否有发现路径、是否允许访问、页面是否独特、是否选错规范地址。
如果你怀疑抓取资源被浪费，需要把两个现象联系起来：重要 URL 没有及时被访问，同时，可避免的请求或服务器容量问题确实占用了资源。只看到参数页出现在日志里，还不足以证明它们挤占了核心内容。
把请求日志、内容发布时间和期望更新时效放在一起看，才比较容易判断下一步：优化服务器、控制 URL 组合，还是改进页面价值与发现入口。即使没发现容量瓶颈，也仍可能是抓取需求偏低。[D05]
假设一个电商站有两万件商品，而颜色、尺码、排序、库存和每页数量可以自由组合，程序可能生成远多于两万个 URL。优化的重点是控制 URL 生成面：哪些筛选结果值得独立落地，哪些只服务站内操作，哪些组合根本无结果。只在最后给海量页面加 noindex，并不会消除访问这些页面以读取指令的成本。
还有一种瓶颈来自服务器。若每次访问列表都实时查询昂贵聚合，爬虫和用户同时进入时会相互争用资源。可考虑缓存公开结果、预计算稳定列表、优化数据库查询与压缩响应。然而速度改善不会自动制造搜索需求；日志证明抓取变快，只说明传输环节改善，需要继续观察重要页面是否更及时更新。
不要为了“每天都有新东西”批量改标题或更新时间。这样的策略增加版本噪声，也让运营难以判断真正内容变化。先把新增、更新、删除这三个事件做准，再让内部链接与站点地图反映事件，通常比制造虚假更新更易维护。
13.8 把多个控制合起来检查
现在回到开头的“页面意图表”。单个设置已经清楚，组合时就按目的核对：
| 页面目的 | 组合检查 | 关键冲突 |
|---|---|---|
| 公开并希望索引 | 允许访问、正文正确、无 noindex、规范信号一致 | 一边申请索引，一边发出排除指令 |
| 公开可用，但不希望索引 | 让爬虫能够读取 noindex | 用 robots.txt 挡住读取指令的请求 |
| 合并重复内容 | 代表地址可用，内链、地图、canonical 指向一致 | 各个信号选择了不同代表地址 |
| 保密 | 实施身份验证与授权 | 误把抓取或索引控制当作访问控制 |
下面用三个假设故障，把这些检查串成实际排查过程。
第一个案例是响应头里残留了排除指令。假设文章 /guides/go-errors 两周没有进入索引，编辑已经反复点了申请索引。首先保存具体 URL 和发布时间，不要只说“新文章都不收录”。访问线上页面，发现浏览器显示正常，GET 请求返回 200。接着查看 HTML 也没有 noindex，但响应头中存在 X-Robots-Tag: noindex。进一步对比同模板旧文章，只有新的 /guides/ 路径带这个头。
此时合理假设是路径级代理配置，而非文章写作质量。检查发布变更后发现，测试环境的响应头规则被复制到新路由。修复应在产生响应头的组件中移除错误规则，清理相关缓存，并重新请求同一路径和相邻路径。验收不能只看模板差异，因为最初错误就不在模板里。待实际响应正确后，再通过搜索工具核对最近抓取时间与索引状态，不能把“代码已合并”写成“索引已恢复”。
第二个案例是规范地址错误。假设五十篇文章都声明首页为 canonical。先抽取各文章主体，确认它们并非首页副本；再检查模板的 canonical 字段是否为空时回退到站点首页。合理修复是使用各内容记录的正式 URL，并为缺失字段报错，而不是静默回退。随后验证所有受影响模板，特别是语言版本、分页页与预览页，防止只修复一个样本。
第三个案例涉及 robots.txt 与 noindex。某筛选页已被索引，团队先禁止抓取，再添加 noindex，几周后仍看到 URL。这里不应继续加更多标签。先确认该页确实不需要保密，才允许抓取以便读取排除指令；如果涉及隐私，则优先封闭访问并使用适当移除渠道。处理顺序来自目标，不能脱离内容性质套一条万能流程。
交互实验：抓取与索引信号
SEO 实验室 · 抓取与索引信号
配置了，不等于爬虫读到了
先禁止抓取，再加 noindex，能让页面从搜索结果消失吗？亲手改一项设置，沿着证据找答案。
学习目标：分清页面设置、爬虫读到的信号和真实索引状态。这是有限教学案例，不会请求真实网站，也不预测收录。
01 选择一个起点
切换案例会重新演练标签写了，但抓取入口被挡住。
只放开抓取，观察 noindex 能否被读到。
正常公开页面，也不等于已经收录。
声明原文偏好，最终选择仍待验证。
03 过程 · 逐步取证
每次只推进一步，看哪些信息真正变成了证据。
步骤 0 / 4准备开始
- 设置当前
- 发现待检查
- 抓取尝试待检查
- 读取信号待检查
- 判断边界待检查
先预测：你配置的信号，爬虫这次能读到哪些？逐步按钮只推进这个假设案例，不请求任何真实网站。
到这一步，实际取得了什么？
未读取的设置，不计入已知证据。
- 已知 URL
- 尚未进入发现步骤
- 抓取许可
- 尚未检查
- 实际取得的 HTTP 状态
- 尚未请求
- noindex
- 尚未检查
- canonical
- 尚未检查
- Google 选定的规范版本
- 未知，本实验不作选择
- 真实索引状态
- 未知，需核对实际记录
04 结果 · 证据能说明什么
走完取证步骤后，这里会给出本次判断，以及还需要核对的证据。
记住这三个区别
robots.txt 管抓取；noindex 要先被读到，才表达排除索引的要求；canonical 为重复页面表达首选地址。正常返回 200、没有禁止标记，仍不保证收录。
动手比较：只改一项，为什么结果就变了？
- 只放开抓取。先用默认“拦抓＋noindex”走到最后，再把抓取许可改成“允许”。noindex 没变，变化的是爬虫终于能读到它。修改设置会暂停播放并从头开始。
- 比较两个标签。选“重复版本指向原文”，走到最后。规范版本为什么仍是未知？因为 canonical 只是偏好。再勾选 noindex，观察两种不同目的的设置。
- 区分两类错误。把 HTTP 从 200 改成 503，再改成 404。暂时服务故障与资源不存在，需要不同的修复证据。
前提与不模拟的部分
假设 URL 已被发现，robots.txt 文件有效且适用规则已经解析，允许抓取时安排这一次假设请求。200 表示真实、完整、受支持格式的公开 HTML，不是软 404。noindex 与 canonical 均在有效 HTML 中，不依赖 JavaScript。
步骤顺序只用于解释依赖，不代表搜索引擎内部严格串行运行。本实验不解析 robots 路径、请求头冲突、重定向、登录、缓存、渲染、站点地图、抓取预算、内容质量或历史状态。真实系统可能重试、并行或使用旧记录；“已读取”只描述案例，不代表线上验证。
robots.txt 与 noindex 都不保护私人内容。需要保密时，应先设置身份验证与访问控制，不应为了让爬虫读标签而公开敏感资料。
机制依据：Google 官方文档
- robots.txt：拦抓后 URL 仍可能出现
- noindex：必须可访问并读到规则
- 规范网址选择：偏好不是指令；canonical 与 noindex 的用途区别
- 200、404 与 503 的处理边界
- 技术资格不保证索引；URL 检查与实时测试的区别
文档核对：2026-10-14。步骤与预设为教学案例，不是 Google 内部算法。
13.9 可复制的检查流程与验收口径
下面的命令只示范获取证据的方法，未在示例域名执行。真实使用前应替换成自己有权测试的站点，并控制请求速率。
bash
# 使用 GET 获取响应头与正文，避免只看 HEAD 的特殊行为。
curl --compressed -sS -D headers.txt \
-o page.html 'https://example.com/guides/go-errors'
# 检查状态链；此命令会跟随重定向。
curl --compressed -sS -L -D chain.txt \
-o final.html 'https://example.com/old-guide'
# 初步查找；复杂 HTML 应使用解析器继续验证。
grep -iE 'x-robots-tag|location|content-type' headers.txt
grep -iE 'canonical|name="robots"|name="googlebot"' page.html命令结果只能证明这次请求的响应。若涉及地区、移动设备、CDN 缓存或登录态，需要增加对应样本，并记录每次请求条件。搜索引擎工具看到的结果还可能来自过去抓取。URL 检查工具的索引视图与实时测试是两类证据，实时测试通过不保证最终索引，也不能预测最终规范选择。[D28]
修复之后，验收也要分清层次。首先确认线上响应和模板已经符合设计；再确认搜索引擎能取得正确内容；最后观察页面是否进入索引，以及系统实际选择了哪个规范地址。
前面的技术修复可以较快检查，索引变化则需要等待再抓取和后续处理。此时报告“已修复，待重新处理”就足够准确，不必给出没有证据的恢复日期。
对于批量修复，建立固定样本集比临时挑好看的页面更可靠。样本应包括最重要页面、随机页面、边界情况和曾经失败的页面。每个样本保存 URL、期望状态、期望 canonical、期望索引规则、发现入口及检查时间。只要路由、缓存、渲染或 CMS 插件变更，就复用这组样本做回归检查。
练习与参考解答
练习一：保留访问，排除搜索。 一个公开活动归档页仍要让老用户打开，但不希望出现在搜索结果中。它已经被 robots.txt 禁止抓取。直接加 noindex，工作就结束了吗？
参考解答：还没有。先确认页面没有隐私需求，再让爬虫能够读取 noindex，并观察后续处理。如果只是禁止抓取，不能推断已有索引会消失。
练习二：地图很大，内容却不对。 站点地图有十万个 URL，其中一半是重定向旧地址。先提高 priority，还是重建数据源？
参考解答：重建数据源，导出预期索引的规范地址，再按体积和条数限制拆分。修改 priority 不能纠正 URL 集合。
练习三：排序与分页能一起合并吗？ 价格排序页与默认分类页包含相同商品，只是顺序不同；第二页则包含另一批商品。这些页面的 canonical 是否都应指向分类首页？
参考解答：不能一起处理。排序变体可以评估合并；第二页包含不同内容，需要独立判断，并提供可抓取的分页链接。
执行清单
- 给每类页面写明公开、索引、重复合并、删除和保密需求。
- 同时检查 robots.txt、响应码、响应头、原始 HTML 和渲染结果。
- 让内部链接、canonical 与站点地图采用一致的正式地址。
- 保留修复前后的证据、发布版本和搜索引擎最近抓取时间。
- 分别报告技术修复完成、抓取恢复与索引变化，避免把三者混为一谈。
本章参考来源
[D01] Introduction to robots.txt | https://developers.google.com/search/docs/crawling-indexing/robots/intro | 访问 2026-10-13 | 抓取限制与索引、安全边界的区别。 [D02] Block Search indexing with noindex | https://developers.google.com/search/docs/crawling-indexing/block-indexing | 访问 2026-10-13 | noindex 的实现与可访问前提。 [D03] How to specify a canonical URL | https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls | 访问 2026-10-13 | 规范化信号及其相对性质。 [D04] Build and submit a sitemap | https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap | 访问 2026-10-13 | 地图限制、地址与更新字段。 [D05] Optimize your crawl budget | https://developers.google.com/crawling/docs/crawl-budget | 访问 2026-10-13 | 预算适用范围与资源机制。 [D06] How HTTP status codes affect Google's crawlers | https://developers.google.com/crawling/docs/troubleshooting/http-status-codes | 访问 2026-10-13 | 错误状态和抓取处理。 [D24] RFC 9309: Robots Exclusion Protocol | https://www.rfc-editor.org/rfc/rfc9309.html | 访问 2026-10-13 | robots 协议边界。 [D26] Robots meta tag and X-Robots-Tag specifications | https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag | 访问 2026-10-13 | 索引与摘要指令、正文robots元标记、响应头、data-nosnippet与结构化数据边界。 [D28] URL Inspection tool | https://support.google.com/webmasters/answer/9012289?hl=en | 访问 2026-10-13 | 索引视图与实时测试的区别。 [D30] RFC 9110: HTTP Semantics | https://www.rfc-editor.org/rfc/rfc9110.html | 访问 2026-10-13 | HTTP 与重定向的协议语义。
[D47] How Google interprets the robots.txt specification | https://developers.google.com/crawling/docs/robots-txt/robots-txt-spec | 访问 2026-10-13 | 路径匹配、规则组与不受支持字段。