UrlEdge
Voltar ao blog
17 de maio de 2026 UrlEdge Editorial4 min read

www, domínio raiz e wildcard forwarding sem quebrar SEO

Normalizar host parece simples até raiz, www, subdomínios, caminhos e query strings seguirem regras diferentes. Uma política clara mantém a URL canônica estável.

Mapa de normalização mostrando domínio raiz, www e subdomínios wildcard resolvendo para um host canônico

Normalizar host parece uma tarefa pequena até entrar tráfego real.

Uma marca prefere o domínio raiz. O site antigo usa www. Uma loja, blog ou campanha usa subdomínio. A agência pede wildcard forwarding. Um link de mídia paga ainda precisa preservar path e UTM. Se cada parte decide sozinha, o resultado costuma ser cadeia de redirecionamento.

A pergunta não é se www ou raiz é sempre melhor. A pergunta é qual host será canônico e como as outras variantes vão seguir esse destino.

Se isso faz parte de uma migração maior, comece pela checklist de redirects para migração de site. Aqui o assunto é a camada de host.

Host também é política de URL

example.com.br, www.example.com.br e *.example.com.br não são iguais na operação.

  • O domínio raiz pode ficar mais limpo em marketing.
  • www ainda aparece em stacks antigas.
  • Subdomínio pode ser loja, docs, suporte ou produto.
  • Wildcard ajuda quando muitos hosts seguem a mesma regra.

O importante é não deixar isso acontecer por acidente.

Host normalization map for apex, www, and wildcard subdomains

Escolha o host canônico antes do lançamento

Responda cedo:

PerguntaPor que importa
O site fica na raiz ou em www?Define a URL canônica visível
Quais subdomínios são aliases?Nem todo subdomínio deve ser unido
Caminhos devem ser preservados?SEO, favoritos e deep links dependem disso
Query strings sobrevivem?UTM, cupom e IDs podem sumir
Há exceções temporárias?Campanhas e lançamentos podem precisar de outra lógica

Se isso fica aberto, várias camadas tentam ajudar ao mesmo tempo.

DNS não resolve tudo

DNS aponta para onde o tráfego vai. Ele não decide sozinho a mudança visível de URL.

Modelo limpo:

http://www.marca-antiga.example/precos?utm_source=email
  -> https://marca-nova.example/precos?utm_source=email

Modelo frágil:

http://www.marca-antiga.example/precos
  -> https://www.marca-antiga.example/precos
  -> https://marca-antiga.example/precos
  -> https://marca-nova.example/precos

Um hop é mais fácil de auditar e manter.

Wildcard forwarding funciona quando a estrutura acompanha

Uma regra wildcard ajuda quando os paths continuam alinhados:

old.example.com/* -> new.example.com/$1

Funciona bem quando:

  • há muitas URLs antigas para preservar
  • a estrutura mudou pouco
  • você não quer escrever uma regra por página
  • subdomínios antigos são aliases reais

Se a arquitetura mudou muito, mapeie explicitamente as URLs importantes.

Preserve path e query quando o link ainda importa

Normalizar host não deve apagar o contexto.

http://old.example.com/docs/api?ref=partner&utm_source=newsletter

deveria terminar, se a estrutura permite, em:

https://new.example.com/docs/api?ref=partner&utm_source=newsletter

Isso importa para:

  • páginas SEO
  • documentação
  • mídia paga
  • afiliados
  • links salvos por clientes

Se path ou query somem, o redirect pode parecer certo e mesmo assim perder valor.

Evite a cadeia

O erro comum é espalhar responsabilidades:

  • HTTP para HTTPS em um lugar
  • www para raiz em outro
  • troca de domínio em CDN ou hosting
  • aplicação adiciona outra regra canônica

Resultado: http -> https -> www -> final.

Se sua stack já está assim, leia Redirect chains and loops.

Matriz de QA antes de mover tráfego

Teste variações reais:

TesteExemplo
Raizhttps://example.com.br/
wwwhttps://www.example.com.br/
Path profundohttps://example.com.br/precos
Path com queryhttps://example.com.br/precos?utm_source=email
Host antigo com pathhttps://old.example.com.br/blog/post-1
Subdomínio wildcardhttps://docs.example.com.br/guide

Launch QA matrix for canonical host, path preservation, query preservation, and redirect hops

Confirme:

  • host final correto
  • path preservado
  • query preservada
  • status code certo
  • sem hop extra

Onde a UrlEdge entra

A UrlEdge ajuda quando a normalização de host precisa virar política de routing, não snippet solto.

A vantagem é ter um lugar responsável por host canônico, variantes, paths, queries e status codes.

FAQ

Sempre devo usar raiz em vez de www?

Não. Ambos funcionam. O importante é escolher um canônico e fazer o resto seguir limpo.

Posso cobrir subdomínios wildcard com uma regra?

Sim, se a estrutura continua alinhada. Se mudou muito, use mapeamentos explícitos para URLs importantes.

DNS basta?

Não. DNS não substitui uma política HTTP de redirect visível para o usuário.

Devo preservar parâmetros de campanha?

Normalmente sim, salvo motivo explícito para remover. Atribuição perdida é difícil de recuperar.

Referências

Defina o host canônico uma vez

Redirecione raiz, www e subdomínios wildcard com HTTPS automático, preservação de caminho e destino canônico.

Testar Free Redirect Service

Artigos relacionados

Ver tudo