Página con redirección en Search Console: cuándo oculta un problema

"Página con redirección" en Search Console significa que Google solicitó una URL, el servidor la envió a otra dirección y Google tiene en cuenta el destino para su índice en lugar de la URL que usted ve en la lista. La mayoría de las veces es una redirección que hace exactamente lo que usted quería, después de pasar a HTTPS, de decidir entre www y sin www o de cambiar una URL. Se convierte en un problema cuando el destino es incorrecto o no está indexado, o cuando su propio sitemap, sus enlaces y sus etiquetas canónicas siguen enviando a Google a la dirección antigua. Si usa Search Console en inglés, verá este estado como "Page with redirect".

Qué significa el estado según Google

La documentación de Google sobre el informe "Indexación de páginas" (consultada en octubre de 2026) lo describe como "una URL no canónica que redirige a otra página", añade que esta URL "no se indexará" e indica que el destino "puede indexarse o no, según lo que Google opine de esa URL de destino".

De esa redacción se derivan dos consecuencias:

• El estado se refiere a la URL de origen, nunca al destino. Ver http://example.com/pricing en la lista no le dice nada sobre si https://www.example.com/pricing está indexada. El destino se comprueba por separado.
• El tipo de redirección importa. La documentación de Google sobre redirecciones (consultada en octubre de 2026) divide las redirecciones en 2 grupos. Las permanentes (HTTP 301 y 308, un meta refresh o HTTP refresh configurado a 0 segundos y una redirección JavaScript con location) se usan como señal de que el destino debe ser la URL canónica, y el destino es lo que muestran los resultados de búsqueda. Las temporales (302, 303, 307 y un meta refresh o HTTP refresh con retraso) se siguen, pero no se usan como esa señal, así que los resultados de búsqueda muestran la URL de origen. Una redirección JavaScript solo se ve si Google renderiza la página correctamente.

Es un estado distinto de "Error de redirección", que Google usa para las redirecciones que no pudo completar: un bucle, una cadena demasiado larga, una URL de redirección que superó la longitud máxima de URL o una URL incorrecta o vacía en la cadena.

De dónde salen las URLs que redirigen

En un sitio sano, los orígenes normales generan la mayoría de las URLs de esta lista:

1. Normalización del protocolo y del host. De http:// a https://, y del dominio raíz a www o al revés.
2. Normalización de la barra final. De /blog a /blog/, por un valor predeterminado de la plataforma o del servidor.
3. Migraciones y cambios de URL. Un dominio nuevo, un nuevo esquema de rutas, un producto renombrado. WordPress, por ejemplo, envía un 301 desde el slug antiguo de una entrada a su nuevo enlace permanente cuando usted edita el slug.
4. Páginas retiradas que se consolidan en una sucesora. Una guía antigua fusionada con otra más reciente.

Los patrones problemáticos son todos cosas que hace su propio sitio:

1. Su sitemap incluye URLs que redirigen. En 29 sitios web externos cuyas páginas del sitemap SEOReport descargó entre mayo y octubre de 2026, 6 (21%) incluían en su sitemap XML URLs que redirigen a otro lugar.
2. Sus enlaces internos, sus etiquetas canónicas o sus anotaciones hreflang nombran la URL antigua. Las plantillas de navegación, los enlaces antiguos dentro del contenido y las etiquetas canónicas con http:// escrito a mano siguen ofreciendo a Google la dirección que redirige.
3. La redirección va al lugar equivocado. Las recomendaciones de Google sobre la migración de sitios (consultadas en octubre de 2026) advierten que redirigir muchas URLs antiguas a una sola página no relacionada, como la página de inicio, "podría tratarse como un error soft 404".
4. La redirección es una cadena, o es temporal cuando debería ser permanente. Varios saltos hasta llegar al destino, o un 302 que se dejó después de una migración que nunca se va a revertir.

Las redirecciones fueron la más frecuente de las 3 señales contradictorias en esa muestra. Cada una pide a Google que indexe una URL de la que usted ya le ha dicho que no es la verdadera.

¿Es un problema? Dejar, corregir o vigilar

