不少站长把内容结构理顺了、标记补齐了、问答对也排好了，回头去问答案引擎，自己最得意的那几篇稿子还是不被提。反复检查内容质量找不出毛病，因为问题往往不在内容本身——抓取端拿到的那份 HTML 里，正文可能压根不存在。浏览器替你把内容渲染出来了，抓取工具没有这一步。
先分清「看得见」和「取得到」是两件事
浏览器打开一个页面，实际做了两件事：先下载 HTML，再执行 JS，把接口返回的数据填进 DOM。你眼睛看到的，是第二步之后的结果。
抓取端的情况要分三档看：
- 传统搜索引擎爬虫（百度、必应）具备一定的 JS 执行能力，但有配额、有超时、有失败率。能执行，不等于每次都执行、每次都执行完。
- 面向大模型语料与实时检索的抓取工具，多数只做第一步。拿到 HTML 就走，不等 JS，不发接口请求。
- 少数带浏览器内核的检索代理会做 JS渲染，但停留时间极短，异步加载慢一两秒就被截断。
结论很直接：正文进了 DOM 却没进初始 HTML，等于把内容押在「对方愿意多花一步」上。而在生成式检索链路里，这一步经常没有。
三步自查：确认正文到底有没有进源码
第一步：拿原始 HTML，别看浏览器
浏览器的「查看源代码」和「检查元素」是两回事：后者显示的是渲染后的 DOM，很多人在这里就误判了。最干净的做法是绕开浏览器，用命令行取一次：curl -s "https://你的域名/某篇文章" > raw.html。
拿到文件后剥掉 script 与 style，统计剩下的汉字数量，和页面上肉眼可见的正文量对比。差 30% 以上就要警惕，如果只剩导航、页脚和几行版权，那基本是一页空壳。
第二步：关掉 JS 再看一遍页面
Chrome 里进「设置 — 隐私和安全 — 网站设置 — JavaScript — 不允许」，然后刷新目标页面。剩下的部分，大致就是纯 HTML 抓取端能拿到的东西。
重点核六样：H1 在不在、正文段落在不在、表格和列表在不在、问答对在不在、发布与更新时间在不在、作者与来源信息在不在。这六样里少哪一样，对应的引用机会就少一块。
第三步：把最想被引用的句子逐条搜一遍
前两步看的是总量，第三步看的是要害。挑三段你最希望被整段摘走的文字——一句定义、一句结论、一句带数据的判断——各取 8 到 12 个连续汉字，在 raw.html 里直接搜。
搜不到，就说明这段不在服务端输出里。这一步比数字数更准，因为很常见的一种情况是：页面框架和导航都在 HTML 里，恰恰最有价值的那几个模块是靠接口现拉的。
四类最常踩的渲染坑
整站客户端渲染。 Vue、React 写的单页应用，HTML 里往往只有一个空 div，连标题都可能是占位符，不改就没有起点。
局部异步加载。 主体是服务端输出的，但参数表、用户评价、FAQ 折叠面板、价格模块是 JS 补上去的。麻烦在于，这几块恰好是最容易被整段引用的部分。
滚动加载与点击展开。 长文分页、「阅读全文」按钮、手风琴式问答。判断标准是看内容来源：如果内容本来就写在 HTML 里、只是用 CSS 隐藏，影响不大；如果是点击后才发请求，抓到的就是空的。
打断式拦截。 反爬中间件、地区跳转、Cookie 同意弹窗，会把整页 HTML 换成一屏提示。还有一种更隐蔽：服务端对陌生 UA 直接返回 403 或极简页面，自己用浏览器测一辈子也发现不了。
修法按成本从低到高排
最低成本：把核心段落做服务端直出。 不动整体架构，只把最需要被引用的部分——定义、结论、参数表、问答对——在服务端渲染进 HTML，交互仍交给前端。这一档投入产出比最高，一般改几个模板就能落地。
中等成本：做预渲染或静态生成。 对内容型页面生成完整的 HTML 快照，抓取端和用户拿到同一份东西。文章、帮助文档、产品参数页最适合走这条路，因为更新频率低、可以放心缓存。
较高成本：迁到服务端渲染或同构方案。 适合本来就在重构的站，不建议单纯为了爬虫抓取启动大改。
配套动作：别让折叠吃掉内容。 折叠交互可以保留，但内容实体必须写在 HTML 里，靠 CSS 控制显隐。这样用户看到的是干净界面，抓取端拿到的是完整文本。
改完之后怎么确认真的生效
三条验证缺一不可。
一是重跑第一步的 curl，把之前搜不到的三段关键句再搜一次，全部命中才算过。
二是换 UA 复测。至少测三种：正常浏览器 UA、常见抓取工具的 UA、以及空 UA。三次返回的状态码和正文内容应当一致。服务端按 UA 给不同内容，是自己给自己埋雷。
三是翻服务器日志。筛出非浏览器 UA 的请求，看响应码是不是 200、响应体大小是不是和正常页面同一个量级。日志里一片 200、但响应体只有几 KB，说明它们拿到的全是壳子。
一张可以直接照着跑的排查表
| 检查项 | 具体做法 | 通过标准 |
|---|---|---|
| 源码正文量 | curl 取原始 HTML，剥离脚本后数汉字 | 与页面可见正文相差不超过 10% |
| 关键句命中 | 取 3 段各 10 字，在源码中搜索 | 3 段全部命中 |
| 禁用 JS 复现 | 浏览器关闭 JavaScript 后刷新 | H1、正文、表格、问答、时间均在 |
| 多 UA 一致性 | 浏览器 UA、抓取工具 UA、空 UA 各测一次 | 状态码与正文内容一致 |
| 日志响应体 | 查非浏览器 UA 请求的响应大小 | 与正常页面同量级 |
| 折叠内容 | 检查折叠模块是 CSS 隐藏还是异步拉取 | 内容实体在 HTML 中 |
顺序反了，后面的功夫都白搭
写内容、补标记、排问答对，这些事都有价值，但它们全部建立在同一个前提上：抓取端确实拿到了这段文字。前提不成立，上层功夫落不到实处。
所以自查顺序应该倒过来做：先确认源码里有正文，再谈怎么把它写成更容易被引用的内容。
一个今天就能做完的动作：挑站内三篇你最希望被引用的文章，各跑一次 curl，搜一下里面的核心结论句。三分钟出结果，就能知道自己有没有站在这个坑里。