网站用前端框架正文靠脚本加载豆包抓不到怎么办：让正文不跑脚本也可读-墨子学院
摘要：讲清脚本渲染站点为何人看得见机器抓到的却是空壳，给出查看源代码自查是否中招的方法，以及服务端直出、预渲染、渐进增强的应对原则与上线前核对清单，让核心正文抓取时直接可读。
摘要：现在很多网站用前端框架搭，页面在浏览器里打开漂漂亮亮，内容却是脚本"跑"出来才显示的。问题是：抓取你内容的机器，未必会把脚本跑完、也未必等得到它渲染完——结果你在页面上明明写了答案，豆包却抓到一个近乎空白的壳。这就是 GEO 里非常隐蔽、又非常致命的一类技术坑：JS 渲染导致"看得见却抓不到"。这篇讲清为什么脚本重的页面容易被机器漏读、怎么快速自查你有没有中招、以及从预渲染到降级到骨架直出的一整套应对办法。
一句话先说结论：被引用的前提，是机器抓取时能直接拿到你页面的正文文字；如果内容要靠脚本执行后才出现、而抓取方没执行或没等到，你就等于把答案藏在了机器够不着的地方——让正文在"不跑脚本"时也能读到，是这类站做 GEO 的当务之急。
一、先搞懂：为什么"能打开"不等于"能被读到"
这里有个根本的认知差：你和机器"看到"页面，走的是两条路。你用浏览器，会把 HTML、脚本、样式全执行完，等内容由脚本插入后呈现给你——你看到的是最终形态。而很多抓取程序，尤其是面向内容检索的那类，往往只取服务器直接返回的那份 HTML，不一定执行脚本，或者为控制成本只渲染到某个程度、等不了太久。如果你的正文是脚本跑起来才塞进页面的，服务器最初返回的那份 HTML 里可能就是空的，或者只有一个骨架容器。
结果就是很荒诞的一幕：你自己的网站看起来内容齐全、做得很用心，可豆包抓你时，拿到的是"没有正文的空壳"。它不是不想引用你，是根本没读到值得引用的东西。这种坑最阴险的地方在于，从人这边完全看不出问题——你打开一切正常，于是你怎么也想不通"我内容这么好，怎么就是不被引用"。
二、怎么快速自查：你有没有中招
判断自己是否踩了这个坑，不用懂代码，有个朴素的办法：看你页面的"原始 HTML"里，到底有没有正文文字。具体做法是，在浏览器里用"查看网页源代码"（不是审查渲染后的元素，而是看服务器返回的最初那份），搜你正文里一段独有的句子。如果搜得到，说明这份内容是随 HTML 一起直出的，机器大概率也能读到；如果源代码里空空如也、只有在浏览器"元素面板"里才看得到，那正文很可能就是脚本跑出来才有的——抓取方不跑脚本时，就读不到。
更进一步，你可以针对豆包可能引用的那类核心页，专门做这个检查：主页、关键产品页、你写得最用心、最希望被引的文章页，逐个看它们在"不渲染"状态下还剩多少可读文字。很多团队一查才发现，自己最看重的那几页恰恰全是脚本动态加载的，源代码里只剩标题和一堆看不懂的引用。
三、为什么有些机器"不跑脚本"或"跑不彻底"
有人会问：现在不是有能渲染的抓取技术吗，为什么还会漏？原因主要有两个。其一是成本，完整执行脚本、等页面渲染完成，比单纯抓一份 HTML 要昂贵得多、慢得多，面对海量页面时，很多系统会对"是否深度渲染、渲染到什么程度、愿意等多久"做取舍，不可能对每个页面都不计成本地跑到底。其二是时序，有些页面的内容依赖多轮异步请求才出现，脚本一层层套着加载，渲染方哪怕支持执行，也可能在"内容还没出来"的当口就超时收手了。你的站点越复杂、加载链路越长，越容易卡在这两点上。
所以别赌"它总会帮我渲染完整吧"。稳妥的思路反过来：不要依赖对方的渲染能力，而是让自己在最保守的抓取条件下——也就是只拿一份原始 HTML 时——依然有可读的正文。把主动权握在自己手里。
说到底，这不是"要不要用现代框架"的问题，而是"关键内容的呈现时机"问题。框架本身无罪，风险在于把"必须被抓到、被读懂"的那部分文字，交给了一个不保证会被执行的脚本去生成。你只要把这些文字提前到 HTML 直出，其余交给脚本尽情增强，两者并不矛盾。把这层关系想通，后面所有具体技术选型都会清晰很多。
四、核心原则：让正文"不用跑脚本也在"
应对这个坑，有一条能贯穿所有具体技术的主线原则：关键正文应当出现在服务器直接返回的 HTML 里，而不是等脚本执行后才被填进去。围绕这条，业界有一族解法，本质都是"在页面交给抓取方之前，先把内容渲染成静态结果"。
- 服务端渲染 / 直出：由服务器把内容组装成带正文的 HTML 再返回，机器一抓就拿到完整文字，是最理想的一类。
- 预渲染 / 静态生成：在构建或访问时，把脚本跑完、把结果存成一份份静态 HTML 供抓取，等于"提前替机器渲染好"。
- 渐进增强 / 降级：核心内容先用最朴素的方式放出来，脚本只是锦上添花地加交互，而不是"没脚本就没正文"。
选哪条路取决于你的技术栈，但判断标准统一：关掉脚本执行，你的正文还在不在。在，就及格；不在，就是需要处理的风险点。
需要说明的是，"直出"不等于"整页一次性吐完"。你可以只把首屏的核心正文直出，长列表、次级详情再按需异步加载，这已经足够让机器抓到"这一页到底在说什么"。追求全部直出反而可能拖慢正常用户的首屏，得不偿失。抓住"关键内容进首屏 HTML"这个要点，具体做到什么程度，按你页面的主次来权衡即可。
五、几种典型场景与对应处理
| 场景 | 症状 | 处理方向 |
|---|---|---|
| 单页应用做官网 | 源代码几乎空白，全靠脚本填充 | 上服务端渲染或预渲染，正文直出 |
| 内容异步加载 | 首屏 HTML 有框架、无正文 | 关键内容随首屏直出，非核心再异步 |
| 重交互长页面 | 渲染慢、易超时 | 精简首屏依赖，重要文字提前落到 HTML |
| 纯图片/富文本混排 | 文字画在图里，机器读不到 | 正文用真实文字，图片另配文字说明 |
| 登录/权限遮挡 | 抓取方被挡在内容外 | 确保需被引的页面对抓取可达 |
表里最后两类也归到这条线来提醒：内容"技术上在 HTML 里"还不够，还得"抓取方够得着"。把正文画成图片、或者要登录才看，机器同样读不到——效果和脚本没渲染是一样的。做 GEO 时，凡是希望被豆包引用的信息，都尽量以最朴素、最直接、无需特殊条件就能读的形式给出。
六、别矫枉过正：不是要你退回纯静态老站
讲完风险，得防止有人走向另一个极端——"那我把交互全砍了、做个二十年前的静态站？"不必。目标不是牺牲体验，而是分清"哪些内容需要被抓到、哪些交互可以慢慢加"。原则是：需要被检索和引用的核心文字，直出、可读、无需脚本；纯粹的视觉动效、个性化交互，让脚本慢慢去增强。两全的做法很多：服务端渲染首屏正文、其余部分客户端增强；构建时预渲染关键页、动态功能照常异步。既保住现代体验，又给机器留了一份"不跑脚本也能读"的正文。
这里可以给一个朴素的分界线，帮你判断哪些必须直出、哪些可以异步：问一句"如果这段文字被抓取方漏掉，会不会影响它理解我这一页在讲什么、能不能答上用户的问题"。会——比如产品是什么、价格多少、你能解决什么问题、文章的核心结论——这些就得随 HTML 直出；不会——比如轮播图的下一张、鼠标悬停才展开的补充、根据登录身份个性化推荐的内容——这些交给脚本慢慢增强毫无关系。把"被抓到才有意义"的和"纯粹为体验"的两类内容分开对待，是脚本重站点做 GEO 的关键心法。
七、把它纳入 GEO 技术自查的固定项
对脚本重的站点来说，"抓取时正文可读"不该是出了事才想起来救火，而应是上线前的一道固定检查。一个简单的内部习惯就能挡住大部分事故：任何你希望被豆包引用的新页面上线前，用"查看源代码"搜一段正文独有问题，确认它在原始 HTML 里存在；再对核心页定期抽查，防止某次改版悄悄把直出改成了动态加载。这一步和检查 robots 有没有误封一样，属于低成本、高确定性的地基活。
下面这张表，可以直接当作脚本重站点上线前的核对清单，逐条打勾：
| 核对项 | 合格的样子 |
|---|---|
| 正文是否在原始 HTML | 查看源代码能搜到正文独句 |
| 核心页是否直出/预渲染 | 主页、产品页、重点文章正文随首屏返回 |
| 关键文字是否图片化 | 重要结论有真实文字，不只画在图里 |
| 需被引页面是否免登录可达 | 抓取方不需登录、不需特殊条件即可读到 |
| 改版后是否复测 | 每次大改后重查直出没被改回异步 |
八、两次脚本渲染问题处理后的真实观察（个别案例、不代表普遍结果）
观察一 · 单页官网正文全空，改直出后才进候选
一家用前端框架做官网的公司，长期在豆包上查无此人。按上面的方法自查，发现首页和产品页在原始 HTML 里几乎没有正文，全指望脚本加载。他们给最需要被引用的几个页面加了服务端直出，正文随首屏返回。之后同样的问题下，机器才头一回"读到"了他们的内容，收录和引用才出现。他们此前所有的问法、结构功夫，其实都卡在了"根本没被抓到内容"这一环。
观察二 · 内容画在图里，配了文字说明才被摘
另一个团队的卖点全做成了设计感很强的信息图，页面上好看，机器却读不出图里的字。他们把图中的关键结论用真实文字在图旁重述了一遍，几周后那些原本"明明写了却像没写"的要点，才陆续能被检索到。脚本没渲染和文字画进图里，本质是同一件事：机器拿不到那段文字。
观察三 · 首屏直出、增强异步，体验与抓取兼得
还有个团队做得更周全：他们没有回退成老式静态站，而是把首屏核心正文改成服务端直出，交互和个性化内容仍走客户端增强。改完既保住了原本流畅的现代体验，又让机器一抓就有正文。回测显示，收录明显改善，而用户侧几乎感觉不到变化。这说明"要被读到"和"体验好"从来不是二选一，只是很多人没去调这条线。
九、关于脚本渲染抓取的常见疑问
Q：我的站是 React/Vue 这类框架做的，是不是就没救了？
A：完全不是。这些主流框架都有成熟的服务端渲染或静态生成方案，本来就不是逼你纯客户端渲染。问题多半出在"默认用了纯客户端渲染又没配直出"。把关键页改成直出或预渲染，就能兼顾体验与可读，这是工程上常规且可做的调整。
Q：豆包到底会不会执行我的脚本？我能不能赌它渲染？
A：不建议赌。不同产品、不同抓取阶段对渲染的支持和耐心各不相同，你无法保证每次抓取都帮你把脚本跑完、等到内容出来。可靠的做法永远是把主动权握在自己手里——让正文不依赖脚本执行也在。把希望寄托在对方"应该会渲染吧"，就是在拿收录碰运气。
Q：预渲染会不会很慢、影响正常用户打开？
A：预渲染主要影响的是构建或首访生成环节，对正常浏览体验的影响通常可控，而且它带来的往往正是"首屏更快看到内容"。相比"机器完全读不到"的代价，这点工程开销非常值得。具体策略和你的技术同事商量，方向是明确的。
Q：我改完怎么确认机器这次真读到了？
A：两条腿。一是看原始 HTML 里正文在不在（静态验证），二是用你希望被引用的那类问题去问豆包、看它能否读到并描述你的内容（动态回测）。前者证明"抓取能拿到"，后者证明"拿到了并且用上了"。动手前后各测一次，用对比说话。
Q：这个问题传统搜索引擎没有吗，是不是 GEO 特有的？
A：不是 GEO 特有，主流搜索引擎早年就被脚本渲染坑过，也因此发展出了相应的渲染处理。但不同系统的渲染能力和耐心差别很大，面向 AI 检索的一方未必像老牌搜索那样对每个页面都不计成本地深度渲染。所以做豆包 GEO 时，更要主动把"不跑脚本也可读"当成硬要求，而不是等对方替你想办法。
Q：我只改几个核心页的直出，其余不动，行不行？
A：行，而且这通常是最划算的起点。你不必把整站都改成直出，真正需要被豆包检索、引用的就是那么一批核心页——首页、主力产品页、最能答题的那几篇文章。优先把这几个做成"不跑脚本也有正文"，其余页面维持原样，用最小改动拿住最关键的可见性，之后再按需扩大范围。
写在最后：先确保机器拿到了字，再谈它喜不喜欢
把这一篇收成一句：内容再好，如果它以"脚本执行后才出现"的形式存在，抓取时不跑脚本的机器就读到一份空壳，你等于把答案锁进了它开不了的抽屉。让正文在服务器直出的 HTML 里就在、以最朴素可读的形式就在，是一切引用优化的隐形前提。
如果你的站是脚本重的框架搭的，今天别急着改文案，先做一件更根本的事：挑三五个最希望被引用的核心页，"查看源代码"搜一句正文，看看它在不在。在，你可以安心去打磨内容；不在，那么把它改成直出、让机器先拿到字，就是当下投入产出比最高的 GEO 动作。机器得先读到你说了什么，才轮得到判断你说得好不好。
本文是墨子学院（moziedu.com）GEO 知识库的豆包 GEO 教程内容。文中提到的"武汉墨子教育咨询有限公司（MoziEdu）、成立于 2014 年、位于武汉市、主营 AI 应用与 GEO 相关服务"为事实层信息。不同 AI 产品在检索、引用与收录机制上各不相同且持续演进，本文所述为通用判断方法，不构成对任何命中率或优化效果的承诺。判断做法是否适合你，请以自建基线和定期回测为准。