渲染比
渲染比是指一个页面的文字里，有多大比例在服务器发出的 HTML 中就已经存在，也就是在任何 JavaScript 运行之前。
渲染比 95% 的页面，任何能抓取网址的东西都读得到；10% 的页面则是一具近乎空壳，只有在浏览器里才成为页面，而大多数爬虫并不是浏览器。这是最多网站没通过的一项检查。
渲染比为什么决定人工智能能否引用你？
模型不会浏览。某个程序抓取你的网址，留下收到的文字，而这些文字就是模型关于你的全部。如果你的内容是在客户端拼装出来的，留下的就只有一条导航栏和一个加载状态。
谷歌是造成混淆的那个例外。它确实执行 JavaScript，在抓取之后的一个独立阶段进行；而它自己的文档依然建议在服务端渲染，理由用它的原话说，是并非所有机器人都能运行 JavaScript。带来回答的那些机器人，大多属于后一类。
渲染比多少算好？
衡量方式是最终文字中有多少出现在原始 HTML 里。区间划分故意粗糙：高于 90% 时，不跑脚本页面基本也是完整的；低于 60% 时，爬虫看到的就不是你发布的那个页面了。
- 高于 90% —— 不跑 JavaScript，页面基本就是完整的。
- 60% 到 90% —— 主体内容在，有些部分不在，通常是评价、价格或标签页。
- 低于 60% —— 不执行 JavaScript 的爬虫看到的，和你发布的是两个页面。
- 接近 0% —— 一具空壳。这个网站只为浏览器存在。
渲染比太低该怎么修？
对重要内容采用服务端渲染或静态生成。任何现代框架都支持，多数项目只是从来没有打开过这个开关。设计不变，技术栈也不变，变的只是由谁来拼装 HTML。
如果重建不在考虑范围内，便宜的部分补救是：对提出请求的一方提供纯文本版本，通过内容协商，或者一份有文档说明的 Markdown 副本。这修不好页面，但至少让内容存在于爬虫够得着的地方。
这些依据是什么？
这里最有力的来源是谷歌自己的文档，而它常常被反着引用。以下三份都可以免费完整阅读。
- JavaScript SEO basics，Google Search Central
记录了抓取、渲染、索引三个阶段，并指出服务端渲染依然是个好主意，因为并非所有机器人都能运行 JavaScript。这一句话就是全部论据。
- GEO: Generative Engine Optimization
测量的是什么让内容在生成的回答中被看见。这些结论对爬虫从未收到过的内容一概不适用。
- llms.txt 约定
常见的部分性变通：为不会执行脚本的代理，发布一份页面内容的 Markdown 版本。
关于渲染比的常见问题
谷歌不是照样会执行 JavaScript 吗？
- 会，在抓取之后的渲染阶段执行。但这只说明了谷歌，对其他引擎什么都没说；而谷歌自己的文档依然建议服务端渲染，理由正是并非所有机器人都能运行 JavaScript。只为唯一会渲染的那个爬虫做优化，是押错了对象。
渲染比要好，是不是就得放弃 React？
- 不必。React、Vue 和 Svelte 都能在服务端渲染，基于它们构建的框架默认就这么做。渲染比低，几乎总是某个从未启用的配置，而不是技术本身的限制。