flowchart TD
    A["URL listada como Página con redirección"] --> B{"¿Quería redirigirla?"}
    B -->|no| C["Quite la redirección o restaure la página"]
    B -->|sí| D{"¿Es el destino la sustituta correcta?"}
    D -->|no| E["Redirija al equivalente más cercano, o devuelva 404 o 410"]
    D -->|sí| F{"¿Un solo salto y permanente?"}
    F -->|no| G["Redúzcala a un único 301 o 308"]
    F -->|sí| H{"¿Su sitemap, un enlace o una canónica nombran la URL antigua?"}
    G --> H
    H -->|sí| I["Actualice cada referencia a la URL final"]
    H -->|no| J{"¿Está indexado el destino?"}
    I --> J
    J -->|sí| K["Déjela"]
    J -->|no| L["Revise el estado propio del destino"]

Cómo confirmar cuál es la causa

Empiece por el filtro de sitemap. En la parte superior del informe "Indexación de páginas", cambie el filtro de "Todas las páginas conocidas" a "Todas las páginas enviadas" y vuelva a abrir "Página con redirección". Cualquier URL que siga apareciendo ahí es una URL que redirige y que uno de sus sitemaps envió. La tabla de ejemplos se limita a 1,000 filas, así que en un sitio grande compruebe también el sitemap directamente (más abajo).

Inspeccione algunas URLs. La documentación de Google sobre Inspección de URLs indica que el resultado indexado refleja la URL que usted introdujo, no el destino de su redirección. Dos campos apuntan al origen del problema: "Página de referencia" muestra una página que Google pudo usar para descubrir la URL, y "Sitemaps" muestra los sitemaps que la incluyen. Si la página de referencia está en su propio sitio, tiene un enlace interno que actualizar. Si está en otro sitio, la redirección está cumpliendo su función.

Siga usted mismo los saltos. La misma documentación indica que la prueba en directo ("Probar URL publicada") sigue las redirecciones sin avisar y no muestra la URL final que probó. Una terminal muestra todos los saltos:

curl -sIL http://example.com/old-page | grep -iE '^(HTTP/|location)'

Un 301 o 308 seguido de un 200 es una redirección limpia. Dos o más líneas de redirección forman una cadena, y un 302 o 307 en un traslado permanente debería cambiarse.

Inspeccione el destino por separado. Pegue la URL final en Inspección de URLs. Si no está indexada, el problema está en esa página, y su propio estado le indica dónde mirar: un destino con noindex se trata en «La URL se ha marcado como "noindex"», y uno que Google descargó pero dejó fuera se trata en Rastreada: actualmente sin indexar.

Encuentre qué archivos suyos siguen nombrando la URL antigua

Search Console muestra una muestra de las fuentes de descubrimiento. Sus propios archivos las muestran todas. Compruebe cada URL que incluye su sitemap y muestre las que no responden con un 200:

curl -s https://www.example.com/sitemap.xml \
  | grep -o '<loc>[^<]*</loc>' | sed -e 's/<loc>//' -e 's/<\/loc>//' -e 's/&amp;/\&/g' \
  | while read -r url; do
      code=$(curl -s -o /dev/null -w '%{http_code}' "$url")
      [ "$code" != "200" ] && echo "$code $url"
    done

Un 301, 302, 307 o 308 en la salida es una entrada que redirige. Si el archivo es un índice de sitemaps, ejecute el mismo bucle con cada sitemap secundario que incluya, y descomprima antes cualquier archivo .xml.gz. Después revise las plantillas que comparten todas las páginas, ya que un enlace de la cabecera se repite en cada URL:

curl -s https://www.example.com/ \
  | grep -oE '(href|content)="[^"]+"' \
  | grep -E 'http://|//example\.com'

Sustituya el último patrón por el protocolo, el host o la ruta antiguos que abandonó. En WordPress, las URLs absolutas antiguas suelen estar en el contenido de las entradas, y WP-CLI puede contarlas antes de cambiar nada:

wp search-replace 'http://example.com' 'https://www.example.com' --dry-run

Cuando lo ejecute de verdad, haga antes una copia de seguridad de la base de datos y añada --skip-columns=guid, para que los GUID de las entradas conserven sus valores originales.

Cómo corregir cada causa

Entradas del sitemap. Regenere el sitemap solo con URLs finales: cada entrada debe responder con un 200 y declararse a sí misma como canónica. La documentación de Google sobre sitemaps (consultada en octubre de 2026) pide incluir las URLs que usted quiere ver en los resultados de búsqueda, y una URL que redirige no lo es. La documentación de Google sobre canonicalización añade que cada página incluida en un sitemap se sugiere como canónica. Nuestra guía de sitemaps XML explica el resto de un sitemap limpio.

