No GTranslate, a versão gratuita e o plano pago resolvem problemas diferentes. O seletor ajuda uma pessoa a ler a página em outro idioma; o TDN cria uma versão localizada com endereço próprio. Eu testei a solução paga no meu site principal e acabei saindo por causa da estrutura das URLs e de conflitos com o meu cache. É por esses pontos que eu decidiria se vale pagar hoje.
A versão gratuita traduz a leitura, mas não cria outra página
No teste que fiz, o seletor gratuito mudava o texto exibido no navegador, mas a URL continuava igual e a tradução não ficava salva como uma versão separada da página. Isso ajuda alguém que já chegou ao site e quer ler em outra língua; não é o mesmo que publicar páginas localizadas para outras pessoas encontrarem.
O widget antigo do Google deixou de receber suporte em 1º de outubro de 2026. A versão atual do plugin GTranslate substituiu esse widget pelo próprio seletor do serviço, mas a diferença continua: na versão gratuita, o endereço não muda e o texto traduzido não é armazenado como uma página por idioma.
Há também uma condição de uso que muda a recomendação: a versão gratuita é permitida para uso pessoal, educacional, teste interno, organizações sem fins lucrativos e órgãos públicos, desde que o serviço não gere receita diretamente. Sites comerciais ou monetizados precisam de uma assinatura paga adequada. Então eu não instalaria o plano gratuito num blog que ganha dinheiro supondo que basta mostrar um botão de idioma.
A tradução abriu público novo no meu site
Quando comecei a traduzir meu conteúdo, as visitas mensais saíram de perto de 200 mil e passaram de um milhão. A receita com anúncios, naquele período, foi de algo como US$ 300 para cerca de US$ 2 mil. Esse é o resultado do meu site e da configuração que eu tinha; não é uma previsão para quem ativar tradução automática. Para mim, ficou claro que outros idiomas podiam trazer leitores que não encontravam as páginas em português.
Também cresceu o banco de dados e aumentou o trabalho para servir as páginas. Eu já tinha migrado o site para NVMe, e cada idioma adicionava mais conteúdo. Foi por isso que o TDN chamou minha atenção: em vez de manter as traduções no WordPress, a versão paga do GTranslate entrega cópias localizadas pela infraestrutura em nuvem do serviço.
A cobrança mensal também me parecia mais previsível do que pagar por lote de caracteres. Na época eu citei um plano de US$ 19 por mês; trato esse valor como histórico, porque preços e limites atuais dependem do plano. O fornecedor diz que seus planos pagos não cobram adicionalmente por cada palavra traduzida ou página vista. Para um site com muitos artigos e idiomas, esse modelo pode evitar a ampliação do banco e parte da carga da hospedagem de origem.
Escolha a estrutura das URLs antes de ativar o TDN
O TDN permite usar subpastas, como `site.com/fr/`, ou subdomínios, como `fr.site.com`; alguns planos também permitem domínios por país. Eu preferia subpastas para manter os idiomas dentro do domínio principal, mas essa era a minha escolha para aquele projeto, não uma promessa de que uma estrutura sempre ranqueia melhor. O próprio GTranslate orienta a selecionar uma estrutura e não configurar subpasta e subdomínio ao mesmo tempo.
O ponto que me fez hesitar apareceu quando traduzi slugs. No meu teste de 2022, encontrei uma referência `hreflang` com o slug original no endereço do idioma; ao abrir aquele caminho, ele redirecionava para o slug traduzido. O suporte não esclareceu a situação completamente, então preferi não deixar essa configuração no projeto principal. Isso descreve a instalação que testei naquela época, não afirma que o serviço atual sempre se comporta assim.
Antes de publicar os idiomas, eu escolheria a estrutura, decidiria se os slugs precisam de tradução e conferiria o HTML de algumas páginas. Cada referência `hreflang` deve levar à versão correspondente e ao endereço final, sem depender de uma sequência de redirecionamentos. Se os slugs do seu conteúdo são nomes de produto ou termos que devem ficar iguais entre línguas, teste o TDN com a tradução de URL desativada.
- Escolha subpastas, subdomínios ou domínios por país conforme a arquitetura do seu site.
- Defina quais slugs devem mudar; preserve marcas e nomes que continuem iguais nos outros idiomas.
- Inspecione os endereços e as referências hreflang no HTML da página traduzida.
- Abra cada destino: confirme que a URL final responde sem redirecionamento inesperado.
Teste cache, imagens e CSS no mesmo ambiente de produção
No meu site, o TDN precisava conviver com regras de cache da Cloudflare, minificação e uma CDN para imagens. A combinação me trouxe problemas, e o suporte demorou para responder sem resolver todos os pontos. Por isso abandonei a solução no projeto principal.
Isso pode não acontecer na sua instalação. O que eu aprendi é que testar o TDN num WordPress limpo não responde se ele funciona junto do seu tema e das suas otimizações. Eu usaria o mesmo cache, a mesma minificação e a mesma entrega de imagens que o site já utiliza antes de migrar o conteúdo inteiro.
- Ative um idioma e algumas páginas representativas numa área de teste ligada à mesma configuração de cache.
- Confira se texto, folhas de estilo, scripts, imagens e formulários carregam também na URL traduzida.
- Limpe e aqueça o cache de novo; veja se uma língua não recebe HTML da outra.
- Só então estime o trabalho e o custo de levar o restante do site para o TDN.
Confira como editar e recuperar o conteúdo traduzido
No meu teste, eu queria as traduções no MySQL do WordPress para pesquisar e corrigir várias strings de uma vez com ferramentas como Search Regex. Foi um dos motivos para ficar com o TranslatePress. No TDN, os textos traduzidos ficam na infraestrutura do GTranslate, não na minha tabela local.
Isso não quer dizer que você não possa corrigir nada no GTranslate: os planos pagos oferecem um editor visual para ajustar o texto na página. A diferença é onde os dados ficam e o que você consegue fazer com eles fora do painel do fornecedor. Como as páginas traduzidas eram servidas pela plataforma, eu não tinha uma cópia delas no meu MySQL para usar quando quisesse. Antes de contratar, eu perguntaria como exportar ou recuperar as traduções e o que continua funcionando se eu cancelar.
Eu usaria o GTranslate em um site diferente do meu principal
Num site pequeno, com poucas páginas de serviço, eu compararia o custo de uma mensalidade com um plugin que guarde as traduções no WordPress. Foi o que fiz no meu projeto: escolhi o TranslatePress e adaptei uma integração com a API da OpenAI. Também contei <a href="/blog/curso-de-traducao-de-sites-experiencia-e-resultados">como planejei traduzir meus sites</a>.
Num catálogo grande ou num blog que publica conteúdo em muitos idiomas, eu ainda testaria o TDN. Ele pode poupar espaço no banco e tráfego na hospedagem de origem; o preço mensal também pode fazer sentido quando há bastante conteúdo para traduzir. Para um site que ganha dinheiro, porém, eu começaria pelo plano pago compatível, não pelo serviço gratuito.
Minha decisão sairia de um teste pequeno, mas feito com a configuração real: uma subpasta ou subdomínio, algumas páginas com slugs diferentes, meu cache e a edição de traduções no painel. Se os nomes de marca e os slugs internacionais não precisarem mudar, eu desativaria a tradução de URL e confirmaria qual plano cobre a estrutura restante. Se URLs, páginas e correções funcionassem do jeito que preciso, avaliaria o custo atual. No projeto principal, o banco local e os problemas de cache pesaram mais; em outro site, com menos regras e muitos idiomas, o resultado poderia ser diferente.