Página con redirección en Search Console: normal o problema

Si abres el informe de páginas de Search Console y ves decenas o cientos de URLs bajo los estados "página con redirección" y "página alternativa con etiqueta canónica adecuada", la primera reacción suele ser de alarma. No debería serlo casi nunca: ambos estados aparecen entre los motivos de páginas no indexadas, no son errores, y en la inmensa mayoría de los sitios describen exactamente lo que el propietario quiso que pasara. El problema no es que existan, sino que amontonan bajo la misma etiqueta URLs muy distintas entre sí, y dentro de ese montón sí hay un subconjunto que merece revisión.

Esta guía separa los dos casos: qué hace que estos dos estados sean ruido inofensivo, y qué patrones concretos, dentro de las mismas dos etiquetas, apuntan a un sitemap mal generado, a enlaces internos que apuntan a URLs muertas o a un canonical mal configurado.

Qué significa realmente "página con redirección"

Este estado aparece cuando Googlebot solicita una URL y el servidor responde con una redirección, normalmente un 301 o un 302, hacia otra dirección. Google no indexa la URL de origen porque, por definición, no hay contenido que indexar en ella: solo hay una instrucción de ve a mirar aquí. La URL de destino es la que entra a rastreo e indexación de forma independiente, con su propio estado dentro del mismo informe.

Es fácil confundir este informe con uno que explica tipos de redirección, y no lo es. Aquí no importa si el salto es 301 o 302, si pasa por una cadena de varios saltos o si va directo; lo único que registra el informe de páginas es el hecho de que, al pedir esa URL, la respuesta fue una redirección y no un documento con código 200. Para entender diferencias entre tipos de redirección hace falta otra pieza del sitio, no este informe: aquí el dato relevante es únicamente el conteo y la lista de URLs afectadas, no el mecanismo que las mueve.

Cuándo este estado es exactamente lo que debería pasar

En la mayoría de los sitios, este estado es una consecuencia sana de decisiones ya tomadas, no un fallo que arreglar. Las situaciones más comunes:

• Una migración de HTTP a HTTPS, o de un dominio a otro, en la que las URLs antiguas siguen redirigiendo por diseño.
• Un cambio de estructura de URLs, por ejemplo quitar una fecha o una categoría del slug, donde las rutas viejas redirigen a las nuevas.
• Páginas con y sin barra final, con y sin www, o con parámetros de sesión que redirigen a su versión limpia.
• Productos descatalogados o contenido fusionado que redirige a la página que lo sustituye.

Las tres señales de que sí hay un problema debajo

En todos estos casos, Google está haciendo justo lo que se espera de él: reconoce que la URL antigua ya no tiene contenido propio y consolida las señales en el destino, sin que haga falta ninguna acción sobre esas filas del informe más allá de comprobar de vez en cuando que el destino sí está indexado. El estado deja de ser inofensivo, en cambio, cuando la redirección no era la intención, o cuando algo en el sitio sigue tratando esa URL vieja como si fuera la buena. Hay tres patrones que conviene revisar con el informe abierto y el sitemap al lado.

El sitemap sigue listando URLs redirigidas. Un sitemap.xml que se regenera a mano, o que depende de una caché que no se invalidó tras la migración, puede seguir enviando a Google la URL vieja como si fuera contenido activo. Google la rastrea, ve el 301 y la marca como página con redirección, hasta aquí normal, pero además puede restar fiabilidad a ese sitemap como fuente, porque le está pidiendo que trate como contenido algo que ya no lo es. Si el número de páginas en este estado sube justo después de publicar un sitemap nuevo, la causa casi siempre es esta: exporta el sitemap, cruza sus URLs con la lista de páginas con redirección y elimina del sitemap las que coincidan.

Enlaces internos que siguen apuntando a la URL antigua. Actualizar el destino de una redirección no arregla el origen del enlace. Si la navegación, el pie de página, un widget de contenido relacionado o una plantilla de categoría enlazan todavía a la ruta vieja, cada rastreo vuelve a gastar presupuesto pasando por el salto en lugar de llegar directo, y en sitios grandes eso se traduce en menos rastreo disponible para páginas nuevas. La forma de detectarlo no es este informe, que solo dice que esa URL redirige, sino un rastreo propio del sitio con cualquier crawler, buscando enlaces internos cuyo destino sea una URL que también aparece en la lista de excluidas por redirección.

Cadenas o bucles de redirección. Cuando A redirige a B y B redirige a C, Google sigue la cadena, pero cada salto adicional cuesta tiempo de rastreo y, pasado cierto número de saltos, puede simplemente abandonar antes de llegar al destino final, dejando la URL de origen atascada en este estado sin que la de destino llegue nunca a indexarse. Un bucle, A hacia B y B de vuelta hacia A, es el caso extremo: ninguna de las dos URLs se indexa jamás. La señal de alarma es una URL que lleva varios rastreos seguidos marcada como página con redirección sin que su destino aparezca nunca como indexado dentro del mismo informe.

Qué significa "página alternativa con etiqueta canónica adecuada"

