📍 WDQWDWQD987AAAAA:35.187.36.114
📱 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
🔗 /
📄

网店收录工具改版或迁移时应核对什么：先保住可抓取与可索引

改版或迁移时，网店收录工具最该核对的是三件事：旧地址是否还能被抓取、新地址是否允许被索引、两者之间的对应关系是否完整。只提交新站点地图并不够，站点地图不保证收录；robots.txt 的抓取限制也不等于可靠的索引移除。正确做法是先收集证据，再决定是否放行、重定向或调整工具设置。

先核对抓取通道：robots.txt、状态码与服务器响应

改版后如果收录工具显示抓取异常，不要先怀疑工具本身。按顺序检查：

• 旧域名的 robots.txt 是否仍禁止抓取，或新域名是否误封了整站。
• 旧 URL 返回的是 301、302、404 还是 200。迁移应尽量使用 301 指向新页面对应地址，而不是全部跳到首页。
• 服务器是否对收录工具返回 5xx，或对同一 URL 返回不同状态码。
• 页面是否依赖 JavaScript 才能呈现主要内容，而收录工具拿到的初始 HTML 里没有对应链接或文字。

这里要区分“可能原因”和“已经定位的原因”。抓取量下降可能是 robots 限制、服务器超时、内链断裂或工具抓取配额变化，不能只凭一个现象就断定唯一原因。核对时先记录证据：抓取时间、返回状态码、响应正文、抓取工具标识。只有同一 URL 在多次抓取中稳定返回同一异常，才适合把它当作已定位的问题处理。

再核对索引信号：canonical、noindex 与旧页面处置

改版或迁移最容易犯的错误，是把旧页面全部保留为可访问的 200 页面，同时新页面也开放索引。这样收录工具会同时看到两套内容，无法判断哪个是主版本。核对项包括：

1. 新页面是否带 noindex 或错误的 canonical 指向旧域名。
2. 旧页面是否仍返回 200，且没有指向新页面的 canonical 或 301。
3. 分页、筛选参数和商品变体是否生成了大量近似 URL，是否被收录工具反复抓取。
4. HTTPS 切换后，HTTP 与 HTTPS 是否同时可访问，证书是否覆盖当前域名。

HTTPS 不保证安全无漏洞或排名，它只是传输层条件之一。判断是否完成迁移，要看旧地址是否稳定跳转到新地址，新地址是否返回 200，以及 canonical 是否指向新地址本身。若旧页面必须保留一段时间，可用 301 或 canonical 明确主版本，而不是让两个地址长期并存。

站点地图与收录工具设置：提交只是通知，不是收录保证

站点地图的作用是告知抓取工具有哪些 URL，不保证收录。改版后应核对：

• 站点地图里是否只包含返回 200 且允许索引的 URL。
• 是否把 301、404、noindex 页面错误地放进站点地图。
• 站点地图中的 URL 是否与页面 canonical 一致。
• 收录工具中是否仍保留旧域名的资源验证，是否需要新增新域名验证。

不同搜索引擎支持情况须分别核查。有的收录工具支持 URL 检查、抓取统计和索引覆盖报告，有的侧重站点地图提交。不要假设一个平台的操作会同步到另一个平台。核对时以各平台实际返回的状态为准，不以“已经提交”作为收录完成的证据。

用一份对照表定位问题，再决定下一步

可以按下面这张假设的对照表收集证据，适用于改版后出现具体抓取或索引异常的场景：

• 旧 URL：返回 301 到新 URL，且新 URL 返回 200，允许索引。
• 旧 URL：返回 200，但 canonical 指向新 URL，且新 URL 允许索引。
• 旧 URL：返回 404，新 URL 可访问，但内链仍指向旧 URL。
• 新 URL：返回 200，但页面含 noindex，收录工具显示“已排除”。
• 新 URL：返回 200，但 robots.txt 禁止抓取，收录工具无法读取内容。

判断结果时看组合，不看单点。例如“收录工具显示未收录”可能是抓取被禁、页面 noindex、内容重复、内链不足或抓取配额未到，不能只改一个标签就认定解决。若旧地址返回 404 且没有重定向，应优先补上对应关系；若新地址被 noindex，应先移除该指令，再观察抓取与索引状态变化。

下一步：选一个改版前有代表性的旧商品 URL，记录它当前的状态码、canonical、robots 限制和站点地图中的出现情况，再与对应新 URL 逐项对照。只有证据一致时，才把问题标记为已定位。