同一個頁面，因為协议、主机名、末尾斜杠、路径大小寫、參數顺序的不同，可能在服務器日誌和索引里表現為好几個地址。搜尋引擎把它們当成不同 URL 分別抓取、分別判断，頁面能拿到的信号就被摊薄了。與其反复問「這個頁面為什么收錄不稳定」，不如先把 URL 寫法收敛成一個版本，再观察收錄狀態。
一、先列出所有指向同一内容的寫法
把站点上可能出現的變体列成一張表，逐項核對服務端返回什么。常见的有：
- 协议：http 與 https 各自可訪問；
- 主机名：带 www 與不带 www，以及大小寫混寫；
- 端口：顯式寫出 :80、:443；
- 路径：/about 與 /About、/about 與 /about/；
- 預設文档：/ 與 /index.html、/default.aspx；
- 參數：顺序不同、追踪參數（utm_source、gclid、fbclid）；
- 會话類參數：sid、sessionid、PHPSESSID；
- 轉义寫法：中文路径直接寫與寫成 %E4%B8%AD 形式；
- 冗余符号：双斜杠、路径中的 ./ 與 ../、结尾多出来的 # 或空參數。
這張表不用一次列全，先把首頁、栏目頁、几篇核心内容頁拿出来测，通常就能看出站点的 URL 生成习惯。
二、確認它們目前各自返回什么
對表里的每個地址，用 curl -I 或浏览器開發者工具看狀態碼和 Location：
- 全部 301 到同一個地址：說明服務端已做過统一，問题多半在頁面内的連結寫法；
- 部分返回 200、部分 301：索引里很可能同时存在两個候選地址；
- 返回 200 但内容略有差別（比如带參數的頁面排序不同）：要判断這是不是同一個頁面；
- 返回 404 或 500：先修可訪問性，再谈收錄。
同时對照日誌中蜘蛛訪問的完整 URL，往往能看到自己没意识到的寫法，比如带上了分頁參數、排序參數或一段来源标记。
三、归並的處理顺序
處理顺序建议從影响面最大的開始，改完一批观察一批：
- 選定規范版本：确定协议、主机名、是否带末尾斜杠、路径大小寫規則，寫成一句话，所有改動都以此為准。
- 服務器层做 301：http 跳 https、非 www 跳 www（或反之）、去掉重复斜杠、补全或去掉末尾斜杠。301 是明确的信号，比頁面里的任何提示都直接。
- canonical 自指：每個頁面寫自己的規范地址，不要寫到一個並不存在的地址，也不要在多個變体之間互相指。
- 统一站内連結：導航、面包屑、正文内鏈、站点地图只使用規范寫法，避免同一個頁面在不同入口下被寫成两種地址。
- 參數收敛：追踪參數在服務端或邊缘层剥离後再跳轉；對内容無影响的排序、视图參數，考虑不生成可抓取的 URL。
- 观察：改完後看日誌里各寫法的訪問占比是否向規范地址集中，索引中的候選地址數量是否慢慢减少。這個過程需要時間，不适合一天一改。
四、容易漏掉的细节
- 大小寫混用：服務器和 CDN 規則對大小寫的處理可能不同，路径统一用小寫最省事。
- 301 不要串成鏈條：A 跳 B 再跳 C，鏈路越長越容易在中途断掉。
- 頁面里的 JS 跳轉不能替代 301，它更像普通連結，處理方式完全不同。
- 带參數的地址如果已经被索引，先確認它是否真的有獨立内容；没有獨立内容就做归並，不要简單屏蔽了事。
- canonical 與 301 指向不一致时，先以服務端跳轉為准去排查。
- 站点地图只提交規范地址，別把各種變体一起寫進去。
五、日常核對清單
- 新增頁面是否只生成一個地址；
- 服務端跳轉規則是否覆盖新出現的频道路径；
- canonical 是否與目前地址一致；
- 日誌里是否出現新的變体寫法；
- 站点地图是否只含規范地址。
URL 寫法归並是件需要長期维護的事，新功能、新模板、新參數都可能重新制造出變体。把核對做成固定動作，比事後集中清理轻松得多。它不保證頁面一定被收錄，但能减少因地址歧义带来的判断成本。