Tradução de um site Next.js: rotas de idioma rastreáveis e SEO

Traduzir um site Next.js não é apenas uma questão de usar uma biblioteca de i18n. Os mecanismos de busca precisam de URLs distintas e rastreáveis para cada versão de idioma, com metadados e conteúdo renderizados na resposta HTML inicial. Seletores de idioma baseados em cookies ou que funcionam apenas no cliente em uma única URL deixam o Google sem páginas separadas para indexar.

Resposta rápida: rotas de idioma rastreáveis são melhores que seletores baseados em cookies

Se você precisa de uma única regra antes de se aprofundar nos segmentos do App Router: dê a cada idioma sua própria URL rastreável. O Google recomenda URLs diferentes por idioma ou região, em vez de depender apenas de cookies ou do idioma do navegador. Prefixos de caminho como /en/ e /de/, subdomínios dedicados ou domínios separados criam endereços indexáveis. Seletores que dependem apenas de cookies em uma única URL não fazem isso.

A troca de idioma baseada em cookies pode parecer conveniente durante o desenvolvimento, pois evita a duplicação de rotas. Para o SEO em produção, esse padrão esconde as variantes de idioma dos rastreadores. Idiomas definidos por caminhos disponibilizam endereços estáveis que você pode listar em sitemaps, anotar com hreflang e monitorar no Search Console. Para entender melhor a diferença entre uma estratégia por mercado e uma por idioma, consulte nosso guia sobre SEO internacional versus SEO multilíngue.

Escolha um padrão de URL para idiomas no Next.js

As equipes que usam Next.js costumam escolher um destes três padrões rastreáveis:

1. Subdiretórios — example.com/en/docs, example.com/fr/docs. Fáceis de implantar em um único host; hierarquia clara para hreflang.
2. Subdomínios — en.example.com, fr.example.com. Úteis quando as equipes regionais operam com certa independência; ainda exigem hreflang recíproco.
3. ccTLDs ou domínios dedicados — sinal geográfico mais forte quando você realmente opera propriedades separadas; maior custo e complexidade operacional.

O Google determina o idioma da página principalmente pelo conteúdo visível. Seja qual for o padrão escolhido, mantenha cada URL predominantemente em um único idioma — incluindo navegação, links do rodapé e páginas de erro. Evite misturar idiomas no mesmo modelo sem um motivo claro para o usuário.

Não redirecione visitantes automaticamente com base em suposições sobre idioma ou localização. O Google desaconselha esse comportamento porque ele pode bloquear rastreadores e frustrar os usuários. Em vez disso, ofereça um seletor de idioma visível com links para as URLs das versões alternativas.

App Router e estrutura dos segmentos de idioma

No App Router, o padrão mais comum é usar um segmento dinâmico [locale]: app/[locale]/layout.tsx engloba as páginas localizadas. Defina os idiomas e regiões compatíveis em um único objeto de configuração e valide params.locale nos layouts ou no middleware. Localidades inválidas devem retornar um erro 404, e não exibir silenciosamente o conteúdo em inglês na mesma URL.

O middleware pode redirecionar o caminho raiz / para uma pasta de idioma padrão, como /en/, mas mantenha as versões alternativas acessíveis por links. Combine o middleware com generateStaticParams ao gerar páginas de marketing estaticamente, para que cada versão de idioma seja gerada antecipadamente.

Idiomas por cookies versus por caminhos: a negociação por cookies ou cabeçalhos em uma única URL altera o conteúdo sem mudar o endereço. Em geral, os rastreadores acessam cada URL uma vez; eles não verão todas as variantes de idioma. Idiomas definidos por caminhos (ou por subdomínios/domínios equivalentes) seguem a orientação do Google de usar URLs diferentes. Os cookies ainda podem armazenar a preferência do usuário depois que ele escolher um idioma, desde que as URLs públicas permaneçam distintas.

