Google索引改版或迁移时应核对什么，一份可执行的检查清单
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b9b9bc5b9891.html
📄
Google索引改版或迁移时应核对什么，一份可执行的检查清单
改版或迁移时，Google索引层面最该核对的是：旧URL是否还能被访问、是否被正确重定向、新页面是否可被抓取、以及旧页面的信号是否被继承。核心目标是让Google尽快把旧URL替换成新URL，而不是让两套页面长期并存或直接消失。
先看一个假设的迁移场景
假设你把一个产品站从 example.com/old-product 迁到 example.com/new-product，同时把栏目结构从 /category/ 改成 /collections/。迁移后你发现旧URL返回404，新URL在搜索结果里迟迟不出现。问题通常不在“提交了没有”，而在迁移时漏掉了几个索引层面的核对点。
常见错误包括：只改了页面模板，没处理旧链接；用JavaScript跳转代替服务器端301；robots.txt误屏蔽了新目录；站点地图只提交了新URL，没保留旧URL的映射关系。这些都会让Google索引更新变慢，甚至丢失原有收录。
核对重定向与旧URL状态
迁移时优先确认旧URL的HTTP状态码。理想情况是旧URL返回301，并指向最相关的新URL，而不是全部跳首页。可以用命令行或浏览器开发者工具查看响应头：
curl -I https://example.com/old-product
如果返回200，说明旧页面还在，Google可能继续索引旧内容；如果返回404或410，旧页面会逐渐从索引中移除，但新页面不会自动继承它的位置；如果返回302，属于临时跳转，Google可能仍保留旧URL。判断结果：301是迁移场景下更明确的信号，302适合临时调整，404/410适合确实要下线的页面。
注意，robots.txt的抓取限制不等于可靠的索引移除。如果旧URL被robots.txt屏蔽，Google可能无法抓取到重定向指令，反而延长旧页面在索引中的停留时间。
核对新页面的可抓取与可索引
新页面需要同时满足“可抓取”和“可索引”。检查项包括：
- 新URL是否返回200，且HTML中不包含
<meta name="robots" content="noindex">。 - robots.txt是否误屏蔽了新目录，例如
Disallow: /collections/。 - 新页面是否有规范的
<link rel="canonical">，且指向自身而非旧URL。 - 站点地图是否包含新URL，并更新了最后修改时间。
站点地图不保证收录，它只是帮助Google发现URL。如果新页面本身被noindex或robots.txt阻止，提交站点地图也不会让它进入索引。HTTPS同样不保证安全无漏洞或排名，它只是迁移时应当保持的基础条件之一。
核对索引覆盖与信号继承
迁移后，在Google Search Console的“页面”报告中查看索引状态。重点看两类问题：
- 旧URL是否仍显示“已编入索引”，如果长期不消失，检查重定向是否生效、内链是否仍指向旧URL。
- 新URL是否显示“已发现，尚未编入索引”或“已抓取，尚未编入索引”，这通常意味着Google已知道新页面，但还需要时间评估或抓取资源不足。
同时核对内部链接：导航、面包屑、文章正文中的链接是否已指向新URL。如果内链仍大量指向旧URL，Google会持续抓取旧地址，拖慢索引替换。外链无法控制，但可以通过更新自身可控链接来减少混淆。
迁移后需要持续观察的指标
迁移不是一次性动作。建议在迁移后几周内定期核对：
- 旧URL的301是否仍然有效，没有被误删或改成404。
- 新URL的抓取频率和索引状态是否在改善。
- 站点地图是否只包含返回200且可索引的URL。
- 是否有新的软404或重复页面出现。
不同搜索引擎对重定向和索引更新的处理节奏不同，Google的索引变化需要单独在Google Search Console中核查，不要用其他平台的收录情况直接推断Google的结果。
下一步：选一个你最近改版或迁移过的URL，用 curl -I 检查它的状态码，再对照Search Console的索引报告，确认旧URL和新URL是否都处于预期状态。
