网站收录方法：改版或迁移时应核对什么
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3ec21b5e24ed.html
📄
网站收录方法：改版或迁移时应核对什么
改版或迁移时，核对的核心不是“新页面能不能打开”，而是旧地址是否把权重与用户完整交给新地址，新地址是否允许被抓取、被理解、被收录。交付时应把“收录结果”拆成可验收项：URL 映射、状态码、robots 与 meta 指令、站点地图、内链、规范链接、服务器可访问性。多人协作时，每一项都要有负责人、产出物和验收依据，否则最容易出现“开发认为已上线、SEO 认为还没完成”的返工。
先定交付物：一份可执行的 URL 映射表
改版迁移最常见的返工来源，是旧 URL 与新 URL 的对应关系只存在于口头或表格里，没人对最终跳转负责。交付物应是一张表，每行至少包含：旧 URL、新 URL、处理方式（301、410、保留）、负责人、验收状态。
- 有等价内容的页面，用 301 指向最相关的新页面，不要全部跳到首页。
- 已彻底删除且无替代内容的页面，可评估返回 410，而不是让它返回 200 的空白页。
- 参数页、分页、筛选页要单独列出，判断是保留、合并还是屏蔽抓取。
验收时抽查跳转链：旧地址应一次跳转到最终地址，而不是 301 跳 301 再跳 302。跳转链过长会稀释传递效果，也增加超时风险。
核对抓取与索引指令，别把两件事混为一谈
robots.txt 限制抓取，不等于可靠的索引移除。页面被 robots.txt 禁止抓取后，搜索引擎仍可能因为外链等信号将其收录，只是无法读取页面内容来判断。因此核对时要分清目标：
- 想阻止抓取：检查 robots.txt 对应路径规则。
- 想阻止索引：优先用页面级
<meta name="robots" content="noindex">，并确保该页面允许被抓取，否则 noindex 读不到。 - 想移除已收录页面：noindex 只是逐步生效的信号，不等于立即消失。
改版上线前，务必确认测试环境的“禁止收录”配置没有被打包进生产环境。常见事故是 staging 的 robots.txt 或全局 noindex 随代码一起发布，导致整站从索引中退出。
站点地图、内链与规范链接的验收方式
站点地图不保证收录，它的作用是帮助发现 URL，不能替代内链和跳转。核对项包括：
- 站点地图只包含返回 200 且允许被抓取的规范 URL，不含已 301 的旧地址、404 和 noindex 页面。
- 新页面能从首页或栏目页通过可抓取的
<a>链接到达，而不是只靠 JavaScript 点击事件。 - 每个页面有明确的 canonical，指向自身或正确的首选地址；改版后检查 canonical 是否仍指向旧域名。
- 旧域名与新域名不要互相 canonical，形成循环会让搜索引擎难以判断首选版本。
多人协作时，这几项适合做成上线检查清单，由开发、SEO、运维分别签字，而不是靠某个人凭记忆确认。
服务器与技术层的检查项
HTTPS 不保证安全无漏洞，也不保证排名。它只是核对项之一。技术层应确认：
- 新域名或新路径返回正确的状态码，不出现大量 5xx 或软 404（返回 200 的错误页）。
- 证书覆盖所有使用的子域名，且 HTTP 正确跳转到 HTTPS，不产生跳转环。
- 服务器日志能反映抓取情况，便于上线后观察旧地址与新地址的访问变化。
- 不同搜索引擎对指令和功能的支持情况须分别核查，不能假设一套配置对所有引擎等效。
判断是否“已经定位原因”还是“可能原因”很重要。例如流量下降可能是跳转配置错误，也可能是抓取延迟、内容改写或外链变化，不能只凭单一现象下结论。
上线后的核对与责任分工
上线不是终点。建议在迁移后按固定节奏核对：旧 URL 跳转是否仍生效、新 URL 是否被逐步发现、站点地图是否被读取、日志中是否出现异常状态码。每一项指定一名负责人，验收标准写成“可复现的检查结果”，例如“随机抽取 20 个旧 URL，全部一次 301 到对应新 URL，无 404 与跳转链”。
下一步：把上述核对项整理成一张迁移验收表，按 URL 映射、抓取索引指令、站点地图与内链、技术状态码四组分配负责人，上线前逐项确认，上线后按同一张表复查。
