Um site criado por IA pode acumular URLs antigas em poucas iterações. O agente renomeia uma página, troca o slug de uma campanha, reorganiza uma seção ou substitui o domínio temporário pelo oficial — mas os links distribuídos continuam chegando aos endereços anteriores.

Redirecionar bem não é mandar toda rota antiga para a home. É decidir se o conteúdo mudou de lugar, se a mudança é permanente ou temporária e se o destino realmente preserva a intenção de quem abriu a URL.

Este guia organiza a revisão da fonte à versão publicada, com atenção a status HTTP, cadeias, loops, canonical e evidências de navegação.

Quando um redirecionamento faz sentido

Um redirect é apropriado quando uma URL ainda recebe acessos e existe um destino equivalente ou claramente sucessor.

Exemplos:

  • /precos-antigos passou a ser /planos;
  • /servicos/design foi consolidada em /servicos/branding com o mesmo propósito;
  • uma campanha mudou de domínio sem mudar de oferta;
  • uma rota foi reorganizada, mas os links antigos continuam publicados;
  • uma página está temporariamente indisponível e há um destino provisório útil.

Não redirecione só para esconder um erro. Se a página foi removida e não há substituta equivalente, uma resposta 404 honesta ajuda mais que enviar a pessoa para uma home genérica. O guia de páginas removidas e erros 404 mostra como decidir entre restaurar, redirecionar e manter a ausência.

Diferencie mudança permanente e temporária

A documentação do Google sobre redirects separa dois grupos:

Situação Status mais comum Sinal principal
mudança permanente 301 ou 308 a URL de destino deve substituir a origem
mudança temporária 302 ou 307 a URL de origem continua sendo a referência

Escolha pelo ciclo de vida, não por hábito.

Use uma mudança permanente quando a rota antiga não voltará e o destino representa o mesmo conteúdo ou necessidade. Use uma mudança temporária quando a origem deverá voltar, como durante uma manutenção ou campanha provisória.

Os códigos 307 e 308 preservam o método HTTP. A referência de status HTTP da MDN detalha essa diferença. Para navegação GET de páginas estáticas, 301 e 302 costumam aparecer com mais frequência; para endpoints e formulários, preservar método e corpo pode ser decisivo.

Comece com um mapa origem → destino

Antes de escrever regras, faça um inventário:

origem: /consultoria-antiga
destino proposto: /consultoria
motivo: reorganização de conteúdo
equivalência: total / parcial / nenhuma
tipo: permanente / temporário
links internos atualizados: sim / não
campanhas externas conhecidas: [lista]
responsável pela decisão: [nome]

Inclua rotas encontradas em:

  • navegação e rodapé;
  • campanhas de e-mail e mídia;
  • sitemap;
  • canonical e Open Graph;
  • Analytics e relatórios de 404;
  • documentos e QR codes;
  • links de parceiros;
  • versões antigas do site;
  • domínios temporários e Custom Domains.

O inventário evita duas decisões perigosas: criar regras sem tráfego ou referência conhecida e apontar uma origem importante para um destino apenas parecido.

Exija equivalência entre as páginas

Um bom redirect responde à pergunta que levou a pessoa até a URL antiga.

Se /ebook-gestao oferecia um material específico, mandá-la para uma home institucional quebra a promessa. Se /produto-a foi incorporada por /produto-b, o destino precisa explicar a continuidade — não apenas compartilhar o mesmo layout.

Classifique cada origem:

  • equivalente: o mesmo conteúdo mudou de URL;
  • sucessora: a oferta ou informação foi substituída por outra claramente relacionada;
  • sem substituta: o conteúdo encerrou e nenhum destino cumpre a mesma intenção;
  • incerta: falta decisão editorial ou comercial.

Crie redirect para as duas primeiras. Para as demais, preserve uma resposta de ausência útil ou interrompa a implementação até a decisão correta.

Trate redirects como capacidade separada do pacote

O contrato atual do Site no Ar publica index.html, outras páginas HTML e assets nos caminhos enviados. Ele não interpreta um arquivo _redirects incluído no pacote. Portanto, não adicione esse arquivo esperando que uma regra de rota seja aplicada automaticamente.

Quando um redirect for indispensável, confirme primeiro qual camada controla a resposta HTTP: um domínio ou proxy administrado pela equipe, uma origem anterior ainda ativa ou uma capacidade de redirect explicitamente oferecida pela plataforma. A regra precisa existir nessa camada e ser testada na URL pública.

Se nenhuma camada autorizada oferecer redirects, não simule a mudança com JavaScript ou meta refresh. Preserve a página antiga quando possível, corrija links internos e campanhas e registre a limitação até existir um mecanismo que devolva o status HTTP adequado. A documentação de Publicação descreve o comportamento suportado para páginas e assets do pacote atual.

Evite regras amplas demais

Uma regra curinga pode simplificar uma migração ou apagar diferenças importantes.

Este exemplo envia tudo para a home:

