Um site criado por IA pode ter conteúdo convincente e ainda enviar visitantes para uma rota inexistente, um fragmento que não existe ou uma URL antiga. O problema costuma aparecer depois de renomear arquivos, reorganizar seções, trocar domínio ou copiar um CTA de outra versão.

Encontrar links quebrados não é apenas clicar no menu principal. É inventariar destinos, entender como o pacote vira URLs, automatizar o que for verificável e repetir o fluxo crítico na versão publicada.

Este guia mostra como fazer essa revisão sem confundir todo redirect, bloqueio externo ou link dinâmico com um defeito.

Comece pelo mapa de destinos

Antes de testar, liste para onde a página pode levar uma pessoa.

Inclua:

  • navegação principal;
  • CTAs;
  • links no texto;
  • logo que volta ao início;
  • rodapé;
  • políticas e termos;
  • mailto:, tel: e WhatsApp;
  • downloads;
  • links para redes e ferramentas externas;
  • fragmentos como #precos;
  • páginas abertas por cards, menus ou scripts;
  • destinos de formulário e telas de confirmação.

Registre também a intenção. Um endereço responder com sucesso não prova que é o destino certo.

origem: hero
texto do link: "Solicitar orçamento"
destino esperado: formulário de contato desta campanha
comportamento esperado: rolar até #contato
responsável: marketing

Esse inventário separa três perguntas:

  1. o endereço existe?
  2. ele leva ao lugar pretendido?
  3. a pessoa entende o que acontecerá ao ativá-lo?

Entenda como arquivos viram rotas

No Site no Ar, index.html vira a página inicial /. Outros arquivos HTML viram rotas: sobre.html, por exemplo, fica disponível em /sobre. CSS, JavaScript, imagens e fontes preservam o caminho enviado.

Isso cria falhas previsíveis:

Arquivo ou destino esperado Link usado no HTML Risco
sobre.html /sobre correto quando a página está no pacote
contato.html /contato quebra se o arquivo foi renomeado ou omitido
assets/logo.svg /logo.svg aponta para a raiz errada
seção id="planos" #precos fragmento não encontra o elemento
site externo /parceiro.com vira caminho interno em vez de URL externa

A documentação de Publicação descreve o contrato do pacote. Confira esse contrato antes de decidir se a correção pertence ao HTML, ao build ou ao arquivo publicado.

A documentação de links da MDN distingue destinos internos, externos, relativos, relativos à raiz e fragmentos. Cada tipo falha de um jeito.

Um destino como contato.html é resolvido a partir da URL do documento atual. Em uma página mais profunda, ele pode apontar para outro lugar do que apontava na home.

Use links relativos quando a relação entre arquivos for intencional e continuar válida depois do build.

Um destino como /contato começa na raiz do Site. Ele costuma ser mais previsível para navegação interna quando a mesma barra aparece em várias páginas.

Ainda assim, a rota precisa existir. A barra inicial não cria uma página ausente.

URLs externas

Um destino externo precisa incluir a URL completa, normalmente com https://. Verifique também se a campanha exige parâmetros específicos e se eles foram aprovados.

Fragmentos

Um link #planos precisa encontrar um elemento com id="planos" na página. Fragmentos podem quebrar quando o agente reescreve um heading, remove uma seção ou gera IDs diferentes no build.

Esquemas especiais

mailto:, tel: e links de mensageria podem não responder como uma página HTTP. Valide formato, conteúdo e comportamento em um dispositivo compatível, sem tratá-los como uma URL comum.

Inspecione a fonte e a saída do build

Comece em modo somente leitura. Procure por:

  • tags <a> sem href;
  • href="#" usado como ação provisória;
  • javascript: em links;
  • URLs de exemplo;
  • localhost;
  • caminhos absolutos do computador;
  • domínio antigo;
  • fragmentos sem ID correspondente;
  • links gerados em JavaScript;
  • destinos presentes na fonte, mas ausentes na build.

Depois gere a saída atual e repita a inspeção nela. Frameworks podem transformar rotas, adicionar base paths ou remover páginas durante o build. A fonte é intenção; o artefato é o que será publicado.

