站点结构选型，是外贸独立站所有网站优化动作里悔起来最贵的一步。我们的欧洲市场就是这样翻车的：主站子目录下那批德语、法语页面，Google 抓是抓了，收录只放行三成；两个 ccTLD 独立站更惨，.de 站收录率 31%，.fr 站 22%，基本在搜索结果里隐身。这篇把当初的决策失误、底层机制和迁移过程完整摊开讲。

适用读者：负责外贸独立站 SEO 的技术同学、正在多区域多语言方案里做站点结构选型的团队负责人、接手了「历史遗留多站点」被迫做架构收敛的运维同学。

先交代下我们当时的站点结构

事情要从 2019 年说起。主站 example.com 靠英文站起家，2020 年决定发力欧洲，当时做了两个动作：一边在主站上开了 /de/ 和 /fr/ 子目录，只铺了骨架——分类页加两百多个半成品产品页，翻译机翻完没人工校对；另一边又注册了 .de 和 .fr 两个 ccTLD（country code top-level domain，国家代码顶级域名），各搭了一个独立站。内容团队一共 4 个人，要同时养 5 个语言站点，产能的账从一开始就没算过。

一年半之后做收录盘点，数据很难看。两边内容还互相重复：新品先发 .de 站，隔一周又同步到主站 /de/ 子目录，URL 结构和文案都不一致，Google 面对两套高度相似的页面，只挑了一小部分放进索引。三种主流多区域结构的差异，当时的我们并没有真正算清。

回头看这张表，第三行才是命门：我们的内容团队只有 4 个人，ccTLD 方案需要的是「每个市场至少一个懂行的人」，这个条件根本不成立。

当初为什么拍板选了 ccTLD

复盘这一步，理由今天听着都耳熟。sales 的说法是德国客户只认 .de 域名，参加汉诺威展会递名片时本地后缀有说服力；技术的说法是 .de 站可以放在法兰克福机房，对本地访问速度友好；老板的说法是多几个域名就是多几份资产。三条理由听起来都对，但没有一条讨论过内容产能和权重分散。子目录方案当时也有人提，讨论了两轮就搁置了，理由是「先都试试，哪个跑出来再说」。

这种两头下注的思路在小团队里特别常见，也特别致命。两边都建了，意味着两边都养不熟。画一张当初决策流程的复盘图，问题出在哪个环节一目了然。

flowchart TD
    A[2020 年立项欧洲市场] --> B{结构选型讨论}
    B --> C[ccTLD：.de / .fr 独立域名]
    B --> D[子目录：example.com/de/]
    C --> E[理由：本地信任感强<br/>可放本地机房]
    D --> F[理由：权重集中<br/>一套后台好维护]
    E --> G[决策结果：两边都建<br/>先跑出来再说]
    G --> H[执行一年半<br/>内容团队 4 人养 5 个站点]
    H --> I[结果：ccTLD 站长期不更新<br/>两边内容大面积重复]
    I --> J[复盘结论：只选一条路<br/>按内容产能选子目录]

真正该做的决策动作，是在选型之前先盘内容产能这张底牌。一个月能产出的合格本地化页面是有限的，结构方案必须围着产能转，而不是围着展会名片转。

收录率只有三成，问题出在收录机制上

这一节讲清楚底层机制，因为不看懂机制，迁移方案就是瞎做。Google 对一个页面的处理分三步：抓取（crawling）、索引（indexing）、排序（ranking）。收录率低卡在第二步——抓到了，但没进索引。这就是为什么当时我们在 Search Console 里看覆盖率报告，一排「已抓取，尚未编入索引」，看着特别扎眼。

Google 的规范化机制（canonicalization）在遇到内容高度相似的页面组时，会自己挑一个「代表页面」进索引，其余页面直接判定为重复。我们 .de 站和主站 /de/ 子目录的内容相似度经工具测过一半以上超过 85%，Google 把信号全部押到了 .de 那边，主站子目录页面大面积落选，这就是三成收录率的主要来源。

ccTLD 那边是另一个机制在吃亏。新域名冷启动，外链几乎为零，站点规模小，分到的抓取预算（crawl budget）也小，Googlebot 隔几天才来一次。半年不更新的站，在 Google 眼里活跃度信号一路走低，索引里的存量页面还会慢慢被清出去。两套结构等于互相拆台：一边抢重复内容的信号，一边把有限的抓取预算摊薄成两份。收录率是 SEO 里最诚实的指标，它直接反映了架构层面对抓取和索引机制的干扰程度。

收敛到子目录：301 迁移方案怎么做

方案定下来很干脆：所有市场收敛到主站子目录，ccTLD 全站 301 永久重定向过去。Google 官方文档里对多区域结构的态度也是子目录在权重集中度上占优，这一点在官方的多区域多语言文档里写得很明确，放在文末参考链接里。

迁移的完整时间线是这样走的，前紧后松，关键动作全压在头三周。

flowchart LR
    A[W1：全量 URL 清点<br/>生成 301 映射表] --> B[W2：nginx 上线 301<br/>提交新 sitemap]
    B --> C[W3：hreflang 收口<br/>ccTLD 站标注停更]
    C --> D[W2-W8：每天盯覆盖率报告<br/>处理 404 与软 404]
    D --> E[W9-W12：收录率对照盘点<br/>输出复盘文档]

第一周的 URL 清点没有走人工对表，写了个小脚本做主键匹配。脚本不长，直接贴出来。

