做蜘蛛池的人经常會碰到一種入口頁：頁面本身能正常打開，但目标 URL 並不是用标准連結寫出来的，而是靠 meta refresh 或者一段 JavaScript 自動跳過去。這種頁面搜尋蜘蛛到底會不會跟？答案不是简單的“會”或“不會”，而取决于你用的是哪一種跳轉，以及爬虫在解析這一层时走到了哪一步。
先把三種“跳轉”分清楚
- 連結跳轉：入口頁里寫一個普通的 a 标簽，href 指向目标 URL。這是爬虫最明确、最容易處理的形式。
- 服務器跳轉：入口頁返回 301、302，浏览器地址栏直接變到目标 URL。這是 HTTP 层面的信号，通常在抓取入口頁时就已经完成。
- 頁面内跳轉：入口頁正常返回 200，HTML 里寫着 meta refresh，或者用 JavaScript 的 location.href 把自己送到目标 URL。這属于“渲染 / 解析阶段”的行為，也是最不确定的一類。
很多人把後面两類混在一起谈，其實它們的表現差別不小，尤其在蜘蛛池這種“入口頁數量多、目标 URL 數量更多”的场景下，差別會直接体現在抓取日誌里。
meta refresh 會被识別，但分量不如普通連結
主流搜尋引擎對 meta refresh 是有處理的：常见的寫法是在 head 里放一條類似 content="0;url=目标地址" 的标簽，延迟為 0 或很小的时候，解析器一般能從中讀出目标地址，並把它当作一個可訪問的 URL。也就是说，meta refresh 里的目标並不是完全不可见。
但“能讀出来”和“当作連結跟進”是两件事。實际表現上，meta refresh 经常被当成頁面的一種跳轉属性来處理，而不是像 a 标簽那样直接進入待抓取队列。结果通常是：目标 URL 被發現了，但抓取優先級偏低，跟進時間点也更靠後。如果延迟秒數寫得比較大，比如 30 秒、60 秒，部分爬虫在解析时甚至不會把它作為跳轉處理，只当成頁面里的一段文本。
JavaScript 跳轉的發現更不稳定
用 location.href、location.replace 或者前端路由做的跳轉，依赖的是爬虫是否执行頁面脚本。能不能执行脚本，各家爬虫不一样，同一家爬虫在不同资源配額下也可能不一样。即使能执行，一般也要排進渲染队列，等待時間明顯長于直接解析 HTML。
所以在蜘蛛池里，纯 JS 跳轉是最不该当作唯一入口路径的一種寫法。它不报错，頁面人眼看也正常，但目标 URL 可能長時間停留在“已發現未抓取”，日誌里只看到入口頁被訪問，看不到目标頁。
和标准 a 連結相比，差在哪
- 發現明确度：a 标簽是最清晰的信号；meta refresh 次之；JS 跳轉最模糊。
- 抓取时机：a 标簽通常在解析入口頁时就被登记；meta refresh 往往延後；JS 跳轉要等渲染。
- 可驗證性：a 标簽能在日誌里直接對應到目标 URL 的請求；跳轉方式经常只能看到入口頁，目标頁迟迟不出現。
- 容错性：連結寫错還能靠爬虫反复尝试；跳轉寫错，往往连“有過這個目标”都看不出来。
實际操作上的几点建议
- 入口頁的主路径尽量保留标准 a 标簽，href 寫完整绝對地址，跳轉只作為辅助。
- 如果确實要用 meta refresh，延迟尽量设小，並把地址寫在 head 里，不要用 JS 動態寫入。
- 別把跳轉代碼塞進 noscript，或者让跳轉依赖用戶交互（点击、滚動）才触發。
- 避免多层 meta refresh 串联，一层接一层會让爬虫在解析鏈上消耗更多预算。
- 入口頁本身要能正常返回 200，跳轉目标和入口頁不要跨到完全無關的站点。
- 用抓取日誌和站点後台的抓取統計核對：目标 URL 有没有實际請求记錄，間隔多長，是不是只抓了一次。
需要提醒的是，無论用哪種跳轉方式，都只是给搜尋蜘蛛提供一個發現 URL 的路径，並不代表目标頁一定會被收錄或获得排名。跳轉方式能改善的是“被發現和被跟進”的概率，收錄结果仍取决于目标頁本身的质量和站点整体情况。
如果非要在几種寫法里排序：标准連結最稳，meta refresh 次之，纯 JS 跳轉最不可靠。做蜘蛛池时，把入口頁的跳轉方式统一成普通連結，再用日誌確認目标 URL 是否真的产生了抓取請求，比反复調整跳轉參數要有效得多。