网站索引申请改版或迁移时应核对什么：别把提交新站点地图当成完成
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d0f8ae23708c.html
📄
网站索引申请改版或迁移时应核对什么：别把提交新站点地图当成完成
改版或迁移时，网站索引申请最容易出现的误解是：只要把新网址提交一遍、换上新的站点地图，索引就会自动跟着切换。实际上，提交只是通知，不是迁移。真正需要核对的是旧地址如何退场、新地址是否可抓可索引、以及两套地址之间有没有把权重和用户都送错地方。下面按可执行的检查顺序展开。
先确认旧地址是跳转还是消失
迁移时最怕的是旧页面直接返回 404，却没有 301 到新页面。对搜索引擎来说，301 是明确的替换信号，404 则会让原有积累逐步失效。核对方法：
- 抽取旧站访问量最高的 50–100 个 URL，逐条访问，确认返回状态码。
- 旧页面对应新页面时，用 301 指向最相关的新 URL，不要全部跳到首页。
- 已经确定不再提供的页面，返回 410 或保留 404，不要伪造 200 空白页。
适用条件：域名更换、目录结构调整、URL 重写都适用。判断结果：如果旧 URL 能 301 到内容对应的新 URL，迁移链路基本成立；如果大量旧 URL 直接 404，索引申请做得再多也补不回断掉的路径。
robots.txt 的抓取限制不等于索引移除
常见错误是改版期间用 Disallow: / 挡住整站，以为这样能防止旧内容被看到，等上线后再放开。问题在于，robots.txt 只限制抓取，不保证已收录页面从索引中消失。旧页面可能仍以无摘要形式出现在结果里，而新页面因为被挡住也无法被抓取。
正确做法分两种情况：
- 如果只是短期维护，尽量用 503 状态码加 Retry-After，而不是全站禁止抓取。
- 如果确实要移除旧内容，优先用 301 或 410，而不是依赖 robots.txt。
检查项：打开 /robots.txt，确认没有误伤新站需要抓取的目录；同时确认测试环境没有被搜索引擎访问到。判断结果：抓取限制只影响爬虫是否读取，索引移除要看页面状态码和规范标签。
canonical、站点地图与内链要指向同一套地址
迁移后常见的混乱是：页面自己声明 canonical 指向旧域名，站点地图里却写新域名，内链又混用 http 和 https、带 www 和不带 www。这会让搜索引擎收到互相矛盾的信号。
- 每个页面的 canonical 必须指向该页面自己的最终地址。
- 站点地图只放返回 200 且允许抓取的最终 URL。
- 站内链接统一使用最终地址，不要依赖多次跳转。
站点地图不保证收录，它只是帮助发现 URL。核对时不要只看提交成功，要抽查站点地图里的 URL 是否可访问、是否与 canonical 一致。
多人协作时的交付核对表
改版或迁移往往由开发、内容和运营多方参与，减少返工的关键是把核对项写成可勾选的清单，而不是口头约定。
- 旧 URL 清单：谁负责导出，谁负责确认 301 映射。
- 新 URL 清单：是否全部返回 200，canonical 是否自指。
- robots.txt：是否误挡新站，是否暴露测试环境。
- 站点地图：是否只含最终 URL，是否已更新地址。
- 索引申请：在新站可抓取后提交，提交后记录日期和范围。
判断结果：以上五项都有明确负责人和完成状态，迁移交付才算清楚；只提交一次站点地图就宣布完成，通常会在几周后发现旧地址仍在、新地址没进索引。
HTTPS 与安全不是索引申请的替代项
启用 HTTPS 是迁移中常被一并处理的事项，但它不保证站点没有漏洞，也不直接保证排名。核对时应把证书有效性、混合内容、强制跳转与索引申请分开检查。如果 HTTPS 版本和 HTTP 版本同时可访问，需要确认 canonical 和 301 都指向 HTTPS 最终地址。
下一步：从旧站导出访问量最高的 URL 列表，逐条确认状态码和跳转目标，再对照新站 canonical 与站点地图。这份对照表就是多人协作时最直接的交付依据。