Não corrija automaticamente todos os links para a mesma convenção. Um download, uma âncora interna e uma navegação entre páginas têm necessidades diferentes.

Automatize a varredura, mas leia o resultado

Um verificador de links pode extrair anchors e destinos, seguir páginas e relatar falhas. O Link Checker do W3C é um exemplo; sua documentação informa que ele também verifica fragmentos e avisa sobre redirects.

Ferramentas desse tipo ajudam a encontrar:

  • respostas 404;
  • fragmentos ausentes;
  • destinos inacessíveis;
  • redirects;
  • anchors duplicados;
  • links repetidos para o mesmo erro.

Mas o relatório precisa de contexto.

Um link externo pode rejeitar robôs, exigir autenticação, limitar requisições ou responder de modo diferente a HEAD e GET. Um redirect pode ser esperado. Um link que responde 200 pode abrir a página errada.

Classifique o resultado:

Resultado automático Próxima verificação
404 interno confirmar rota e arquivo no pacote
fragmento ausente conferir o id na página final
redirect interno decidir se o link deve apontar direto ao destino final
falha externa abrir manualmente e verificar bloqueio ou indisponibilidade
sucesso no destino errado comparar com briefing e intenção do CTA
link acionado por script executar o fluxo no navegador

Evite uma varredura agressiva em sites externos. Limite escopo e concorrência, respeite robots e não transforme QA em carga indevida.

Faça o teste manual do fluxo crítico

Automação encontra endereços. Uma pessoa confirma a jornada.

Percorra pelo menos:

  1. logo até a home;
  2. todos os itens do menu;
  3. CTA primário;
  4. CTA secundário;
  5. formulário e confirmação;
  6. links de prova, termos e privacidade;
  7. rodapé;
  8. navegação de volta;
  9. um fluxo completo em celular.

Observe texto, foco e contexto. “Clique aqui” pode funcionar tecnicamente e ainda ser ambíguo. A MDN recomenda texto de link que descreva o destino e atenção especial quando a ação abre nova aba ou baixa um arquivo.

O guia de acessibilidade em sites criados por IA ajuda a revisar links fora de contexto, foco e navegação por teclado.

Links externos mudam sem que o seu build mude. Antes de publicar:

  • confirme o domínio;
  • remova parâmetros que não deveriam ser compartilhados;
  • verifique se há login obrigatório;
  • sinalize downloads ou mudança inesperada de contexto;
  • decida conscientemente sobre nova aba;
  • não inclua tokens ou dados pessoais na URL;
  • registre destinos comerciais que dependem de campanha.

Não substitua uma URL indisponível por outra “parecida” sem autorização. O endereço pode representar uma decisão jurídica, comercial ou de tracking.

Quando target="_blank" for necessário, aplique as proteções definidas pelo projeto e avise a pessoa de forma adequada. O comportamento de abertura deve servir à experiência, não ser uma regra automática para todo link externo.

Corrija a causa, não apenas o sintoma

Para cada falha, escolha uma ação explícita.

A rota deveria existir

Inclua a página correta no build e no pacote. Depois teste conteúdo, navegação e assets dessa nova rota.

A rota não deveria existir

Atualize o link para o destino aprovado ou remova o controle quando a ação deixou de fazer sentido.

O fragmento mudou

Alinhe href e id. Prefira IDs estáveis e significativos quando outras páginas ou campanhas apontam diretamente para a seção.

O asset não foi publicado

Corrija o caminho ou inclua o arquivo ausente. Confirme maiúsculas e minúsculas, porque diferenças toleradas em um computador podem falhar no ambiente publicado.

O domínio mudou

Atualize fontes controladas, templates e campanhas autorizadas. Um redirect externo pode reduzir o impacto, mas não substitui a correção dos links sob seu controle.

Teste o evento e o fallback. Um card visualmente clicável sem anchor ou botão adequado pode falhar com teclado, scripts bloqueados ou tecnologias assistivas.

