Comprei um domínio que havia sido registrado pela primeira vez em 2000. No papel, essa história parecia até uma vantagem. Depois coloquei o novo site no ar e os logs do servidor começaram a encher de requisições para páginas que eu nunca tinha criado.
Mais de 1.000 requisições por dia chegavam a URLs que não existiam no novo projeto. Nos analytics, isso aparecia como um grande pico de direct traffic com quase nenhum engajamento. Ao mesmo tempo, o crawler do Yandex revisitava caminhos antigos, recebia 404 Not Found, e o Yandex Webmaster acumulou mais de 900 erros em uma única noite.
Minha primeira explicação foi simples: bots antigos estavam batendo em URLs mortas, o Yandex via essa atividade e por isso continuava rastreando essas URLs. Era assim que a sequência parecia do meu lado. Mas meus dados não eram suficientes para provar essa relação causal.
O que eu realmente conseguia confirmar
Havia três observações separadas. Primeiro, o servidor recebia um volume grande de requisições para URLs herdadas da vida anterior do domínio. Segundo, esse tráfego praticamente não gerava engajamento real. Terceiro, o crawler do Yandex também solicitava caminhos antigos, e o Webmaster mostrou mais de 900 erros em uma noite.
Operacionalmente, isso era um problema: logs ruidosos, requisições desnecessárias e um relatório de erros para limpar. Mas esses fatos não provam que bots de terceiros fizeram o Yandex rastrear essas URLs nem que os erros prejudicaram diretamente ranking ou tráfego orgânico. Rastreamento não é indexação, indexação não é ranking e um relatório de erros não é prova de penalização.
O que eu tinha simplificado demais sobre 404 e 410
Antes eu pensava assim: 404 quer dizer “talvez esteja faltando só por enquanto”, e 410 quer dizer “sumiu para sempre”. Como intuição, funciona; tecnicamente, não é preciso.
404 Not Found significa que o servidor não consegue fornecer uma representação atual do recurso solicitado; o código por si só não informa se a situação é temporária ou permanente. 410 Gone é mais específico: faz sentido quando o servidor sabe que o recurso não está mais disponível e espera que essa condição seja permanente.
Essa precisão também importa para SEO. Mecanismos de busca podem remover URLs que retornam 404 ou 410. Por isso hoje eu não descrevo 410 como um status magicamente “mais forte para SEO” nem considero 404 errado para toda página removida.
Por que 410 direcionado ainda fazia sentido no meu caso
Os caminhos antigos não eram uma falha temporária. Eles pertenciam ao conteúdo anterior do domínio e não faziam parte do novo projeto. Eu sabia que aquelas URLs específicas tinham desaparecido de forma permanente. Nesse contexto, 410 Gone descrevia corretamente o estado delas.
Então configurei respostas 410 apenas para caminhos legacy conhecidos, em vez de transformar qualquer URL desconhecida em 410. Depois dessa mudança, o ruído de rastreamento e de relatórios em torno desses caminhos diminuiu, e a situação nas ferramentas para webmasters ficou bem mais limpa.
Ainda assim, sou cuidadoso com a causalidade. Posso dizer que a melhora veio depois da mudança e que 410 expressava corretamente o estado das URLs. Não posso provar que o 410, sozinho, fez todos os bots pararem. Um bot de terceiros pode ignorar o significado do status HTTP e continuar requisitando o mesmo caminho indefinidamente.
A regra de decisão que uso hoje
A pergunta útil não é “410 é melhor que 404?”, e sim “o que realmente aconteceu com esta URL?”
- Existe uma substituição clara: use um redirecionamento permanente, como
301, para a nova URL realmente equivalente. - O recurso antigo foi removido de forma permanente e não tem substituto:
410 Goneé uma escolha precisa. - A URL é simplesmente desconhecida, contém erro de digitação ou nunca existiu: um
404 Not Foundnormal é apropriado.
O que eu evitaria é redirecionar toda URL morta para a home só para fazer os erros sumirem. Isso esconde o estado real do recurso e pode piorar a experiência tanto para usuários quanto para crawlers.
Como eu auditaria um domínio antigo antes do lançamento
Se eu reutilizar outro domínio com histórico, vou tratar o passado das URLs como parte da migração mesmo que eu não esteja migrando o site antigo.
- Inspecionar a pegada antiga. Procurar URLs históricas e seções legacy óbvias antes do lançamento.
- Observar os access logs desde o primeiro dia. Requisições repetidas a caminhos que você nunca criou mostram que o domínio ainda tem memória externa.
- Separar humanos, crawlers de busca e bots aleatórios. Um pico de direct traffic e um erro de crawler são sinais diferentes e não devem ser fundidos automaticamente em uma única explicação.
- Classificar URLs mortas recorrentes. Para cada padrão importante, decidir conscientemente entre 301, 404 e 410.
- Monitorar resultados separadamente. Frequência de requisições, relatórios de crawler e indexação são dimensões diferentes; eu não resumiria tudo em uma métrica vaga de “saúde de SEO”.
É pouco trabalho comparado a descobrir o problema quando logs e ferramentas para webmasters já estão cheios de ruído.
O que 410 não resolve
410 é uma declaração HTTP sobre o estado de um recurso. Não é firewall, rate limiter nem mecanismo de bloqueio de bots. Se um scraper continuar enviando requisições depois de receber 410, o servidor ainda terá de recebê-las e responder. Se o problema real for um volume abusivo de requisições, isso é uma questão de infraestrutura separada.
Também não é um impulso de SEO. Retornar o status correto ajuda um crawler a entender o que aconteceu com uma URL; isso, sozinho, não faz o novo site rankear melhor.
A lição que ficou
O mais surpreendente não foi um domínio antigo ter URLs antigas. Foi a rapidez com que aquela história invisível reapareceu depois do lançamento: mais de 1.000 requisições por dia para páginas que eu não tinha, quase nenhum engajamento e mais de 900 erros no Yandex Webmaster em uma noite.
Um domínio antigo não é um namespace vazio. Links, crawlers, scripts e bots podem lembrar caminhos anos depois de o conteúdo original ter desaparecido. Minha regra hoje é simples: auditar esse histórico, devolver o status que corresponde à realidade e manter o tráfego operacional de bots separado das conclusões sobre mecanismos de busca.
História pode ser um ativo. Também é estado que você herda.