Voltar ao blog
3 de outubro de 2025Sergei Solod4 min de leitura

O Yandex rastreou meu blog sem /en. Redirects 308 evitaram uma onda de 404

Depois de adicionar cerca de 3.000 páginas /en/blog/... ao sitemap, vi o Yandex tentar os caminhos correspondentes em /blog/.... Redirects 308 que já existiam impediram que essas requisições terminassem em 404. A principal lição não foi que o Yandex “quebrou” meu sitemap, mas o valor de uma camada de redirecionamento bem definida.

SEOYandexSitemapRedirect 308SEO técnicoRastreamento

Publiquei uma atualização do sitemap com cerca de 3.000 novas páginas em /en/blog/.... Pouco depois, apareceu um padrão inesperado no Yandex Webmaster: o Yandex tentava rastrear os caminhos correspondentes em /blog/..., sem o prefixo /en.

Se essas URLs simplesmente retornassem 404, eu poderia acabar com milhares de tentativas de crawl inúteis em caminhos inexistentes. Felizmente, eu já tinha configurado redirects 308 permanentes das rotas sem prefixo de idioma para as URLs inglesas corretas.

Essa pequena camada defensiva de routing acabou sendo muito mais útil do que eu esperava.

O que eu realmente observei

  1. Publiquei um sitemap com cerca de 3.000 novas páginas na estrutura /en/blog/....
  2. Depois, o Yandex Webmaster mostrou o Yandex tentando rastrear URLs correspondentes em /blog/....
  3. Esses caminhos alternativos já estavam cobertos por redirects 308.
  4. Em vez de terminar em 404, as requisições iam para as URLs pretendidas em /en/blog/....

Há uma correção importante em relação à forma como descrevi isso originalmente: eu não posso provar que o Yandex “interpretou o sitemap errado”. Eu observei os caminhos inesperados depois da atualização, mas a sequência temporal, sozinha, não demonstra a causa interna. Mecanismos de busca podem descobrir URLs por diversos sinais e fontes históricas. Sem evidência adicional, a afirmação correta é apenas que o Yandex rastreou caminhos que eu não esperava.

Essa distinção importa. Um crawler pedir uma URL estranha é uma observação. Explicar exatamente por que ele pediu aquela URL é outra afirmação.

Por que os redirects 308 ajudaram

Minha lógica tratava o caminho curto como um alias permanente da URL localizada:

/blog/example-post  -> 308 ->  /en/blog/example-post

Assim, mesmo entrando por uma URL inesperada, o crawler chegava à página que eu realmente queria servir.

308 Permanent Redirect é um redirecionamento HTTP permanente que preserva método e corpo da requisição. Em GETs comuns de crawlers, preservar o método geralmente não é a parte principal; aqui, o valor estava em ser explicitamente permanente. A documentação atual do Yandex Webmaster classifica 301 e 308 como redirects permanentes.

Documentação oficial do Yandex Webmaster sobre redirects.

Isso não significa que 308 seja automaticamente melhor do que 301 para SEO. No meu caso, os 308 já existiam e cumpriram a função necessária: uma URL inesperada não virou um beco sem saída.

Redirect é rede de segurança, não correção do sitemap

Os redirects limitaram o problema, mas não tornaram o crawl extra desejável. Cada redirect desnecessário adiciona uma requisição e um salto. Uma regra ampla demais também pode esconder erros de geração de URL se você deixar de investigar a origem dos endereços errados.

Se o próprio sitemap contém URLs antigas ou URLs que redirecionam, a solução correta é corrigir o sitemap e apontar para as URLs finais. Redirects devem proteger caminhos antigos, alternativos ou descobertos por acidente; não justificar dados de URL malformados.

No meu caso, o sitemap já tinha /en/blog/.... Os redirects apenas tornavam o site mais tolerante quando um crawler chegava por /blog/....

O que eu verificaria hoje

  1. Abrir o sitemap realmente publicado. Não confiar apenas no gerador; conferir o arquivo final e uma amostra de URLs.
  2. Checar as respostas finais. URLs destinadas à indexação deveriam, idealmente, resolver diretamente para a página correta.
  3. Testar caminhos alternativos previsíveis. Se uma URL antiga tem destino permanente, o mapeamento deve ser explícito e um para um.
  4. Evitar cadeias. A -> B -> C é mais difícil de controlar do que A -> C.
  5. Comparar relatórios do crawler com evidência do servidor quando possível. Ferramentas de Webmaster são úteis, mas nem sempre mostram onde uma URL foi descoberta.
  6. Não inferir ranking a partir de crawl. Crawling, indexação, ranking e tráfego são etapas distintas.
curl -I https://example.com/blog/example-post

HTTP/2 308
location: https://example.com/en/blog/example-post

O exemplo é ilustrativo: a ideia é verificar status e destino exatos, em vez de presumir que a regra está funcionando.

O que posso concluir e o que não posso

Posso confirmar que os 308 já configurados impediram que as requisições inesperadas para /blog/... terminassem em 404 e as enviaram para as URLs corretas.

Não posso confirmar que o parser de sitemap do Yandex foi a causa. Também não medi ganho de ranking, melhora de indexação ou uma quantidade específica de tráfego “salvo”. Afirmar isso ultrapassaria a evidência.

A lição que ficou é mais restrita e mais útil: a arquitetura de URLs deve tolerar erros previsíveis nas bordas do sistema. Um sitemap limpo continua sendo a primeira linha de defesa. Uma camada precisa de redirects permanentes é a segunda.

Com as duas, uma rota inesperada do crawler tem muito menos chance de se transformar em milhares de URLs mortas.