# 依赖：Python 3.9+，无第三方库，标准库够用
# 环境：ccTLD 旧 URL 清单与新子目录 URL 清单各导出一份 CSV，字段含 path
import csv

# 读 .de 站全量旧 URL，每行一条站内相对路径
with open("old_de_urls.csv", newline="", encoding="utf-8") as f:
    old_rows = [r["path"] for r in csv.DictReader(f)]

# 读主站 /de/ 子目录的目标 URL 清单，作为迁移终点
with open("new_com_de_urls.csv", newline="", encoding="utf-8") as f:
    new_rows = [r["path"] for r in csv.DictReader(f)]

# 用「路径末段 SKU + 语言码」做主键匹配，比人工对表靠谱
def build_map(old_paths, new_paths):
    mapping = []
    for old in old_paths:
        # 取路径最后一段当 SKU，例如 /produkt/sku-88213 取 sku-88213
        sku = old.strip("/").split("/")[-1]
        # 在新清单里找同 SKU 的子目录页，找不到就落分类页兜底
        hit = [n for n in new_paths if sku in n]
        mapping.append((old, hit[0] if hit else "/de/categories/"))
    return mapping

# 输出给 nginx 用的映射表，同时留一份存档备查
with open("redirect_map_de.csv", "w", newline="", encoding="utf-8") as f:
    w = csv.writer(f)
    w.writerows(build_map(old_rows, new_rows))

兜底规则值得多说一句：匹配不上的旧 URL 一律 301 到对应市场的分类页，而不是 404，这样旧域名积累的那点可怜外链权重才不至于直接蒸发。nginx 侧的配置是两个 server 块的事。

# 环境：nginx 1.20+，.de 站点是独立 server 块
server {
    listen 443 ssl;
    server_name example.de;

    # 整站 301 到主站德语子目录，保留原始路径不丢参数
    return 301 https://www.example.com/de$request_uri;
}

# 主站侧把历史遗留的带语言参数写法归一到路径式
server {
    listen 443 ssl;
    server_name www.example.com;

    # 旧地址带 ?lang=de 的写法统一并进 /de/ 路径
    if ($arg_lang = "de") {
        return 301 https://www.example.com/de$request_uri;
    }
}

上线后第二天就要做的事：把合并后的 XML sitemap 重新提交到 Search Console，旧 ccTLD 站的 sitemap 保留观察。前两周数据会先跌一波，这是机制内的正常现象——Google 在重新评估规范化归属，别慌着回滚。

第二周到第八周的日常盯守也有不少杂活。覆盖率报告里冒出过 217 条 404，大部分来自 .de 站旧博客里已经删掉的节日营销页，这类页面在映射表里故意没给 301，直接放走；另有一批软 404（soft 404，页面返回 200 状态码但内容是空模板），是子目录侧两个翻译未完成的分类页造成的，补完文案后一周内清零。那段期间团队养成了一个习惯：每周五下午固定拉一次抓取统计和覆盖率报告，把数字贴进共享表格，趋势一歪当场就能定位到是哪条迁移规则出的问题。

Search Console 的国际定位设置怎么处理

这里要澄清一个流传很广的误区。很多教程还在教「去 Search Console 设置国际定位（International Targeting）」，但 Google 已经下线了这块面板，官方的解释是这类信号的权重本来就被高估了。真正对区域归属起作用的，是 ccTLD 后缀本身、hreflang 标注和站内链接结构这三个底层信号。

所以迁移时我们的动作是：ccTLD 后缀随 301 迁移自然退场，hreflang 标注全站重新收口一遍，让每对语言版本互相指认。hreflang 的写法细节之前写过一篇，这里不展开，只强调一条跟本次迁移直接相关的：301 到的每个子目录页面，hreflang 返回列表必须包含全部语言版本，包括已经下线的 ccTLD 对应语言，否则 Google 会把部分市场页当成孤立页面重新评估。

60 天后的收录率对照

盘一下迁移后的数据，口径统一取 Search Console 覆盖率报告里「已编入索引」的页面占比，每周五固定拉一次。

三个现象值得记录。第一个，前两周收录率普遍下探，.de 站一度跌到 24%，这是规范化重新评估期的正常波动。第二个，回升曲线不是匀速的，第 6 周起明显加速，对应 Googlebot 对子目录的抓取频次翻了将近一倍——权重集中后抓取预算跟着涨。第三个，原来收录的三成页面在合并后全部保住了排名，没有出现迁移掉排名的情况，说明 301 映射表做得够细。

结尾的话

这个案例里最该被记住的误区是：多买几个域名不等于多几份流量，域名在内容产能跟不上时是负债而不是资产。选型先盘内容产能，再定结构，团队 4 个人就老老实实走子目录。趋势上，Google 对多区域结构的建议这些年一直在收敛，子目录的优先级在官方文档里越来越靠前，犹豫的时候跟着官方口径走，踩坑的概率小得多。

如果你也在被 ccTLD 站的低收录折磨，或者已经完成了类似的迁移，评论区聊聊你们第 60 天的收录数据。

参考与延伸

• Google 官方多区域多语言网站管理指南：https://developers.google.com/search/docs/specialty/international
• Google 官方重定向与搜索说明：https://developers.google.com/search/docs/crawling-indexing/301-redirects
• Google Search Console 官方产品页：https://search.google.com/search-console/about

关键词：SEO、Google收录、ccTLD、子目录结构、301重定向、外贸独立站、多区域站点