Como tratar páginas removidas e erros 404 em sites criados por IA

Remover uma página de um site criado por IA parece simples: apagar o arquivo, gerar outra build e publicar. O problema aparece depois, quando anúncios, buscadores, favoritos, QR codes ou sites parceiros continuam levando pessoas até a rota antiga.

Nem todo 404 precisa virar redirect. Nem toda página removida deve ser restaurada. A decisão correta depende da intenção da URL, da existência de um substituto e do status que a versão publicada realmente devolve.

Este guia mostra como investigar a ausência, escolher uma resposta honesta e oferecer uma saída útil sem mascarar o problema com uma página genérica que responde 200.

O que um 404 realmente informa

O status 404 Not Found informa que o servidor não encontrou o recurso solicitado. Ele não explica se a ausência é temporária, permanente ou um erro de digitação.

Uma resposta 404 pode representar:

• link interno incorreto;
• arquivo omitido do pacote;
• rota renomeada;
• campanha antiga ainda ativa;
• asset removido;
• página encerrada sem substituta;
• endereço digitado errado;
• URL descoberta em uma versão anterior.

O número sozinho não escolhe a correção. Primeiro identifique a origem e a intenção.

Separe quatro decisões possíveis

Para cada rota ausente, escolha uma destas ações:

Em uma infraestrutura que permite indicar remoção permanente, 410 Gone pode ser uma opção. Não simule esse status dentro de um HTML se o hosting continuará devolvendo 200 ou 404; a resposta HTTP pertence à camada que serve a página.

No pacote estático do Site no Ar, trabalhe com uma rota real, um redirect compatível ou um 404.html. Não prometa um status que o artefato não controla.

Confirme se a rota deveria existir

Comece com a fonte e a build:

URL solicitada:
origem do acesso:
arquivo esperado:
rota esperada na build:
última versão em que existia:
conteúdo ou oferta correspondente:
responsável:

Procure por diferenças comuns:

• contato.html foi renomeado, mas o menu ainda usa /contato;
• uma pasta servicos/index.html não entrou na saída;
• o build distingue maiúsculas e minúsculas;
• um base path transformou a URL final;
• a extensão foi preservada em um lugar e removida em outro;
• o arquivo está no repositório, mas não no diretório publicado;
• uma atualização parcial removeu um asset ainda referenciado.

Se a página deveria estar no ar, restaure a causa. Um redirect para outra rota apenas esconderia a regressão.

Redirecione somente quando houver substituto

Quando o conteúdo mudou de endereço, use um redirect permanente para a página equivalente. Se a mudança é provisória, use um redirect temporário.

O guia de revisão de redirecionamentos mostra como escolher status, evitar cadeias e alinhar links, canonical e sitemap.

Não envie toda página removida para a home. A orientação do Google sobre erros de rastreamento recomenda um redirect permanente quando existe uma substituta clara; páginas de erro que devolvem sucesso ou redirects irrelevantes podem ser interpretados como soft 404.

Compare a intenção:

origem: /curso-planilhas
destino: /cursos
equivalência: parcial
pergunta: a nova página responde à promessa específica do link antigo?

Se a resposta for não, mantenha a ausência e ofereça navegação contextual na página 404.

Crie uma página 404 que continue sendo 404

Uma página de erro útil pode ter o mesmo design do site, mas a resposta HTTP deve continuar sendo 404.

No Site no Ar, inclua 404.html na raiz do pacote. A publicação estática procura essa página quando nenhuma rota corresponde e a serve com status 404. A documentação de 404 para sites estáticos nos Workers detalha esse comportamento.

Uma boa página inclui:

• mensagem direta de que a página não foi encontrada;
• link para a home;
• navegação para seções importantes;
• busca, quando o site realmente oferece esse recurso;
• contato ou suporte, se adequado;
• linguagem consistente com a marca;
• foco visível e navegação por teclado;
• nenhum formulário ou CTA enganoso.

Evite:

• culpar a pessoa;
• fingir que nada aconteceu;
• esconder a URL solicitada em um redirect automático;
• copiar uma página 404 de outro cliente;
• carregar scripts e assets desnecessários;
• devolver 200 para qualquer caminho inexistente.

Entenda o soft 404

Um soft 404 acontece quando o conteúdo parece uma página de erro, mas a resposta técnica não representa a ausência corretamente — por exemplo, uma página “não encontrada” com status 200 ou um redirect irrelevante para a home.

Isso pode acontecer quando:

• o roteador de uma SPA devolve index.html para toda URL desconhecida;
• a aplicação renderiza a mensagem no cliente depois de responder 200;
• uma regra curinga manda toda rota para a home;
• uma página vazia permanece publicada;
• o conteúdo principal não carregou e sobrou apenas uma mensagem genérica.

