Search Console 的走法只有一条主干：属性先验证一次，之后固定每周按同一个顺序打开同一组报告——先扫手动操作与安全问题，再看页面索引，然后回到 Performance 对齐日期区间，最后才轮到核心网页指标和页面体验。顺序不是仪式感，它决定了你看到的是原因还是症状。顺序反了，接下来一整周的排查都建在错的假设上。
每周一早上九点二十，我坐下来，咖啡放左手边，屏幕上那排标签页已经开好了。属性切换的下拉框停在最上面，里面躺着 com、de、jp、br 四行，我从上往下切，每个停留的时间差不多。桌子右边压着一张便签，上面只有六个词：手动操作、索引、表现、抓取、站点地图、验证。那是我自己的顺序，写了几年，没改过。六个词大概二十分钟，剩下的时间才拿去回邮件、排内容。
属性这一步做错，后面每个周一都在还债
域名属性覆盖这个域下面所有子域和 http、https 两种协议，一次验证，全线生效。URL 前缀属性只覆盖你输入的那一个前缀：https://example.com 和 https://www.example.com 在你眼里是同一个站，在 Search Console 眼里是两个属性，数据是分开的两份。我见过有人图省事，四个市场各建一个前缀属性，结果半年后想按国家对比趋势，得手工拼四张表。
多市场到底选哪种，取决于你的站点结构。如果德国、日本、巴西是挂在主域下的子目录或子域，一个域名属性就够了，市场维度用 Performance 里的「国家/地区」筛选去切。如果各市场是独立域名，那就是各自独立的属性，没有捷径。但命名一定要有个规矩，比如「市场-域名」这种前缀，否则一年后你在下拉框里看到四行长得一样的东西，会开始靠猜。
验证方式有五种：DNS、HTML 文件、meta 标签、Google Analytics、Google Tag Manager，可以同时挂好几个，这本身就是保险。我永远先做 DNS TXT 记录，再做一层备份。原因很直接：DNS 不依赖页面模板、不依赖代码发布流程、也不依赖别人的账号权限。HTML 文件可能被下次部署覆盖掉，meta 标签可能被主题更新冲掉，而 GA4 和 Tag Manager 那条路要麻烦得多——它要求你在那个容器上有编辑权限。权限是活的，同事离职、账号被移出、代理商交接没做干净，容器权限一掉，验证就跟着掉了，而站本身还在正常跑，你根本不会察觉。
Google 会不会为此发提醒邮件，我不敢打包票。所以我在便签上加了一条：扫一眼「设置」里的所有权验证，绿灯就走，不点进去。三秒钟的事。
不同报告用不同节奏看，不要一遍过
「页面索引」是每周的。它回答的问题是：哪些 URL 进了索引，哪些没进，没进的原因是什么。这个报告里最值钱的不是总数，是「已抓取 - 尚未编入索引」和「已发现 - 尚未抓取」的区别。前者是内容被看到了但没被采纳，通常要回头看页面本身的质量和重复度；后者是排期问题，多半和抓取预算、内链结构有关。把这两个混着看，你会一直修错东西。真要具体查某一个 URL，用顶部的 URL 检查工具，别在列表里翻。
「核心网页指标」和「页面体验」我放在每两周甚至每月看一次。它们回答的是另一个问题：已经进了索引的页面，在真实用户手里跑得快不快。样本积累很慢，每周看只会看到噪音，也容易被几个低流量页面带偏。还有一个常见情况是显示「数据不足」——那通常只是流量没到阈值，不是技术故障，不用当故障去查。
然后才是 Performance。这个报告我只关心两件事：趋势，和日期对齐。它保留大约十六个月的数据，超出的行会从界面里消失，不是折叠，是消失。所以每月初我固定导一次 CSV，按属性、按月份分文件夹存着。第一次做的时候很烦，做完一年之后你会发现它是唯一能让你做同比的东西。
看的时候我会先拉一个比较区间，一般是最近 28 天对上一个 28 天，然后按国家、按设备各切一刀。绝对数字我不太看，因为里面混着品牌词，波动大又说明不了什么。我要的是：哪个国家的点击掉了，掉的是展现量还是点击率。这两个信号完全不同——前者多半是排名或者索引出了事，后者多半是标题和描述被改坏了，或者某个词的位置被别的东西占掉了。
数据是有滞后的。抓取、索引、再到报告更新，中间隔着几天到一个多星期。新站上线头两三周打开报告几乎全是空的，这是正常现象，不是验证没生效，也不是被罚了。我见过有人为此把属性删了重建，重建完还是空的，白白把前面那段数据丢掉。
举个最近的实际例子。我们关注的一个南非英语内容站（Roof to Meter）就是典型的国别域名新站：内容只有二十来篇，.co.za 域名上线初期又几乎拿不到外链，头几个星期效果报告基本是空的，URL 检查里多数页面停在「已发现 - 尚未编入索引」。这类站的解法没有捷径——sitemap 只提交该收录的 URL、内链从站点自己的层级里长出来、内容按节奏持续发，然后等抓取队列慢慢轮到你。新站的这段空窗不是出错，是排队。
出事的时候，顺序比工具重要
当某个站点看起来不对，我不会从 Performance 开始看。它是症状层，它告诉你掉了，但不告诉你为什么。我的顺序是这样的。
第一步，手动操作和安全问题。这两个在最上面，平时基本全绿，但它们一旦出问题，你下面看什么都是错的。红字先处理，别的都往后放。
第二步，页面索引。看排除原因有没有突然聚集——是某一类 URL 批量掉，还是零星几个。批量掉就往模板、noindex、robots 那个方向想，零星掉往往是单页问题。
第三步，抓取统计。这个藏在「设置」里面，很多人从来不看。如果服务器在某段时间大量返回 5xx，排名会直接受压，而这在 Performance 上只表现为一条平滑的下降曲线，光看曲线看不出原因。
第四步，回到 Performance，把日期区间对齐到上面几步发现异常的那几天。顺序反过来——先看曲线再找原因——你会在三四个可疑方向之间来回猜，猜到最后还是回到这里。
第五步才是核心网页指标。它很少是流量下降的直接原因，更多是长期摩擦，放在最后看，不占前面的时间。
按国别分站的时候，这套流程要在一个属性里走完再切下一个。切的时候记得把筛选清干净——我有一次忘了清掉「设备 = 移动」，对着一份被筛过的数据查了四十分钟的服务器日志。
最后是账号本身。多市场意味着多属性，多属性意味着至少要有两个人持有完全权限。单点很危险，尤其是人在国内、而账号挂在某个已经联系不上的邮箱上的时候。属性命名、用户管理、验证方式的冗余，这三件事做一遍，之后每个周一的二十分钟才真的是二十分钟。
那张便签上的六个词，我到现在也没改过。
