提交网址收录：改版或迁移时应核对什么
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /350af18a3fd6.html
📄
提交网址收录：改版或迁移时应核对什么
改版或迁移后提交网址收录，核心不是把新网址一股脑推给搜索引擎，而是先核对旧网址到新网址的对应关系、可抓取性和索引状态。提交只是最后一步；如果映射、重定向或抓取规则出错，提交得越多，错误暴露得越快。下面用一个假设例子说明该核对什么、怎么定位问题。
假设例子：栏目路径从 /old/ 迁到 /new/
假设某站点把产品栏目从 /old/ 整体迁到 /new/，页面内容基本不变。迁移后运营人员直接提交了新栏目下的几百个网址，但两周后搜索表现仍不稳定。此时不应继续重复提交，而应按下面顺序核对。
- 核对旧网址返回状态。用抓取工具或命令行请求旧网址，确认返回的是 301 跳转到对应新网址，而不是 302、404 或跳回首页。302 是临时跳转，不能稳定传递迁移信号；全部跳首页则会让搜索引擎无法判断新旧页面的对应关系。
- 核对新旧页面一一对应。把旧网址和新网址列成两列，逐条检查是否语义相同。常见错误是旧分类页跳到新首页，或旧文章跳到新栏目页。对应关系错了，提交新网址也无法替代旧网址的权重和流量。
- 核对 robots.txt 是否误拦。迁移时容易把测试环境的
Disallow: /带到线上。若新网址被 robots.txt 拦截，提交后抓取会被拒绝。注意：robots.txt 只限制抓取，不等于可靠的索引移除；已经收录的旧页面即使被拦截，也可能继续出现在结果中。 - 核对 canonical 与站点地图。新页面应指向自身规范网址，站点地图应只列最终可访问的新网址。站点地图不保证收录，它只是发现入口；如果地图里混入重定向网址或 404 网址，会降低对地图的信任。
- 核对 HTTPS 与混合内容。迁移常伴随协议切换。HTTPS 不保证安全无漏洞或排名，但若页面仍加载 HTTP 资源，或被证书错误阻断，抓取和渲染都会受影响。
提交网址收录前的最小检查清单
把下面几项做成可执行的检查，而不是凭感觉判断：
- 旧网址是否返回 301，且
Location指向语义对应的新网址。 - 新网址是否返回 200，且无需登录、无需特殊 cookie 即可访问。
- robots.txt 是否允许抓取新网址所在路径；meta robots 是否误写
noindex。 - canonical 是否指向新网址自身，而不是旧网址或无关页面。
- 站点地图中的网址是否全部为最终网址，且与页面 canonical 一致。
- 内链是否已从旧路径改为新路径，避免用户和抓取工具反复经过重定向。
判断结果时，若旧网址 301 正常、新网址 200 且可抓取、canonical 自指，再提交网址收录才有意义。若其中任一项失败，应先修复再提交。不同搜索引擎对提交入口、站点地图和索引更新的支持情况须分别核查，不能假定一处提交就覆盖所有搜索来源。
常见错误：把“提交”当成“修复”
最常见的错误是看到新网址没收录就反复提交，却不检查旧网址是否 404、是否全部跳首页、是否被 robots.txt 拦截。提交网址收录只是通知搜索引擎“这些网址存在”，它不能修复错误的重定向，也不能强制移除旧索引。另一个错误是迁移后立刻删除旧网址，导致用户和抓取工具同时失去跳转路径。更稳妥的做法是保留旧网址并维持 301 一段时间，直到确认新网址已稳定承接流量。
定位问题时如何收集证据
如果表现异常，按“现象—可能原因—已定位原因”分开记录。例如：现象是新栏目页未出现；可能原因是抓取被拦截、canonical 指向旧页、页面返回 404；已定位原因需要靠服务器日志、抓取测试和页面源代码确认。不要在没有证据时断言唯一原因。可以先用抓取工具请求一个旧网址和一个新网址，保存返回状态、跳转链和页面 canonical，再对照站点地图和 robots.txt。这样得到的证据能直接指向是映射问题、抓取问题还是索引问题。
下一步：选一个已迁移的旧网址，完成一次 301 链路、新网址状态、robots.txt 和 canonical 的核对；确认无误后，再通过对应搜索引擎的提交入口提交最终新网址，并在一段时间后复查索引状态。
