搜索引擎不收录改版或迁移时应核对什么：先分清阻止抓取与阻止索引
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e846d79faefc.html
📄
搜索引擎不收录改版或迁移时应核对什么：先分清阻止抓取与阻止索引
改版或迁移后发现搜索引擎不收录，最先要核对的不是“提交了多少链接”，而是新页面到底处于哪一层状态：是抓取被挡住，抓取成功但未索引，还是旧地址仍可访问、新地址没有被当作同一实体。很多人把 robots.txt 当成万能开关，这是最常见的误解。robots.txt 只能限制抓取，不能可靠地移除已经进入索引的页面，也不能保证新页面被收录。因此核对顺序应当是先确认可抓取，再确认可索引，最后确认新旧地址的对应关系。
误解：把 robots.txt 和 noindex 当成同一件事
这两种机制作用点不同。robots.txt 的 Disallow 阻止的是抓取，爬虫看不到页面内容，也就无法读取页面上的 noindex。若一个页面既被 robots.txt 挡住、又写了 noindex，爬虫因为抓不到页面，可能仍保留旧索引信息，无法及时移除。反过来，如果希望页面从索引中消失，正确做法通常是允许抓取、在页面返回可读取的 noindex，而不是只在 robots.txt 里屏蔽。
改版迁移时还要注意：如果整站迁移期间用 robots.txt 屏蔽了全站，爬虫无法抓取新页面，也就无法发现新地址和新的规范化信号。屏蔽期越长，新旧交替越容易混乱。
核对抓取：新地址是否允许爬虫访问
第一步是确认新地址没有被意外拦截。可以逐项检查：
- robots.txt 中是否有针对新目录或新路径的 Disallow 规则；
- 服务器是否对爬虫返回 403、503 或频繁超时；
- 页面是否需要登录、验证码或特定 Cookie 才能看到内容；
- 站点地图是否指向新地址，且其中 URL 返回 200。
站点地图只是发现线索，提交站点地图不保证收录。它帮助爬虫知道有哪些地址，但最终是否抓取、是否索引由搜索引擎自行判断。因此站点地图正常，不等于收录正常。
核对索引：页面是否明确允许进入索引
抓取正常后，检查页面本身是否发出“不要索引”的信号：
- HTML 头部是否有
<meta name="robots" content="noindex">； - HTTP 响应头是否有
X-Robots-Tag: noindex； - 页面是否返回 404、410 或软 404；
- 规范化标签是否指向了另一个不打算收录的地址。
这里要区分“可能原因”和“已经定位的原因”。例如页面未收录，可能是 noindex、可能是抓取预算不足、可能是内容质量判断，也可能是新旧地址重复。只有逐项验证返回状态和页面信号，才能确定是哪一项在起作用，不能凭单一现象下结论。
核对迁移：旧地址与新地址如何对应
迁移场景下，需要比较两种处理方案，适用条件不同：
- 逐对 301 重定向。适用于旧页面与新页面一一对应、内容主题基本延续的情况。旧地址返回 301 指向新地址，可以帮助用户和爬虫到达新位置，并传递信号。若旧地址直接 404 且没有对应新地址，已积累的外部链接和入口会失效。
- 保留旧地址并加规范化。适用于两套地址长期并存、内容高度重复的情况，例如参数页或镜像页。此时应让其中一个版本作为规范版本，另一个通过
<link rel="canonical">指向它。但规范化是建议信号，不是强制指令，仍需观察实际选择结果。
判断哪种方案更合适，先看旧地址是否还有搜索流量和外部链接。若有，优先逐对重定向；若旧地址只是重复入口且无独立价值，可考虑规范化或直接下线。无论哪种，都不要让旧地址和新地址同时返回 200 且内容相同，否则容易造成重复和信号分散。
核对安全与协议：HTTPS 不是收录保证
迁移到 HTTPS 时，要检查证书是否有效、页面资源是否混合加载、HTTP 是否重定向到 HTTPS。但需要明确：HTTPS 不保证安全无漏洞，也不保证排名。它只是协议层面的基础条件。若证书报错或重定向链路过长，反而可能影响抓取。
实际执行时，可以按以下顺序推进：先确认新地址可抓取，再确认页面允许索引，然后核对旧地址重定向或规范化，最后提交站点地图并观察抓取与索引状态。不同搜索引擎的支持和反馈方式需要分别核查，不能假设一个平台的结果直接套用到另一个平台。
下一步，建议先抽出迁移中流量最高的一批旧地址，逐个访问并记录返回状态、重定向目标和页面 robots 信号，形成一张对照表，再决定哪些走 301、哪些走规范化。