Use next-intl, next-i18next ou bibliotecas semelhantes para carregar mensagens, mas deixe que o roteamento — e não apenas os cookies — defina as URLs públicas.

Localize metadados, Open Graph e dados estruturados

Cada rota de idioma precisa de seu próprio <title>, metadescrição, URL canônica e tags Open Graph no HTML renderizado no servidor. No App Router, use generateMetadata em cada página, lendo as strings traduzidas dos arquivos de mensagens. O título e a metadescrição localizados não devem depender de uma troca de idioma no cliente após a hidratação.

Aplique o mesmo rigor ao JSON-LD: os blocos WebPage, Organization e FAQ devem usar strings traduzidas e valores de inLanguage adequados ao idioma e à região. Se você gerar elementos de link hreflang, crie o conjunto recíproco completo no layout ou na função auxiliar de metadados da página — a ausência de links de retorno compromete os grupos de hreflang.

Hreflang, URLs canônicas e sitemaps para Next.js

O hreflang informa ao Google sobre URLs alternativas por idioma ou região. Cada URL de um grupo deve referenciar todas as outras, incluindo a si mesma, com códigos correspondentes. Implemente o hreflang em <head>, nos cabeçalhos HTTP ou em sitemaps XML por meio de entradas xhtml:link — escolha um método consistente para cada site.

Cada URL de idioma também precisa de uma tag canônica que aponte para a URL preferencial daquele idioma quando houver duplicatas (por exemplo, parâmetros de rastreamento ou versões para impressão). Não defina a versão em inglês como canônica de uma página em francês; as tags canônicas consolidam duplicatas dentro do mesmo idioma.

Gere sitemaps por idioma ou um único índice de sitemaps que liste as URLs de todos os idiomas. Os sitemaps facilitam a descoberta e podem incluir anotações hreflang. Após a implantação, verifique uma amostra usando a Inspeção de URL do Search Console e um processo de teste de hreflang. A visão geral da nossa plataforma de SEO multilíngue explica como as equipes de SEO auditam esses sinais em diferentes idiomas e regiões.

Evite estruturas de página com tradução apenas no cliente

Um erro frequente no Next.js é renderizar uma estrutura HTML em inglês e depois substituir as strings em useEffect. Os rastreadores podem não executar essa troca de forma confiável; os usuários veem brevemente o idioma errado. Server Components, geração estática ou SSR devem renderizar o conteúdo traduzido já na primeira resposta. Client Components podem hidratar elementos interativos, mas o conteúdo de marketing e os títulos devem ficar na árvore de componentes do servidor.

Rotas de idioma baseadas em caminhos ou subdomínios criam URLs distintas e rastreáveis; seletores de idioma que dependem apenas de cookies não atendem à recomendação do Google. Se você usar um proxy de tradução para pré-visualização, garanta que o ambiente de produção continue entregando HTML completo para cada URL de idioma.

Fluxo de trabalho de conteúdo: glossário, memória de tradução e revisão

As escolhas de engenharia não trazem resultados no mercado quando as traduções se afastam da terminologia do produto. Complemente os arquivos de i18n do Next.js com um glossário, memória de tradução (TM) e revisão humana. As orientações do Google sobre conteúdo útil priorizam páginas feitas para as pessoas; versões de idioma com conteúdo superficial ou apenas padronizado são fracas tanto para SEO quanto como fontes de respostas.

Esboço do fluxo de trabalho:

• Extraia strings de arquivos JSON ou PO para um fluxo compatível com ferramentas de tradução assistida por computador (CAT).
• Garanta o uso dos termos do glossário para nomes de produtos e rótulos da interface.
• Faça o controle de qualidade linguística nas URLs do ambiente de homologação, em vez de apenas comparar alterações nos arquivos de origem.
• Sincronize novamente quando o conteúdo original em inglês mudar; versões de idioma desatualizadas prejudicam a confiança.

Lista de verificação de implementação

Antes do lançamento, confirme os caminhos de rastreamento, os metadados e as anotações:

