做站点运营时经常冒出这种担心：正文被折叠在“展开全文”里、规格参数放在第二个 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 里。