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

批量查收录改版或迁移时应核对什么：先分清“抓取”和“收录”

改版或迁移时，批量查收录最先要核对的不是收录数量涨跌，而是新旧URL的对应关系、抓取通道和索引状态是否一致。很多团队一上线就盯着收录量，发现下降便急着提交或删旧链接，这往往把可恢复的波动变成真正的丢失。正确顺序是：先确认每个旧URL有没有明确去向，再确认新URL能被抓取，最后才判断是否被索引。

常见误解：收录量下降不等于迁移失败

迁移后收录数短期波动很常见，原因可能是旧URL被移除、新URL尚未被抓取、索引在重新计算。它不等于新站被惩罚，也不等于操作一定出错。真正需要警惕的是以下情况：旧URL返回404却没有指向新地址，新URL被robots.txt挡住，或者整站返回异常状态码。这些属于“已经定位的原因”，而单纯的收录数下降只是“可能原因”，需要逐项排查才能下结论。

最先核对的四项内容

1. URL映射完整性：每个有流量或有外链的旧URL，是否都有一条301指向语义最接近的新URL。不要全部跳到首页，那会被视为软404，也不要把无关页面互相跳转。
2. 抓取通道是否畅通：检查robots.txt是否误挡了新目录，确认站点地图里的地址全部返回200。站点地图不保证收录，但没有它会让发现速度更慢。
3. 索引状态：对重点URL逐一查询，确认返回的是“已收录”而不是“已发现但未收录”。后者说明抓取到了但还没进入索引，需要看内容质量和内链。
4. 规范标签：新旧页面如果同时可访问，确保canonical指向新URL，避免两个版本互相竞争。

人手有限时，优先处理有外链和自然流量的旧URL，其余长尾可以稍后批量核对。判断依据是流量和外链数据，不是页面数量。

一个可执行的最小核对流程

假设你有一份旧URL清单（示例，非真实项目数据），可以这样操作：

1. 把旧URL和新URL做成两列表格，逐条填写。
2. 用批量请求工具检查每个旧URL的状态码，期望是301且Location指向新URL。
3. 用批量请求工具检查每个新URL的状态码，期望是200。
4. 抽查20%的重点URL，确认canonical和robots元标签没有误写。
5. 把结果分成三组：已正确跳转、跳转错误、无跳转。只处理后两组。

如果旧URL返回200而不是301，说明旧页面还在，需要判断是保留还是替换。保留会造成重复内容，替换则要确保新页面已可访问。

批量查收录时容易踩的坑

• 把robots.txt当作索引移除工具：robots.txt限制的是抓取，不是索引移除。被挡住的URL仍可能出现在索引里，只是没有摘要。
• 只看总量不看结构：总量持平可能掩盖了重点页面丢失。应按目录或页面类型分组核对。
• 迁移当天就下结论：索引更新需要时间，当天数据不能说明最终结果。至少观察一个抓取周期后再判断。
• 忽略HTTPS和重定向链：HTTPS不保证安全无漏洞，也不保证排名。但多次跳转（A→B→C）会浪费抓取预算，应尽量一步到位。

下一步该做什么

先导出旧URL清单，按外链和流量排序，只核对前20%的重点页面。确认它们的301、状态码和canonical无误后，再批量检查其余URL。如果发现旧URL无跳转或新URL被挡，先修复这两类问题，再观察收录变化。