蜘蛛池入口頁能不能被抓，很多时候卡在最基础的一层——HTTPS 握手。蜘蛛訪問入口頁的第一步是建立 TLS 连接，這一步失敗，後面的 robots.txt、連結、正文都無從谈起。日誌里可能只留下一句“连接超时”或“SSL 错誤”，看起来零散，其實有比較固定的排查顺序。
為什么證书問题會表現成“完全抓不到”
和 404、403 不同，證书错誤發生在 HTTP 之前。蜘蛛拿不到狀態碼，也拿不到頁面内容，只能放弃這次請求。更麻烦的是，不同抓取节点的表現可能不一致：有的节点能訪問，有的不能，于是在日誌里呈現出“偶發失敗”的样子，让人誤以為是限速或反爬。
常见的技術原因
- 證书鏈不完整：只部署了站点證书，没有带上中間證书。部分客戶端和爬虫不會自動补齐鏈條，直接判定不可信。
- 域名不匹配：證书簽發给带 www 的版本，入口頁用的却是不带 www 的寫法，或者反過来，而跳轉又没有做干净。
- SNI 配置不当：同一 IP 上放了多個站点，服務器對未知 SNI 返回預設證书，蜘蛛拿到的是另一個域名的證书。
- 證书過期或服務器時間偏移：有效期判断依赖系統時間，時間漂移同样會造成校驗失敗。
- 解析或鏈路問题：只解析到單個失效节点、只配了 IPv6，或者某個机房出口到源站不通。
跳轉與 HSTS 的坑
HTTP 到 HTTPS 的跳轉如果寫成循环，蜘蛛會在几次跳轉後被终止；HSTS 一旦配上較長的 max-age 或提交了预加载列表，浏览器和部分客戶端會强制走 HTTPS，此时如果證书有問题，连“降級訪問”這條退路都没有。轉發鏈路上每一跳都要確認最终落到唯一地址，並且返回 301，而不是来回摆動的 302。
混合内容與资源加载
入口頁本身是 HTTPS，但頁面里的脚本、样式、图片走 HTTP，浏览器會拦截，渲染型抓取也可能拿不到這些资源。如果連結是靠 JS 動態生成的，资源加载失敗基本等于連結不存在。检查方式很直接：打開開發者工具，看控制台有没有混合内容警告，再看渲染後的 DOM 里連結是否真的出現。
一個可执行的排查顺序
- 先用 curl -I 看响應头，再用 openssl s_client 带上 servername 參數看證书鏈，確認鏈條完整、域名匹配、有效期正常。
- 換不同的 SNI 再连一次，確認服務器不會對任意域名都回預設證书。
- 把 http/https、带 www/不带 www 四種组合各訪問一次，画出跳轉路径，確認没有循环和多余的中間跳。
- 在服務器日誌里筛 SSL/TLS 相關错誤，看失敗是否集中在某個 IP 段、某台机器或某個時間段。
- 換一個網絡出口，比如不同机房、不同 ASN，再重试一次，区分是全局問题還是個別鏈路問题。
- 以上都正常，再回到 robots.txt、nofollow、JS 渲染、目錄深度這些更上层的话题。
把證书和跳轉修好，只是把“抓不到”還原成“抓得到”。至于抓取频次、是否收錄、權重如何，仍然取决于内容质量、站点整体表現和搜尋引擎自己的判断，別把技術修复当成效果承诺。
日常维護上的两点建议
- 把證书到期時間、跳轉規則、入口頁可達性放進例行巡检，別等到抓取量掉了才回头查。
- 更換證书或調整机房时，先在小范围驗證，再全量切換，避免一次改動把整池入口頁同时打挂。
排查這類問题的價值在于把不确定性缩小：当你能確認蜘蛛确實连得上、能拿到 200、能讀到連結，後面關于内容、更新节奏、投放量的讨论才有意义。反過来，如果连握手都過不去，再多的連結和再好的正文也無從被看到。