SEO internacional é o trabalho de fazer um site aparecer na busca de outros países e idiomas, com a versão certa da página para cada mercado. Para um SaaS brasileiro, isso envolve escolher a estrutura de URL (domínio por país, subdomínio ou subpasta), implementar hreflang sem erro, localizar o conteúdo em vez de só traduzir e construir autoridade no país de destino.
A expansão para a América Latina e para mercados como Portugal e Estados Unidos costuma começar pelo produto e pelo time comercial. O site vem depois, muitas vezes com uma tradução automática da home e da página de preços. Meses depois, o time percebe que as páginas em espanhol não aparecem no México. Em alguns casos, o tráfego do Brasil também cai após uma mudança de estrutura feita sem planejamento.
Neste guia eu mostro como escolher a estrutura de URL com base na documentação do Google, como configurar hreflang e evitar os erros mais comuns, quando localizar por país, como pesquisar palavras-chave em cada mercado e como tratar preço, autoridade local e respostas de IA em outros idiomas. No fim há um checklist de auditoria de SEO internacional, que é o ponto de partida que eu recomendo antes de qualquer mudança.
O melhor sinal é demanda que já existe. Se o SaaS vende para fora, o time comercial sabe de onde vêm os clientes. Se ainda não vende, o relatório de desempenho do Search Console mostra, por país, as impressões que o site já recebe. O artigo sobre como usar o Search Console para SEO explica como filtrar esses dados.
Outro critério é capacidade de atender. Um site em espanhol que gera demonstrações sem ninguém para fazer a reunião em espanhol desperdiça demanda e cria uma experiência ruim. Eu recomendo alinhar a expansão do site com a capacidade de vender e dar suporte no idioma de cada mercado.
Também vale lembrar que o SEO internacional multiplica o trabalho de manutenção. Páginas novas e mudanças de preço precisam chegar a todas as versões, com a mesma qualidade. Começar por um ou dois mercados bem atendidos tende a funcionar melhor que abrir vários idiomas de uma vez.
A escolha da estrutura é a decisão mais difícil de reverter, porque qualquer mudança posterior exige migração com redirecionamentos. O Google descreve as opções e os prós e contras de cada uma no guia oficial Managing multi-regional and multilingual sites. A tabela resume o que a documentação aponta.
| Estrutura | Exemplo | Prós segundo o Google | Contras segundo o Google |
|---|---|---|---|
| Domínio de país (ccTLD) | exemplo.mx | Sinal claro de segmentação geográfica; localização do servidor irrelevante; separação fácil entre os sites | Custo maior; disponibilidade do domínio; exige mais infraestrutura; alguns países têm requisitos rígidos para registro |
| Subdomínio em domínio genérico | mx.exemplo.com | Fácil de configurar; permite servidores em locais diferentes; separação fácil entre os sites | O usuário pode não reconhecer a segmentação só pela URL (não fica claro se "mx" é idioma ou país) |
| Subpasta em domínio genérico | exemplo.com/es-mx/ | Fácil de configurar; manutenção baixa, porque usa o mesmo host | O usuário pode não reconhecer a segmentação só pela URL; um único local de servidor; separar os sites é mais difícil |
| Parâmetro de URL | exemplo.com?loc=mx | O Google não recomenda esta opção | Segmentação pela URL difícil; o usuário pode não reconhecer a segmentação só pela URL |
Para a maioria dos SaaS brasileiros em expansão, eu recomendo subpastas num domínio genérico, como exemplo.com/es/ ou exemplo.com/en/. A autoridade construída pelo domínio principal ajuda as novas versões, e a manutenção fica concentrada num único CMS.
O ccTLD faz mais sentido quando a empresa terá operação própria no país, com equipe e marca locais, ou quando o mercado local valoriza muito o domínio nacional. Subdomínio costuma aparecer quando a versão internacional roda em outra plataforma, o que é uma decisão de infraestrutura mais que de SEO.
Um detalhe que muda a decisão antiga: o Search Console tinha um relatório de segmentação internacional que permitia indicar o país de um domínio genérico. O Google descontinuou o relatório de segmentação internacional, então a indicação de mercado passa a depender do hreflang e de sinais locais no próprio conteúdo.
O hreflang é a anotação que diz ao Google quais páginas são versões equivalentes em outro idioma ou para outra região. A documentação Tell Google about localized versions of your page descreve as regras. A função dele é ajudar o Google a mostrar a versão certa para cada usuário.
Na forma de tag no HTML, cada versão da página leva no cabeçalho uma linha como <link rel="alternate" hreflang="es-MX" href="https://exemplo.com/es-mx/precos/">, repetida para todas as versões, inclusive a própria.
É tentador redirecionar o visitante para a versão do país dele com base no IP ou no idioma do navegador. O Google explica, em How Google crawls locale-adaptive pages, que o Googlebot costuma rastrear a partir de endereços IP dos Estados Unidos e pode não ver as versões servidas só para outros locais. O próprio Google recomenda URLs separadas com hreflang.
Na prática, eu prefiro um banner discreto que sugere a versão do país, sem redirecionar à força. O visitante que quer ver a página em inglês estando no Brasil continua vendo, e o robô consegue acessar todas as versões.
A tradução passa o texto para outro idioma. A localização vai além e adapta o conteúdo ao mercado: vocabulário, exemplos, preço, meios de pagamento, integrações relevantes, casos de clientes locais e a forma como o comprador descreve o problema.
O guia do Google sobre sites multilíngues recomenda usar um único idioma por página e evitar traduzir só o menu e o rodapé deixando o conteúdo no idioma original. Tradução automática sem revisão também merece cuidado: as políticas de spam do Google tratam como abuso a geração de muitas páginas sem valor para o usuário, independentemente de como foram produzidas.
Para começar na América Latina, uma versão em espanhol neutro costuma ser o caminho mais viável. Ela evita regionalismos fortes e atende vários países com um só conjunto de páginas. O limite aparece quando o vocabulário do produto muda de país para país, ou quando há regras locais que alteram o produto, como exigências fiscais e de faturamento.
Diferenças simples de vocabulário já mudam a busca. "Ordenador" é comum na Espanha e "computadora" na maior parte da América Latina; "móvil" e "celular" seguem a mesma divisão. Em Portugal, termos como "utilizador" e "telemóvel" substituem "usuário" e "celular". Um SaaS que vende para Portugal com o texto do Brasil tende a parecer estrangeiro para o comprador local.
Minha recomendação é começar com a versão neutra e criar páginas por país quando houver demanda comprovada e diferença real de produto ou de busca. Aí entram hreflang com código de país, preço local e casos de clientes daquele mercado.
Traduzir a lista de palavras-chave do Brasil é um dos erros mais caros do SEO internacional. O termo que o comprador usa em outro país pode ser diferente, e o volume relativo entre os termos também muda. Cada mercado precisa de pesquisa própria.
O artigo sobre SEO para SaaS detalha como organizar as palavras-chave por etapa do funil, e o mesmo modelo vale para cada mercado.
O guia do Google lista, entre os sinais que ajudam a entender o público de uma página, links de outros sites locais. Um SaaS com autoridade forte no Brasil costuma começar a expansão com pouca presença na mídia e nos portais do país de destino.
Os caminhos mais consistentes são parcerias com empresas e integradores locais, participação em eventos do setor no país, artigos e entrevistas em portais especializados, cadastro em diretórios e marketplaces regionais de software e casos com clientes locais que aceitem ser citados. A página sobre link building explica como a PIPA trabalha essa frente sem comprar links.
A página de preços é, com frequência, a mais visitada antes de um pedido de demonstração. Mostrar valores só em reais para um comprador no Chile cria atrito e ainda envia um sinal confuso sobre o público da página. O Google cita o uso da moeda local entre os sinais que ajudam a identificar o mercado de uma página.
Eu recomendo exibir preço na moeda do mercado, ou pelo menos em dólar para a versão internacional, e explicar no idioma local os meios de pagamento, o tratamento de impostos, a forma de cobrança e as condições de contrato. Se o preço é sob consulta, a página precisa explicar o que define o valor e como funciona a proposta.
O comprador de outro país também pergunta para ChatGPT, Gemini, Claude e Perplexity, no idioma dele. A resposta em espanhol se apoia em fontes em espanhol, e a marca que só tem conteúdo em português tende a ficar de fora ou ser descrita com base em fontes de terceiros.
O Google afirma, na documentação sobre recursos de IA e o seu site, que as boas práticas de SEO continuam valendo para aparecer em AI Overviews e AI Mode. Para GEO internacional, isso começa com páginas localizadas e indexadas. Depois vêm a descrição consistente da empresa em cada idioma e as menções em fontes do país. A medição também precisa ser feita por idioma, com um conjunto de perguntas próprio para cada mercado. A página sobre GEO mostra como a PIPA estrutura esse monitoramento.
Antes de criar versões novas ou de corrigir uma expansão que não está trazendo resultado, eu faço uma auditoria focada nos pontos abaixo. Ela complementa a auditoria geral descrita no artigo sobre o que precisa ter em uma auditoria de SEO.
Boa parte desses itens é técnica e exige ferramenta de rastreamento. A página de SEO técnico explica como a PIPA conduz esse tipo de verificação.
É uma anotação que indica ao Google quais páginas são versões equivalentes em outros idiomas ou para outras regiões. Ela ajuda o buscador a mostrar a versão certa para cada usuário, por exemplo a página em espanhol do México para quem busca no México.
O Google descreve prós e contras das duas opções e não aponta uma como obrigatória. Para a maioria dos SaaS, eu recomendo subpastas, pela facilidade de manutenção e pelo aproveitamento da autoridade do domínio principal. Subdomínio faz sentido quando há razão de infraestrutura para separar as versões.
Pode usar como ponto de partida, desde que haja revisão por alguém que conhece o mercado. As políticas de spam do Google tratam como abuso a geração de páginas em escala sem valor para o usuário, e texto traduzido sem revisão tende a converter mal.
Nem sempre. Uma versão em espanhol neutro costuma bastar no início. Versões por país fazem sentido quando há diferença real de produto, preço, regras locais ou vocabulário de busca.
Estrutura de URL, indexação das versões, hreflang com retorno e códigos válidos, x-default, ausência de redirecionamento por IP, idioma único por página, localização de títulos e preços, pesquisa de palavras-chave por mercado e autoridade local. O checklist deste artigo traz a lista completa.
Pode derrubar se a migração for feita sem mapa de redirecionamentos ou sem monitoramento depois da publicação. Com planejamento, o risco tende a ser menor, mas qualquer mudança de URL exige acompanhamento próximo nas semanas seguintes.
Filtre o Search Console por país e separe as conversões por versão do site no GA4. No CRM, registre o país de origem de cada oportunidade. Assim dá para saber se cada mercado gera receita, além de visitas.
Se o seu SaaS já tem versões em outros idiomas, ou está prestes a criar, uma auditoria internacional mostra o que está impedindo cada versão de aparecer no mercado certo. Se ainda vai começar, ela ajuda a escolher a estrutura antes de publicar a primeira página.
A PIPA faz essa análise inicial sem custo, olhando estrutura, hreflang, conteúdo localizado e presença da marca em buscadores e IAs em cada mercado. Quero meu diagnóstico gratuito
