Nossa Domain Rating da Ahrefs caiu de 23 para 6. O número era difícil de ignorar. Mas também não era uma explicação.
Essa distinção norteou a investigação. Uma pontuação de um terceiro pode te dizer que algo mudou no modelo. Mas não consegue dizer qual decisão técnica causou a mudança, nem se o mesmo movimento aparece no desempenho de busca. Então tratamos a queda como um pedido para inspecionar o site , e não como um veredicto.
A inspeção encontrou um problema real na raiz da URL. Para visitantes sem uma preferência de idioma existente, a mesma URL podia retornar um redirecionamento temporário para diferentes caminhos de locale, dependendo da localização da requisição. Esse comportamento era inconsistente com a estrutura permanente de locale que queríamos que os mecanismos de busca entendessem.
Nós corrigimos isso. Ainda assim, não podemos dizer honestamente que esse redirecionamento causou a queda da Domain Rating.
O que a pontuação realmente nos diz
A Ahrefs define Domain Rating como uma medida relativa do perfil de backlinks de um site em uma escala de 0 a 100. O cálculo depende dos sites que linkam para um domínio e também do índice mais amplo da Ahrefs. Por isso, uma pontuação pode mudar mesmo quando um site não perdeu a mesma proporção de backlinks.
A Ahrefs também afirma que Domain Rating não é um fator de ranqueamento do Google. Ela é útil para comparar perfis de backlinks e perceber mudanças, mas não é uma medição direta de como o Google ranqueia uma página.
Isso nos deixou com dois fatos separados:
- Observamos a queda da pontuação de 23 para 6.
- O comportamento do redirecionamento na nossa URL raiz precisava ser corrigido.
Os fatos existiam ao mesmo tempo. O timing deles não comprova que um causou o outro.
O que a URL raiz estava fazendo
O middleware antigo selecionava um locale com base no país da requisição quando ainda não havia uma preferência de locale presente. Depois, redirecionava um caminho não localizado , como a URL raiz , para aquele locale com uma resposta 302.
Em forma simplificada, o comportamento relevante parecia assim:
const country = request.cf?.country
|| request.headers.get('CF-IPCountry')
|| 'US'
const targetLocale = LOCALE_MAP[country] || 'en'
return new Response(null, {
status: 302,
headers: { Location: `/${targetLocale}/` },
})
O código tentava ser útil. Um visitante na Alemanha poderia ser enviado para o locale alemão, enquanto um visitante nos Estados Unidos poderia ser enviado para o inglês.
O problema era a visão do crawler por trás do contrato. Uma única URL de origem não tinha um destino estável. A resposta dependia da localização, e o redirecionamento dizia que a mudança era temporária.
Isso importa porque o Google trata redirecionamentos permanentes e temporários de forma diferente. A orientação de redirecionamentos dele diz que redirecionamentos permanentes como 301 e 308 são sinais fortes de que o destino deve se tornar canônico. Com redirecionamentos temporários como 302 e 307, a origem geralmente permanece como URL canônica nos resultados de busca.
Redirecionamentos temporários são válidos quando a mudança realmente é temporária. Eles são o padrão errado quando o site tem uma hierarquia permanente de locales e precisa de um ponto de entrada canônico determinístico.
Por que o roteamento dependente de localização era arriscado
Imagine dois crawlers solicitando a mesma URL raiz, mas a partir de locais diferentes. Um recebe um redirecionamento para /en/. O outro recebe um redirecionamento para /de/. Ambas as respostas são temporárias.
Nada em qualquer uma das respostas conta uma história estável sobre qual é o destino canônico preferido para a raiz do site. Esse comportamento também pode fazer ferramentas externas registrarem cadeias diferentes dependendo de onde e quando fazem o crawl.
Isso não destrói automaticamente a autoridade, e um 302 não é uma penalidade. Mecanismos de busca podem interpretar redirecionamentos usando mais do que o status code sozinho. O problema foi que a nossa implementação misturou três preocupações em uma única resposta:
- A estrutura permanente do site
- O provável idioma do visitante
- A preferência salva do visitante
Essas preocupações merecem tratamentos diferentes. A rota canônica deve ser estável. A personalização só deve acontecer quando houver uma preferência explícita ou depois de a página estável ter carregado.
A correção determinística
O middleware corrigido separa uma nova requisição de um visitante que está retornando com uma escolha de locale salva.
Para uma requisição sem cookies para um caminho não localizado, o servidor agora retorna um redirecionamento permanente 301 para o caminho em inglês. O destino é o mesmo independentemente do país:
https://zenovay.com/ -> https://zenovay.com/en/
Para um visitante que já tem um cookie de preferência de locale, o middleware ainda pode respeitar essa escolha pessoal com um redirecionamento temporário. Isso é uma resposta genuinamente específica do usuário, e não uma alegação sobre a estrutura canônica do site.
Esta é uma pequena mudança de código com uma propriedade útil: um crawler e um navegador limpo agora veem um primeiro salto previsível. Validamos a resposta da raiz ao vivo com requisições comuns, requisições do Googlebot e headers de idioma diferentes. Cada uma retornou um 301 para a mesma URL em inglês.
A correção não exige remover páginas localizadas. Cada locale ainda tem sua própria URL. Seletores de idioma e preferências salvas continuam servindo os visitantes. A mudança apenas torna o caminho de entrada padrão determinístico.
O que podemos concluir , e o que não podemos
Podemos concluir que o redirecionamento antigo na raiz era um defeito técnico. Ele usava um status temporário para uma estrutura permanente do site e permitia que o destino variasse conforme a localização da requisição. O comportamento atual é mais fácil para crawlers, ferramentas externas de auditoria e humanos entenderem.
Não podemos concluir que esse defeito causou a mudança completa na pontuação da Ahrefs. Não temos um experimento controlado que isole o redirecionamento das mudanças no índice da Ahrefs, no grafo de backlinks, nos domínios de referência ou em outros fatores do site.
Também não podemos alegar uma recuperação antes dos dados mostrarem uma. Publicar a correção é o começo da observação, não o fim da história.
A abordagem responsável é registrar a data da mudança e observar vários sinais separadamente:
- Domain Rating e os domínios de referência por trás dela
- Backlinks recém-descobertos e perdidos
- Impressões e cliques de dados de busca da primeira parte
- Indexação e seleção canônica para as páginas de raiz e de locale
- A resposta de redirecionamento vista por requisições limpas ao longo do tempo
Se esses sinais melhorarem juntos após a correção, a evidência fica mais interessante. Ainda assim, exige uma interpretação cuidadosa.
Uma auditoria prática de redirecionamentos
Você não precisa de uma grande plataforma de SEO para detectar esse tipo de problema. Comece pelo próprio HTTP response.
- Requira a URL raiz sem cookies e registre o status e o header
Location. - Repita a requisição com headers de idioma diferentes e, se possível, a partir de regiões diferentes.
- Confirme que rotas públicas permanentes têm um destino determinístico.
- Siga a cadeia e verifique se ela termina sem hops extras ou loops.
- Inspecione os links canônicos e de idiomas alternativos da página final.
- Teste um visitante retornando com uma preferência explícita de locale separadamente.
- Salve o resultado e a data do deploy para que mudanças futuras de métricas tenham contexto.
Um check útil na linha de comando é deliberadamente “chato”:
curl -I https://example.com/
Depois, varie apenas uma entrada por vez. Adicione um header Accept-Language. Use um cookie jar limpo. Execute a requisição a partir de outra região. Se a URL pública deve ter um único destino canônico, o primeiro salto não deve virar um “sorteio” geográfico.
A lição mais ampla
Quedas de métricas geram pressão por uma história rápida. Uma história rápida é frequentemente onde uma observação técnica vira uma alegação causal sem suporte.
A sequência melhor é mais lenta e mais útil:
- Confirme o que a métrica mede.
- Inspecione o sistema em busca de defeitos concretos.
- Corrija defeitos porque eles são defeitos.
- Separe comportamento verificado de hipóteses sobre impacto.
- Observe sinais primários e de terceiros após a mudança.
A queda da nossa Domain Rating nos levou a um problema real de redirecionamento. Corrigir esse problema deu ao site um caminho de entrada canônico estável. Se isso explica a movimentação do score, continua sendo uma pergunta em aberto , e preferimos manter essa pergunta aberta a fabricar certeza.
Esse é o tipo de registro de depuração em que confiamos: exato quanto ao código, cuidadoso quanto à causalidade e claro sobre o que medir em seguida.
