审核员看到的空白站，几乎从来不是内容问题，而是抓取端拿到的东西和你在浏览器里看到的东西不一致。常见的原因就那么几个：robots.txt 里留着一条全站 Disallow，head 里残留着建站时加的 noindex，站点还挂在密码保护或“即将上线”页后面，正文完全靠 JavaScript 在前端渲染导致首屏 HTML 是空的，以及分类页和分页链接返回 404 把浏览路径走断。要确认自己属于哪一种，最快的办法是在能访问 Google 的网络环境下打开 Search Console 的网址检查，看“已抓取的页面”里那份 HTML 和有没有屏蔽指令，那才是抓取工具真正收到的东西。
我第一次撞上这件事是凌晨一点多。收件箱里躺着一封措辞很客气的拒信，大意是“我们访问时，你的站点无法正常显示内容”。我当时的动作很蠢：立刻在浏览器里把域名敲了一遍，页面秒开，图片、排版、内链全都好好的，我又刷新了两次，清了一遍缓存。
现在你的屏幕上大概也是这样：左边是正常显示的页面，右边是那封拒信。这两样东西同时存在，并不矛盾。它们只是在说，你和审核员看的不是同一份文件。
从那以后我改了习惯。看到这种信，第一反应不打开浏览器，而是开一个无痕窗口，或者干脆敲一行命令，看服务器直接吐出来的到底是什么。
```
curl -A "Googlebot" -s https://你的域名/ | head -60
```
如果这一屏里搜不到你的正文关键词，问题就不在内容上。你要分清三个视角：你在浏览器里看到的那一份、服务器原始返回的 HTML、以及抓取工具执行完 JavaScript 之后拿到的 DOM。这三者的差值，就是全部线索。
先怀疑 robots.txt，它最容易被忘，也最致命
robots.txt 放在域名根目录，任何一行 Disallow: / 就足以让整站从抓取工具眼里消失。来源通常是这几种：测试阶段加的，上线时忘了删；主题或 SEO 插件在“开发模式”下自动写入；改版时临时把整个文件替换成了禁止抓取的版本。
还有一种更隐蔽的情况：robots.txt 本身返回 503。不少抓取工具在拿不到正常的 robots.txt 响应时，会保守地暂停抓取整个站点。共享主机在负载高的时候间歇性返回 503 很常见，所以这不是理论问题。
检查方式很土：在无痕窗口里直接打开 你的域名/robots.txt。别只看内容，也看状态码。内容正常但状态码是 5xx，和内容里写着 Disallow，后果一样严重。
noindex 比 Disallow 更难发现，因为它藏在 head 里
Disallow 你至少能在 robots.txt 里看到一行字。noindex 不会主动出现在你面前。它可能来自模板里写死的 <meta name="robots" content="noindex, nofollow">，可能来自 HTTP 响应头的 X-Robots-Tag: noindex，也可能来自建站插件或维护模式插件在特定状态下自动注入。
我用两条命令把这一步压到三十秒：curl -sI 看响应头，curl -s 看 head 里有没有 meta robots。
这里有个顺序问题，很多人栽在上面。如果同一个 URL 既被 robots.txt 屏蔽，又带着 noindex，抓取工具根本读不到那行 noindex，页面会一直留在索引里。想把一个页面干净地拿下线，正确顺序是先把 Disallow 放开、让 noindex 生效、等它掉出索引，最后再加回 Disallow。反过来做，你只会看到“被 robots.txt 屏蔽”的提示，然后困惑为什么几个月了页面还在。
还有一个现实约束值得说清楚：noindex 只是让页面不进索引。如果审核流程是从搜索结果里找你的站，页面抓得到但搜不到，对审核员来说和没站是一样的。
密码保护和“即将上线”页，是根本进不去，不是看不到内容
如果你建站时开过 .htpasswd、CDN 的访问保护、托管平台的密码保护，或者装了带维护模式的插件，审核员打开首页看到的是一个登录框、一个倒计时，或者一句“即将上线”。这一层必须先关掉再申请，关掉之后还要验证：无痕窗口打开首页，正文直接可见，没有任何遮罩。
这里的坑在于，有些维护模式插件只对未登录用户生效。你自己一直是登录状态，所以你永远看不到那层膜，直到有人告诉你他打不开。
缓存层是另一个变种。CDN 里存着一个旧版本的 403 页面、或者“Under Attack”拦截页，你本地刷新看到的是新版本，抓取工具拿到的是缓存里的旧版本。改完保护设置之后，记得把首页和几个主要栏目页的缓存清一遍。
纯前端渲染：你看的是 JS 跑完的结果
如果站点是单页应用，或者用了前端框架的纯客户端模式，服务器返回的 HTML 里可能只有一个空的挂载点。抓取工具现在多数能执行 JavaScript，所以内容仍然有被索引的可能，但执行有预算、有超时，而审核员用的工具不一定跑 JS，很多人就是直接请求一下、或者用一个简单的预览器看首屏。
判断办法简单粗暴：在浏览器里选“查看网页源代码”，注意不是“检查元素”。如果源代码里搜不到任何一个正文关键词，那你就面临这个风险。
缓解手段是服务端渲染或预渲染。WordPress 这类传统服务端渲染的站天然没有这个问题，所以这一类故障在纯前端站和 headless 架构上更集中。
导航断了，审核员就走不下去
这条最容易被低估。审核员不会只看首页，他会点分类、翻第二页、点几个内链。
如果分类链接指向 /category/xxx/ 而实际路径是 /categories/xxx/，如果改版后旧 URL 没有 301 到新 URL，如果 /page/2/ 直接返回 404，他走到第二页就断了。断一次也许还能忍，连着断几次，印象就定型了。
还有几种混着来的：内链还写着旧域名；http 和 https 混用；带 www 和不带 www 混用，其中一个版本跳转到了 404 而不是做统一跳转。
我的做法是上线前跑一遍全站爬取，把 4xx 和 5xx 全部挑出来清零，然后手动在无痕窗口里从首页点三层，确认路径是通的。自动工具能覆盖大部分，但人工点一遍能发现工具漏掉的跳转链问题。
用网址检查，看抓取工具到底收到了什么
Search Console 的网址检查就是为这件事准备的。输入 URL，如果页面已经被索引，点“查看已抓取的页面”；如果还没索引，先用“测试实际网址”，等几秒，再看“查看测试过的页面”。
我在那一页里固定看三样东西：
- HTML 里有没有正文文字。没有，就是渲染问题。
- 有没有“已屏蔽”之类的提示。有，就是 robots.txt 或 noindex。
- 页面资源里有没有成片的加载失败。有，通常是静态资源目录被 Disallow 了，或者 CDN 出了状况。
“屏幕截图”那一栏特别值得看，因为它就是抓取工具看到的画面。如果那张截图是一片白，那你已经看到了审核员看到的东西。
页面下面还会给“网页无法编入索引”的具体理由，比如“已发现，尚未编入索引”“已抓取，尚未编入索引”“被 robots.txt 屏蔽”“已被 noindex 排除”。这几句话的指向完全不同，别混着猜。
站点地图：不是必需，但值得交
审核并不要求你提交 sitemap。但如果你刚发了一批新页面，提交一下能让抓取工具更快发现它们，审核窗口里就更容易被抓到。
它还有一个反向诊断的作用。提交之后看“已发现的网页数”，如果是零，那说明 sitemap 本身有问题：格式不对、返回 404，或者被 robots.txt 屏蔽了。这个数字比 sitemap 文件本身诚实。
一个常见错误是把 noindex 的页面也塞进 sitemap。那只会浪费抓取预算，还会让这两个信号互相打架。sitemap 里应该只放返回 200、可索引的规范 URL。
共享主机的 5xx：审核窗口可能正好落在宕机时段
这条最气人，因为你什么都没做错。共享主机在流量高峰、或者同机房邻居站点被打的时候，会间歇性返回 502 或 503。审核是一瞬间的事，那一刻你正好在宕机，结果就是“站点无法访问”。
对策是把可用性监控单独拉出来，不要和 Search Console 混在一起看。监控要能告警，而不只是记录。另外，如果拒信里说的是“服务器错误”而不是“内容问题”，基本可以往这个方向查。
坦白说，我没法预知审核发生在哪一分钟，能做的只是别让自己长时间处在会崩的状态里。
提交前我自己会走一遍的清单
- 无痕窗口打开首页，正文直接可见，没有登录框、没有倒计时、没有遮罩。
你的域名/robots.txt返回 200，里面没有Disallow: /。- 查看首页源代码，能搜到正文关键词。
- 响应头里没有
X-Robots-Tag: noindex。 - 从首页点三层，全程不出现 404。
- Search Console 网址检查，截图里能看到正文。
- 全站爬一遍，4xx 和 5xx 清零。
- sitemap 能正常打开，里面的 URL 全部返回 200。
最后一句提醒：申请之后不要马上继续折腾站点。很多人一提交就去换模板、换 CDN、调路径，审核恰好落在改动窗口里，于是一堆本来没问题的东西看起来都像问题。
审核员不是在评判你的审美。他只是在确认一件事：这个 URL 返回的东西里，有没有内容。前面那八条，都只是这句话的展开。
