不少站点在收錄上遇到的麻烦，並不是頁面质量或内容本身，而是同一個頁面同时存在多個主机名可訪問。蜘蛛抓到的是哪一個、外鏈指向的是哪一個、内部連結又鏈到哪一個，一旦不统一，就會出現同一份内容被拆成好几份的情况。
先列清楚站点一共有几種可達地址
以 example.com 為例，常见的组合有四種：
- http://example.com
- http://www.example.com
- https://example.com
- https://www.example.com
如果服務器對這四個地址都返回 200，那就等于把一份内容摊成了四份。即使看上去是同一套頁面，對搜尋引擎来说它們也是不同的地址。
主机名不统一會带来什么
- 抓取被分散：蜘蛛在多個主机名之間来回爬，日誌里能看到重复抓取相同内容。
- 信号被拆分：同一頁面的外鏈、内鏈分別指向不同主机名，頁面获得的信号被摊薄。
- 規范化變难：canonical 寫了 https，可實际返回的是 http，或者反過来，容易造成冲突。
- 統計口径混乱：站点查询和索引报告里的數字對不上，难以判断收錄是否真的出了問题。
規范化的顺序
比較稳妥的做法是先定一個唯一的主机名，再把其他所有形式 301 過去。顺序大致如下：
- 确定最终的协议和主机名，通常是 https 加一個固定前缀，带 www 或不带，二選一即可。
- 把 http 全部 301 到 https，把另一種前缀 301 到選定前缀，注意避免鏈式跳轉，尽量一步到位。
- 頁面内的 canonical、sitemap、内鏈、外鏈，全部改成最终地址。
- 舊地址的 301 保持長期有效，不要图省事改回 200，也不要直接 404。
301 和 canonical 的分工
301 處理的是地址层面的跳轉，蜘蛛訪問舊地址时會直接被送到新地址；canonical 處理的是頁面层面的声明，用于說明“如果這些地址都被訪問到了，以哪個為准”。两者不冲突，但能靠 301 解决的問题，尽量不要只靠 canonical 兜着。
相對連結是個隐蔽的坑
如果頁面通過 http 訪問，頁面里的相對連結、图片地址也會被解析成 http。這时候就算 canonical 寫了 https，蜘蛛從頁面里發現的仍然是 http 版本，等于每次抓取都在制造新的重复入口。切換协议之後，把内部連結统一检查一遍。
几個容易被忽略的地方
- 證书：https 站点的證书要覆盖所有用到的主机名，否則會出現訪問告警，蜘蛛也可能抓取失敗。
- 混合内容：https 頁面里引用了 http 资源，浏览器會提示不安全，尽量全部替換。
- CDN 與回源：缓存規則、回源协议如果和源站不一致，可能让某些舊主机名意外繼續可訪問。
- HSTS：開啟後浏览器會强制走 https，但這不能代替 301，蜘蛛的行為並不完全等同于浏览器。
- 多語言、多地区站点：如果按子域划分，注意每個子域本身的主机名也要统一，別在規范化上再叠一层問题。
怎么確認已经處理干净
- 用不带跳轉的方式訪問各個舊地址，確認返回 301，且最终落到同一個地址。
- 抽查服務器日誌，看蜘蛛近期訪問的是哪個主机名，是否還有舊地址在被反复抓取。
- 在站点查询和索引报告里分別看两個前缀的數量，確認舊前缀在逐步减少。
- 检查頁面源碼里的 canonical、内鏈和 sitemap，是否已经全部換成新地址。
主机名規范化本身不复杂，难的是坚持：只要有一個入口没改，蜘蛛就會沿着它繼續發現舊版本。