Dimensión de Core/Dash: Conteo de redirecciones

Mide cuántas redirecciones HTTP encuentran los usuarios antes de llegar a tu página y su coste directo en el TTFB.

Prueba gratuita

Trusted by market leaders · Client results

ebayvpnkpnnina careworkivacomparealeteiamonarchadevintanestleperionloopearplugsmarktplaatsdpg mediasnverasmusmchappyhorizonharvardsaturnwhowhatwearmy work featured on web.devfotocasa

Dimensión: Navegación: Conteo de redirecciones (redir)

La dimensión redir cuenta las redirecciones HTTP antes de llegar a la página final. Los valores son 0, 1, 2 o 3+. Cada redirección es un viaje de ida y vuelta completo en la red que ocurre antes de que tu servidor siquiera comience a generar el HTML.

En una conexión con un RTT de 100ms, una redirección añade 100ms al TTFB. En una conexión móvil de 200ms, eso se duplica. Dos redirecciones en móvil: 400ms de pura espera antes de que el navegador reciba un solo byte de tu página. Esta latencia es invisible en las pruebas de laboratorio que acceden directamente a la URL final, pero los usuarios reales que siguen enlaces, marcadores o resultados de búsqueda la absorben en cada visita.

coredash redirect count

Los valores

0 redirecciones

El estado ideal. El navegador accedió a la URL final en la primera solicitud. Toda navegación interna debería producir este valor. Si los enlaces de tu propio sitio, sitemaps y etiquetas canónicas son correctos, el tráfico interno se mantiene en 0.

1 redirección

Común en tráfico externo: actualizaciones de HTTP a HTTPS, normalización de www o URL de campañas de marketing. Aceptable para enlaces entrantes que no controlas. Inaceptable para tus propios enlaces internos. Si CoreDash muestra 1 redirección en navegaciones internas, tus enlaces apuntan a URL antiguas o inconsistentes.

2+ redirecciones

Cadenas de redirección. Una URL acortada redirige a un dominio de rastreo, que redirige a tu endpoint HTTP, el cual redirige a HTTPS. Tres saltos, tres viajes de ida y vuelta. Agrupa por URL para encontrar qué puntos de entrada crean estas cadenas y, luego, elimina a los intermediarios.

De dónde provienen las redirecciones

  • HTTP a HTTPS: Enlaces internos obsoletos que todavía apuntan a http://. Actualiza todos los enlaces, sitemaps y etiquetas canónicas para usar https:// directamente.
  • Normalización de www: Inconsistencia entre usar www y no usar www. Aplica una de forma obligatoria a nivel de DNS y actualiza todas las referencias.
  • Cambios de slug en el CMS: Rutas antiguas que redirigen a rutas nuevas a través de 301. Está bien para backlinks externos, pero actualiza cada enlace interno para que apunte directamente al nuevo slug.
  • URL personalizadas (vanity) de marketing: Rutas personalizadas como /spring-sale que redirigen a /products/seasonal. Cada visitante paga el coste de latencia en cada clic.
  • Acortadores de URL en correos electrónicos y redes sociales: Enlaces que pasan por Bitly, píxeles de rastreo o proveedores de servicios de correo electrónico antes de llegar a tu dominio. Cada servicio añade un viaje de ida y vuelta que no puedes controlar, pero puedes minimizar tus propias redirecciones para que el total se mantenga bajo.

Flujo de trabajo de depuración

  1. Filtra por redir ≥ 1: Observa qué porcentaje de tu tráfico total se topa con al menos una redirección. Cualquier cifra por encima del 15% merece ser investigada.
  2. Agrupa por URL: Encuentra qué páginas de destino son las peores infractoras. Las páginas de marketing y las publicaciones antiguas de blog con slugs cambiados suelen dominar.
  3. Divide entre interno y externo: Filtra por origen de navegación (navigation origin). El tráfico del mismo origen con redirecciones significa que tus propios enlaces están mal. Las redirecciones de origen cruzado son más difíciles de arreglar, pero menos urgentes.
  4. Arregla el origen, no la redirección: No optimices la redirección en sí misma (respuesta más rápida del servidor). Elimínala actualizando el enlace que la causó.

Reglas generales de ingeniería

  • 0 redirecciones en toda la navegación interna. Ninguna redirección desde tu propio sitio es aceptable cuando controlas el enlace de origen.
  • Audita después de cada migración de URL. Cuando cambies slugs o muevas páginas, busca en tu código (grep) y en tu CMS las rutas antiguas. Las redirecciones son una red de seguridad para los enlaces externos, no un sustituto para actualizar tus propias referencias.
  • Presupuesta 150ms por redirección en móvil. Si tu objetivo de TTFB es 800ms y los usuarios se topan con dos redirecciones, ya has gastado 300ms antes de que tu servidor haga algún trabajo.

Las redirecciones son la mejora de TTFB más fácil de encontrar y arreglar. Sin cambios de código, sin ajustes de servidor, sin optimización de recursos. Simplemente actualiza la URL que apunta al lugar equivocado.