很多时候，站点在日誌里能看到搜尋引擎蜘蛛的訪問记錄，抓取量也正常，但真正進入索引的頁面始终只有首頁和少數几個栏目頁。問题未必出在 Sitemap 或内鏈，而可能是内容在到達蜘蛛之前，被几层“门”挡住了：同意彈窗、登入狀態、地域跳轉、人机校驗。這些机制對普通用戶是合理的，對蜘蛛却常常直接把正文截断。
蜘蛛看到的，是一次没带狀態的請求
搜尋引擎蜘蛛抓取一個 URL 时，通常不带 Cookie、不点击按钮、没有登入態，也不一定會执行頁面上的全部脚本。它拿到的就是服務器在“一個干净請求”下返回的响應。如果這個响應里没有正文，只有一段等待脚本加载的容器，那後續能不能看到内容，就完全取决于渲染能力與彈窗是否阻塞。
容易被忽略的四道门
一、Cookie 同意层
同意管理平台如果采用“未同意前不輸出正文”的做法，蜘蛛拿到的就是一個空壳頁面。更常见的坑是：彈窗由脚本注入並覆盖整個视口，正文虽然還在 DOM 里，但渲染後可讀区域被判定為主要内容為空。相對稳妥的做法是让正文照常輸出，彈窗用固定定位覆盖，用戶選擇後只影响統計脚本，不影响内容本身。
二、登入墙與會員内容
登入後才能看的内容預設抓不到，這是设計使然，不是故障。如果希望這部分内容的标题和摘要被用戶搜到，可以保留一段無需登入即可看到的介绍，並配合付費墙相關的结构化資料說明可訪問范围。但要清楚：這不等于正文會被索引，也不该指望靠绕路让蜘蛛越過登入。
三、地域與 UA 判断
按 IP 归属地做 302 跳轉、按 User-Agent 返回不同模板，都會让蜘蛛走到的路径與用戶不一致。如果蜘蛛被跳到另一個 URL，它抓到的就是那個頁面；如果按 UA 返回精简版甚至空版，抓到的那一版就是最终版本。
四、人机校驗與频率限制
WAF 的脚本挑战頁、驗證碼頁，對蜘蛛来说等同于一次異常响應。偶尔一次問题不大，但如果每次抓取都撞上校驗，整段 IP 可能被降速甚至短时封禁，表現為抓取量骤降。通常的解法是確認搜尋引擎的 IP 段，通過反向 DNS 校驗後加入白名單，而不是简單放過某個 UA 字符串。
怎么確認是哪一道门在起作用
- 用不带 Cookie 的請求抓取首頁和一個詳情頁，直接看响應正文里有没有目标文字。
- 關閉 JavaScript 再抓一次，對比内容是否還完整。
- 查服務器日誌，看蜘蛛拿到的狀態碼是 200、302 還是 403，以及返回的字节數是否明顯偏小。
- 用渲染後的 HTML 快照對比原始 HTML，確認正文是服務端輸出還是脚本拼出来的。
把门開在该開的位置
- 正文優先服務端渲染，彈窗、推荐位、個性化模块再交给前端。
- 被限制的内容返回明确的 401/403，不要返回 200 加空正文，那會让爬虫反复回来。
- 同意彈窗不要占據首屏全部文本，也不要在未同意时清空主体。
- robots.txt 與頁面 meta 的規則要和實际可訪問性一致，避免声明允许却被 WAF 拦下。
蜘蛛没拿到内容，通常不會带来惩罚，只是那個 URL 没有被索引的理由。排查顺序建议從“服務器返回了什么”開始，而不是從“是不是被降權了”開始。
把這些门前移或後置，让正文在最朴素的一次請求里就能被讀到，往往比反复提交 Sitemap 更有效。