• URL pública distinta para cada idioma ou região (caminho, subdomínio ou domínio)
• Seletor de idioma visível com links para URLs alternativas
• Títulos e descrições renderizados no servidor para cada idioma e região
• Hreflang recíproco em todo o grupo
• URLs canônicas por idioma, sem apontar para versões em outros idiomas
• Entradas de sitemap adequadas a cada idioma e região
• Ausência de redirecionamentos automáticos por localização ou idioma que bloqueiem rastreadores
• Controle de qualidade no ambiente de homologação, nos idiomas de destino e com navegação real

As Diretrizes para Webmasters do Bing também enfatizam conteúdo rastreável e útil, além de uma estrutura clara — os padrões que ajudam o Google geralmente também favorecem a indexação no Bing.

Erros comuns

Idioma definido apenas por cookies em uma única URL — esconde as variantes dos rastreadores.

Ausência de links hreflang de retorno — quebra a reciprocidade e enfraquece o agrupamento.

URL canônica em inglês nas páginas traduzidas — envia o sinal errado de consolidação.

Metadados apenas do lado do cliente — títulos e descrições ausentes do HTML inicial.

Redirecionamento automático por IP ou Accept-Language — bloqueia os rastreadores e ignora a escolha do utilizador.

Elementos da interface por traduzir — a navegação com vários idiomas misturados dificulta a deteção do idioma.

Tradução automática superficial e sem revisão — não corresponde às expectativas de conteúdo útil.

Fundamentos da busca tradicional e dos mecanismos de respostas

Os fundamentos comuns às rotas por idioma no Next.js e ao HTML renderizado no servidor continuam a ser importantes para o Google, o Bing e os motores de resposta: versões linguísticas rastreáveis, entidades claramente identificadas, afirmações sustentadas por evidências, dados estruturados que correspondam à realidade e uma verdadeira localização — não apenas estruturas em inglês. Encare os guias abaixo como perspetivas específicas de cada plataforma sobre os mesmos requisitos de disponibilização de conteúdo multilingue.

Guia da plataforma: Pesquisa Google

Na Pesquisa Google, a descoberta depende de URLs de idioma e região rastreáveis, com HTML adequado ao idioma, títulos e cabeçalhos precisos e hreflang recíproco quando houver versões alternativas. Os fundamentos técnicos incluem conteúdo indexável (não apenas seletores baseados em cookies), metadados localizados, sitemaps e rigor na canonicalização. Qualidade de conteúdo significa oferecer conteúdo principal feito para pessoas em cada idioma; a autoridade vem da identidade clara da organização e de fontes que confirmem as informações — não do marketing de ferramentas de tradução. Implicação multilíngue: cada URL de mercado ou idioma deve funcionar de forma independente. Meça os resultados com a cobertura do Search Console e a Inspeção de URL por idioma e região. O que se sabe e o que é incerto: o Google documenta o comportamento multilíngue e do hreflang; não garante posicionamentos com base em nenhum CMS ou fluxo de trabalho de MTPE.

Guia da plataforma: Bing

O Bing descobre e indexa páginas multilíngues rastreáveis com estrutura clara, de forma semelhante às expectativas do Google quanto à clareza de URLs e conteúdo. Os fundamentos técnicos incluem URLs de idioma e região que possam ser acessadas pelos rastreadores, conteúdo útil e monitoramento no Bing Webmaster Tools. Priorize a localização de cabeçalhos, afirmações e perguntas frequentes, em vez de traduzir apenas os elementos da interface. Os sinais de autoridade continuam dependendo de fontes confiáveis e entidades consistentes. Implicação para sites multilíngues: não esconda idiomas atrás de seletores que funcionam apenas no lado do cliente. Meça a indexação e as estatísticas de rastreamento no Bing Webmaster Tools. O que se sabe e o que é incerto: as diretrizes do Bing enfatizam conteúdo útil e rastreável; não invente fatores de classificação exclusivos do Bing para ferramentas de tradução.

