pt-BR 页面照搬英文的标题长度预算，是这套多语言站里最先出问题、也最容易被当成小事放过去的一处：同样的意思用葡萄牙语写出来会明显变长，英文里刚好塞得下的标题，到巴西的搜索结果页上会被从中间切开。要改的不是一个点，是四处会在葡语环境下改变行为的页面元素——标题按像素重新量宽度、带重音字符的 URL 只锁一种编码形态、内链锚文本换成巴西人真正会搜的词、面包屑和导航字符串翻成葡语而不留在英文。四处一起改才成立，单改一处反而更别扭。
把椅子拉到我这边来。屏幕左边是 pt-BR 文章页的标题输入框，中间是搜索结果预览，右边是那份英文原稿的标签页。标题框里那行葡语还在，预览里已经被切在「…como escolher o」的位置，后面那半句没了——而那半句正好是这篇要抢的词。就是在这个预览框里，我第一次意识到英文字符计数器在这里基本没用。
我先看的不是字数，是切口落在哪
字符数是个假指标。截断发生在像素上，桌面端大概在六百像素上下这个量级，我从来不记准数，我记的是切口：切在哪个词上，核心词有没有活下来。葡语多出来的长度不是均匀分布的，它集中在几类东西上——介词和缩合形式（de、da、do、para、com、em、no、na），以及更长的词尾（-ção、-mente、-dade）。一句英文标题翻过来，多出来的两三个词基本全是这类，而它们偏偏喜欢挤在核心词前面。
一个具体的对照：英文写 Best Cheap Running Shoes for Beginners，四十来个字符放得下；写成 Melhores tênis de corrida baratos para iniciantes，末尾的 para iniciantes 已经在切口外面。要保住它，就得把 iniciantes 提到前面，或者砍掉 baratos——而不是把字号问题的责任推给谷歌。
我现在写标题的顺序是反过来的：先在葡语里写，写完看预览，再回头调。不从英文翻，因为一翻就带着英文的语序和英文的填充词。另外几条是我固定执行的：核心词放在前四十个字符内；品牌名永远放最后，切了不心疼；guia completo、tudo o que você precisa saber 这类词一个都不留，它们在英文里是习惯，在葡语里是纯占位。
Meta description 是同一回事，而且更隐蔽。英文写惯了一百五十五字符，照搬过来在葡语里常常超出去一截，被切掉的正好是最后那句行动号召。我的做法是描述在葡语里写到一百四五十字符就停手，把最要紧的一句放第一行——反正第二行随时可能不存在。
重音字符：能写，但必须写死一种
café 这样的 slug，浏览器地址栏里显示 café，实际传输是 caf%C3%A9。两种形态都合法，搜索引擎也都认。真正出问题的是第三种情况：站内一半链接写 /cafe/，另一半写带重音的形态，sitemap 里又是百分号编码的那种，三个地方指向三个地址。
所以我做的第一件事是定形态，两条路都行。省事的做法是去掉重音，写 cafe、saude、educacao，巴西的大站很多这么干。另一种是保留重音，统一用 percent-encode 或者统一按 UTF-8 原始字符输出。选哪条我不坚持，我坚持的是选完当天就锁死：sitemap、正文内链、canonical、hreflang 里的 href，全部指向同一种形态。历史上两种都存在的，做 301 收敛到一个，别留两个都能打开的版本。
还有一个容易被忽略的细节：页面 head 里声明的编码必须是 UTF-8，否则标题里的 ã、ç、õ 在部分结果里会变成 ã 这种乱码；而如果内链的 href 里直接贴了带重音的原始字符、页面编码声明又不正确，爬虫解析出来的地址会和 sitemap 里的对不上。这不是「能不能写重音」的问题，是「写完以后是不是同一个地址」的问题。
锚文本：翻过来的词，不等于巴西人搜的词
英文原稿里一条内链的锚文本写着 cheap flights，直译成 voos baratos 语法上没错，但巴西人实际搜的是 passagens aéreas baratas。翻译工具给你的是「正确的葡语」，不是「被搜索的葡语」，这两者之间的差距，在锚文本上会被放大，因为锚文本本身就是给爬虫看的语义标签。
我现在的规矩是：每一条内链锚文本都回到葡语关键词表里核一遍，不在正文里现翻。葡语里找不到对应词的，宁可用中性说法（este guia、veja o passo a passo），也别硬凑一个直译。另外把英文残渣清干净——click here、read more、learn more 出现在 pt-BR 正文里，不只是难看，是白白浪费掉一个能带语义的锚文本位。
顺带说清巴葡和葡葡的分界
如果站上同时有 pt-BR 和 pt-PT，两边的锚词不能互串：celular 对 telemóvel，ônibus 对 autocarro，geladeira 对 frigorífico。混用不是「用户也看得懂」的问题，是给对面那个语言版本递了错误的语义信号。
标题层级跟着葡语词序走，不要跟着英文语法走
英文的复合名词是修饰语在前：best wireless headphones。逐字翻过来会变成 melhores sem fio fones 这种坏掉的词序，葡语里形容词跟在名词后面，应该是 melhores fones sem fio。H2 从英文逐字翻的时候最容易犯这个毛病——每个词单看都对，连起来没人这么搜。我的做法是 H2 直接从葡语关键词表里取短语、再补成一句话，跳过英文那一层。
面包屑和导航字符串：被爬、被展示、最常被留在英文
Home > Blog > Category 这种字符串在模板里躺了很多年，没人动，理由永远是「用户看得懂英文」。但巴西的结果页里，面包屑经常就显示在标题下面，爬虫也拿它当层级信号。一个葡语页面顶着英文面包屑，在结果页上就是一眼的「这不是给我看的」。
改成 Início > Blog > Categoria 只是开头。同一批要动的还有：上一篇/下一篇、相关阅读、返回顶部、侧栏的分类名、翻页的「第 2 页」。BreadcrumbList 结构化数据里的 name 字段也要跟着改，不然富媒体结果里显示的还是英文——页面显示和结构化数据不一致，是另一个常见的小坑。
内链留在语言版本里面
英文页通常是全站权重最高的，写稿时顺手就往回链，这个动作在一个刚起步的 pt-BR 簇里是有代价的：本来就不多的簇内权重被自己人抽走，葡语页面之间还是孤岛。
我的默认规则很简单：pt-BR 正文里的链接，指向 pt-BR 页面。语言切换交给 hreflang 和语言选择器，不要靠正文内链干这件事。例外我也认：有些产品页、政策页只有英文版，这种我不做语境锚文本链过去，而是明写「英文页面」，或者用中性短语，让读者点之前知道会跳到哪。宁可少一条内链，也别让人在葡语文章里点进英文页再绕回来。
我现在过一遍的顺序
一，标题用葡语直接写，写完只看预览的切口。二，当天定下 slug 形态，sitemap 和内链一起统一。三，抽二十条内链看锚文本，是不是关键词表里的词。四，H2 从葡语词表取，不从英文翻。五，面包屑连同 BreadcrumbList 的 name 一起改。六，最后看 hreflang 和簇内链接是不是都落在语言版本里。
这四处单拎出来，没有一处算得上致命。合起来才是。页面照样能收录，也能排上几个词，但点击率会一直差一口气，簇内权重也攒不起来——而这种差，你在后台的曲线里看不出来是哪一步造成的，只能回到那个预览框前面，看切口落在哪。
