做站点运营时经常冒出這種担心：正文被折叠在“展開全文”里、規格參數放在第二個 Tab、图片靠懒加载才出現——蜘蛛到底能不能看到？答案是“分情况”。關键不在于是不是折叠，而在于這些文字有没有出現在服務器返回的初始 HTML 里。
先分清三種“看不见”
- 样式隐藏：内容在源碼中，只是被 CSS 折叠或设為 display:none。
- 交互切換：Tab、轮播里的非目前項，HTML 里存在，展示时才需要点击。
- 執行时生成：内容由脚本請求接口後插入 DOM，初始 HTML 里是空的。
前两種偏向“展示問题”，第三種是實打實的“抓取問题”，處理思路完全不同。
蜘蛛拿到的往往不止一份内容
現代搜尋引擎一般會先取初始 HTML，再把頁面放進渲染队列，用無头浏览器执行脚本後得到一份渲染结果。理论上两份都會看，但渲染要排队、有超时、也可能因资源加载失敗而不完整，成本遠高于直接讀 HTML。所以：
- 能寫在初始 HTML 里的正文，就不要留给脚本拼装；
- 渲染队列是“可能發生”，不是“一定會發生”；
- 如果接口地址被 robots.txt 屏蔽，或渲染依赖登入態，内容照样拿不到。
折叠面板本身不是問题
用 details/summary 或按钮控制的展開区域，只要文字在源碼里，一般不影响被抓取和收錄。需要留意的是另外两類做法：
- 把核心段落藏起来，展開前頁面几乎讀不到有效内容，容易被判定為内容量不足；
- 用隐藏文本堆關鍵詞，這属于作弊——風險不在“能不能被讀到”，而在“被讀到之後怎么判”。
一個简單的判断标准：把 CSS 和 JS 全部關掉，頁面上還剩多少能讀懂的内容？剩下的那部分，才是收錄最稳的部分。
懒加载與無限滚動怎么處理
图片懒加载通常没問题，但寫法有讲究：使用原生 loading="lazy" 时，src 仍指向真實图片地址更稳妥；如果只寫 data-src、由脚本在滚動时替換，就要確認脚本执行後地址确實會被寫入。列表頁的無限滚動更麻烦——後續條目既不在初始 HTML 中，也没有獨立地址。可行的做法是保留分頁 URL，滚動时用 history API 更新地址，让每一批内容都有可直接訪問的入口。
容易踩的两個坑
- 把分頁彻底删掉，只留滚動加载，结果第 2 頁之後既抓不到也認不出；
- 渲染依赖的接口加了鉴權或限速，蜘蛛請求时直接返回错誤，頁面就只剩一個空壳。
上线前的三個自检動作
- 右键“查看網頁源代碼”（不是元素面板），搜尋正文里的一句话，確認它在初始 HTML 中。
- 禁用浏览器 JS 後重新打開頁面，观察還剩多少内容。
- 在服務器日誌里找到该地址的抓取记錄，對照抓取时返回的字节數與頁面真實大小是否接近。
折叠、Tab、懒加载都是正常的交互手段，不必為了收錄把頁面做得又長又平。需要守住的底线只有一條：决定這個頁面價值的那段文字，應该出現在你交付给蜘蛛的第一份 HTML 里。