做蜘蛛池或站点运营时，入口頁上的連結经常不是寫死的绝對地址，而是相對路径。多數情况下這没問题，但如果頁面里出現過 base 标簽，解析基准就被改掉了，搜尋蜘蛛最终請求的地址可能落在一個你根本没打算推廣的域名上。日誌里出現陌生的抓取路径，很多时候原因就在這里。
現象：日誌里抓到的 URL 不是你以為的那個
典型表現是：入口頁地址是 https://a.com/dir/list.html，你希望蜘蛛去抓 a.com 下的目标頁，结果日誌里出現的却是 b.com 上的路径，或者一批 404、一批指向測試环境的請求。這时候先別怀疑蜘蛛池效果，先確認連結的解析基准對不對。
相對連結的解析基准是什么
HTML 里相對 URL 會基于“文档基准 URL”展開。没有額外声明时，基准就是目前文档自身的地址。例如入口頁是 https://a.com/dir/list.html：
- 連結寫 target/1.html，解析结果是 https://a.com/dir/target/1.html
- 連結寫 /target/1.html，解析结果是 https://a.com/target/1.html
- 連結寫 ../target/1.html，會先退一級再拼接
也就是说，路径寫法本身就决定了层級，斜杠位置和层級符号寫错，解析结果就會偏。
base 标簽會改寫整個基准
只要頁面里出現 base href，頁面上所有相對連結都會以它為基准，而不是以目前頁面地址為基准。举例：入口頁在 https://a.com/dir/list.html，頁面里声明 base href="https://b.com/"，連結寫 x/1.html，最终解析成 https://b.com/x/1.html。搜尋蜘蛛如果解析並跟進了這個連結，抓的就是 b.com。
base 常见的几種寫错方式
- 寫了 base href="/"，但站点部署在二級目錄，連結全部跑到根目錄
- base 里的域名漏了结尾斜杠，拼接结果變成 b.comx/1.html 這類错誤地址
- 頁面是 https，base 里却寫成 http，出現混合内容
- base 的值来自模板變量，多域名、多語言站点上輸出了別的域名
- 頁面由前端拼接或嵌在 iframe 中，base 的實际取值與预期不一致
按這几步排查
- 用抓取工具或命令行拉取入口頁的原始 HTML，不要用浏览器渲染後的 DOM，因為渲染過程可能額外插入基准
- 在源碼里搜尋 base，確認它的值以及出現的位置和次數
- 手工取一條相對連結，按 base 的值拼一次，得到實际會請求的完整地址
- 拿這個地址去服務器日誌里比對，按搜尋蜘蛛的 UA 篩選，看它請求的路径是否與你拼接的一致
- 如果解析到了其他域名，检查那個域名是否可達、是否返回正常狀態碼、内容是否為你要推的目标頁
- 修正後（改 base 或改連結寫法）再观察一段時間日誌，確認抓取路径回到预期范围
要不要干脆全部用绝對路径
對入口頁和站点導航来说，把連結统一寫成 https:// 開头的绝對地址，能省掉大部分解析歧义，排查时也一眼能看懂。代價是以後換域名或調整目錄结构时改動量大。折中做法是保留相對路径，但保證 base 只出現一次、值固定且正确，並在每次部署後抽查几條連結的解析结果。
相對路径本身不是問题，基准不對才是問题。排查时先確認基准，再看連結本身，顺序反了會白忙。
几個容易忽略的细节
- base 标簽只認第一個，後面再出現的會被忽略，模板叠加时容易踩
- base 的 target 属性只影响打開方式，不影响 URL 解析，別把两者混在一起看
- 协议相對連結 //example.com/x 會跟随目前頁面的协议，站点同时支持 http 和 https 时要留意
- 路径大小寫和结尾斜杠在拼接时會影响结果，有的服務器會当成两個地址
- 入口頁返回 200，不代表解析出来的那個域名也能正常返回，两邊都要單獨驗證
如果確認解析没問题、目标 URL 也能稳定返回，剩下的就是抓取节奏和收錄進度的事，不必因為一时没動静就反复改動入口頁结构——改動越频繁，日誌越难比對，排查成本反而更高。