📌 Search Console 是 Google 免费提供的站长后台，也是你唯一能直接看到「Google 到底怎么看你这个网站」的地方。这篇讲清楚：怎么验证、四个指标该怎么读、页面不被收录时那些英文状态各是什么意思、以及每周花十五分钟该盯哪几张表。内容依据 Google 官方文档整理，截至 2026 年 8 月，功能与阈值以官方页面为准。本文含推荐链接，通过链接下单我可能获得少量佣金，不影响你的价格，详见佣金披露说明。
做独立站的人，十个里有九个装过 Google Analytics，但认真用 Search Console 的可能连一半都不到。这事挺可惜的，因为这两个工具管的根本不是一回事——Analytics 告诉你人进来之后干了什么，Search Console 告诉你人是怎么进来的，以及更关键的：有多少人本来能进来，却因为 Google 压根没收录你的页面而永远进不来。
我从 2014 年开始写点点KG百家乐，中间换过主题、迁过服务器、改过好几轮 URL 结构。每一次出问题，最先给我报警的都是 Search Console，不是 Analytics。原因很简单：Analytics 只统计已经来到你网站的人，页面从 Google 索引里掉了，Analytics 那边只是曲线往下走，它不会告诉你为什么；Search Console 会直接把原因写在报告里，虽然写的是一堆需要翻译的英文术语。
这篇文章就是把那些术语翻译成人话。不讲玄学，不讲「SEO 秘诀」，只讲这个后台里每一张表在说什么、哪些数字值得你花时间、哪些报错要立刻处理、哪些看着吓人其实完全正常。读完你应该能独立完成一次网站体检，而不是每次看到一片红色感叹号就去搜「网站不收录怎么办」。
先弄清楚它管什么，以及它不管什么
Google 官方对 Search Console 的定义很朴素：一个帮助任何拥有网站的人了解自己在 Google 搜索里表现如何的工具。注意这个限定词——Google 搜索。它不管你的 Bing 流量，不管你的社交媒体来源，不管直接输入网址进来的人，也不管站内跳转。它只管一件事：从 Google 搜索结果页到你网站这一段路。
这个边界很重要，因为它解释了新手最常见的困惑：为什么 Search Console 的数字和 Analytics 的数字对不上？答案是它们统计的根本不是同一批访问。Google 官方文档里明确列过几个原因，比如 Search Console 会做额外的数据处理来剔除重复访问和机器人流量，而像 Google Analytics 这类工具只能统计启用了 JavaScript 的用户。再加上时区差异（表现报告按加州当地时间统计每日数据，Analytics 通常按你自己设的时区），两边天然对不齐。
所以正确的用法是：把它们当成两个不同的仪表盘，各看各的，不要试图对账。想知道「今天有多少人从 Google 搜索点进来、搜的是什么词」，看 Search Console；想知道「这些人进来之后看了几页、有没有下单」，看 Analytics。
Search Console 的核心能力可以粗略分成三块。第一块是数据：你在 Google 搜索里的展示量、点击量、搜索词、排名。第二块是诊断：哪些页面被收录了、哪些没有、为什么没有、抓取的时候有没有出错。第三块是提交与干预：提交站点地图、请求重新抓取某个页面、临时从搜索结果里撤下某个 URL。绝大部分人只用了第一块，而第二块和第三块才是真正拉开差距的地方。
开通与验证：域名资源还是网址前缀资源
注册和验证是第一道坎，也是很多人第一步就选错的地方。Search Console 里有两种资源（Property）类型，选哪种直接决定了你后面看到的数据范围。
域名资源（Domain property）覆盖一个根域名下的全部内容，官方的说法是包含所有子域名（m、www 等等）和多种协议（http、https、ftp）。也就是说，你验证 example.com 这一个域名资源，那么 www.example.com、blog.example.com、https:// 和 http:// 的数据会全部汇总到一起。
网址前缀资源（URL-prefix property）只覆盖指定前缀开头的网址，而且协议也算在内。https://example.com/ 和 http://example.com/ 是两个不同的资源，https://example.com/blog/ 又是第三个。
验证方式上，两者的差别更大。域名资源只能用 DNS 记录验证——去你的域名服务商后台加一条 TXT 记录，这是官方文档里明确写的唯一路径。网址前缀资源则支持多种方法：上传 HTML 验证文件、在页面里加 HTML 标签（<meta> 标签）、用 Google Analytics 跟踪代码验证、用 Google Tag Manager 容器代码验证，以及同样可以用的 DNS 记录；如果站点建在 Google Sites 或 Blogger 上，用同一个账号还能自动验证。
那到底选哪个？如果是我，我会先建域名资源。理由有三个：一是数据最全，不会因为 www 和非 www 分成两半而让你误判流量下滑；二是网站将来加子域名（比如开个 shop.example.com）时不用重新配置；三是 DNS 验证一次搞定，不依赖网站文件，换主题、换服务器、重装 WordPress 都不会掉验证——用 HTML 文件验证的人，迁站之后验证失效是家常便饭。
唯一的例外是，如果你只想单独看某个目录的数据（比如只看 /blog/ 这个子目录的表现），那就再额外建一个网址前缀资源。两种可以并存，互不影响。我自己的做法是域名资源做主力，需要拆分析的时候再加前缀资源。
验证之后不会立刻有数据。Google 的说法是收集到的数据通常需要 2 到 3 天才能显示出来，新站甚至更久，所以刚验证完看到一片空白是正常的，不用反复刷新。
表现报告：四个数字里真正重要的是哪两个
表现报告（Performance report）是大部分人打开 Search Console 第一眼看的地方，默认展示的是过去三个月的数据。上面有四个指标，官方定义分别是：
- 点击次数（Clicks）——用户从 Google 搜索结果点击进入你网站的次数。
- 展示次数（Impressions）——你的网站在搜索结果里出现的次数。
- 点击率（CTR）——点击次数除以展示次数。
- 平均排名（Average position）——你网站排名最靠前的那条结果的平均位置。
这四个数字里，我认为真正值得你天天看的只有两个：展示次数和点击率。
点击次数当然重要，但它是结果，不是原因。展示次数才是前置信号——它说明 Google 有没有把你放进结果页。展示涨了点击没涨，说明你的标题和摘要没吸引力，或者排名靠后到没人看得见；展示跌了点击必然跟着跌，那要查的是收录和排名，不是文案。这两种情况的处理动作完全不同，所以先分清是哪一种。
平均排名这个数字则被严重误读。它的算法比大家想的复杂：在图表里它代表你整个网站排名最靠前的那条结果的平均位置，在表格里它代表该行对应的那个网址或分组的平均位置。更要命的是，官方文档专门提醒过，搜索结果会因为时间、地点、设备和搜索者的近期历史而不同。所以「平均排名 8.3」这个数字，不代表任何一个真实用户看到的排名。它只适合看趋势——这个月比上个月是往上还是往下——绝对值本身没什么意义，更不要拿它跟别人比。
为什么总数永远对不上：匿名查询这件事
这是 Search Console 里最容易让人抓狂、也最少被解释清楚的一个设计。你会发现：图表上的总点击是 1000，但下面搜索词表格里所有词的点击加起来只有 400。是数据错了吗？不是。
Google 出于隐私考虑，会把「匿名查询」（anonymized queries）从表格里拿掉。官方的定义是：那些在两到三个月内没有被超过几十个用户搜索过的查询词，实际内容不会显示在搜索表现数据里，目的是保护搜索用户的隐私。官方文档还写过，它可能不会追踪那些搜索次数极少、或者包含个人及敏感信息的查询。
关键在于这些被隐去的查询怎么参与计算：它们始终不出现在表格里，但会被计入图表总数——除非你按查询词做了筛选。这就导致一个很反直觉的后果：一旦你加了查询词筛选条件，匿名查询就被整体排除，于是「包含某个词的查询数」加上「不包含某个词的查询数」，往往加不到总数。
另外还有一层差异，官方文档也说明过：图表总数和表格总数有时不一致，通常是因为聚合方式不同——一个按网站（property）聚合，一个按页面（page）聚合。同一次搜索里你的网站出现了三条结果，按网站算是一次展示，按页面算是三次。
知道这件事之后，实际操作里该怎么办？我的建议是：把表格里的搜索词当成样本看，不要当成全集看。它足够你判断方向——读者在关心什么话题、哪些词有排名但没点击——但你永远拿不到完整的搜索词清单。尤其是中文长尾词和小众站点，被匿名掉的比例可能相当高。有人为此焦虑，觉得自己的数据「不准」，其实不必：所有网站都是这个规则，横向比较依然成立。
时间范围、数据延迟和导出上限
几个实用的边界，知道了能省不少事。
时间范围上，日期选择器里最远的选项是过去 16 个月，再往前的历史数据 Google 不再提供。这意味着如果你想做年度同比，或者想保留建站早期的数据，就得自己定期导出存档。我的做法很土：每季度导一次 CSV 丢进云盘，几分钟的事，但等你真的需要三年前的数据时会庆幸自己做过。
数据延迟前面提过，通常 2 到 3 天。所以今天看昨天的数据是空的，属于正常现象。想看「实时」搜索流量，Search Console 做不到，也不该指望它做到。
时区是加州当地时间。这条经常被忽略，但如果你的读者主要在国内，那 Search Console 的「一天」和你感受到的一天差了十几个小时，做单日对比的时候要留意。
导出上限方面，界面里一次导出的行数是有上限的（目前是 1000 行），需要更大量的数据就得走 Search Analytics API 或者官方的 Looker Studio 连接器，具体配额以 Google 官方文档为准。对绝大部分个人站来说 1000 行完全够用，真到了嫌不够的规模，你多半也该上更专业的分析流程了。
关于怎么把这些数据反过来指导内容规划，我在Google SEO 完整指南那篇里写得比较细，这里就不重复了。
网页索引报告：Google 用这些话告诉你「没收录」
如果说表现报告是体检的血常规，那网页索引报告（Page indexing report，早期叫 Index Coverage）就是 CT。它把你网站上 Google 知道的所有 URL 分成两堆：已编入索引的，和没编入索引的。没编入索引的那一堆，会按原因细分成十几种状态，每种状态都是一句英文短语。
这些短语才是重点。它们不是错误提示，而是 Google 在解释自己的判断。看懂了，你就知道该改什么；看不懂，就容易把正常状态当成故障去乱修。下面这张表把常见的状态整理出来，都是 Google 官方文档里的原话含义。
| 状态（英文原文） | 官方含义 | 要不要处理 |
|---|---|---|
Server error (5xx) |
请求该页面时，你的服务器返回了 500 级别的错误 | 要，优先级最高 |
Redirect error |
跳转出了问题，比如跳转链太长、跳转循环、跳转网址格式错误 | 要 |
Not found (404) |
请求该页面时返回 404 | 看情况 |
URL blocked by robots.txt |
该页面被你网站的 robots.txt 文件拦住了 | 看情况 |
URL marked 'noindex' |
Google 尝试索引时遇到 noindex 指令，因此没有索引 | 通常不用 |
Soft 404 |
页面返回的内容 Google 认为是一个「软 404」——给用户看的找不到提示，但没返回真正的 404 状态码 | 要 |
Crawled - currently not indexed |
页面已被 Google 抓取，但没有编入索引 | 要，但急不得 |
Discovered - currently not indexed |
Google 已经发现这个页面，但还没抓取 | 要，但急不得 |
Alternate page with proper canonical tag |
这是一个副本页面，并且正确指向了已被索引的规范网页 | 不用，这是正常的 |
Duplicate without user-selected canonical |
重复页面，你没有指定规范网址，Google 自己选了一个别的 | 要 |
Duplicate, Google chose different canonical than user |
你指定了规范网址，但 Google 选了另一个 | 要，说明有信号冲突 |
Page with redirect |
这是一个会跳转走的非规范网址 | 不用，这是正常的 |
Blocked due to access forbidden (403) |
服务器返回 403，导致无法索引 | 要 |
Blocked due to unauthorized request (401) |
页面因为要求身份验证而挡住了 Googlebot | 看情况 |
这张表里，我想单独展开三组，因为它们占了实际问题的绝大多数。
已抓取但未编入索引，和已发现但未抓取
这两个是新站站长最焦虑的来源，也是最容易被误解的。先分清楚它们的区别：Discovered - currently not indexed 的意思是 Google 知道这个 URL 存在（多半是从站点地图或者内链发现的），但还没派爬虫来抓；Crawled - currently not indexed 是已经抓过了，看完之后决定暂时不放进索引。
前者通常和抓取资源有关。Google 不会无限制地抓你的站，新站、权重低的站、服务器响应慢的站，被分到的抓取量都有限。你能做的是：确保站点地图里的 URL 干净（别把大量 404 和跳转塞进去）、减少无价值的 URL（标签页、分页、参数页），以及别让服务器响应慢到让爬虫失去耐心。
后者更多是质量判断。Google 抓了，也看了，然后决定这个页面暂时不值得占索引位置。常见的触发原因是内容太薄、和站内其他页面高度相似、或者整站还没建立起足够的信任。
我要说一句可能不太受欢迎的话：这两个状态在新站上大面积出现，是常态，不是故障。一个刚上线三个月、只有二十篇文章的站，有一半页面卡在这两个状态里完全正常。这时候最不该做的事，就是每天去 URL 检查工具里点「请求编入索引」——那既没用，也说明你把力气用错了地方。真正有用的是继续写、把内链织起来、让老页面有理由指向新页面。
重复内容相关的几个状态
四个带 duplicate 或 canonical 的状态里，有两个是完全正常的，两个需要处理，很多人分不清。
Alternate page with proper canonical tag 和 Page with redirect，这两个不用管。前者是你有意做的副本（比如打印版页面、AMP 版本、带参数的同一篇文章），并且已经正确用 canonical 标签指向了正主；后者是跳转源 URL。它们不被索引恰恰说明你的设置是对的。我见过有人为了「清零」这些状态折腾一整个周末，纯属浪费。
要处理的是另外两个。Duplicate without user-selected canonical 说明你压根没声明规范网址，Google 只好自己挑一个，挑的结果不一定合你心意。Duplicate, Google chose different canonical than user 更值得警惕：你声明了，但 Google 不认，说明你给出的信号自相矛盾——比如 canonical 指向 A，但站点地图里放的是 B，内链全指向 C，或者 A 页面本身内容太薄撑不起规范地位。
WordPress 站上，这类问题多半出在 SEO 插件的配置上。分类页、标签页、作者页、日期归档页如果都开着索引，很容易互相打架。我自己的站用 Rank Math 管这一块，具体怎么配置我写过一篇Rank Math 使用完整指南，需要的话可以对着改。
noindex 和 robots.txt 一起用，等于什么都没做
这是我见过最多的一个技术性错误，而且犯错的人往往自我感觉良好——「我既加了 noindex，又在 robots.txt 里屏蔽了，双保险」。
实际上这是双失效。Google 官方文档写得很直白：要让 noindex 规则生效，页面或资源必须不能被 robots.txt 文件屏蔽。逻辑很简单——robots.txt 拦的是抓取，Googlebot 根本进不去这个页面，就永远看不到你写在 HTML 里的 noindex 指令。结果是这个页面依然可能因为外部链接而出现在搜索结果里，只是显示不出摘要。
正确的做法是二选一，而且要选对：想让页面不出现在搜索结果里，用 noindex，同时允许抓取；想节省抓取资源、不让爬虫浪费时间在某些目录上，用 robots.txt，但要接受这些 URL 可能仍会被索引。两个目标不一样，不要混用。
网址检查工具：请求编入索引不是催更按钮
网址检查工具（URL Inspection）是 Search Console 里最好用的一个功能，也是最被滥用的一个。
它其实提供了两种完全不同的信息，很多人搞混。默认看到的是已编入索引的版本——官方措辞是这个数据来自该页面最近一次被编入索引的版本，而不是网络上的实时版本。另一个是实时测试，它会当场去抓取这个 URL，让你验证刚做的修改是否生效。
这个区别在排障时特别关键。假设你昨天修好了一个页面的问题，今天来检查，默认视图很可能还显示旧的错误状态——那不是没修好，那是 Google 还没重新抓。这时候点「测试实际网址」，如果实时测试通过，你的修改就是对的，剩下的只是等。
至于「请求编入索引」这个按钮，我得说点实话。官方文档写得很清楚：提交请求并不保证页面会出现在 Google 索引中，而且每天能提交的索引请求数量是有上限的。它的作用是把 URL 放进一个队列，仅此而已。页面能不能进索引，取决于它本身够不够格，跟你点了几次按钮无关。
官方也给了替代方案：需要批量提交的时候，应该用站点地图，那比逐个提交高效得多。所以合理的用法是——刚发布一篇重要文章、或者刚修好一个具体问题，点一次；然后就别管了。每天挨个点几十个 URL 的做法，除了消耗你的时间，不产生任何额外收益。
站点地图：提交之后该期待什么，不该期待什么
站点地图（Sitemap）是个被神话了的东西。它的真实作用是：告诉 Google 你的网站上有哪些 URL 值得抓。它不能让页面排名更高，也不能保证页面被收录，它只是一份清单。
先说硬性限制。Google 官方文档写明：所有格式的单个站点地图文件都限制在 50MB（未压缩）或 50000 个网址以内，超过就得拆分成多个文件，或者用站点地图索引文件。个人博客基本碰不到这个上限，做电商站铺货的可能会。
提交方式有好几种，官方列出的包括：在 Search Console 的站点地图报告里提交（好处是能看到抓取情况和错误）、用 Search Console API 提交、在 robots.txt 里加一行 Sitemap: https://example.com/sitemap.xml、以及针对 Atom/RSS 的 WebSub。我的建议是同时做前两件里的第一件和第三件——在 Search Console 里提交一次，再在 robots.txt 里写一行，成本几乎为零。
然后是最值得说的一点：站点地图里的那些标签，Google 并不是全都看。官方明确表态过——<lastmod> 的值 Google 会用，前提是这个值一贯且可验证地准确，它应该反映内容、结构化数据或链接的实质性更新；而 <priority> 和 <changefreq> 这两个值，Google 直接忽略。
这条信息的实用价值在于：别再花心思去调 priority 了，那是纯粹的自我安慰。反过来，lastmod 要认真对待——如果你的插件把每次微小改动（改个错别字、换张图）都算作更新，把全站几百个页面的 lastmod 一起刷新，那这个信号就失去了可信度，Google 会开始不信任它。改内容才叫更新，动排版不叫。
WordPress 用户基本不用手写站点地图，主流 SEO 插件都会自动生成并保持更新。你要做的是打开生成的文件看一眼：里面有没有混进标签归档、附件页、搜索结果页这类不该被收录的 URL。清单干净，抓取资源才用在刀刃上。
网页体验：Core Web Vitals 的三条及格线
核心网页指标（Core Web Vitals）报告用的不是模拟测试数据，而是真实用户数据。官方说明是它依赖 CrUX（Chrome 用户体验报告）数据库，里面是访问你网址的真实用户的匿名性能数据，采用过去 28 天的窗口，取的是 75% 分位——也就是说，「75% 的页面请求耗时在这个数值以内」。
目前的三个指标和它们的判定标准如下，这是 Search Console 报告里实际使用的阈值：
| 指标 | 良好 | 需要改进 | 差 |
|---|---|---|---|
| LCP（最大内容绘制） | ≤ 2.5 秒 | ≤ 4 秒 | > 4 秒 |
| INP（与下次绘制的交互） | ≤ 200 毫秒 | ≤ 500 毫秒 | > 500 毫秒 |
| CLS（累积布局偏移） | ≤ 0.1 | ≤ 0.25 | > 0.25 |
顺带说一句，INP 是替代原来 FID（首次输入延迟）的指标，2024 年正式成为稳定的核心网页指标。如果你看的还是几年前的中文教程，上面写的 FID 已经过时了。
报告的呈现方式有两个坑。第一，它不是按单个 URL 报告，而是把体验相似的网址归成一组——官方的说法是按框架和预期性能相似度分组，数据不足时会升级到来源级别的分组（同一个 protocol://host:port 下的全部网址）。所以你看到「12 个网址有问题」，实际上代表的是一整类页面，修一个模板可能就全好了。
第二，一个网址组的整体状态取的是它在该设备类型下最差的那个状态。三个指标里有一个是「差」，整组就是「差」，另外两个再漂亮也没用。这个设计经常让人误以为问题很严重，其实往往只是某一项拖后腿。
说到怎么修，LCP 和 INP 这两个的改善路径不太一样。LCP 很吃服务器响应速度和首屏图片体积，属于「基础设施 + 图片优化」的活；CLS 基本是前端布局问题，图片没写宽高、广告位没预留空间、字体加载导致文字跳动，这三样占了绝大多数；INP 则和 JavaScript 执行有关，插件装太多、主题太重是常见原因。
基础设施这块我得说句公道话：很多人在插件层面反复折腾，效果远不如换一台响应更快的服务器来得直接。我自己的站从共享主机迁到 Cloudways 之后，LCP 的改善是立竿见影的，因为服务器首字节时间本来就是 LCP 的组成部分。当然这不是说换主机能解决一切——图片没压缩、主题堆了一堆特效，换什么服务器都救不回来。速度优化是个系统工程，服务器、图片、主题、插件四块都要照顾到，只解决其中一块通常看不到明显变化。
不常看，但一出事就必须看的三个地方
Search Console 里还有几个报告，平时可以不管，但出问题的时候它们是唯一的信息来源。这三个我建议你至少知道它们在哪。
手动操作（Manual actions）。这个报告显示的是 Google 对你的网站采取的人工处罚。正常情况下它应该是空的，写着「未检测到问题」。一旦这里出现内容，说明有真人审核员判定你的网站违反了 Google 的垃圾内容政策——买链接、大量自动生成内容、隐藏文字之类。被处罚的后果是排名断崖式下跌甚至整站消失。这是整个 Search Console 里唯一一个「出现红色就必须立刻停下手上一切事情」的报告。
安全问题（Security issues）。它报告的是黑客攻击和恶意软件警告。WordPress 站被挂马注入垃圾页面是很常见的事，尤其是用了来路不明的破解主题和插件之后。被入侵的站在搜索结果里会被标红警告，点击率直接归零。这里出现问题，第一步是隔离和清理，不是找 SEO。
丰富网页摘要状态报告（Rich result status reports）。它用来检查你的结构化数据实现有没有问题。如果你的站有 FAQ、教程步骤、商品、评价这类结构化数据，这个报告会告诉你哪些标记写错了。错误的结构化数据不会导致处罚，但会让你失去在搜索结果里获得增强展示的机会——而增强展示对点击率的影响是实打实的。
另外还有一个「变更地址工具」（Change of Address tool），只在换域名的时候用得上。真要迁站的话，这个工具要配合 301 跳转一起用，单独用哪个都不行。
删除工具：最容易被误用的一个按钮
移除网址工具（Removals）值得单独说，因为它的名字骗了太多人。很多人以为点了它，页面就从 Google 那里彻底消失了。完全不是。
官方文档说得很明确：这是一次临时移除，时长大约六个月。六个月之后，你的信息可以重新出现在 Google 搜索结果里。它做的事情是暂时不在搜索结果中显示这个页面，同时清除 Google 索引里的页面摘要。
它不做的事情更多，官方逐条列过：屏蔽一个网址并不阻止 Google 抓取你的页面，只是不在搜索结果里显示；它只从 Google 搜索里移除内容，不会把内容从互联网上删掉；它对其他搜索引擎无效；单独使用它不构成永久移除方案。
那真正要永久移除该怎么做？官方给的路径是：先真正处理内容本身——删除内容、让页面返回 404 或 410 状态码、用密码保护，或者加 noindex 标签；然后如果之前用过移除工具，需要在工具里解除屏蔽再重新屏蔽，才能把它从索引里清掉。
什么时候该用它？我能想到的正当场景只有一个：你不小心公开了不该公开的内容（客户信息、内部价格表、测试页面），需要争取时间。这时候先用移除工具把它从搜索结果里撤下来，再从容地做真正的处理。除此之外，日常运营里几乎用不到这个按钮，用错了反而会把正常页面误伤掉。
我自己怎么用：一套十五分钟的例行检查
工具讲完了，讲讲节奏。写了这么多年博客，我的体会是 Search Console 最怕两种用法：一种是装了就再也不打开，另一种是每天打开五次盯着曲线上下起伏。前者错过问题，后者制造焦虑。中间有一条挺舒服的路。
我的做法大概是这样，你可以直接抄。
- 每周一次，十五分钟。打开表现报告，时间范围选「过去 28 天」并勾选「与上一时段对比」，只看两件事：展示次数的趋势方向，以及有没有某个页面的点击突然掉了一大截。然后扫一眼网页索引报告，看未编入索引那一栏里，有没有出现新的
Server error、Redirect error或Soft 404。有就处理，没有就关掉。 - 每月一次，半小时到一小时。把表现报告的时间拉到三个月，按查询词排序，找那些展示量高但点击率低的词——这些是最容易见效的改写对象，标题和摘要改一遍，往往比新写一篇文章的回报更快。同时看看有没有意料之外的搜索词，那通常意味着一个你没想到的选题机会。
- 每季度一次。导出数据存档（因为 16 个月一到就没了），检查一次核心网页指标报告，把站点地图打开翻一遍看有没有脏 URL。
- 出事的时候。流量突然掉一半，检查顺序是：手动操作 → 安全问题 → 网页索引报告的已编入索引数量 → 表现报告里是全站掉还是个别页面掉。这个顺序是按「后果严重程度」排的，不是按「可能性」排的，因为前两项虽然罕见但代价最大。
还有一个习惯我强烈推荐：每次改动网站结构之前——换主题、改固定链接、装新的 SEO 插件、迁服务器——先把当前的已编入索引页面数记下来。改完之后隔一两周对比一下。这个数字是最简单、也最灵敏的健康指标，比任何花哨的报表都管用。我自己吃过亏，改固定链接结构没做好跳转，等发现的时候流量已经掉了大半，而如果当时记了这个数字，一周内就能察觉。
这类结构性改动的排查流程，还有更细的诊断顺序和一些我不方便公开写的实操细节，我放在点点KG百家乐会员区里持续更新。会员是 980 元人民币一年，里面主要是这些年做站、做跨境业务积累下来的具体操作记录和答疑，不承诺流量增长，只提供我自己验证过的方法。
新手最常走偏的五件事
最后把我看到过最多的误区集中列一下，每一条都能省你不少时间。
第一，把没被收录当成被惩罚。这两件事差着十万八千里。没被收录多半是内容不够格或者抓取资源不足，是个渐进过程；被惩罚是手动操作报告里明确写出来的事。前者靠积累解决，后者靠整改申诉解决，弄混了就会用错方法。
第二，追着「平均排名」优化。前面说过，这个数字的计算方式决定了它只适合看趋势。把它当 KPI 盯，你会做出很多莫名其妙的决策——比如为了拉高平均排名去删掉那些排名靠后但仍在带来流量的长尾页面。
第三，用数据倒推「Google 喜欢什么」。Search Console 告诉你的是结果，不是原因。看到某篇文章排名好，就得出「Google 喜欢两千字的文章」这种结论，是典型的过度解读。样本太小，变量太多。
第四，只盯着自己的站看。展示次数下滑不一定是你的问题，也可能是整个搜索需求在变化，或者搜索结果页的形态变了。2025 年之后这一点尤其明显，AI 摘要占据了越来越多的结果页空间，很多站的展示量没变但点击率明显下滑，这不是你做错了什么。这个变化怎么应对，我在AI 时代独立站 SEO 那篇里专门写过。
第五，把 Search Console 当成 SEO 的全部。它是个诊断和监测工具，不是策略工具。它能告诉你哪里坏了、哪些词有机会，但选题、内容质量、外链、品牌信任这些真正决定长期结果的东西，它一个都管不了。工具用得再熟，内容不行还是不行。
常见问题 FAQ
网站刚上线，多久能在 Search Console 里看到数据？
验证通过之后，Google 的说明是收集到的数据通常需要 2 到 3 天才会出现。但这指的是「已经有数据」的前提下。全新的网站可能要几周甚至更久才会有第一次展示，因为在那之前 Google 还没把你的页面放进结果页。这段时间该做的是提交站点地图、保证内部链接通畅、持续更新内容，而不是反复点「请求编入索引」。
为什么搜索词表格里的点击数加起来对不上总数？
因为匿名查询。Google 会把那些在两三个月内没有被超过几十个用户搜索过的查询词从表格里隐去，用于保护搜索用户的隐私。这些查询依然计入图表总数，但一旦你加上查询词筛选条件就会被整体排除。另外图表和表格的聚合方式也不同（按网站聚合还是按页面聚合），这也会造成差异。数据没错，是设计如此，所有网站一视同仁。
页面显示「已抓取，但尚未编入索引」，我该怎么办？
先确认技术上没有障碍：页面能正常访问、没有 noindex、没被 robots.txt 挡住、canonical 指向自己。这些都没问题的话，剩下的就是内容和时间的问题了。Google 抓了但没收录，通常意味着它暂时没看到收录这个页面的必要性。有效的动作是把内容做扎实、从站内其他相关文章加上自然的内链、让这个页面在整站结构里有位置。反复提交索引请求没有用，官方也明确说过提交请求不保证会被索引。我把自己排查这类问题的完整清单整理在会员区，按顺序一条条过，比凭感觉试要快。
Search Console 和 Google Analytics 的数字对不上，是哪个装错了？
大概率两个都没装错。这两个工具统计的对象不同：Search Console 只统计从 Google 搜索结果到你网站的那一段，Analytics 统计的是所有来源的访问。而且 Search Console 会做额外处理来剔除重复和机器人流量，Analytics 依赖 JavaScript（没启用 JS 的用户统计不到），两边的时区口径也不一样——Search Console 按加州当地时间。所以正确做法是各看各的，别对账。
域名资源和网址前缀资源，我该建哪一个？
如果只建一个，建域名资源。它覆盖所有子域名和协议，数据最完整，而且用 DNS 验证，换主题、迁服务器都不会掉验证。代价是必须能操作域名的 DNS 设置。如果你只想单独分析某个子目录，或者拿不到 DNS 权限，再用网址前缀资源。两种可以同时存在，互不冲突。
写在最后
Search Console 有个特别的地方：它是所有 SEO 工具里唯一一个数据直接来自 Google 自己的。第三方工具的排名和流量估算再精致，也是外部推测；Search Console 上的每一个数字，都是 Google 在告诉你它实际做了什么判断。这个信息源的价值，不该被它朴素的界面掩盖。
但我也想说清楚它的边界。这个工具能帮你发现问题、验证修复、找到被忽略的机会，它帮不了你的是决定写什么、以及怎么写得比别人好。我见过太多人把 SEO 学成了工具操作学，报告翻得比谁都熟，站却一直做不起来。反过来，那些真正把站做起来的人，往往只用了这个后台里三成的功能，剩下的力气全花在内容上。
如果非要我给一句最实在的建议：把这篇文章里的例行检查流程照抄一遍，每周十五分钟，坚持三个月。你会发现绝大多数所谓的「网站问题」，要么在这套流程里被提前发现了，要么根本就不是问题。省下来的时间，拿去多写两篇文章，回报大得多。
📎 本文为一般性信息分享，依据 Google 官方文档整理，截至 2026 年 8 月。Search Console 的功能、报告名称与判定阈值 Google 会不定期调整，实际操作以 Search Console 帮助中心与 Google 搜索中心文档为准。文中涉及的第三方产品条款以各自官方页面为准，购买前请自行确认最新条件。
图片：首图 Laptop computer monitor，来源 Wikimedia Commons，作者 Taduuda，许可证 CC0；文中配图 Laptop on desk book stacks，来源 Wikimedia Commons，作者 freddie marriage，许可证 CC0。
