--- title: Por que um WordPress multilíngue decide se a IA cita você canonical_url: https://lolacore.com/pt-br/wordpress-multilingue-geo/ last_updated: 2026-07-26T11:48:16+00:00 plugin_version: 1.2.3 --- ## O idioma da pergunta decide quem pode ser citado Um modelo generativo que responde a uma pergunta em italiano não traduz a web inteira e depois escolhe a melhor fonte. Ele recupera passagens, e essa recuperação filtra por idioma antes que a qualidade entre em jogo. Sua página em inglês pode ser a mais precisa, a melhor estruturada e a mais autorizada que existe sobre o assunto. Se o leitor perguntou em italiano e não existe versão italiana dessa página, sua página nunca esteve no conjunto entre o qual o modelo escolheu. Esta é a parte que se perde quando o trabalho multilíngue é arquivado sob a etiqueta de "tradução". Estamos diante de um problema de elegibilidade, não de ranking, e por isso não se ganha com conteúdo melhor em inglês. Ou você tem uma página no idioma da pergunta ou não tem, e nenhuma quantidade de qualidade do outro lado compensa essa ausência. Isso muda todo o quadro da decisão. Traduzir seu site é sobre existir dentro do conjunto de recuperação do modelo que responde a alguém quando decide perguntar no próprio idioma, que é o que as pessoas fazem por padrão quando a resposta vai ser sobre o próprio negócio. Muitos desses leitores leem inglês perfeitamente. Perguntam no idioma deles mesmo assim. ## O que a evidência sustenta e o que não sustenta Sobre esse assunto circulam muitas cifras. Quase todas vêm de empresas que vendem tradução, e várias estão construídas de um jeito que não aguenta uma leitura atenta. Aqui não vamos repeti-las, porque um dado que você não consegue verificar vale menos que um mecanismo sobre o qual você consegue raciocinar diretamente. O mecanismo se sustenta sem as cifras. A recuperação é sensível ao idioma. A documentação do Google sobre sites internacionais diz há anos que URLs por idioma e anotação hreflang correta são como um buscador decide qual versão de uma página corresponde a qual audiência. Motores generativos são construídos em cima da mesma recuperação e dos mesmos sinais. Nada disso precisa de um whitepaper para acreditar. Do que não há evidência boa é de que ativar tradução automática em todo o site produz benefício GEO. Os modelos não contam suas versões de idioma. Eles citam passagens que se leem como se uma pessoa competente as tivesse escrito para aquela audiência. Traduzir literalmente copy comercial é o caminho mais rápido para produzir texto que está tecnicamente em português e semanticamente em lugar nenhum. ## O problema de entidade por baixo do problema de idioma Há um segundo efeito, e para um produto pesa mais que para um blog. Através dos idiomas, o modelo está montando uma imagem do que é seu produto. Mesmo nome, mesmo preço, mesmas capacidades, mesmas afirmações. Quando a página em espanhol diz uma coisa sobre o preço e a inglesa diz outra, quando o nome do produto é suavizado em português porque soou melhor assim, quando o schema de uma versão omite o que as demais declaram, você não criou quatro descrições de um produto. Você criou quatro meias descrições de algo sobre o qual o modelo agora tem menos certeza. Coerência entre versões é o que permite a um modelo tratá-las todas como a mesma entidade e somar a autoridade. Incoerência divide. Por isso traduzir o site de um produto é um exercício de posicionamento antes de ser um exercício linguístico: cada termo que você possui precisa atravessar intacto, e cada termo que você não possui precisa sair no vocabulário que o leitor local usa de verdade. ## O que precisa estar bem montado tecnicamente Os requisitos técnicos são pouco glamorosos e não são negociáveis. Cada idioma vive em sua própria URL. Em um WordPress o usual são subdiretórios: /es/, /pt-br/, /it/. Um idioma por página, nunca misturados. Anotações hreflang conectam as versões entre si e declaram qual corresponde a cada audiência, com tag autorreferencial em todas. O canonical aponta para a própria página no seu idioma, não de volta ao original em inglês, que é a forma mais comum em que uma instalação multilíngue de WordPress se apaga do índice sem ninguém perceber. Marcação schema.org declara inLanguage em cada versão e mantém a mesma identidade de entidade em todas. O sitemap inclui todas as versões. Qualquer plugin de tradução decente para WordPress faz quase tudo isso por você. [LolaCore for Polylang](https://lolacore.com/lolacore-for-polylang/) é a ponte que usamos neste site quando a Lola precisa manter versões vinculadas e hreflang em dia. O importante não é qual você escolhe. O importante é que, se esses sinais estiverem errados, o conteúdo por baixo não se lê como você pretendia, e você pagou o custo de traduzir sem colher o benefício. ## O que traduzir, e em que ordem Não tudo, e a home não vem primeiro. Modelos citam passagens que respondem perguntas. Isso significa documentação, guias, comparativos, páginas de casos de uso, o que as pessoas formulam como pergunta quando digitam em uma janela de chat. Uma home traduzida é um folheto em outro idioma. Uma seção de documentação traduzida é um conjunto de respostas recuperáveis em outro idioma, que é o que acaba aparecendo dentro de uma resposta gerada. Em uma loja WooCommerce, a prioridade equivalente são as fichas de produto, as categorias e as FAQ que penduram nelas, porque o que as pessoas perguntam a um modelo sobre uma loja é justamente o que uma ficha de produto responde. A home importa para o humano que chega depois que o modelo já mandou. O que mandou foi outra coisa. ## O custo que ninguém coloca no orçamento Aqui está a parte que decide se um site multilíngue sobrevive ao primeiro ano. Você publica uma página em inglês. Depois publica em mais três idiomas. Depois muda um preço. Depois renomeia uma função. Depois reescreve a seção que não convertia. Cada uma dessas edições agora são quatro edições, em quatro lugares, em quatro idiomas que talvez você não fale todos, com quatro conjuntos de anotações hreflang que quebram em silêncio se uma versão ficar desatualizada. Ninguém abandona um site multilíngue porque traduzir é difícil. Abandonam porque a manutenção é constante e invisível. A versão em inglês se mantém em dia porque é a que você olha todo dia. As outras três vão ficando para trás, quietas, até que a página italiana descreve um produto que não existe mais e o modelo está citando com toda confiança a um leitor italiano uma afirmação sua que caducou há seis meses. Essa deriva é um sintoma de fadiga administrativa: a distância entre a frase simples que você tem na cabeça, "muda o preço desta página", e a quantidade de telas e idiomas que essa frase toca de verdade. [Aqui explicamos o que queremos dizer com isso.](https://lolacore.com/admin-fatigue/) A consequência prática é uma regra que soa conservadora e não é: escolha menos idiomas do que acha que consegue levar, e mantenha-os sincronizados. Quatro idiomas mantidos ganham de oito idiomas publicados. Uma página desatualizada em um idioma que você não lê é pior do que não ter página, porque ainda é elegível para ser citada. ## Escrito a partir de um site que faz isso Nada do que veio antes é projeção. Este site existe em inglês e em espanhol, e a versão em inglês da página que você está lendo está a um clique no seletor de idioma. Não passou por tradutor automático em bloco. Cada página foi adaptada a partir da intenção, com Polylang e [LolaCore for Polylang](https://lolacore.com/lolacore-for-polylang/), o que significa que a terminologia que nos pertence atravessou como está e a que não nos pertence saiu como um leitor local diz de verdade. O problema de sincronização da seção anterior é ao qual dedicamos tempo real. E é a razão de os próximos idiomas estarem sendo planejados em vez de publicados de uma vez.