网站收录入口：改版或迁移时应核对什么
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d0b71de0c27d.html
📄
网站收录入口：改版或迁移时应核对什么
改版或迁移时，核对“网站收录入口”的核心不是找一个提交按钮，而是确认搜索引擎能否从旧地址、新地址和站内链接三个方向发现并抓取新页面。最关键的一步是：在切换前先固定一份URL映射表，切换后逐项验证旧URL到新URL的跳转、新站可抓取性和站点地图一致性。只提交新站点地图，不等于旧页面会被替换；只做301跳转，也不等于新页面一定被收录。
准备阶段：先确认哪些入口会失效
改版或迁移常见的入口包括：旧域名或旧目录下的URL、站内导航与面包屑、站点地图、robots.txt、canonical标签、分页与筛选链接、外部链接指向的旧地址。准备阶段要做的是把“会变的入口”列全，而不是只盯首页。
- 导出旧站可抓取URL清单，按栏目、内容页、列表页、标签页分类。
- 为每个旧URL指定唯一新URL，形成映射表；无法对应的页面，明确是保留、合并还是返回410。
- 记录哪些旧URL有外部链接或站内重要入口，优先保证这些地址的跳转正确。
- 检查新站是否已能正常访问，robots.txt是否误屏蔽测试环境或新目录。
判断结果：如果映射表里存在“旧URL对应多个新URL”或“旧URL无对应新URL”，先解决再切换。适用条件是站点结构发生较大变化；若只是模板微调、URL不变，核对重点可缩到模板输出和canonical。
实施阶段：301、canonical与站点地图怎么配合
迁移时常见两种处理方案：一是用301永久跳转把旧URL指向新URL；二是保留旧URL并输出canonical指向新URL。两者适用条件不同。
- 301跳转适合旧URL不再提供内容、希望用户和搜索引擎直接到新地址的情况。它应逐条对应，避免全部跳首页。
- canonical适合同一内容存在多个可访问URL、需要指定首选版本的情况。它不能替代旧URL的迁移处理，旧地址仍可能被访问。
- 站点地图应只列新站希望被抓取的规范URL，并随新结构更新。站点地图不保证收录，但能帮助发现页面。
- robots.txt只控制抓取，不等于可靠的索引移除；若旧目录被屏蔽，旧页面可能仍留在索引中，需配合跳转或移除请求。
最关键的一步在实施阶段：先小范围验证一条旧URL的跳转链，确认没有跳转多次、没有跳到404、没有跳到无关页面，再批量上线。假设旧地址是 /old-a，新地址是 /new-a，正确结果是访问旧地址返回301并落到新地址；若返回302，迁移信号的稳定性会弱一些，应改为301。若旧地址直接返回404，外部链接带来的用户和抓取会中断。
验证阶段：切换后查什么、怎么判断
切换完成后，不要只看首页。按准备阶段的映射表抽样验证，并覆盖不同层级。
- 用浏览器或抓取工具访问旧URL，检查状态码和最终落地页。
- 检查新URL是否返回200，页面内容是否完整，canonical是否指向自身或正确规范地址。
- 查看新站点地图中的URL是否都能访问，是否包含已删除或不应收录的地址。
- 检查robots.txt是否允许抓取新站重要目录，是否误屏蔽CSS、JS或图片资源。
- 在搜索引擎的抓取与索引报告中分别核查不同搜索引擎的表现，不要用一家结果推断另一家。
判断结果：若旧URL跳转正确、新URL可抓取、站点地图一致，说明入口层基本就绪；若旧URL仍返回200且内容与新版重复，应补跳转或canonical；若新URL被robots.txt屏蔽，先修正规则再谈提交。HTTPS只说明传输层加密，不保证安全无漏洞或排名，迁移核对时不应把它当作收录保障。
维护阶段：把核对变成固定检查项
迁移后的一段时间内，持续观察旧URL跳转是否被改动、新URL是否因模板调整变成404、站点地图是否仍指向旧地址。维护阶段可执行的最小检查是：每周抽取映射表中若干旧URL，确认跳转链未断；每次发布新栏目时，同步更新站点地图和站内入口。
下一步：拿一份旧站URL清单，按“保留、301、410、合并”四类标注，先完成映射表，再按本文实施与验证顺序逐项核对。这样处理的是网站收录入口本身，而不是泛泛检查SEO设置。