Este segundo estado no tiene que ver con redirecciones HTTP, sino con la etiqueta canonical que vive dentro del HTML. Aparece cuando una página incluye un canonical que apunta a otra URL, y Google, tras rastrearla, está de acuerdo con esa elección: considera que la URL etiquetada es una variante y que la que señala el canonical es la versión que merece indexarse. La palabra clave es adecuada: el propio informe te está diciendo que no hay conflicto entre lo que pediste y lo que Google decidió.

Es, en ese sentido, el estado más tranquilizador de todo el informe: significa que tu etiquetado y el criterio de Google coinciden. Aparece con mucha frecuencia en variantes de una misma página generadas por parámetros de campaña, por filtros de una tienda, por versiones para impresión, o por una paginación mal gestionada donde cada página numerada canonicaliza hacia la página uno. También es habitual entre http y https, o entre la versión con y sin www, cuando el canonical, y no una redirección, es el mecanismo elegido para señalar la preferencia.

Cuándo la misma etiqueta te avisa de un error

El problema aparece cuando la URL excluida por canonical adecuado es una página que sí querías indexada de forma independiente, y el canonical que la excluye está mal puesto, no por Google, sino por tu propio código o tu gestor de contenidos. Tres orígenes cubren la mayoría de los casos:

• Una plantilla que copia el canonical de otra página. Sucede a menudo tras clonar una plantilla de producto o de artículo: el desarrollador cambia el contenido visible pero olvida que la etiqueta canonical seguía apuntando a la página original de la que se copió.
• Conflicto entre canonical y hreflang. Si una página en español lleva un canonical que apunta a su versión en inglés, le estás diciendo a Google dos cosas contradictorias a la vez: esta es la versión para el idioma español, dice el hreflang, pero la versión que cuenta es la inglesa, dice el canonical. Google casi siempre prioriza el canonical, y la página en español queda excluida aunque tuviera que posicionar por sí sola en su propio mercado.
• Paginación que canonicaliza siempre hacia la página uno cuando en realidad cada página de la serie tiene contenido único, por ejemplo listados de producto con resultados distintos en cada página, y debería autocanonicalizarse en lugar de apuntar todo hacia la primera.

Cómo revisarlo en la práctica sin perder un día entero

La forma de distinguir un canonical correcto de uno erróneo es preguntarte, para cada URL de la lista, si el contenido de esa página es realmente una variante de la de destino o si tiene entidad propia; si tiene entidad propia y aun así aparece excluida, el canonical está mal puesto en el HTML, no es una decisión de Google que haya que aceptar sin más. No hace falta, eso sí, auditar fila por fila un informe con miles de URLs. Un proceso razonable, repetible cada vez que cambias de plantilla:

• Exporta la lista completa de URLs bajo ambos estados desde el informe de páginas; el botón de exportar entrega un CSV o una hoja de cálculo.
• Cruza esa lista con tu sitemap.xml actual: cualquier coincidencia es una URL que el sitemap no debería estar anunciando como contenido vivo.
• Cruza esa misma lista con un rastreo propio del sitio y filtra los enlaces internos cuyo destino coincida con alguna URL de la lista: son enlaces que conviene actualizar hacia el destino final en lugar de dejar que pasen por el salto.
• Para un muestreo de URLs bajo canonical adecuado, abre cada una en la Inspección de URL y compara, en la sección de indexación, el canonical declarado por el usuario con el elegido por Google; si coinciden y el destino es realmente el correcto, no hay nada que hacer.
• Repite la comprobación después de cada cambio de plantilla o de cada migración, no solo una vez: estas dos categorías son las que más rápido reflejan un error de plantilla, porque afectan a URLs por lotes y no de una en una.

Errores frecuentes al interpretar estos dos estados

El objetivo no es vaciar estas dos categorías del informe, eso no va a pasar en un sitio con historia y no debería pasar, sino asegurarte de que cada URL que aparece ahí está ahí por una razón que reconoces, y no por un accidente de sitemap o de plantilla. Dicho esto, hay tres formas habituales de leer mal este informe:

• Tratar no indexada como sinónimo de error. El informe de páginas de Search Console agrupa estos estados como motivos de no indexación precisamente porque muchas exclusiones son intencionadas; entrar en pánico por un número alto en estas dos filas sin mirar qué URLs contienen es la causa más común de tiempo perdido en este informe.
• Comparar el número de URLs en este estado con semanas anteriores sin tener en cuenta que acabas de lanzar una migración o una campaña con parámetros de seguimiento: un pico aislado justo después de un cambio conocido no es una anomalía, es la consecuencia esperada de ese cambio.
• Dar por bueno un canonical solo porque el estado dice adecuado. Ese calificativo describe que Google está de acuerdo con tu etiqueta, no que tu etiqueta sea la decisión correcta desde el punto de vista de negocio. Si pusiste el canonical equivocado y Google lo respeta, el informe seguirá diciendo adecuado aunque estés perdiendo visibilidad de una página que sí querías posicionar por su cuenta.

La lectura correcta de ambos estados exige mirar la lista de URLs, no solo el número agregado, y contrastarla con lo que tu sitio pretendía comunicar con esa redirección o con ese canonical.