/* / 301

Ele pode mascarar erros de digitação, páginas removidas e assets ausentes. Também impede que uma URL inexistente devolva 404 corretamente.

Antes de usar um padrão, liste amostras que devem e que não devem combinar:

regra: /conteudos/* → /blog/:splat
deve combinar: /conteudos/guia-de-marca
não deve combinar: /conteudos, /conteudos-antigos/logo.svg

Teste bordas como barra final, letras maiúsculas, parâmetros e caminhos profundos. Não presuma que uma expressão usada em outro provedor terá a mesma sintaxe.

Elimine cadeias e loops

Uma cadeia acontece quando a origem passa por vários saltos:

/a → /b → /c → /destino

Atualize /a, /b e /c para apontarem diretamente ao destino final quando a migração for permanente e equivalente.

Um loop é bloqueante:

/a → /b → /a

Ele também pode surgir de diferenças de hostname, protocolo ou barra final. Uma regra força www, outra força o apex; uma adiciona barra, outra remove. Teste o conjunto como sistema, não linha por linha.

Registre para cada origem:

  • status da primeira resposta;
  • valor do cabeçalho Location;
  • número de saltos;
  • status e conteúdo finais;
  • hostname final;
  • presença de loop ou retorno à origem.

Redirect é uma rede de segurança, não a URL preferida para continuar usando.

Depois de criar a regra:

  1. atualize menus, CTAs e links de conteúdo;
  2. use o destino final no canonical;
  3. remova a origem do sitemap;
  4. atualize Open Graph e links absolutos;
  5. revise campanhas sob controle da equipe;
  6. preserve a origem apenas onde ela ainda precisa capturar referências antigas.

O guia de canonical para sites criados por IA ajuda a manter os sinais convergentes. Para encontrar links que continuam passando por redirects, use o checklist de links quebrados.

Cuidado ao mudar o slug do Site no Ar

Alterar o slug muda a URL <slug>.sitenoar.app. O slug anterior é liberado e não recebe um redirect automático.

Antes de trocar:

  • inventarie onde a URL antiga foi divulgada;
  • decida se o Custom Domain será o endereço público estável;
  • atualize links e metadata no pacote;
  • preserve evidências da versão anterior;
  • teste o novo endereço depois da mudança;
  • trate a URL antiga como uma migração separada, não como um alias garantido.

Um Custom Domain adiciona outro endereço ao mesmo Site, mas não reescreve URLs fixas dentro do HTML. A documentação de Domínios próprios cobre DNS, verificação e SSL.

Teste antes e depois de publicar

Antes de tocar na camada de redirect, confirme na saída da build:

  • os arquivos finais das páginas de destino existem;
  • links internos já apontam para o destino final;
  • canonical e sitemap usam a URL aprovada;
  • nenhuma página aponta para localhost, preview ou domínio de template.

Na camada que realmente controla o redirect, confirme que todas as origens têm destino aprovado, que regras específicas precedem curingas e que a configuração foi aplicada ao hostname correto.

Depois do deploy, faça requisições sem seguir o redirect automaticamente para inspecionar o primeiro salto:

Terminal window
curl -I https://www.exemplo.com/precos-antigos

Em seguida, siga o fluxo completo:

Terminal window
curl -IL https://www.exemplo.com/precos-antigos

Confirme status, Location, quantidade de saltos e conteúdo final. Abra as rotas críticas no navegador, inclusive em mobile, porque o resultado técnico não prova que a página de destino atende à intenção.

Se houver erro, corrija a fonte, gere o pacote e republique o mesmo Site. Não crie outro Site para contornar uma regra defeituosa.

Peça ao agente uma auditoria fechada

Audite os redirecionamentos deste site sem alterar arquivos ainda.


Fonte: [caminho]
Pasta publicável: [pasta]
Domínio oficial: [domínio]
URLs antigas conhecidas: [lista]


Para cada origem, retorne:
- destino atual e destino esperado;
- status HTTP;
- equivalência entre os conteúdos;
- cadeia, loop ou curinga envolvido;
- links internos, canonical e sitemap divergentes;
- arquivo que controla a regra;
- correção mínima proposta.


Não redirecione tudo para a home.
Não troque permanente por temporário sem justificar.
Não publique. Pare quando faltar uma decisão editorial.

Depois da aprovação, peça o diff, a build e uma matriz de testes. A automação deve executar decisões explícitas, não escolher sozinha qual página substitui outra.

Checklist final

  • origem e destino inventariados;
  • equivalência de conteúdo confirmada;
  • tipo permanente ou temporário justificado;
  • regras específicas antes de curingas;
  • nenhuma cadeia ou loop;
  • links internos apontam direto ao destino final;
  • canonical e sitemap usam a URL aprovada;
  • camada responsável pelos redirects foi confirmada;
  • primeira resposta e fluxo completo testados;
  • hostname, barra final e parâmetros conferidos;
  • URL publicada aberta no navegador;
  • evidências registradas por rota e versão.

Redirecionamentos confiáveis preservam a intenção da URL antiga sem transformar o site em um labirinto. Quando regra, conteúdo, metadata, pacote e resposta publicada contam a mesma história, a migração deixa de ser um remendo e passa a ser uma entrega verificável.