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

网站索引_改版或迁移时应核对什么：一份可交付的检查清单

改版或迁移时，核对网站索引的核心是确认三件事：旧URL是否把权重和用户正确导向新URL、新页面是否具备被抓取和收录的条件、以及旧页面是否按预期退出索引。下面用一个假设例子展开，帮助你在多人协作中把交付做清楚。

假设场景：把栏目页从旧路径迁到新路径

假设某站点把/old/products/迁移到/new/products/，共涉及200个URL。协作中常见错误是：开发直接删旧页、运营只提交新站点地图、SEO只检查首页收录。结果是旧链接大量404，新页面迟迟不进索引，用户从外部链接点进来看到错误页。核对时应按“映射、可达、可抓、可收、退出”五步走。

第一步：核对URL映射与重定向

• 每个旧URL是否有一一对应的新URL，而不是全部跳到首页。全部跳首页会被视为软404，用户和搜索引擎都难以判断对应关系。
• 重定向是否使用301，且链条不超过一跳。A→B→C的多跳会稀释传递效果，也增加排查难度。
• 是否保留了原有参数逻辑。带查询参数的旧链接跳转后参数是否丢失，需要抽样验证。
• 大小写和结尾斜杠是否一致。服务器对/New/Products和/new/products/的处理不同，可能产生重复或404。

可执行检查：用爬虫工具或脚本对旧URL列表逐一请求，记录状态码和最终落地URL，输出一张对照表作为交付物。判断结果：状态码为301且落地页内容对应，才算通过；出现404、302或跳到无关页面，必须返工。

第二步：核对新页面是否可抓取

• 新页面的robots.txt是否误屏蔽了目录。抓取限制不等于索引移除，但会阻止发现。
• 页面是否有noindex标签。改版测试阶段常加，上线后忘记删除是高频事故。
• 重要页面是否被JavaScript渲染后才出现内容，而抓取端看不到。需要确认渲染后的HTML里包含正文和链接。
• 内链是否已从导航、面包屑、相关推荐指向新URL，而不是仍指向旧URL。

判断结果：用抓取工具模拟搜索引擎请求，若返回的HTML中能看到目标内容与可跟随链接，说明具备被抓取条件；若只看到空壳，需要调整渲染或提供静态回退。

第三步：核对站点地图与收录状态

站点地图不保证收录，但它是发现新URL的重要入口。核对时确认：站点地图只包含返回200状态码的规范URL，不包含重定向页、404页或已noindex的页面；lastmod时间与实际修改一致，不要全部写成同一时间。随后分别在不同搜索引擎的站长工具中查看已收录数量与抓取异常，因为各搜索引擎支持情况和处理节奏不同，不能用一个平台的结果推断另一个。

第四步：核对旧页面是否按预期退出索引

旧页面退出索引有两种路径：一是通过301让搜索引擎逐步替换，二是对确实不再提供内容的页面返回410或404。不要用robots.txt屏蔽来替代移除，因为被屏蔽的页面仍可能留在索引中，只是描述信息无法更新。核对时抽样搜索旧URL的完整地址，观察结果是否仍指向旧页；若仍存在，检查是否还有内链或外部链接指向旧地址，以及重定向是否生效。

多人协作中的交付要点

1. 建立一张迁移对照表，字段包括旧URL、新URL、状态码、负责人、验证时间。
2. 上线前冻结URL清单，任何新增或删除都需在表内登记，避免口头变更。
3. 上线后按批次验证：先抽查首页和一级栏目，再全量跑一遍旧URL列表。
4. 把验证结果截图或导出为文件，作为交付证据，减少“我以为已经好了”的返工。

下一步：拿你手头正在进行的改版或迁移项目，先导出全部旧URL清单，按上面的对照表跑一遍状态码，把不通过的项目直接分配给对应负责人。