Guia da plataforma: ChatGPT

O ChatGPT pode citar ou resumir páginas acessíveis publicamente quando as versões de idioma são claras e estão prontas para fornecer respostas. A descoberta não segue uma classificação convencional de busca por rastreamento; a visibilidade se manifesta na seleção como fonte ou na menção nas respostas. Os fundamentos técnicos ainda começam com URLs HTML acessíveis — não com sobreposições de widgets que ocultam o texto. Entre as qualidades de conteúdo que ajudam estão respostas diretas, perguntas frequentes e terminologia estável baseada em glossários. A autoridade vem de evidências e de entidades consistentes entre versões de idioma e região. Implicação multilíngue: cada página localizada deve ser compreensível por si só. A medição é imperfeita — trate as verificações de citações como hipóteses. O que se sabe e o que é incerto: não há garantia documentada de que a MTPE ou qualquer integração com um CMS gere citações no ChatGPT.

Guia da plataforma: Gemini

O Gemini e as experiências relacionadas de IA do Google se beneficiam de entidades coerentes, dados estruturados precisos e páginas localizadas indexáveis. A visibilidade está ligada a receber referências ou ser reconhecido — não a inventar fatores de classificação do Gemini. Os fundamentos técnicos coincidem com os da Pesquisa Google em relação à rastreabilidade e à qualidade dos metadados. O conteúdo deve apresentar afirmações e definições claras em cada idioma. A autoridade depende da consistência da organização e da confirmação das informações por outras fontes. Implicação para sites multilíngues: nomes de produtos padronizados por um glossário reduzem a confusão entre versões de idioma e região. Faça a medição tradicional pelo Search Console e avalie qualitativamente amostras de respostas da IA. O que se sabe e o que é incerto: o comportamento do Gemini não substitui as orientações documentadas da Pesquisa Google sobre hreflang e versões de idioma.

Guia da plataforma: Google AI Overviews

O Google AI Overviews pode incluir links para páginas de apoio; os critérios de elegibilidade continuam baseados em conteúdo indexável e voltado para as pessoas. Esse recurso não funciona como um seletor de idiomas nem substitui o hreflang. As bases técnicas continuam sendo HTML rastreável para cada localidade e dados estruturados fiéis ao conteúdo. Entre as qualidades do conteúdo estão respostas concisas e títulos claros em cada idioma. Os sinais de autoridade seguem as expectativas para conteúdo útil. Implicação para sites multilíngues: a inclusão no AI Overviews não é garantida para nenhuma página traduzida. Acompanhe os relatórios de recursos generativos no Search Console, quando disponíveis, e mantenha as métricas tradicionais de indexação separadas. O que se sabe e o que permanece incerto: nenhum fluxo de trabalho de tradução pode prometer presença no AI Overviews.

Onde a GlotEO se encaixa

Uma implementação própria de i18n em Next.js funciona para sites pequenos; à medida que a escala aumenta, tornam-se necessários o controlo do glossário, as filas de revisão e a validação de SEO em todas as versões regionais. A GlotEO integra-se com tecnologias modernas para que as equipas de marketing façam a gestão das traduções enquanto as equipas de engenharia mantêm a estrutura do App Router.

As equipas que tratam a localização como uma questão de encaminhamento e qualidade do conteúdo — e não apenas como uma substituição de textos — lançam novas versões mais rapidamente sem comprometer os percursos de rastreio. Partilhe um glossário antes de os tradutores começarem, reveja as páginas em contexto num ambiente de pré-produção e volte a verificar o hreflang sempre que adicionar rotas. Meça a indexação no Search Console por pasta ou subdomínio de cada versão regional, em vez de se basear apenas nos dados agregados do site.

Explore a plataforma de localização de sites em Localização de sites com a GlotEO e compare os preços e planos da GlotEO ao definir o âmbito da implementação.