Uma das formas mais simples de conseguir mais tráfego orgânico é traduzir um site.
É lógico: mais URLs, mais intenções de pesquisa; se o conteúdo for bom, traz-te mais tráfego.
Claro, fazê-lo com IA parece fácil. E é, em sites pequenos.
Em sites médios e grandes, a coisa complica-se, pelo menos se tentares fazê-lo bem.
Porque não se trata apenas de pegar num artigo em espanhol, colá-lo no ChatGPT e pedir cinco versões.
Isso serve para um teste, mas um site real tem categorias, etiquetas, SEO, imagens, campos personalizados, links internos, menus, páginas de arquivo, páginas iniciais, slugs, datas, hreflang e estrutura editorial.
Sem falar que dentro de cada artigo há negritos, listas e itálicos que convém manter na tradução.
E tudo tem de estar traduzido.
O que fiz esta semana no meu site foi construir um sistema para passar de um site em espanhol para um site multilingue em dez idiomas: inglês, francês, português, italiano, alemão, neerlandês, sueco, polaco e norueguês, usando o plugin Polylang, um plugin desenvolvido por mim e alguns GPTs personalizados.
O resultado é que já tenho o site em dez idiomas, com toda a estrutura de categorias e etiquetas e vários artigos publicados traduzidos.
E com um sistema que acrescenta entre 5 e 10 minutos extra a qualquer artigo em espanhol para o ter traduzido nestes dez idiomas, o que me parece um tempo mais do que razoável.
Conto-te todo o processo caso o queiras repetir.
Índice de Contenidos del Artículo
- 1. O problema inicial: traduzir artigos não era suficiente
- 2. A base: WordPress, Polylang e cópia local
- 3. O sistema: plugin próprio mais GPTs
- 4. O conteúdo já criado: pouco a pouco
- O resultado
- Aprendizagens do processo e conclusão
- Perguntas frequentes
- Sim, mas não convém encarar isso como uma simples tradução de textos. Um site tem artigos, páginas, categorias, etiquetas, slugs, metadados SEO, imagens, links internos, menus, chamadas à ação e relações entre idiomas.
- Precisas de uma instalação multilingue bem montada, de um sistema para relacionar cada conteúdo com a sua tradução e de uma forma controlada de exportar, traduzir e importar a informação.
- Porque isso pode servir para traduzir um texto solto, mas não para traduzir um site completo.
- Polylang serve para gerir a parte multilingue dentro do WordPress e relacionar cada conteúdo com as suas versões noutros idiomas.
- O plugin próprio acrescenta controlo. Permite exportar o conteúdo num formato estruturado, traduzi-lo fora do WordPress e voltar a importá-lo mantendo a lógica interna do site.
- Depois de o sistema estar montado, traduzir um artigo novo pode acrescentar apenas alguns minutos extra ao fluxo de publicação.
- Os GPTs personalizados podem ser suficientes se quiseres manter algum controlo manual e reduzir custos. A API faz mais sentido se quiseres automatizar tudo, integrá-la diretamente no plugin e assumir o custo por uso.
- Sim, mas é preciso dar-lhe instruções concretas.
- Pensar que traduzir um site é apenas mudar o idioma do texto visível.
1. O problema inicial: traduzir artigos não era suficiente
Quando comecei a analisar o desenvolvimento, descobri que, no meu caso, para além dos artigos em si, tinha de traduzir tudo isto:
- Categorias.
- Etiquetas.
- Slugs.
- Meta descrições.
- Títulos SEO.
- Imagens destacadas.
- Textos alternativos.
- Campos ACF.
- Blocos internos.
- Ligações entre artigos.
- Páginas de arquivo.
- Textos fixos do tema.
- Módulos da página inicial.
- CTAs.
- Formulários.
- Tabelas de conteúdos.
- Artigos relacionados.
- Manter datas e notas.
- …
Muitos textos ali e muitos idiomas para fazer isso um a um.
Mas era preciso traduzi-lo, porque se qualquer uma dessas peças ficar em espanhol, a tradução fica a meio.
Por isso o objetivo não era “traduzir conteúdo”, mas criar uma arquitetura multilingue completa e escalável, caso amanhã queira adicionar mais idiomas.
E, de facto, foi isso que aconteceu: comecei só com cinco (inglês, português, francês, alemão e italiano) e acrescentei os outros quatro pelo caminho. E, já agora, comprovei que o sistema me permitia escalar o que fosse preciso.
2. A base: WordPress, Polylang e cópia local
O projeto parte de um site WordPress com tema Genesis, design próprio tipo revista e vários modelos personalizados.
Por ser algo com alguma dimensão e que ia exigir muitos testes, trabalhei com uma cópia local usando LocalWP. A ideia era poder partir coisas sem medo, testar importações, rever taxonomias e validar que Polylang ligava bem cada tradução.
Já agora, usei este plugin como base porque já gera tudo o que é necessário para ter um site em vários idiomas. A partir dele, criei o meu plugin, complementando-o e adaptando-o ao que eu precisava: criar rapidamente a estrutura do site e os artigos em vários idiomas.
Também nesta primeira fase otimizei o LocalWP porque no início o ambiente estava demasiado lento e eu precisava de um lugar onde exportar, importar, apagar, repetir e validar de forma fluida..
3. O sistema: plugin próprio mais GPTs
Poderia ter usado uma solução padrão de tradução automática, mas o objetivo era outro.
Tradução simples de cada artigo
Na tradução dos artigos fui MUITO ambicioso, porque queria um sistema em que GPTs criados para isto traduzissem o conteúdo de cada artigo mantendo:
- O meu estilo pessoal.
- A mesma estrutura do artigo original.
- Títulos oficiais de filmes, séries ou livros em cada idioma (ou seja, se a obra é em espanhol, a tradução deveria usar o título com que estreou em Itália, por exemplo.
- Slugs limpos.
- Alt das imagens traduzidos.
- Yoast com campos completos traduzidos, incluindo description.
- Campos ACF personalizados, para que eu pudesse escolher se são exportados ou não, se são traduzidos ou se ficam como estavam (como, por exemplo, a nota que dou a cada obra nas minhas críticas).
- Fragmentos HTML sem os partir: listas, negritos, blocos de código… que se mantivessem e que as partes necessárias ficassem por traduzir (como os scripts de código).
- Links internos dos artigos: para apontarem para a URL de cada idioma, e não sempre para a original.
- Data de publicação: tem de se manter a original do artigo em espanhol.
Como vês, a lógica por trás disto não é “traduzir e pronto”. Há muitos testes por trás e até alguns descartes, como o schema que, por enquanto, só fica em espanhol.

E, além disso, queria que fosse um sistema gratuito, usando GPTs em vez da API da OpenAI ou da Claude. Mais manual, mas menos custo.
A solução que adotei inclui estes passos:
- Publico um artigo em espanhol da forma habitual.
- Uso o meu plugin para exportar um JSON estruturado, que contém todo o conteúdo do artigo dividido em partes para tradução.
- Um GPT traduz esse JSON para os nove idiomas, devolvendo-me nove JSON (um por idioma).
- O plugin importa os nove JSON traduzidos.
- Polylang liga cada tradução ao seu original.
- Os artigos são gerados como rascunho.
- Revisto e/ou publico.
- Reparo links internos (automaticamente) se for necessário.
Além disso, houve um passo inicial que foi criar a estrutura em vários idiomas. Isto só se faz na primeira vez que há idiomas novos, que no meu caso foram duas vezes: a primeira para os cinco idiomas iniciais e a segunda para os outros quatro.
Se retirarmos essa primeira tarefa única, o processo que desenhei acrescenta cerca de cinco minutos a mais à preparação de cada artigo apenas, enquanto multiplico por nove o conteúdo útil do meu site.
Nada mau.
A estrutura multilingue
Vejamos:
- Site personalizado ao máximo.
- Com textos de interface.
- Uma página inicial que guardava quase todos os seus textos no código.
- 23 categorias e subcategorias, com os seus cabeçalhos de módulos, os seus vários textos em campos à medida e as suas variáveis SEO.
- 24 etiquetas com características semelhantes.
- Vários módulos à medida.
- Plugins que não permitem multilingue por defeito.
E não sei se me esqueço de mais alguma coisa.
Tudo isto tinha de ser traduzido uma vez por idioma. E teria levado, sei lá, pelo menos quatro horas em cada caso. E isso supondo que eu soubesse todos esses idiomas, o que não é o caso.
Nem pensar.
O que fiz?
Pois, este processo:
- Adaptar todos os textos a variáveis, no código e nos campos personalizados do ACF..
- Criar uma funcionalidade no plugin que exporta todas estas variáveis de cada categoria ou etiqueta em JSON.
- Criar um GPT que traduz esse JSON para o idioma de que preciso.
- Adicionar um importador no plugin que recolhe o JSON traduzido e cria a estrutura completa de taxonomias no novo idioma.
- Repetir o processo com cada língua.
- Alterar os textos que ficaram pendentes.
Houve vários pontos que me deram trabalho, como os slugs nas taxonomias, já que o Polylang básico não permite criar dois slugs iguais (só com o Pro).
Ou seja, a etiqueta “comic” em espanhol não podia ser criada como “comic” em inglês, tinha de ser “comic-en” ou semelhante.
Desenvolvi o plugin para permitir isso, mantendo dominio.com/comic em espanhol e dominio.com/en/comic em inglês.
Yaarp (o plugin que eu usava para artigos relacionados) também me dava problemas, por isso desativei-o, já que recomendava artigos de outros idiomas. Provavelmente no futuro criarei uma funcionalidade que priorize o idioma sobre o resto das variáveis nas suas recomendações.
A subscrição à lista noutros idiomas também foi descartada para o lançamento. Talvez no futuro decida enviar a minha newsletter traduzida, mas, por enquanto, não o vou fazer, por isso não criei novas listas no Acumbamail.
4. O conteúdo já criado: pouco a pouco
Tudo o que te contei funciona muito bem para os novos artigos, mas o que acontece aos mais de duzentos que já tenho publicados?
Pois, adorava dizer-te que criei uma funcionalidade que automatiza a tradução deles, mas não é assim.
O máximo a que cheguei foi criar uma funcionalidade que me gera JSON exportados em lotes de vários artigos, mas quando tentei traduzir vários artigos ao mesmo tempo para nove idiomas, o GPT processa pior. Portanto, por enquanto, um a um.

Considerando que demoro cerca de três minutos por artigo, é bastante simples traduzir dez por dia, o que faria com que em menos de um mês tivesse todo o site nos dez idiomas.
Faz sentido para mim.
Também pensei em montar um Hermes e testar se o faz manualmente, mas como por agora não tenho pressa e isto não me dá dinheiro, prefiro não gastar em tokens mais do que o necessário.
O resultado
Por enquanto estou contente. Já tenho mais de dez artigos traduzidos em dez idiomas. Ou seja, o meu site cresceu 33% numa semana.
Por enquanto não estou a forçar a indexação de nada. Quero esperar até ter pelo menos 50 ou 60 artigos. Mas, se indexar, também não me preocupa. Isto é a longo prazo.
O que te posso dizer é que estou contente com o resultado.
Acho que o sistema que montei é bastante robusto — com as suas prováveis melhorias, claro — mas nem nos meus melhores sonhos, há cerca de um ano, imaginava que iria gerir um site multilingue com este volume de conteúdo.
Agora, como digo sempre, veremos onde isto me leva.
Aprendizagens do processo e conclusão
A principal conclusão — que eu já previa — é que traduzir um site com IA não é “traduzir textos”, mas desenhar um sistema.
A IA é super útil se receber entradas limpas e devolver saídas controladas. Mas se lhe deres um bloco enorme, sem estrutura e sem regras, devolve-te algo bonito, mas que não serve para importar.
Acredita, isso aconteceu-me muitas vezes no início disto.
A chave foi construir um sistema onde cada parte faz o que deve fazer:
- WordPress é o coração de tudo.
- Polylang relaciona conteúdos.
- O plugin exporta e importa.
- GPT traduz.
- Eu tomo as decisões editoriais.
Ter claro onde encaixa cada peça e por que faz isso e não outra coisa, foi o que me permitiu criar um sistema real para escalar um site usando a tradução com IA como alavanca.
Se gostaste do meu sistema e queres que eu esclareça algum ponto, deixa as tuas dúvidas nos comentários e eu respondo.

Deixe um comentário