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

SEO域名规范化，改版或迁移时应核对什么

改版或迁移时，SEO域名规范化要核对的核心只有一件事：同一份内容是否只通过一个规范主机名和路径对外提供，并且站内链接、重定向、canonical、站点地图、robots 与统计口径都指向这个版本。只要其中一项仍指向旧域名、旧协议或旧路径，就可能出现重复收录、权重分散或抓取浪费。多人协作时，建议把这项核对做成一张可交付的清单，而不是靠口头确认。

准备阶段：先确定唯一规范版本并写进交付物

动手之前，先明确规范版本是什么。它至少包含四层：主机名（带不带 www）、协议（HTTP 还是 HTTPS）、路径写法（是否带尾斜杠、大小写是否统一）、参数处理（哪些参数保留、哪些忽略）。把结论写进一份《域名规范化说明》，作为设计、开发、运维、内容编辑共同遵守的基线。

检查项可以这样列：

• 旧域名到新域名的映射表：每条旧 URL 对应哪条新 URL，是 301 还是 410。
• 规范主机名：example.com 与 www.example.com 只能保留一个作为对外主版本。
• 协议版本：确认 HTTPS 证书覆盖所有子域，HTTP 访问统一跳转到 HTTPS。
• 路径规则：目录页、文章页、分页的 URL 格式是否有统一约定。

这一步最关键的是映射表。没有它，后面所有验证都无从对照。映射表要标明“旧 URL—新 URL—状态码—负责人”，并在实施前完成评审。

实施阶段：重定向、canonical 与站内链接要一致

实施时容易出现的返工，是不同出口给出不同答案。例如页面 A 通过 301 跳到新域名，但页面内的 canonical 仍写旧域名；或者站点地图里是旧 URL，而导航里已经是新 URL。对搜索引擎来说，这些信号互相矛盾，规范化就失效了。

需要逐项核对：

1. 旧 URL 是否返回 301 到对应的新 URL，而不是全部跳到首页。全站跳首页属于软 404 式处理，会丢失原页面相关性。
2. 新页面 canonical 是否指向自身规范 URL，且与重定向目标一致。
3. 站内链接、导航、面包屑、分页是否全部使用规范版本，不再出现旧域名。
4. 站点地图只列规范 URL。站点地图不保证收录，但它不应再提交旧地址，否则会干扰抓取判断。
5. robots.txt 是否误封了需要抓取的路径。抓取限制不等于可靠的索引移除，被 robots 挡住的页面仍可能因外链被收录，需要移除时应用 noindex 或 404/410 配合。

多人协作时，把“重定向规则”和“canonical 规则”交给同一名负责人验收，能减少两边各自为政的情况。

验证阶段：用可复现的方法逐条比对

验证不能只看首页。抽一批代表性 URL，覆盖首页、栏目页、文章页、分页、带参数页、已删除页，逐条检查。

可执行的检查方法：

• 对每条旧 URL 发起请求，记录状态码和 Location 头，确认是 301 且目标正确。
• 对每条新 URL 查看页面源码中的 canonical，确认与当前地址一致。
• 用抓取工具或命令行批量跑一遍站内链接，找出仍指向旧域名或非规范协议的链接。
• 检查站点地图中的 URL 是否全部可访问、是否全部为规范版本。
• 分别核对不同搜索引擎的抓取与收录表现，因为各引擎对重定向、canonical 的处理节奏并不相同。

判断结果的标准是：任意一条内容，从旧地址访问、从站内链接访问、从站点地图访问，最终落到的主机名、协议和路径完全一致。只要存在分叉，就继续修。

维护阶段：把规范化变成持续检查项

迁移完成不等于结束。后续新增内容、更换 CDN、调整统计代码，都可能重新引入非规范 URL。建议把下面几项纳入例行检查：

• 新增页面上线前，确认 canonical 和站内链接都使用规范版本。
• 定期抽样旧域名，确认重定向仍然有效，没有被误删。
• 监控 404 和 5xx 日志，发现异常跳转及时处理。
• 统计工具中区分规范与非规范地址的流量，避免把重定向流量误判为自然流量变化。

HTTPS 能改善传输安全，但不等于站点没有漏洞，也不保证排名提升；它只是规范化中协议统一的一环。把安全、抓取、索引分开看待，判断会更准确。

下一步，先整理出旧 URL 到新 URL 的完整映射表，并指定一名负责人对照本文清单逐项验收。映射表没有确认之前，不要批量上线重定向规则。