Redirecionamento 301 em .htaccess numa migração de domínio

Quando alguém procura redirect 301 htaccess, normalmente está tentando resolver um problema bem direto:

• uma URL antiga precisa apontar para uma nova
• HTTP precisa ir para HTTPS
• um domínio antigo precisa mudar em definitivo

Para poucas regras, .htaccess ainda pode bastar. O problema aparece quando o mesmo hábito é esticado até cobrir uma migração inteira de domínio.

A resposta prática costuma ser:

• para alguns redirects 301 estáveis, .htaccess pode ser suficiente
• para migrações de domínio, rebrands, relaunches ou mapas grandes, .htaccess vira com facilidade um ponto de risco operacional

Se a sua mudança já está em andamento, vale manter aberta também a checklist de migração de site SEO com redirecionamentos 301. Aqui o foco é o ponto de partida clássico: 301 em .htaccess.

A resposta rápida

Uma regra simples pode ser algo assim:

Redirect 301 /pagina-antiga https://www.exemplo.com.br/pagina-nova

E uma mudança completa de domínio com preservação de path costuma virar mod_rewrite:

RewriteEngine On
 
RewriteCond %{HTTP_HOST} ^dominio-antigo\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.dominio-antigo\.com$
RewriteRule ^(.*)$ https://www.dominio-novo.com/$1 [R=301,L]

Isso responde a sintaxe. Não responde a pergunta operacional:

[!TIP] Você ainda está gerindo poucas regras, ou já está gerindo um workflow de migração que exige validação, ownership e rollback?

Quando .htaccess ainda funciona bem

Em geral, ele continua aceitável quando:

• o número de redirects é pequeno
• Apache é a única camada ativa
• não existe CDN, proxy ou middleware também mexendo nas rotas
• a lógica de path é simples
• ownership técnico é claro

Onde começa a dar problema

1. Existem várias camadas de redirect

Na prática, o tráfego pode estar sendo mexido por:

• .htaccess
• plugins de CMS
• Nginx ou load balancers
• Cloudflare
• middleware da aplicação

Então uma migração aparentemente simples vira algo assim:

http://dominio-antigo.com/produto-a
  -> https://dominio-antigo.com/produto-a
  -> https://www.dominio-antigo.com/produto-a
  -> https://www.dominio-novo.com/loja/produto-a

Pode até funcionar, mas ainda é uma arquitetura ruim de migração.

2. Path e query ficam nebulosos

Muitos times testam só a homepage. Depois descobrem que deep links, docs ou parâmetros UTM não chegam como esperado.

3. Wildcard deixa de bastar

Uma regra como:

/blog/* -> /artigos/*

parece elegante até o momento em que:

• categorias foram fundidas
• produtos saíram do catálogo
• algumas páginas exigem exceções

Daí em diante você precisa de:

• mapeamento explícito
• prioridades
• validação
• um mapa de redirecionamentos revisável

4. As mudanças ficam difíceis de auditar

Um merge num arquivo de configuração não é um bom trilho de auditoria de migração.

Muito cedo o time quer saber:

• quem mudou o quê
• quais regras são novas
• quais foram removidas
• onde há conflito
• como voltar atrás

.htaccess sozinho não ajuda muito nisso.

Erros mais comuns

Separar host, HTTPS e destino final em vários saltos

Ruim:

http://dominio-antigo.com/docs/api
  -> https://dominio-antigo.com/docs/api
  -> https://www.dominio-antigo.com/docs/api
  -> https://www.dominio-novo.com/docs/api

Melhor:

http://dominio-antigo.com/docs/api
  -> https://www.dominio-novo.com/docs/api

Testar a homepage e esquecer as URLs importantes

A home parece certa, mas produtos, artigos, docs e URLs antigas de tráfego orgânico não estão.

Perder parâmetros

Se a atribuição depende de email, QR, paid social ou links de parceiros, perder utm_ transforma a migração em problema de SEO e de relatório.

Deixar o mapa de redirects fora da camada live

Quando a verdade do projeto está em uma planilha e as regras vivas num arquivo de servidor, os pontos cegos aumentam.

Quando trocar de workflow

Esse momento costuma chegar quando:

• você migra centenas ou milhares de URLs
• vários times ou agências mexem nas regras
• precisa importar CSV
• quer validar conflitos antes do go-live
• rollback precisa ser claro
• você não quer redeployar origin a cada ajuste

É aí que UrlEdge passa a fazer sentido:

• bulk URL management para mapas grandes
• redirect management para ownership e rollout
• permanent 301 redirects para migrações permanentes

Conclusão

A pergunta real não é se .htaccess é bom ou ruim.

A pergunta real é:

A sua migração ainda cabe em poucas regras manuais de servidor, ou ela já virou um projeto de routing com dependências de SEO, campanhas e vários times?

Se for a segunda opção, o snippet já não resolve o problema inteiro.