Como traduzir um site Next.js: rotas por idioma rastreáveis e SEO

Traduzir um site Next.js vai além 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. A troca de idioma por cookies ou apenas no cliente, em uma única URL, deixa o Google sem páginas separadas para indexar.

Resposta rápida: rotas de idioma rastreáveis são melhores que a troca por 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. A troca de idioma apenas por cookies em uma única URL não faz isso.

A troca de idioma por cookies pode parecer conveniente durante o desenvolvimento, pois evita a duplicação de rotas. Em produção, porém, esse padrão prejudica o SEO ao ocultar as versões de idioma dos rastreadores. Idiomas definidos por caminhos oferecem endereços estáveis que você pode listar em sitemaps, sinalizar com hreflang e monitorar no Search Console. Para entender melhor a diferença entre estratégias por mercado e 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 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 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 template sem um motivo claro que beneficie 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 usuários. Em vez disso, ofereça um seletor de idioma visível com links para as URLs das outras versões.

App Router e estrutura dos segmentos de idioma

No App Router, o padrão 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. Valores inválidos devem retornar 404, e não exibir silenciosamente o conteúdo em inglês na mesma URL.

O middleware pode redirecionar / sem prefixo 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 com antecedência.

Idioma por cookie versus por caminho: A negociação por cookie ou cabeçalho em uma única URL altera o conteúdo sem mudar o endereço. Os rastreadores normalmente acessam cada URL uma vez; eles não verão todas as versões 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 continuem 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 <title>, meta description, canonical e tags Open Graph próprios no HTML renderizado no servidor. No App Router, use generateMetadata em cada página, lendo as strings traduzidas dos seus arquivos de mensagens. O título e a meta description 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, gere o conjunto recíproco completo no layout ou na função auxiliar de metadados da página — a ausência de links de retorno quebra os grupos de hreflang.

Hreflang, canonicals e sitemaps para Next.js

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

Cada URL de idioma também precisa de uma canonical apontando 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 página equivalente em inglês como canonical de uma página em francês; canonicals consolidam duplicatas no mesmo idioma.

Gere sitemaps por idioma ou um único índice de sitemaps que liste todas as URLs de idioma. Os sitemaps facilitam a descoberta e podem incluir anotações hreflang. Após a implantação, verifique algumas URLs com a ferramenta de inspeção de URL do Search Console e um fluxo de testes de hreflang. Nossa visão geral da plataforma de SEO multilíngue explica como as equipes de SEO auditam esses sinais em diferentes idiomas e regiões.

Evite estruturas que só mudam de idioma no cliente

Uma armadilha frequente no Next.js é renderizar uma estrutura HTML em inglês e depois trocar as strings em useEffect. Os rastreadores podem não executar essa troca de forma confiável; os usuários veem o idioma errado por um instante. 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 os textos 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; a troca de idioma apenas por cookies não atende à recomendação do Google. Se você usa 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 conteúdo: glossário, memória de tradução e revisão

As escolhas de engenharia falham 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 pessoas; versões de idioma com pouco conteúdo ou apenas textos padronizados 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 nos nomes de produtos e rótulos da interface.
• Faça o controle de qualidade linguística nas URLs de homologação, em vez de apenas comparar os arquivos-fonte.
• Sincronize novamente quando o original em inglês mudar; versões de idioma desatualizadas comprometem a confiança.

Checklist de implementação

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

• URL pública distinta para cada idioma e região (caminho, subdomínio ou domínio)
• Seletor de idioma visível com links para as URLs alternativas
• Títulos e descrições renderizados no servidor para cada idioma e região
• Hreflang recíproco em todo o grupo
• Canonicals por idioma, sem apontar para versões em outros idiomas
• Entradas no sitemap específicas por idioma e região
• Sem redirecionamentos automáticos por localização geográfica ou idioma que bloqueiem rastreadores
• Testes de qualidade em homologação nos idiomas de destino, com navegação real

As Diretrizes para Webmasters do Bing também destacam a importância de conteúdo rastreável e útil e de uma estrutura clara — práticas que ajudam o Google geralmente também favorecem a indexação no Bing.

Erros comuns

Idioma e região definidos apenas por cookies em uma única URL — oculta as variantes dos rastreadores.

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

Canonical apontando para a versão em inglês nas páginas traduzidas — envia o sinal errado de consolidação.

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

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

Elementos da interface não traduzidos — a navegação com idiomas misturados confunde a detecção do idioma.

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

Fundamentos da busca tradicional e dos mecanismos de resposta

Os fundamentos das rotas por idioma e região no Next.js e do HTML renderizado no servidor continuam importantes para o Google, o Bing e os mecanismos de resposta: versões de idioma rastreáveis, entidades bem definidas, afirmações respaldadas por evidências, dados estruturados que reflitam a realidade e localização de verdade — não apenas estruturas em inglês. Considere os guias abaixo como perspectivas específicas de cada plataforma sobre o mesmo padrão de entrega multilíngue.

