德语页面有三条各自独立、都不能破的规则：标题里只有句首词和名词首字母大写，并且把核心复合词压进最前面几个词；URL 里 ä、ö、ü、ß 必须手动转写成 ae、oe、ue、ss，不能交给浏览器去编码；内部链接的锚文本要直接复用目标页所针对的德语查询词形，而不是把英文锚文本翻译过来。这三条都不是风格偏好。任意一条破了，德国用户和 Google 会同时读到同一个信号：这个页面是先从英文写、再翻译过来的。
我第一次被这三条一起绊住，是在改一个德国站的分类页。那天晚上我把英文关键词表关了，屏幕上只留三样东西：左边是竞品在德国 Google 上的结果标题，中间是 CMS 的标题输入框，右边是我一条条抄下来的德语查询词。英文表一开着，我下意识就会去对照，然后标题的语序、大小写、锚文本全跟着英文走了。
我原来那版标题写的是 "Wichtige Tipps Für Den Urlaub"。抄下来的竞品标题大概是另一个样子：一个复合名词打头，一个冒号，后面跟一句普通德语句子，名词大写，其余小写。两句话放在一起，差别一眼就出来了，但那会儿我还说不清差在哪。
后面这几段，是我把那个"说不清"拆开之后留下的东西。
标题的第一条：名词大写，但英文的 Title Case 不能照搬
德语正字法里只有两个大写来源：句子的第一个词，和所有名词。英文标题那套实词首字母全大写的写法，套到德语上就会造出 "Wichtige Tipps Für Den Urlaub" 这种句子。Für 和 Den 都不是名词，却被大写了。德国人看到这个，基本等同于我们中文用户看到一页机翻。
有一个容易漏的例外：尊称 Sie 在任何位置都要大写。"Was Sie beachten sollten" 里的 Sie 大写是对的，不用改。所以判断标准不能简化成"只有名词大写"这一句口号。
Meta description 走同一套规则。它和标题一样会直接出现在结果页上，一个 Title Case 的德语描述，杀伤力和标题一样大。
还有一个纯操作问题：CMS 或编辑器里如果有自动首字母大写、自动 Title Case 的开关，德语站要关掉。我吃过一次亏，一个原本写对的德语标题在上线前被模板重新格式化了一遍。
第二条：复合词太长，前三个词就得把意思交代完
Google 是按显示宽度截断标题的，不是按字符数。德语的麻烦在于，一个复合词就能吃掉英文两三个词的宽度。Rechtsschutzversicherung 是 24 个字母，连在一起，一个词。
所以德语标题的写法跟英文是反的。不要先写修饰语。把核心复合词提到最前面，品牌、年份、形容词全部往后排。理由很直接：一旦被截断，读者该看到的是他正在搜的那个词，而不是 "Die besten"。
我会这样改：不写 "Die besten Tarife für die Rechtsschutzversicherung 2025"，而写 "Rechtsschutzversicherung: Tarife vergleichen und sparen"。
Meta description 没有这么强的紧迫性，因为它的截断位置更靠后，但也别把核心复合词埋进中段。
第三条（URL）：变元音要转写，而不是让浏览器去编码
在 URL 里直接写 ä，浏览器会把它编码成 %C3%A4；ß 会变成 %C3%9F。这不是 Google 的问题，Google 收录带编码的 URL 完全没问题。问题是你每天要打交道的那一圈东西：地址栏、复制粘贴、统计后台、服务器日志、分享到聊天软件时的链接预览。
转写规则是固定的：
- ä 写成 ae，ö 写成 oe，ü 写成 ue
- ß 写成 ss
- 大写同样处理，Ä 写成 Ae 或 ae 都行，但全站要统一，我习惯全部小写
写出来是 muenchen，不是 munchen，也不是把编码后的那一串留在那里。
一个很容易忽略的一致性问题：转写只能做一遍。canonical、hreflang、sitemap、站内链接、旧 URL 的跳转，必须全部指向同一个 slug 形式。半转写——一部分页面是 ae，一部分页面带着 %C3%A4——会让 Search Console 里出现两套 URL，后面的数据会很难看。
代价要说清楚。转写之后 URL 里没有变元音，德语母语者读起来会觉得有点别扭；而且 URL 里含关键词本身是个很弱的信号，我不指望它带来排名。我选转写，是为了让 URL 在各个系统之间搬运的时候不出岔子。
最后一句边界：转写只针对 URL。标题、meta、正文、锚文本、结构化数据文字里的变元音要原样保留，不要写成 ue。
第四条（内部链接）：锚文本用德语人搜的那个词形，不是英文锚的翻译
这一条最容易翻车。英文原稿里的锚文本是 "insurance comparison"，直译过来是 "Versicherung Vergleich"，或者更"通顺"一点 "Vergleich von Versicherungen"。但德国用户敲进搜索框的是 "Versicherungsvergleich"，一个词，连在一起。
规则就一句：锚文本直接复用目标页所针对的那个德语查询词形。目标页打什么词，锚文本就用什么词，不要自己重新造句。
德语语法会给你压力。句子结构经常要求第三格，你想写 "zum Versicherungsvergleich"。我的处理方式是保留复合词不拆，让介词和冠词去承担格的变化。复合词一旦被拆成两个词，它就脱离了那个查询词形。
也别只用一个锚文本。同一个目标页如果有多个入口，可以在 "Versicherungsvergleich"、"Versicherungsvergleiche"、"Versicherungen vergleichen" 之间轮换，但每一个都必须是德国人真的会敲进搜索框的形式，而不是从英文变形过来的。像 "hier klicken"、"mehr erfahren" 这类通用锚，只留给非核心链接。
想验证的话，去德国站的 Search Console 查询报告里看。你能直接看到用户实际用什么词形搜到了你的页面。如果锚文本是从英文翻译来的，报告里会冒出一批你没预料过的长尾，而你想打的那个复合词迟迟不动。
德语爱套从句，所以页面结构要比英文更碎
德语把从句的动词推到句尾，weil、wenn、dass 一出现，一句话很容易长到三行。从英文直译过来的段落会变成一堵墙，而德国读者在屏幕上同样是扫读的。
所以我在德语页面的分段比英文更早：两到三句就换段，每两到三段给一个小标题，关键名词加粗。这不是把内容写浅，德语严肃内容本身不怕长句，变的只是屏幕上的阅读方式。
顺带一句：不要用英文的词数或音节数去控制德语正文的长度，两者没有对应关系，硬套只会让德语读起来很赶。
结构化数据里的文字也跑不掉
FAQ 的问答、Product 的描述、Review 的正文，这些字段会渲染在页面上，所以必须是德语。我见过最刺眼的一类德国站页面：正文是德语，模板自动生成的 FAQ 答案还是英文。用户看不到 schema 源码，但看得到那段英文。
JSON-LD 本身是 UTF-8，变元音直接写 ü 就行，不需要转写成 ue，URL 的转写规则只属于 URL。反过来，在 schema 里写 ue 同样是错的。
还有一个共用模板时经常忘的点：inLanguage 要跟着页面语言走，德语页面上标成 en 是白白送给 Google 一个矛盾信号。
我固定下来的检查顺序
- 先建德语查询表。用德国 Google 的自动补全和相关搜索来攒，不要翻译英文表。
- 定核心复合词。标题里的第一个实词就是它。
- 写标题。句首词和名词大写，其余小写；确认 CMS 的自动 Title Case 是关的。
- 生成 slug。小写、转写、用核心复合词，然后在 canonical、hreflang、sitemap、内链里全部统一。
- 写锚文本。复用目标页的查询词形，复合词不拆。
- 分段、加小标题，比英文版更碎。
- schema 文案德语化，inLanguage 跟着改。
- 上线前找一个德语母语者读一遍标题和前两段。这一步没有替代品。我自己觉得没问题的德语标题，被母语者一句话打回来的次数，多到我不想数。
这三条说到底都不是 Google 的规则，是德语的规则。Google 读到的只是结果。
