你接手了一个 robots.txt，里面 disallow 了 /assets/、/_next/static/ 或 /wp-content/plugins/。理由是 “Googlebot 不需要爬静态资源，省 crawl budget”。但 Googlebot 必须 FETCH CSS 和 JS 才能渲染页面。拿不到，Googlebot 看到的就是一个没布局、半坏的页面，分不清正文和模板、跑不了注入内容的 JS，可能还被标 mobile-unfriendly。Search Console URL Inspection 会显示 “Page resources couldn’t be loaded” 警告。
Google 从 2014 年就明确过：不要 block 影响渲染的 CSS、JS、图片。“crawl budget”在这件事上的直觉是错的——Google 处理静态资源跟 HTML 是分开调度的。
常见原因
1. 2010 年风格的”block /assets/“老规则
那个指令看起来清爽：别浪费爬虫预算。2010 年 Google 还不渲染 JS 时是对的，2015 年起就过时了。
怎么判断：curl https://yoursite.com/robots.txt。看到 Disallow: /assets/、Disallow: /static/、Disallow: /_next/、或 Disallow: /wp-content/plugins/ 就是它。
2. 通配符规则误伤 CSS
Disallow: /*.json$ 想挡 API 响应，顺带挡了 manifest.json、webpack-runtime.json 或者构建需要的配置文件。
怎么判断：列出所有 Disallow: /*.<extension> 规则，对照实际静态文件路径测试。
3. CDN 子域在主站 robots.txt 没问题，但 CDN 自己的有问题
资源在 cdn.example.com。CDN 自己的 robots.txt（Googlebot 拉 CSS 时会去看）整站 disallow，因为没人配过。
怎么判断：curl https://cdn.example.com/robots.txt。如果是 User-agent: * Disallow: /，主站 robots.txt 再正确也救不了 CDN 上的资源。
4. Fastly / Cloudflare WAF 规则挡 Googlebot 访问 /static/
不是 robots.txt，但效果一样。WAF 规则封 bot user-agent 访问资源路径，防 hotlinking。Googlebot 拿到 403。
怎么判断：curl -A "Googlebot/2.1 (+http://www.google.com/bot.html)" https://yoursite.com/static/main.css。状态 403 / 401 就是 WAF 在挡。
5. 子目录 robots.txt 覆盖父目录
https://yoursite.com/robots.txt 允许资源，但 https://yoursite.com/app/robots.txt 单独存在又 disallow。其实 robots.txt 只在根生效——但配错的文件服务可能按路径返回不同内容。
怎么判断：代码库里有多份 robots.txt。应该只有一份，从域名根目录服务。
6. Disallow /api/ 挡了 JS 数据接口
SPA 常见：页面渲染依赖 /api/page/foo。robots.txt 里 Disallow: /api/，Googlebot 客户端渲染就跑不起来。
怎么判断：页面主要靠客户端渲染、并且 robots.txt 里有 Disallow: /api/。渲染必失败。
7. Disallow: /*? 挡掉资源上的 query string
想去重参数 URL。副作用：带 cache-bust 版本号的资源 main.css?v=abc123 也被挡。
怎么判断：看带版本号的资源 URL。带 ? 的都被这条通配符挡了。
最短修复路径
第 1 步：审计当前 robots.txt
curl -s https://yoursite.com/robots.txt打印出来跟团队过一遍，每条 Disallow: 都问一句：“Googlebot 需要 fetch 这个才能渲染或理解页面吗？“
第 2 步：明确放行关键资源
把渲染必需的路径白名单：
User-agent: *
Disallow: /admin/
Disallow: /private/
User-agent: Googlebot
Allow: /assets/
Allow: /static/
Allow: /_next/static/
Allow: /api/articles/
Allow: /wp-content/themes/
Allow: /wp-content/plugins/Allow: 对更具体路径覆盖 Disallow:。
第 3 步：用 Search Console 验证渲染
Search Console → URL Inspection → “Test live URL” → “View tested page” → “Screenshot” + “More info” → “Page resources”。任何标 “Blocked by robots.txt” 的资源都在伤害渲染。改完 robots.txt 再测一次。
第 4 步：核 CDN robots.txt
curl https://cdn.example.com/robots.txt如果返回全局 disallow，去修 CDN 侧的 robots.txt（或干脆删掉让它 404——Googlebot 把 404 当成”没规则、允许”）。
第 5 步：WAF 白名单 Googlebot
Cloudflare：Security → Bots → “Verified Bot” 白名单。Fastly：VCL 规则匹配 User-Agent 含 Googlebot 放行。一定要用反向 DNS 校验，不能只靠 UA 字符串（可伪造）。
第 6 步：通配符规则慎用，必测
把过宽的 Disallow: /*.json$ 换成精准路径 Disallow: /api/admin.json。上线前对照实际文件清单跑一遍通配符。
第 7 步：重提，观察
修完 robots.txt，挑几个关键页面 request indexing。1-2 周内 Search Console 里 “Page resources blocked” 警告应该回落，页面重新正确渲染。
哪些情况可能不是你操作错了
百万级 URL 且服务器吃紧的大站，crawl-budget 的担心是合理的，但解法是站内链接和 sitemap 优先级，不是 block 渲染资源。5 千页的站别套企业级战术。
容易误判的情况
误判成 “JS 没渲染” 问题。症状重叠（rendered HTML 是空的），但根因不同：这里是 Googlebot 根本拉不到 JS，不是 JS 跑了没渲染。出现 JS 渲染问题时先看 robots.txt。
预防建议
robots.txt默认放行一切，除了/admin/、/private/、搜索结果页。- 永远不要 disallow
/assets/、/static/、/_next/、/wp-content/themes/或/wp-content/plugins/。 - CI 跑 robots.txt 对照已知必需资源路径列表的检查。
- 上线时一并校 CDN robots.txt。
- 每年随资源路径演进审一次 robots.txt。
FAQ
- 全放行 Google 会不会因为爬太多惩罚我？ 不会——Google 自动调爬速。block 资源不会显著降低爬取量。
/wp-admin/该挡吗？ 该——那个跟渲染无关、且含私有端点。