📍 WDQWDWQD987AAAAA:216.73.216.72
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e94f88e39e28.html
📄

网站收录改版或迁移时应核对什么：交付前把资料、责任和验收一次对齐

改版或迁移时，与网站收录有关的核对目标不是“新站上线”本身，而是确保旧地址能顺利交接到新地址、搜索引擎能发现并抓取新页面、旧链接不会把用户和爬虫带进死胡同。多人协作下，最稳妥的做法是从交付结果倒推：先明确上线后要拿到哪些可验证的结果，再分配资料、任务、责任和验收项。

先定义交付结果：收录交接要看到什么

不要用“改版完成”作为交付标准，它无法验收。可以把它拆成四个可检查的结果：

• 旧地址到新地址的对应关系完整，且每条重要旧链接都有明确去向。
• 新页面可以被抓取：robots.txt 没有误封，页面没有错误的 noindex，关键内容不依赖必须点击才加载。
• 搜索引擎能发现新地址：内部链接、站点地图和提交入口指向新结构，而不是仍指向旧路径。
• 线上验证通过：随机抽取旧链接和新链接，实际访问后返回预期状态码和内容。

这四项就是验收依据。它们不保证一定被收录，因为收录还取决于抓取预算、内容质量和搜索引擎自身的判断，但缺少任何一项，收录交接都会出现明显漏洞。

从结果倒推需要的资料和任务

多人协作最容易返工的地方，是开发、内容、SEO 和运维各自以为对方手里有完整信息。建议在动工前就建立一张迁移对照表，至少包含：

1. 旧 URL 清单：从站点地图、服务器日志、内部链接和外部链接中汇总，而不是只取导航里的页面。
2. 新 URL 映射：每条旧 URL 对应一个最终新 URL；没有对应页面的，标明是 301 到相关页面还是返回 410。
3. 责任人与完成时间：谁负责填映射、谁负责配置跳转、谁负责检查 robots.txt 和 noindex、谁负责上线后抽查。
4. 验收记录：抽查了哪些 URL、返回什么状态码、内容是否匹配、由谁确认。

如果同一批 URL 由多人维护，映射表要有唯一负责人汇总，否则很容易出现两条旧链接指向同一个新页面、或部分链接被遗漏的情况。

上线前后必须逐项核对的检查点

以下检查项按顺序执行，适用条件是站点结构发生实质变化，包括域名更换、目录调整、页面合并或 CMS 替换。若只是局部改版，可以缩小范围，但逻辑不变。

• 跳转状态码：旧地址应返回 301 永久跳转，而不是 302 或 JavaScript 跳转。用命令行或浏览器开发者工具查看响应头即可确认。
• 跳转链：避免 A 跳 B、B 再跳 C 的多级跳转，尽量一步到位。
• robots.txt：确认没有误封新目录。注意，robots.txt 只是抓取限制，不等于可靠的索引移除；要阻止页面被索引，应使用 noindex 并确保页面可被抓取。
• noindex 标签：测试环境常用的 noindex 必须在上线前移除，否则页面不会被收录。
• 站点地图：只放最终可访问的新 URL，并提交到对应搜索引擎。站点地图不保证收录，它只是发现渠道之一。
• 内部链接：导航、面包屑、正文链接都应指向新地址，不能继续指向旧地址再靠跳转兜底。
• HTTPS 与证书：确认证书覆盖所有域名变体。HTTPS 不保证安全无漏洞，也不保证排名，但它属于基础可访问条件。
• 不同搜索引擎分别核查：各搜索引擎对跳转、站点地图和提交入口的支持情况不同，应分别用其官方工具或抓取测试确认，不能只看一家。

假设一个例子：某旧页面 /old-a 计划合并到 /new-b。验收时应实际访问 /old-a，确认返回 301 且 Location 指向 /new-b；再访问 /new-b，确认返回 200、内容与预期一致、页面没有 noindex。如果返回 404、302 或跳转到无关页面，就说明映射或配置未通过。

用抽查代替全量承诺

上线后不可能逐条人工确认成千上万条 URL，但可以按类型抽查：首页和主要栏目、流量较高的旧页面、近期被外部链接引用的页面、以及映射表中被标记为“合并”或“删除”的页面。每类抽若干条，记录状态码和最终落地页。若抽查发现同类问题反复出现，应回到映射表整体修正，而不是逐条打补丁。

判断是否完成交接，可以看三个信号：旧链接不再返回 404 或错误跳转；新页面在站内可以被正常链接到；提交的站点地图和抓取测试没有报出阻碍抓取的错误。这些信号是验收依据，不是收录保证。

下一步，把上面的检查点整理成一张迁移验收表，指定每项的唯一负责人和确认时间，并在上线后按 URL 类型完成一轮抽查记录。这样交付时讨论的是具体证据，而不是“应该没问题”。