頁面本身没問题，内容也寫好了，但搜尋蜘蛛每次来都撞上一次跳轉，收錄就一直拖着。這種情况往往不在頁面质量上，而在 URL 的跳轉环节和返回的狀態碼上。下面按常见场景和排查顺序梳理一遍。
跳轉為什么會影响收錄
蜘蛛拿到一個 URL 後，如果服務器返回 3xx，它需要再發一次請求去拿目标地址。一次两次没問题，但跳轉鏈越長，消耗的抓取资源越多，蜘蛛放弃或延後處理的概率也越高。更麻烦的是，跳轉如果指向一個不可抓取、被屏蔽或者同样在跳轉的地址，這個 URL 在索引里就容易長期停留在“已發現”或舊版本的狀態。
先分清你属于哪種跳轉场景
整站換域名或 http 到 https
這類跳轉最容易出問题。常见错誤是 A 跳 B、B 再跳 C，形成鏈條。正确做法是让舊地址一跳直達最终地址，同时確認最终地址本身不再跳轉。跳轉上线後，站内連結、sitemap、canonical 都應该直接寫最终地址，而不是繼續指向舊地址。
單頁面改了 URL
内容還在、只是地址變了，用 301。302 和 307 表達的是临时，長期挂着临时跳轉，搜尋引擎可能繼續保留舊地址作為收錄對象，新地址反而進得慢。如果只是短期做活動頁、临时备用地址，临时跳轉没問题，但活動結束要及时處理。
自己给自己制造的跳轉
末尾斜杠、大小寫、协议、www 與非 www，如果站内連結寫法不统一，每個内鏈都會先撞上一次跳轉。這不是嚴重错誤，但會持續浪費抓取预算。统一站内連結寫法，並让 canonical 指向最终形態，能省掉很多無谓的往返。
维護頁和临时下线
網站维護时，用 503 並带上 Retry-After 說明预計恢复時間，比直接甩一個 200 的维護頁更清楚。用 200 返回维護内容，容易被当作软 404；長期 302 到首頁，也會让原 URL 的内容判断變得模糊。
狀態碼的選擇顺序
- 永久搬家：301 或 308，一跳到位，不要串鏈。
- 临时變更：302 或 307，明确是短期行為，並尽快恢复原狀態。
- 頁面確認不要了：404；确定永遠不會再提供该内容：410。
- 不要用 200 掩盖問题，也不要用跳轉掩盖 404。
排查顺序
- 從服務器日誌或抓取測試里，看蜘蛛實际撞到的是哪些狀態碼，而不是只看浏览器里的表現。
- 統計跳轉鏈長度，凡是超過一跳的，评估能否改成直连。
- 检查跳轉的终点：是不是 404、noindex、被 robots 屏蔽，或者又是一個跳轉。
- 检查 sitemap 與站内連結是否直接指向最终 URL。
- 检查舊跳轉是否還需要保留，外鏈和歷史收錄會依赖它，別急着清理。
- 观察一段時間後，看索引里的舊地址是否逐步替換成最终地址。
容易忽略的细节
跳轉目标如果带上了額外參數或片段，實际上會變成另一個 URL，收錄归属可能又跑偏。用 JS 跳轉或 meta refresh 表達地址變更，對蜘蛛来说信号不如 HTTP 狀態碼明确，能改服務器端跳轉就改。還有一種情况是跳轉後落地頁内容與舊頁差別很大，這會被当作一個新頁面重新评估，原来的信号不一定能完整繼承。
跳轉环节的排查思路很简單：让蜘蛛用最少的請求拿到最终地址，並且清楚知道這個 URL 是被搬走了、暂时不在，還是彻底没了。狀態碼寫對、鏈子缩短、内鏈统一，收錄交接通常就顺了。