Enlaces internos, etiquetas canónicas y hreflang. Actualícelos a la URL de destino. La documentación de Google sobre canonicalización (consultada en octubre de 2026) aconseja enlazar a la URL canónica y no a un duplicado, y una etiqueta canónica que nombra una URL que redirige pide a Google que consolide las señales en una dirección que no contiene la página. La guía de etiquetas canónicas explica cómo se combinan esas señales, y Duplicada: el usuario no ha indicado ninguna versión canónica trata el caso en que las variantes de host y protocolo no se redirigen en absoluto.

Destino incorrecto. Apunte cada URL antigua a su equivalente más cercano. Cuando una página no tiene sucesora, un 404 o un 410 es la respuesta honesta, y evita el tratamiento como soft 404 que Google describe para las redirecciones a páginas no relacionadas.

Cadenas y redirecciones temporales. Escriba una sola regla que lleve directamente de la URL de entrada a la URL final, como 301 o 308. Cadenas de redirecciones: cómo se forman y cómo aplanarlas desarrolla un ejemplo de 4 saltos, y la guía de redirecciones y normalización de URLs trata a la vez las reglas de protocolo, host y barra final.

Mantenga las redirecciones. Las recomendaciones de Google sobre la migración de sitios indican que hay que mantener las redirecciones el mayor tiempo posible, en general al menos 1 año. Los enlaces externos y los marcadores siguen llegando a las URLs antiguas mucho después de que sus propias referencias estén limpias.

Cómo validar la corrección

1. Vuelva a ejecutar el bucle del sitemap. No debería mostrar nada.
2. Vuelva a seguir los saltos en una muestra de URLs antiguas: un solo salto permanente y después un 200, en la página correcta.
3. Vuelva a enviar el sitemap en el informe "Sitemaps" de Search Console para pedir a Google que lo lea de nuevo.
4. Observe el filtro "Todas las páginas enviadas". Las URLs que redirigen deberían salir de él cuando Google vuelva a leer su sitemap y a rastrearlas. La documentación de Google sobre cómo solicitar un nuevo rastreo indica que el rastreo puede tardar desde unos días hasta unas semanas, según el calendario de Google y no el suyo.
5. Use "Validar corrección" solo para las redirecciones que eliminó. La validación vuelve a rastrear las URLs afectadas para comprobar si cada una sigue teniendo el problema, y una redirección intencionada sigue redirigiendo por diseño. La documentación de Google indica que la validación suele tardar hasta unas 2 semanas y, en algunos casos, mucho más.

Search Console le dice qué URLs redirigen. Un diagnóstico completo de SEOReport audita el propio sitio y nombra las redirecciones que no debería anunciar: URLs que redirigen entre las páginas que incluye su sitemap, cada una con su destino, un destino canónico de la página de inicio o destinos de idioma alternativo que redirigen, y cada salto cuando la dirección que usted envía requiere más de uno. No comprueba si los enlaces internos redirigen, así que para ellos ejecute la revisión de plantillas descrita arriba.

Preguntas frecuentes

¿Saldrán algún día del informe las URLs que redirigen?

Pueden quedarse mucho tiempo en la vista "Todas las páginas conocidas", porque Google sigue rastreando las URLs que ya conoce, incluidas las URLs a las que enlazan otros sitios. Es el estado final correcto cuando la redirección es intencionada y el destino está indexado. Lo que debería reducirse es el número de esas URLs que envía su propio sitemap.

Mi página de inicio aparece como Página con redirección. ¿Es malo?

Normalmente la URL listada es una variante como http://example.com/, que redirige a su versión preferida https://www.example.com/. Inspeccione la URL preferida de la página de inicio: si está indexada, la variante se comporta correctamente. Si la propia URL preferida aparece en la lista, su página de inicio redirige a un lugar que usted no pretendía, y eso hay que corregirlo.

¿Debo usar una etiqueta canónica en lugar de una redirección?

Use una redirección cuando la URL antigua ya no deba mostrar su propia página a nadie. Use una etiqueta canónica cuando ambas URLs tengan que seguir funcionando, por ejemplo una vista filtrada de la misma lista de productos. Una URL que sigue activa con una canónica que apunta a otra página suele aparecer como "Página alternativa con etiqueta canónica adecuada" cuando Google acepta esa canónica, y no requiere ninguna acción.