域名结构要在第一个市场上线之前定死：ccTLD、子目录、子域名这三条路，决定了之后每加一个市场时 hreflang 注解怎么放、Search Console 属性怎么切、以及将来想换结构要付多少迁移费。这件事没有“先跑起来再优化”的余地，因为后面每一个市场，都是在这个决定上再叠加一次成本。
我盯着 Search Console 的属性列表，从上往下看了三遍。
三行都是 URL-prefix 属性：https://example.com/de/、https://example.com/fr/、https://example.com/es/。点进去各自有各自的查询、各自的收录页面，但域名只有一个。当初给每个市场单独建属性，想法很简单，只是想看清楚哪个语言版本在动。后来才慢慢意识到，当年把德语站塞进 /de/ 文件夹这个动作，顺手把后面两年的验证、报表和 hreflang 维护都变简单了。
这个判断是从一个反面项目里长出来的。那个站第一个市场用了独立国别域名，第二个市场图省事放进文件夹，两套逻辑混在同一个项目里。表面上看也能跑，实际上每次改 hreflang，我都得先想一遍“这次改的是哪套结构下的页面”，然后去翻两份不同的文件。
三种结构，落到每天的操作上是什么样
子目录是 example.com/de/、example.com/jp/ 这种。所有市场挂在一个域名下，外链、品牌信号、权重都汇到一个地方。Search Console 里一个 URL-prefix 属性精确对应一个目录，所以“按市场看数据”这件事天然成立，不需要多买域名、多走一次验证。hreflang 注解通常放在同一个 head 模板或者同一份 sitemap 里，规则改一次，所有语言版本一起生效。
ccTLD 是 example.de、example.jp。国家指向没有任何歧义，用户在德国看到 .de 的那种下意识信任，子目录替代不了。代价是每个域名都从零开始攒历史。每个域名是独立属性，独立验证，独立提交 sitemap，独立维护一套互指注解。三个市场就是三份文件、三次验证、三个可能悄悄出错的地方，而且一处错在另一个域名那边是看不见的。
子域名是 de.example.com。大多数工具把它当作独立主机处理：分析后台按 hostname 拆开，CDN 缓存键分开，日志要额外合并，外链工具按两个站点统计。Search Console 里的 Domain 属性可以一次把主域和所有子域名都覆盖进来，这听起来省事，但反过来，当你要按市场切数据时，这个属性把所有层级压平了。等于两头都不顺。
hreflang 的对称性，本质是结构决定的
hreflang 的规则本身不长：注解必须互指，每一条都要指向一个真实、可收录的 URL，页面要自指，缺一条返回注解，这一对就作废。
真正麻烦的是“要维护多少条”。放在同一个域名下，所有语言版本的互指注解可以集中在同一份 sitemap 里，改动是一处。分散在 N 个国别域名上，就是 N 份文件，而且返回注解落在另一个域名、可能是另一个仓库、另一次发布流程里。错一条，配对的另一边也跟着失效，但报错只会出现在你正好检查的那一侧。
还有一件常被混在一起的事：hreflang 不做权重合并。它只告诉搜索引擎，这几个 URL 是同一内容的不同语言或地区版本，给对应的人看该给哪一个。同一个内容出现两个 URL、需要合并信号时，那是 canonical 的活。把这两个当同一件事处理，是大多数坏掉的国际站架构的起点。而结构选得越碎，你越容易被逼着用 hreflang 去解决 canonical 的问题。
加第二个市场那天，账单才开始结算
如果一开始是文件夹，后来想拆成独立国别域名：每个 URL 都要 301，得有完整的重定向映射，新域名要在 Search Console 重新验证，旧属性的历史数据留在原地，两个属性事后合不到一起。前期省下的那点域名成本，在这里会以一个迁移项目的形式还回来。
反过来，一开始就是国别域名，后来想收回文件夹：这件事更难。一个已经有历史的域名，只能整体重定向到某个文件夹，它自己积累的信号不会自动搬过去。
所以真正该问的不是“哪种结构好”，而是“三年后我要同时维护几份 hreflang 文件、几个属性、几套验证”。如果一年内计划开三个以上市场，文件夹在维护成本上基本没有对手。如果某个单一市场占了大头，而且那个市场的用户对本地域名特别敏感，单独给那一个市场配国别域名、其余放文件夹，也是一种说得通的结构。前提是把你为什么这么分的规则写下来：混合结构本身不会出错，出错的是没有规则，下一次加市场时没人知道该往哪边放。
我现在看一个新项目，先看的不是关键词，是域名结构那一行。加市场是必然会发生的事，而结构是唯一一个以后每加一次都要重新付一遍的决定。
