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

搜索引擎收录改版或迁移时应核对什么 - 交付前必须确认的收录检查项

改版或迁移时，要核对的核心不是页面“看起来正常”，而是旧地址到新地址的对应关系、可抓取性、可索引性和内容一致性是否在交付前被逐项确认。判断标准是：搜索引擎能否发现新URL、是否允许抓取、是否愿意保留索引，以及旧URL是否以正确方式让位。多人协作时，把这些检查写成可勾选清单，比口头交接更能减少返工。

先核对URL映射：旧地址是否都有明确去向

迁移最常见的问题不是新站打不开，而是旧URL没有对应关系。要逐条核对：旧URL是301到最相关的新URL，还是被统一跳转到首页。前者能传递页面主题，后者容易让搜索引擎把大量旧页面视为同一目标。

• 列出旧站可索引URL清单，与服务器访问日志、站点地图交叉比对。
• 为每条旧URL标注：保留、301到新URL、410删除，还是暂时保留。
• 检查跳转链：A跳B、B再跳C会浪费抓取配额，应尽量一步到位。
• 确认跳转状态码不是302、307或JS跳转；这些方式对收录信号的处理不同。

判断结果：如果旧URL返回200且内容已删除，或返回301但目标与旧主题无关，就属于需要返工的高风险项。

再核对可抓取与可索引：别把“能打开”当成“能收录”

页面能打开，只说明用户可访问，不代表搜索引擎能抓取和索引。交付前要分别检查抓取层和索引层。

• 抓取层：robots.txt是否误屏蔽新目录、测试环境是否被放上生产域名、服务器是否对搜索引擎返回403或5xx。
• 索引层：页面是否带有noindex、规范链接是否指向旧域名或错误页面、分页和参数页是否被错误规范到首页。
• 渲染层：重要内容是否依赖JS才出现，以及渲染后的HTML里是否仍有标题、正文和链接。

这里要区分“可能原因”和“已经定位的原因”。如果新页面未收录，可能是抓取被阻止、索引被禁止、规范链接错误或内容重复，不能只凭一个现象断定唯一原因。核对时逐项排除，记录证据，例如抓取工具返回的状态码、渲染后HTML、robots规则命中情况。

注意：robots.txt的抓取限制不等于可靠的索引移除。被robots阻止抓取的URL仍可能因外部链接出现在索引中；要移除索引，应结合noindex、删除或410等方式，并确认搜索引擎能抓到该页面才能看到noindex。

核对站点地图、内链与HTTPS，但不要误解它们的作用

站点地图是发现URL的辅助手段，不保证收录。迁移后应核对：站点地图只包含可索引的新URL、返回200、不含旧域名和重定向地址，并在搜索资源平台提交更新。内链同样重要：导航、面包屑和正文链接应指向新URL，避免站内仍大量指向旧地址。

HTTPS要核对证书链、混合内容和强制跳转，但HTTPS不保证安全无漏洞，也不保证排名。它只是基础条件之一。不同搜索引擎对站点地图、跳转和索引信号的支持情况须分别核查，不能用一个平台的结果推断所有搜索引擎。

交付前复查：用同一套清单做回归验证

多人协作时，建议把复查拆成可执行步骤，并指定一人做最终核对：

1. 随机抽取旧URL样本，用抓取工具查看状态码、跳转目标和最终URL。
2. 抽取新URL样本，检查robots.txt、noindex、规范链接和渲染后正文。
3. 对比改版前后页面标题、主内容、内链是否发生非预期变化。
4. 提交新站点地图，并在搜索资源平台查看抓取和索引报告，记录异常URL。
5. 迁移后按固定周期复查旧URL跳转是否仍有效，避免临时规则被移除。

适用条件：以上清单适用于域名迁移、目录调整、CMS更换和URL规则重写。若只是页面样式改版而URL不变，可重点核对可索引性和内容一致性，不必全量重做映射表。判断是否通过，以“旧URL有正确去向、新URL可抓可索引、站点地图与内链一致”为准。

下一步：把上述检查项固化成一份迁移交付清单，要求每条都有负责人、证据截图或日志记录，再开始正式切换。