Faça uma correção por causa identificada. Trocas amplas por busca e substituição podem alterar URLs válidas, parâmetros ou conteúdo que apenas contém texto semelhante.

Valide novamente no pacote

Depois das correções:

  1. rode os checks do projeto;
  2. gere uma build limpa;
  3. confira as rotas esperadas;
  4. execute novamente a verificação automática;
  5. percorra o fluxo crítico;
  6. registre exceções externas;
  7. aprove o artefato exato.

O checklist de QA para landing pages criadas com IA conecta essa revisão ao conteúdo, formulário, assets, destino e publicação.

Se o Site tiver múltiplas páginas ou assets, mantenha todos sob public/ e preserve os caminhos usados no HTML. Não presuma que um arquivo presente em outra pasta entrou na Version final.

Abra a URL publicada

Build aprovado não encerra o teste. Depois do deploy:

  • abra cada rota interna;
  • acione os CTAs;
  • teste fragmentos;
  • carregue downloads;
  • confirme assets;
  • repita o fluxo em celular;
  • observe redirects;
  • confira se o conteúdo é a versão aprovada.

Uma resposta técnica de deploy concluído prova a operação. A navegação na URL pública prova o resultado.

Quando houver falha, preserve o Site ID e corrija a versão existente com o fluxo de republicação por agente de IA. Criar outro Site para contornar um link quebrado divide tráfego, histórico e referências já distribuídas.

Use respostas 404 como sinal pós-publicação

O Analytics do Site no Ar, disponível no plano Pro, mostra o total de respostas 404 e os caminhos quebrados mais frequentes em janelas de 7, 30 ou 90 dias.

Esse dado ajuda a encontrar problemas que escaparam do QA:

  • campanha divulgando uma rota antiga;
  • erro de digitação recorrente;
  • página removida ainda recebendo acesso;
  • link externo apontando para um caminho inexistente;
  • asset ou rota omitido em uma republicação.

Uma resposta 404 mostra qual caminho falhou. Ela não identifica automaticamente a origem ou a correção certa.

O guia de Analytics para landing pages explica como consultar esses sinais, separar fatos de hipóteses e priorizar a investigação.

Prompt para conduzir a auditoria

Audite os links deste site em modo somente leitura.


Fonte:
- projeto: [caminho]
- comando de build: [comando]
- pasta de saída: [pasta]
- URL publicada, se houver: [URL]


1. Inventarie anchors, CTAs, navegação, rodapé, fragmentos,
   downloads, links externos e destinos acionados por scripts.
2. Compare cada destino com as rotas e assets da build.
3. Verifique links internos e fragmentos automaticamente.
4. Para links externos, limite requisições e diferencie
   indisponibilidade, bloqueio, autenticação e redirect.
5. Percorra manualmente o fluxo crítico no navegador.
6. Classifique por bloqueante, alto, médio ou baixo.
7. Para cada achado, informe origem, texto, destino atual,
   destino esperado, evidência e correção proposta.


Não altere URLs comerciais, jurídicas ou de tracking sem aprovação.
Não publique nem republique nesta etapa.

Depois da aprovação, autorize apenas as correções escolhidas e repita a auditoria.

Relatório que ajuda o handoff

Evite terminar com “links verificados”. Registre:

versão e build:
rotas esperadas:
total de links internos:
total de links externos:
fragmentos verificados:
falhas corrigidas:
redirects aceitos:
exceções externas:
fluxo manual executado:
URL publicada retestada:
pendências e responsáveis:

O relatório permite repetir a revisão depois de mudanças de conteúdo, domínio, estrutura ou campanha.

Critério de saída

Um site está pronto quando toda navegação interna aponta para rotas e fragmentos existentes, CTAs levam ao destino aprovado, links externos críticos foram conferidos, o fluxo principal funciona por mouse, toque e teclado, e a mesma versão foi validada no pacote e na URL pública.

A IA reduz o trabalho de inventário e varredura. A decisão final continua dependendo de intenção: o link certo não é apenas o que abre, mas o que leva a pessoa ao próximo passo prometido.