Uma loja PrestaShop que quer vender em vários países enfrenta três problemas em simultâneo: fazer com que a Google mostre a versão certa da página ao visitante certo (segundo a sua língua e o seu país), permitir ao visitante mudar manualmente de versão, e localizar os preços e as moedas sem partir a conformidade com o IVA. Nenhum dos três é trivial, e as suas interações escondidas geram a maioria dos bugs de SEO multipaís que encontramos em auditoria.
Este artigo detalha a mecânica correta para o PrestaShop 8 em 2026: etiquetas hreflang, seletor de país, localização de preços, e as armadilhas que degradam silenciosamente o SEO internacional quando a configuração não é rigorosa.
A armadilha do multipaís mal feito
Nas lojas multipaís que auditamos, duas famílias de problemas repetem-se sem parar.
O conteúdo duplicado sem controlo. Se a sua página de produto está acessível em português para Portugal (/pt-pt/produto-x) E para o Brasil (/pt-br/produto-x) com o mesmo texto, a Google deteta duas páginas quase idênticas e escolhe ela própria qual indexar em prioridade, muitas vezes não a que queria. Sem hreflang explícito, deixa a Google adivinhar.
A segmentação geográfica deficiente. Um comprador espanhol procura o seu produto, a Google mostra-lhe a versão portuguesa (/pt/) em vez da versão espanhola (/es/). O cliente clica, vê preços e portes para Portugal continental, e desiste a pensar que não entrega em Espanha. Tem a oferta, entrega lá, mas o visitante não sabe porque lhe foi servida a versão errada.
Estes dois problemas resolvem-se com as etiquetas hreflang, desde que estejam corretamente implementadas. Nas auditorias que fazemos, cerca de 60 % das lojas multipaís têm um hreflang tecnicamente partido: etiquetas ausentes, etiquetas não recíprocas, códigos de país mal formados, conflito com as etiquetas canónicas. Nenhum destes bugs é visível do lado do visitante; descobre o problema quando o tráfego de Espanha fica a zero durante 18 meses apesar de o mercado estar aberto.
Hreflang: a etiqueta-chave do SEO multipaís
A etiqueta hreflang diz à Google: «esta página existe também para este outro país ou língua, e este é o URL dessa outra versão». Coloca-se no head de cada página, no sitemap XML ou nos cabeçalhos HTTP. As três formas são válidas, mas o head é o mais simples de depurar.
Formato mínimo para uma página de produto que existe em pt-PT, pt-BR e es-ES:
<link rel="alternate" hreflang="pt-PT" href="https://asualoja.com/pt-pt/produto/...">
<link rel="alternate" hreflang="pt-BR" href="https://asualoja.com/pt-br/produto/...">
<link rel="alternate" hreflang="es-ES" href="https://asualoja.com/es-es/produto/...">
<link rel="alternate" hreflang="x-default" href="https://asualoja.com/produto/...">Quatro regras não negociáveis:
1. Reciprocidade. Se a página A referencia a página B em hreflang, a página B tem de referenciar a página A. Sem isso, a Google ignora a declaração unilateral. É o erro mais frequente: 40 % das lojas multipaís têm pelo menos um hreflang não recíproco algures na sua árvore.
2. Códigos de país e língua corretos. O formato é língua-país segundo a ISO 639-1 (língua) e a ISO 3166-1 alpha-2 (país). pt-PT é válido, pt-PRT ou por-PT são inválidos e ignorados. Para o Reino Unido é en-GB, não en-UK.
3. URL absolutos. As etiquetas hreflang têm de conter URL completos (https://...), não caminhos relativos. Um URL relativo parte a etiqueta.
4. Coerência com a canónica. Cada página da grelha hreflang tem de ter a sua própria etiqueta canónica a apontar para si própria, e não para outra versão. Pôr a canónica da página pt-br a apontar para a página pt-pt anula o efeito do hreflang.
No PrestaShop 8, a gestão nativa do hreflang é parcial e muitas vezes incompleta consoante o tema. O módulo Hreflang da DataFirefly automatiza a geração das etiquetas em todas as páginas multilingues, gere a reciprocidade, valida os códigos ISO e sincroniza com o multiloja. É a forma mais rápida de não ter de depurar estas 4 regras à mão, produto a produto.
O seletor de país: UX e ergonomia
O seletor de país é o elemento que permite ao visitante mudar manualmente de versão da loja. Costuma ficar no canto superior direito do cabeçalho (ao lado da conta e do carrinho) ou no rodapé.
Três padrões de UX dominantes em 2026:
A bandeira clicável simples. Uma bandeira (ícone) que representa o país atual, clicável para abrir um menu com os outros países disponíveis. Compacto, imediatamente compreensível, funciona bem em telemóvel. Limite: se gere muitos países (mais de 10), o menu fica comprido e inutilizável.
O seletor com bandeira e nome do país. Combinação de bandeira e texto («Portugal», «Brasil», «España»). Mais acessível (as bandeiras sozinhas são por vezes ambíguas), e trata melhor os países múltiplos com a mesma língua (pt-PT contra pt-BR, es-ES contra es-MX).
A janela de seleção na primeira visita. Nas lojas fortemente multipaís, uma janela que aparece no primeiro carregamento e propõe explicitamente escolher o país. Mais intrusiva, mas evita os erros de segmentação inicial. A usar com parcimónia: muitos utilizadores detestam janelas que aparecem de imediato.
Erro clássico: redirecionar automaticamente o visitante para a versão do país detetado por IP, sem pedir confirmação. Esta prática é explicitamente desaconselhada pela Google (maus sinais para o SEO), frustra os viajantes e os utilizadores de VPN, e parte as ligações partilhadas (um brasileiro que partilha um URL /pt-br/... com um português vê-o redirecionado). A boa prática em 2026: sugerir o país certo ao visitante através de uma faixa discreta («Está em Espanha. Ver a nossa loja espanhola?»), sem o redirecionar sem perguntar.
No PrestaShop 8, o módulo Seletor de País da DataFirefly implementa o padrão bandeira mais nome do país com menu, suporte multiloja nativo e compatibilidade com o módulo Hreflang para coerência da stack multilingue. A configuração é centralizada e sobrevive às atualizações do PrestaShop.
Localização de preços, moedas e conformidade com o IVA
A localização dos preços é o tema mais delicado tecnicamente, porque cruza SEO, UX e conformidade legal.
Moedas. O PrestaShop 8 gere o multimoeda de origem, com taxas de câmbio configuráveis à mão ou sincronizadas por API (BCE, Open Exchange Rates). Nas lojas multipaís, cada versão deve mostrar a moeda local por omissão (euro na zona euro, real no Brasil, libra no Reino Unido, franco suíço na Suíça). O seletor manual continua possível mas é menos usado em 2026: os visitantes preferem ver diretamente a moeda do seu país.
Preço sem IVA e com IVA. Nas lojas B2C, preço com IVA em todo o lado (com menção «IVA incluído»). Nas lojas B2B, preço sem IVA por omissão com menção «s/ IVA» e um comutador para passar a com IVA. Misturar os dois na mesma página sem hierarquia clara é a causa de atrito mais frequente nas lojas mistas B2B e B2C.
IVA por país. Na zona euro, o IVA depende do país de entrega (e não do país da loja) nas vendas B2C acima do limiar OSS (balcão único) de 10 000 € sem IVA por ano, acumulados para toda a União Europeia. Abaixo do limiar, aplica o IVA português. Acima, aplica o IVA do país de entrega e declara através do OSS. O PrestaShop 8 gere o sistema de origem, desde que o módulo OSS esteja ativo e as taxas por país configuradas. Atenção ao caso português: as Regiões Autónomas dos Açores e da Madeira têm taxas próprias, a tratar por zona de IVA separada, e a fatura fiscalmente válida continua a ter de sair de um programa certificado pela AT, seja qual for o país do cliente.
Localização dos preços de marketing. Para além da simples conversão de euro para real, algumas lojas diferenciam os preços por país por razões comerciais (um produto a 49 € em Portugal pode estar a 55 CHF na Suíça, e não à taxa exata). É exequível com multiloja ou grupos de preços, mas exige trabalho produto a produto. No mínimo, os arredondamentos têm de ser coerentes (49,99 € para 49,99 CHF, e não 50,12 CHF, que parece grosseiro).
Configuração nativa do PrestaShop 8 e módulos de terceiros
O PrestaShop 8 expõe de origem várias das peças do multipaís através do multiloja. Eis o que funciona de origem e o que exige módulos complementares.
Nativo: multiloja com um domínio por país. Pode criar várias lojas (no sentido do multiloja do PrestaShop), cada uma com o seu URL (por exemplo aminhaloja.pt para Portugal e aminhaloja.es para Espanha), partilhando o mesmo catálogo ou com catálogo diferenciado. A configuração é sólida e bem documentada.
Nativo: multilingue por loja. Cada loja do multiloja pode ter várias línguas. Uma loja espanhola pode mostrar castelhano, catalão e português, por exemplo.
Em falta no nativo: hreflang automático entre lojas. O PrestaShop não gera espontaneamente as etiquetas hreflang certas quando tem várias lojas com conteúdos traduzidos. É precisamente o papel do módulo hreflang dedicado.
Em falta no nativo: seletor de país unificado. O PrestaShop tem um seletor de língua no rodapé, mas não um verdadeiro seletor de país ou loja com bandeiras. É preciso um módulo dedicado.
Em falta no nativo: sugestões inteligentes. A faixa «Está em Espanha, ver a nossa loja espanhola?» não existe de origem. Implementa-se com um módulo ou com JS à medida.
A combinação mais estável em 2026: multiloja nativo do PrestaShop (um domínio por país principal, subdiretórios para os países secundários da mesma língua), mais o módulo Hreflang DataFirefly para as etiquetas automáticas, mais o módulo Seletor de País DataFirefly para a interface. Os três formam uma stack coerente que cobre 95 % dos casos de uso multipaís sem improviso.
Medir o sucesso do multipaís
Três métricas a montar para avaliar se o multipaís funciona mesmo.
1. Indexação por país na Search Console. Configure cada domínio ou subdiretório do multipaís como propriedade distinta na Search Console. Cada propriedade mostra o tráfego, as pesquisas, os cliques e as posições do país correspondente. Se a loja espanhola tem 5 % do tráfego da loja portuguesa, sabe onde está.
2. Erros de hreflang na Search Console. Search Console > Melhorias > Segmentação internacional detalha os erros de hreflang detetados pela Google: etiquetas não recíprocas, códigos inválidos, conflitos com a canónica. Uma loja multipaís sem erros de hreflang na Search Console é rara; apontar a zero erros é o objetivo.
3. Tráfego e conversão por país no GA4. No GA4, segmente por país (dimensão Country). Compare o rácio entre sessões e conversões por país. Uma distorção (por exemplo, 30 % de sessões de Espanha mas 5 % das conversões) sinaliza um problema de localização de preços ou entregas, ou um problema de UX local.
Conclusão: o multipaís não é uma opção, é um projeto
Muitos comerciantes abordam o multipaís como uma simples opção de configuração: «acrescento Espanha clicando em algumas caixas». A realidade é que um multipaís bem feito é um projeto por si só, que combina SEO (hreflang), UX (seletor de país), localização (preços, moeda, IVA) e medição (analytics por país). Mal feito, o multipaís degrada o SEO em Portugal em vez de abrir mercados adicionais.
O investimento inicial é de alguns dias de configuração séria, mais algumas centenas de euros de módulos dedicados. O retorno, nas lojas que acompanhamos, situa-se geralmente entre 15 % e 40 % de vendas adicionais em 12 a 18 meses, consoante os mercados abertos e a qualidade da execução.
Para aprofundar, percorra as categorias SEO para e-commerce e Tutoriais PrestaShop. E para alinhar o seu PrestaShop 8 com os padrões multipaís de 2026, o par Módulo Hreflang e Seletor de País cobre as peças técnicas em falta no PrestaShop nativo, com configuração unificada em multiloja.