Guia por plataforma: Google Search

No Google Search, a descoberta depende de URLs por localidade que sejam 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 de idioma baseados em cookies), metadados localizados, sitemaps e uso criterioso de tags canônicas. Qualidade de conteúdo significa ter conteúdo principal voltado às pessoas em cada idioma; a autoridade vem de uma identidade organizacional clara e de fontes que corroborem as informações — não do marketing de ferramentas de tradução. Implicação para sites multilíngues: cada URL de mercado ou idioma precisa funcionar de forma independente. Avalie a cobertura e use a Inspeção de URL do Search Console para cada localidade. O que se sabe e o que é incerto: o Google documenta o comportamento de sites multilíngues e do hreflang, mas não garante posições nos resultados com base em qualquer CMS ou fluxo de pós-edição de tradução automática (MTPE).

Guia por plataforma: Bing

O Bing descobre e indexa páginas multilíngues rastreáveis e bem estruturadas, com expectativas semelhantes às do Google quanto à clareza das URLs e do conteúdo. Os fundamentos técnicos incluem URLs por localidade acessíveis aos rastreadores, conteúdo útil e monitoramento no Bing Webmaster Tools. Prefira localizar 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 da consistência das entidades. Implicação para sites multilíngues: não esconda os idiomas atrás de seletores que funcionam apenas no lado do cliente. Avalie 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 por plataforma: ChatGPT

O ChatGPT pode citar ou resumir páginas acessíveis publicamente quando as versões de idioma estão bem identificadas e o conteúdo está pronto para responder a perguntas. A descoberta não segue a lógica convencional de classificação de páginas rastreadas; a visibilidade se manifesta na seleção como fonte ou na menção em respostas. Os fundamentos técnicos continuam começando por URLs com HTML acessível — não por sobreposições de widgets que ocultam o texto. Entre as características de conteúdo que ajudam estão respostas diretas, perguntas frequentes e terminologia consistente com base em glossários. A autoridade vem de evidências e da consistência das entidades entre localidades. Implicação para sites multilíngues: cada página por localidade deve ser compreensível por si só. A mensuraçã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 CMS gere citações no ChatGPT.

Guia por plataforma: Gemini

O Gemini e outras experiências de IA do Google se beneficiam de entidades coerentes, dados estruturados que reflitam os fatos e páginas localizadas indexáveis. Visibilidade significa ser citado ou reconhecido — não inventar fatores de classificação do Gemini. Os fundamentos técnicos coincidem com os requisitos de rastreabilidade e qualidade dos metadados do Google Search. O conteúdo deve apresentar afirmações e definições claras em cada idioma. A autoridade depende da consistência das informações sobre a organização e de fontes que as corroborem. Implicação para sites multilíngues: nomes de produtos padronizados por glossários reduzem a confusão entre localidades. Faça a mensuração tradicional pelo Search Console e avalie qualitativamente uma amostra das respostas de IA. O que se sabe e o que é incerto: o comportamento do Gemini não substitui as orientações documentadas do Google Search sobre hreflang e versões de idioma.

Guia por plataforma: Google AI Overviews

O Google AI Overviews pode incluir links para páginas que fundamentem as respostas; a elegibilidade continua baseada em conteúdo indexável e voltado às pessoas. O recurso não é um seletor de idioma nem substitui o hreflang. Os fundamentos técnicos continuam sendo HTML rastreável por localidade e dados estruturados que reflitam os fatos. Entre as características de qualidade do conteúdo estão respostas concisas e cabeçalhos claros em cada idioma. Os sinais de autoridade refletem as expectativas de conteúdo útil. Implicação para sites multilíngues: a inclusão no AI Overviews não é garantida para nenhuma página traduzida. Avalie os relatórios de IA generativa do Search Console, quando disponíveis, e mantenha as métricas tradicionais de indexação separadas. O que se sabe e o que é incerto: nenhum fluxo de tradução pode prometer presença no AI Overviews.

Onde a GlotEO se encaixa

Uma implementação própria de i18n no Next.js funciona para sites pequenos; com o crescimento, entram em cena o controle de glossário, as filas de revisão e a validação de SEO para cada idioma e região. O GlotEO se integra a stacks modernas para que profissionais de marketing gerenciem as traduções enquanto a equipe de engenharia mantém a estrutura do App Router.

Equipes que tratam a localização como uma questão de roteamento e qualidade do conteúdo — e não apenas de troca de textos — entregam novas versões mais rápido, sem comprometer os caminhos de rastreamento. Compartilhe um glossário antes de os tradutores começarem, revise as páginas em contexto no ambiente de homologação e verifique novamente o hreflang sempre que adicionar rotas. Monitore a indexação no Search Console por pasta ou subdomínio de idioma e região, em vez de se basear apenas nos dados agregados do site inteiro.

Conheça a plataforma de localização de sites em Localização de sites com o GlotEO e compare preços e planos do GlotEO ao definir o escopo da implementação.