Teste o status antes de avaliar o design:

curl -I https://www.exemplo.com/rota-que-nao-existe

O resultado esperado para uma rota realmente ausente é 404, não 200 com uma aparência de erro.

Atualize as referências sob seu controle

Depois de decidir pela remoção ou migração, revise:

• menu e rodapé;
• links dentro de artigos;
• CTAs e banners;
• sitemap;
• canonical;
• Open Graph;
• campanhas ativas;
• e-mails automáticos;
• arquivos para download;
• QR codes ainda distribuídos;
• integrações e parceiros conhecidos.

Um redirect pode manter links antigos funcionando, mas os links internos devem apontar direto ao destino final. Se não houver redirect, remova as referências que você controla.

O checklist de links quebrados ajuda a inventariar anchors, fragmentos, downloads e rotas produzidas pela build.

Tire URLs removidas do sitemap

O sitemap deve apresentar URLs canônicas e relevantes da versão atual. Não mantenha uma rota 404 na lista apenas porque ela já apareceu em resultados de busca.

Depois de remover:

1. exclua a URL do sitemap;
2. confirme que nenhuma canonical aponta para ela;
3. atualize links internos;
4. publique o pacote;
5. confira a resposta ao vivo;
6. acompanhe o estado externo sem republicar por ansiedade.

O guia de indexação no Google separa deploy, rastreamento, processamento e indexação. Uma URL ainda aparecer em um relatório antigo não prova que a remoção falhou.

Teste rotas conhecidas e desconhecidas

Monte uma matriz pequena:

Faça os testes na build e depois no domínio publicado. Para redirects, inspecione o primeiro status e o destino final. Para 404, compare status, conteúdo, assets e links de recuperação.

Também confirme que 404.html não entrou no sitemap e não declara canonical para a própria URL de erro como se fosse conteúdo indexável.

Use Analytics para descobrir o que escapou

O Analytics do Site no Ar, no plano Pro, mostra respostas 404 observadas em navegações de página e os caminhos mais frequentes em janelas de 7, 30 ou 90 dias. Esse recorte não é um inventário de todo asset ausente nem de toda requisição automatizada que chegou ao host.

Esses dados podem revelar:

• campanha com rota antiga;
• typo recorrente;
• link externo fora do controle da equipe;
• página que ainda recebe tráfego suficiente para merecer um redirect;

Frequência não prova valor comercial. Cruze o caminho com origem, intenção e conteúdo anterior. O guia de Analytics para landing pages mostra como separar fato, hipótese e próxima ação.

Preserve a mesma identidade do Site

Se a ausência veio de uma publicação incompleta, corrija a fonte e republique o mesmo Site. Isso preserva URL, domínio e continuidade operacional.

Criar outro Site para recuperar uma página ausente produz mais endereços e não conserta os links já distribuídos. A documentação de Publicação explica a relação entre os arquivos em public/, o sitemap e as rotas.

Registre:

Site ID:
versão anterior:
versão corrigida:
rota afetada:
causa:
ação: restaurar / redirecionar / manter 404
status antes:
status depois:
URL final testada:

Peça ao agente um diagnóstico antes da edição

Diagnostique as rotas 404 deste site sem alterar arquivos.

Fonte: [caminho]
Pasta publicável: [pasta]
URL publicada: [URL]
Período do Analytics: [7, 30 ou 90 dias]

Para cada caminho, informe:
- origem conhecida do acesso;
- se a rota deveria existir;
- arquivo ou regra relacionada;
- página substituta realmente equivalente, se houver;
- status atual e conteúdo entregue;
- ação proposta: restaurar, redirecionar ou manter 404;
- links, sitemap e metadata que precisam de ajuste;
- evidência necessária para decidir.

Não redirecione tudo para a home.
Não crie conteúdo substituto por conta própria.
Não publique. Pare quando faltar decisão editorial.

Depois da aprovação, autorize as correções escolhidas, gere o pacote e repita a matriz de testes na URL pública.

Checklist final

• rota e origem do acesso identificadas;
• existência esperada confirmada;
• substituto avaliado por equivalência;
• redirect usado apenas quando apropriado;
• 404.html presente na raiz do pacote;
• rota ausente devolve status 404 real;
• nenhuma regra curinga mascara erros;
• links internos e sitemap atualizados;
• canonical não aponta para URL removida;
• rotas válidas continuam respondendo 200;
• build e URL publicada testadas;
• navegações 404 acompanhadas no Analytics;
• decisão e versão registradas.

Uma página removida bem tratada não desaparece em silêncio nem empurra todo mundo para a home. Ela preserva o destino quando existe, assume a ausência quando não existe e oferece um próximo passo sem falsificar o status. Essa honestidade técnica torna o site mais fácil de navegar, monitorar e manter — por pessoas e por agentes.