一个站点跑五个市场，Search Console 最不该做的就是只挂一个资源看总量。能用的拆法是两层：顶层挂一个域名资源（Domain property）拿全站、全子域、全协议的总视图，再在每个语言目录上分别建 URL 前缀资源，每个市场只提交自己目录下的 sitemap，性能报告一律用「国家/地区」加「页面」两个筛选条件交叉下钻，索引问题按市场单独排期处理。只建一个资源，五个市场的病因会糊成同一条曲线，你连是哪个市场在掉都说不清。
我第一次意识到这件事，是在德语的页面上。
那天我照例在域名资源里看性能报告，总点击曲线是往上走的，心情不错。然后我把筛选条件一层层加上去：先按页面筛 /de/，再按国家/地区筛德国。数字一下子塌下来——不是下跌，是这个市场的真实水位本来就不高，只是被英语站的量盖住了。我把国家/地区筛选去掉，光按路径筛，数字又回来了，因为那部分点击里混着奥地利、瑞士，还有一批是误点进来的其他地区用户。
那一下我明白，多市场站点的 Search Console 不是「看报表」，是「分报表」。
域名资源和 URL 前缀资源，是两种不同的眼睛
域名资源是俯视。它把 example.com、www.example.com、blog.example.com，还有 http 和 https，全部收进一个视图。你要看全站趋势、看整个域名有没有被某次算法更新打到，用它最省事。代价是它太粗：它不知道 /jp/ 和 /br/ 是两门生意。
URL 前缀资源是平视，而且只平视它自己那一格。你建了 https://example.com/de/ 这个前缀资源，它管的就是这个目录，多一层子目录都算外人。好处是切进去之后，性能报告、页面报告、sitemap 报表明面上天然只给你德语站的数据，你不必每次进来先手忙脚乱地点三个筛选。
我的做法是两层都留。域名资源当仪表盘，每天早上扫一眼总趋势；真正做判断的时候，切到对应的前缀资源里去。切换器里那五六个资源的名字，我会按市场重命名，比如「DE-德语」，而不是让它默认显示一长串网址——资源一多，名字不清楚，点错的成本比什么都高。
这里有个能省很多事的细节：域名资源是用 DNS 验证的，一旦验证通过，同一个域下面的 URL 前缀资源可以直接添加，不用再走一遍验证流程。多市场铺开的时候，这一步省下来的不是时间，是节奏——你不用等每个市场的负责人都能碰到 DNS 记录。当然，这也意味着权限给得要谨慎，DNS 级别的验证等于把整个域交出去了，谁被加进去要想清楚。
一个语言一份 sitemap，是为了让数据能被切开
很多人图省事，全站就一个 sitemap.xml，里面塞满五个语言的所有 URL。提交是提交成功了，但你去 sitemap 报告里点开，看到的是一个几千条网址的总数——这个数字回答不了任何问题。
我每个语言目录下放一份自己的 sitemap，路径大致是 /de/sitemap.xml、/jp/sitemap.xml 这样，然后在 Search Console 里逐个提交。最直接的好处是每个市场有独立的提交记录和独立的抓取状态。德语站某天 sitemap 读取失败，你不会到第二天才发现，因为你在那个资源里一眼就能看到。
不过这里要说句实话。早期 Search Console 的 sitemap 报告会直接告诉你每个 sitemap「已编入索引的网址数」，现在这个数字不像以前那样摆在明面上了。所以我现在拆 sitemap 的目的变了——它不再是我读索引数的地方，而是我按路径筛选的锚点：我知道 /jp/ 这个目录下应该有哪些页面，再用「页面」报告按 /jp/ 前缀筛一遍，两边的网址数对不上，问题就冒出来了。
还有个「看情况」的地方：如果你的市场目录不是按 /de/、/jp/ 这种纯语言前缀切的，而是按国家切的 /de-de/、/de-at/，那 sitemap 和筛选条件都要跟着这个结构走。语言和市场不是一回事，德语站里本来就混着德国、奥地利、瑞士三拨流量，这一点在后面的国家/地区筛选里会反复咬你。
性能报告：国家和路径，必须一起用
单个筛选条件在多市场站点上基本没用。
只按国家/地区筛：你能看到德国来的所有点击，但这部分里混着英语页面、德语页面，甚至一些根本不该被德国用户看到的页面。你不知道德国市场的德语内容到底表现如何。
只按页面筛：你能看到 /de/ 目录的所有表现，但这部分里混着德国、奥地利、瑞士，还有别处误入的用户。你也不知道德语内容在德国本地到底行不行。
两个一起用，才是这个市场的真实画像。
我通常是这么一路筛下来的：先在域名资源里按页面筛 /de/，看这条曲线跟总曲线是不是同向——如果总曲线在涨而 /de/ 在平，说明增长全来自别的市场；然后加上国家/地区筛选，看德国本地的份额；再往下，把时间范围拉到最近 28 天，切到「网页」标签页，看是哪些页面在带量，哪些页面在这个市场里彻底没人点；最后切到「查询」标签页，看这个市场的人在搜什么。这一步经常能救回一个市场，因为你会发现德国用户在搜的词，跟你照搬英语站关键词做出来的页面根本不是一回事。
有一件事值得单独说：筛出来的数字别直接当 KPI 用。Search Console 的数据有抽样、有延迟，也有它自己算不清楚的部分。它的价值在于方向和对比——同一个市场这个月和上个月比、德语站和法语站比，而不是拿它去精确核对某个页面昨天挣了多少点击。
把索引问题按市场排期，而不是全站扫一遍
「页面」报告（就是以前的索引覆盖报告）最容易被误用。很多人打开它，看到一两千条「未编入索引」就慌了，然后试图一口气全清掉。这是全站思维，在多市场站点上基本是白费力气。
我会先按市场切。切进去之后，看的是状态的分布，而不是总数。
「已发现 - 尚未编入索引」，通常意味着 Google 知道有这么个网址，但还没去抓，或者抓取预算被别的东西占了。这种在刚上线的新市场里很常见——/br/ 刚开出来的时候一片这个状态，不用急着改代码，先看内链有没有把新目录真正连起来、sitemap 有没有提交，然后给它时间。
「已抓取 - 尚未编入索引」，性质不一样。Google 来过了，看了，决定不收。这种多半是内容层面的判断——页面太薄、几页内容高度雷同，或者是同一批内容在多个市场之间互相打架。改代码没用，得回去看内容。
至于规范网址的问题，这里有个必须更新的认知：早期报告里有一类叫「重复，用户未选择规范网址」，这一类现在已经并进「重复，Google 选择的规范网址与用户不同」里了。如果你还在按老分类做排期表，会发现对不上。现在的重点就一条——Google 选的规范页和你想要的不是同一个，那基本上是你自己的 hreflang 或者内部链接在互相拆台。五个市场共用一套模板的时候，这种问题特别容易出现在首页和分类页上。
我现在的做法是：每个市场每周固定看一次自己的「页面」报告，只看三类变化——新出现的、突然变多的、以及一直在那里不动的。不追求清零。有些「已发现 - 尚未编入索引」的网址本来就不该被索引，比如分页的第二页、带筛选参数的页面。把它们清掉是浪费，把真正该收录却被挡住的页面捞出来才是正事。
这么跑一段时间之后，你会发现一件挺有意思的事：五个市场里，真正需要你动手的问题可能只有一两个。剩下三个市场的报告之所以难看，只是因为它们被放在同一张报表里，被那个总量拖着一起难看。
