Nuestra Ahrefs Domain Rating cayó de 23 a 6. El número era difícil de ignorar. Pero tampoco era una explicación.
Esa distinción orientó la investigación. Una puntuación de un tercero puede decirte que algo cambió en su modelo. No puede decirte qué decisión técnica causó el cambio, ni si el mismo movimiento aparece en el rendimiento de búsqueda. Así que tratamos la caída como un aviso para revisar el sitio, no como un veredicto.
La revisión encontró un problema real en la URL raíz. Para visitantes sin una preferencia de idioma existente, la misma URL podía devolver un redirect temporal a distintas rutas de idioma según la ubicación desde la que se hiciera la solicitud. Ese comportamiento era inconsistente con la estructura permanente de idiomas que queríamos que los motores de búsqueda entendieran.
Lo corregimos. Aun así, no podemos afirmar con honestidad que ese redirect haya causado la caída de la Domain Rating.
Lo que la puntuación realmente nos dice
Ahrefs define Domain Rating como una medida relativa del perfil de backlinks de un sitio en una escala de 0 a 100. El cálculo depende de los sitios que enlazan a un dominio y del índice más amplio de Ahrefs. Por lo tanto, una puntuación puede moverse incluso si un sitio no ha perdido la misma proporción de backlinks.
Ahrefs también afirma que Domain Rating no es un factor de ranking de Google. Es útil para comparar perfiles de backlinks y detectar cambios, pero no es una medición directa de cómo Google clasifica una página.
Eso nos dejó dos hechos separados:
- Observamos que la puntuación bajó de 23 a 6.
- El comportamiento del redirect en la raíz necesitaba corregirse.
Los hechos ocurrieron al mismo tiempo. Su simultaneidad no demuestra que uno causara el otro.
Qué estaba haciendo la URL raíz
El middleware anterior seleccionaba un idioma en función del país de la solicitud cuando no había ya una preferencia de idioma presente. Luego redirigía una ruta no localizada, como la URL raíz, a ese idioma mediante una respuesta 302.
En forma simplificada, el comportamiento relevante se veía así:
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}/` },
})
El código intentaba ser útil. Un visitante en Alemania podía enviarse al idioma alemán, mientras que un visitante en Estados Unidos podía enviarse al inglés.
El problema era el contrato que enfrentaba el crawler. Una sola URL fuente no tenía un destino estable. Su respuesta dependía de la ubicación, y el redirect decía que el cambio era temporal.
Esto importa porque Google trata los redirects permanentes y temporales de forma distinta. Su guía de redirects indica que los redirects permanentes como 301 y 308 son señales fuertes de que el destino debería convertirse en canónico. Con redirects temporales como 302 y 307, la fuente generalmente se mantiene como la URL canónica en los resultados de búsqueda.
Los redirects temporales son válidos cuando el cambio realmente es temporal. Son una mala configuración por defecto cuando el sitio tiene una jerarquía permanente de idiomas y necesita un punto de entrada canónico determinista.
Por qué el enrutamiento dependiente de la ubicación era riesgoso
Imagina dos crawlers que solicitan la misma URL raíz desde ubicaciones distintas. Uno recibe un redirect a /en/. El otro recibe un redirect a /de/. En ambos casos, las respuestas son temporales.
Ninguno de los mensajes de respuesta explica una historia estable sobre el destino preferido de la raíz del sitio. Además, ese comportamiento puede hacer que herramientas externas registren cadenas distintas según dónde y cuándo rastreen.
Esto no destruye automáticamente la autoridad, y un 302 no es una penalización. Los motores de búsqueda pueden interpretar redirects usando más que solo el código de estado. El problema fue que nuestra implementación mezcló tres preocupaciones en una sola respuesta:
- La estructura permanente del sitio
- El idioma probable del visitante
- La preferencia guardada por el visitante
Esas preocupaciones merecen un manejo diferente. La ruta canónica debe ser estable. La personalización debería ocurrir solo cuando hay una preferencia explícita o después de que la página estable se haya cargado.
La corrección determinista
El middleware corregido separa una solicitud nueva de un visitante recurrente con una elección de idioma guardada.
Para una solicitud sin cookies a una ruta no localizada, el servidor ahora devuelve un redirect permanente 301 a la ruta en inglés. El destino es el mismo independientemente del país:
https://zenovay.com/ -> https://zenovay.com/en/
Para un visitante que ya tiene una cookie de preferencia de idioma, el middleware aún puede respetar esa elección personal con un redirect temporal. Esa respuesta es genuinamente específica del usuario, no una afirmación sobre la estructura canónica del sitio.
Este es un cambio pequeño en el código con una propiedad útil: un crawler y un navegador limpio ahora ven un primer salto predecible. Verificamos la respuesta real de la raíz con solicitudes ordinarias, solicitudes de Googlebot y distintos encabezados de idioma. Cada una devolvió un 301 a la misma URL de inglés.
La corrección no requiere eliminar páginas localizadas. Cada idioma sigue teniendo su propia URL. Los selectores de idioma y las preferencias guardadas aún atienden a los visitantes. El cambio solo hace determinista la ruta de entrada por defecto.
Lo que podemos concluir y lo que no
Podemos concluir que el antiguo redirect en la raíz era un fallo técnico. Usaba un estado temporal para una estructura permanente del sitio y permitía que el destino variara según la ubicación de la solicitud. El comportamiento actual es más fácil de razonar para crawlers, herramientas externas de auditoría y personas.
No podemos concluir que ese fallo causó el cambio completo en la puntuación de Ahrefs. No tenemos un experimento controlado que aísle el redirect de los cambios en el índice de Ahrefs, el grafo de backlinks, los dominios de referencia o de otros factores del sitio.
Tampoco podemos afirmar una recuperación antes de que los datos muestren una. Enviar la corrección es el inicio de la observación, no el final de la historia.
El enfoque responsable es registrar la fecha del cambio y observar varias señales por separado:
- Domain Rating y los dominios de referencia detrás de ella
- Backlinks recién descubiertos y backlinks perdidos
- Impresiones y clics desde datos de búsqueda de primera parte
- Indexación y selección canónica para la raíz y las páginas de idioma
- La respuesta del redirect vista desde solicitudes limpias a lo largo del tiempo
Si esas señales mejoran juntas después de la corrección, la evidencia se vuelve más interesante. Aun así, requiere una interpretación cuidadosa.
Auditoría práctica de redirects
No necesitas una gran plataforma SEO para detectar este tipo de problema. Empieza por la propia respuesta HTTP.
- Solicita la URL raíz sin cookies y registra el estado y el encabezado
Location. - Repite la solicitud con distintos encabezados de idioma y, si es posible, desde distintas regiones.
- Confirma que las rutas públicas permanentes tienen un único destino determinista.
- Sigue la cadena y verifica que termina sin saltos extra ni bucles.
- Inspecciona los enlaces canónicos y alternativos de idioma de la página final.
- Prueba a un visitante recurrente con una preferencia explícita de idioma por separado.
- Guarda el resultado y la fecha del despliegue para que los cambios métricos posteriores tengan contexto.
Una comprobación útil desde la línea de comandos es deliberadamente aburrida:
curl -I https://example.com/
Luego varía solo una entrada a la vez. Agrega un encabezado Accept-Language. Usa un contenedor de cookies limpio. Ejecuta la solicitud desde otra región. Si la URL pública está pensada para tener un solo destino canónico, el primer salto no debería convertirse en una lotería geográfica.
La lección más amplia
Las caídas de métricas generan presión para contar una historia rápida. Una historia rápida suele ser el lugar donde una observación técnica se convierte en una afirmación causal sin soporte.
La secuencia mejor es más lenta y más útil:
- Confirma qué mide la métrica.
- Inspecciona el sistema en busca de defectos concretos.
- Corrige defectos porque son defectos.
- Separa el comportamiento verificado de las hipótesis sobre el impacto.
- Observa señales primarias y de terceros después del cambio.
La caída de nuestra Domain Rating nos llevó a un problema real de redirect. Corregir ese problema le dio al sitio una ruta de entrada canónica estable. Si eso explica el movimiento de la puntuación sigue siendo una pregunta abierta, y preferimos dejar esa pregunta abierta antes que fabricar certeza.
Ese es el tipo de registro de depuración en el que confiamos: preciso sobre el código, cuidadoso con la causalidad y claro sobre qué medir después.
