搜索引擎收录对比，改版或迁移时应核对什么
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /58ad9e460e7d.html
📄
搜索引擎收录对比，改版或迁移时应核对什么
改版或迁移时做搜索引擎收录对比，核心不是看“新站有没有收录”，而是核对同一批URL在改版前后的可抓取、可索引、可展示状态是否连续。交付结果应当是一份逐URL的对照表：旧URL、新URL、跳转关系、抓取状态、索引状态、站点地图与robots记录，以及每项差异的责任人和验收时间。缺少其中任何一项，收录波动都很难定位原因。
先确定对比对象：URL清单与版本基线
收录对比必须有可复现的基线。改版前先导出旧站URL清单，来源可以包括站点地图、站内链接抓取结果和服务器访问日志。迁移后导出新站URL清单，按URL路径、页面类型、语言或目录分组。
- 核对每个旧URL是否有明确去向：保留、301跳转到新URL、410删除，还是暂时保留。
- 把参数URL、分页URL、筛选URL单独列出，避免把大量低价值页面混入核心对比。
- 记录基线日期和抓取工具版本，否则两次对比结果无法解释。
如果旧站有几十万URL，先按流量或内链权重分层抽样，而不是全量逐条人工检查。抽样规则要写进交接文档，例如“首页、栏目页、前100个详情页、随机200个长尾页”。
核对抓取与索引：robots、站点地图、跳转和状态码
改版或迁移后，最常见的收录差异来自抓取限制和跳转配置，而不是内容质量本身。核对时逐项检查：
- robots.txt：确认新站没有误屏蔽整站或关键目录。注意，robots.txt 的抓取限制不等于可靠的索引移除；已收录URL即使被屏蔽抓取，仍可能出现在结果中。
- 站点地图：确认新站点地图只包含可索引的规范URL，并已提交。站点地图不保证收录，它只是发现URL的辅助入口。
- 跳转：旧URL到新URL应使用301，避免302、JS跳转或跳转链。跳转链越长，抓取和权重传递越容易损耗。
- 状态码：核对旧URL返回301、410还是404。批量删除的页面用410更明确，但不要对应当保留的页面返回404。
- 规范标签：确认新页面的canonical指向自身或正确的规范URL，避免旧URL和新URL互相竞争。
不同搜索引擎对robots、站点地图和索引移除的支持情况须分别核查，不能因为一个搜索引擎处理正常就推断全部正常。
核对页面可索引性与展示结果
抓取正常不代表能索引。逐类页面检查以下项目：
- 页面是否返回200，且HTML中不存在noindex。
- canonical是否指向预期URL，是否误指向旧域名或无关页面。
- 页面是否有实质内容，而不是空模板或仅剩导航。
- 标题、描述、H1是否与旧页面主题一致，避免改版后主题漂移。
- 移动端与桌面端是否都能正常渲染主要内容。
HTTPS 不保证安全无漏洞或排名，它只是传输层配置。迁移到HTTPS后，仍要核对证书链、混合内容和跳转是否完整。
假设一个例子：旧站某产品页 /p/1001 改版后变为 /products/1001。如果旧URL返回301、新URL返回200且canonical指向自身，这是可接受的迁移。如果旧URL返回302，新URL又带noindex，那么收录对比中该URL会表现为“已抓取未索引”，原因已经定位在跳转和noindex，而不是内容质量。
从交付结果倒推任务、责任与验收
收录对比不是一次性检查，而是一组可验收任务。建议按以下结构交付：
- 资料：旧URL清单、新URL清单、跳转映射表、robots.txt历史版本、站点地图历史版本。
- 任务：逐URL核对状态码、跳转、canonical、noindex、站点地图收录情况。
- 责任：开发负责跳转和状态码，SEO或内容负责人负责canonical和内容对应，运维负责robots和服务器日志。
- 验收：核心URL全部有明确去向；抽样URL的抓取状态与索引状态符合预期；差异项有原因分类和修复期限。
对比结果建议分成四类：正常保留、正常跳转、待修复、预期删除。只有“待修复”需要进入排期，其他两类用于确认迁移完整度。
下一步：建立可复查的对照表并定期回查
先导出改版前后各一份URL清单，按上述检查项生成逐URL对照表。对每个差异项标注可能原因与已定位原因，不要把“未收录”直接归因于单一因素。完成首轮修复后，在相同抽样规则下再做一次收录对比，确认差异项是否收敛。这样做的目的不是追求一次对比就恢复全部收录，而是让每个URL的状态变化都有证据可查、有责任可追。
