8 errores de redireccionamiento en un rediseño web y cómo evitarlos

Por qué un rediseño rompe el SEO aunque el sitio quede mejor

Un rediseño casi nunca cambia solo la apariencia. Cambia el menú, la jerarquía de categorías, el CMS y, con ellos, las URLs. Cuando /productos/hombre/ pasa a ser /productos/ropa/hombre/, Google no se entera por intuición: la dirección que tenía indexada, que acumulaba enlaces y que la gente guardó en favoritos deja de existir. Si nadie le dice a dónde se movió, devuelve un 404 y todo lo que esa URL había ganado se pierde.

Una redirección es la instrucción del servidor que dice «este contenido ahora vive en esta otra dirección». En los rediseños en los que he trabajado, el problema rara vez es no saber qué es una 301. El problema es que el plan de redirecciones se deja para el final, se arma con prisa la semana del lanzamiento y nadie lo verifica después.

Tipos de redirección y cuándo usar cada una

Google agrupa las redirecciones en dos familias, y la diferencia práctica es qué URL termina mostrando en los resultados.

La 308 equivale a la 301 y la 307 equivale a la 302; la diferencia entre ellas es técnica (conservan el método HTTP de la petición), no de SEO. La regla que doy a los equipos de desarrollo es simple: si el cambio no se va a revertir, va una 301 o una 308 hecha en el servidor. Las redirecciones por JavaScript tienen además un riesgo que en 2026 se volvió explícito: el mismo tipo de código que mueve al usuario de una URL a otra puede terminar manipulando su historial, y eso ya es una infracción de las políticas de spam de Google (lo explico más abajo).

Los 8 errores de redireccionamiento que más veo en rediseños y migraciones

1. Lanzar sin plan de redirecciones

Es el error más caro. Las URLs antiguas responden 404, los enlaces externos que apuntaban a ellas quedan rotos y las páginas nuevas arrancan de cero, sin el historial que tenían las anteriores. Además, Google necesita rastrear cada URL vieja y cada URL nueva al menos una vez para dar el cambio por completado, y en un sitio mediano eso puede tardar unas semanas o más.

El plan se arma antes del lanzamiento: un inventario de todas las URLs antiguas (sitemaps, exportaciones del CMS, analítica, registros del servidor y Search Console), cada una con su destino nuevo. No olvides imágenes, PDF y otros archivos que tengan tráfico o enlaces.

2. Mandar todo a la página de inicio

Cuando el mapeo se vuelve tedioso, aparece la tentación de redirigir cientos de URLs a la home. Google lo dice explícitamente: enviar muchas URLs antiguas a una sola página sin relación puede tratarse como un soft 404. Para el usuario es igual de malo: buscaba un producto concreto y aterriza en una portada genérica.

Si un contenido se consolidó en otro, redirigir varias URLs a esa página única es correcto. Si el contenido desapareció y no tiene equivalente, es más honesto devolver un 404 o un 410 que fingir un reemplazo.

3. Redirigir a una URL que no existe

Pasa más de lo que parece: la regla apunta /mujer/vestidos-de-bano/ a /vestido, que nunca se creó o cambió de nombre durante el desarrollo. El resultado es una redirección que termina en 404. Todo destino del mapa tiene que responder 200 en el sitio nuevo, y hay que comprobarlo con un rastreo, no a ojo.

4. Bucles de redirección

Un bucle ocurre cuando A redirige a B y B redirige de vuelta a A. El caso típico es con las variantes del dominio: alguien crea una regla de www.ejemplo.com hacia ejemplo.com sin saber que ya existía otra en sentido contrario, por ejemplo en el CDN o en un plugin. El navegador termina mostrando un error de demasiadas redirecciones, y en el informe de indexación de páginas de Search Console la URL aparece como «Error de redirección», que incluye precisamente los bucles.

Este es el error que más encuentro en entornos de desarrollo, porque las reglas viven en varias capas a la vez: el servidor, el CDN, el CMS y algún plugin. Antes del lanzamiento conviene listar dónde hay reglas y dejar una sola fuente para cada tipo.

5. Cadenas de redirecciones

Una cadena se forma con el tiempo: eliminas la página A y la mandas a B; meses después eliminas B y la mandas a C; luego C a D. Quien entra por A pasa por tres saltos antes de llegar. Cada salto agrega tiempo de carga y, por defecto, los rastreadores de Google siguen hasta 10 saltos. Si la cadena es demasiado larga, Search Console también la reporta como error de redirección.

La recomendación de Google para migraciones es redirigir directo al destino final y, si no se puede, mantener la cadena corta: idealmente no más de 3 saltos y menos de 5. En la práctica, cada vez que agregues una regla nueva, revisa si hay reglas viejas que apuntan a la URL que acabas de mover y actualízalas para que A, B y C vayan directo a D.

6. Redirecciones sin relación semántica

La redirección funciona técnicamente, pero lleva a un contenido que no responde a la misma intención. Ejemplo: retiras un cinturón de cuero café de la categoría de hombre y lo rediriges a un cinturón café y blanco de la categoría de mujer porque comparten palabras. Para el usuario es frustrante, y para Google es la misma situación del error 2: un destino que no sustituye al original.

El criterio que uso es preguntarme si una persona que buscaba la página vieja quedaría satisfecha con la nueva. Si la respuesta es no, el destino correcto es la categoría padre más cercana o un 404/410 bien hecho, no el producto que más se parece en el nombre.

7. No resolver la versión canónica del dominio

Para un buscador, http://ejemplo.com, http://www.ejemplo.com, https://www.ejemplo.com y https://ejemplo.com son URLs distintas. Si las cuatro responden con contenido, las señales se reparten entre ellas. La solución es elegir una sola versión y redirigir las otras tres directamente a esa, con 301, sin pasar por una intermedia:

• http://ejemplo.com → https://ejemplo.com
• http://www.ejemplo.com → https://ejemplo.com
• https://www.ejemplo.com → https://ejemplo.com

Google prefiere HTTPS por defecto, pero una redirección de HTTPS hacia HTTP o un certificado inválido pueden hacer que elija la versión equivocada. Por eso la redirección se acompaña de una etiqueta rel="canonical" autorreferenciada en la versión elegida, enlaces internos que apunten solo a ella y sitemaps sin URLs HTTP. Las redirecciones son la señal de canonicalización más fuerte que tiene Google, pero funcionan mejor cuando todas las demás señales dicen lo mismo.

8. Usar una 302 para un cambio permanente

Muchos frameworks y plugins crean redirecciones 302 por defecto, y en un rediseño eso pasa desapercibido porque el usuario no nota ninguna diferencia. Google sí: con una redirección temporal sigue el salto, pero no trata el destino como canónico y la URL de origen se queda en los resultados. Si el cambio de estructura es definitivo, esa redirección le está diciendo lo contrario.

Al revés también es un error: si montas una página de campaña para Black Friday que reemplaza a una categoría solo por unas semanas, ahí sí corresponde una 302 o una 307, porque la URL original va a volver.

Cuándo una redirección deja de ser un error y pasa a ser spam

Los ocho errores anteriores cuestan tráfico, pero no son una infracción. Hay dos prácticas que sí lo son, y en un rediseño pueden colarse sin que nadie lo haya decidido.

Redirecciones engañosas

Las políticas de spam de Google llaman sneaky redirects a redirigir con mala intención: mostrarle a Google un contenido y mandar al usuario a otro distinto, o servir la página normal en escritorio y desviar a los usuarios de móvil hacia otro dominio. La misma política aclara que mover un sitio o fusionar páginas son razones legítimas para redirigir. El riesgo en un rediseño no es la migración en sí, sino una regla por dispositivo o por origen del tráfico que alguien dejó configurada en el CDN o en un plugin y que nadie revisó.

Secuestro del botón «atrás» (back button hijacking)

El 13 de abril de 2026 Google anunció que manipular el historial del navegador para que el usuario no pueda volver de inmediato a la página de la que venía pasa a ser una infracción explícita de su política de prácticas maliciosas. Los casos típicos: el usuario pulsa «atrás» y aterriza en una página que nunca visitó, en recomendaciones que no pidió o en un anuncio. La aplicación empezó el 15 de junio de 2026, y las páginas que lo hagan pueden recibir acciones manuales o degradaciones automáticas.

Lo relevante para una migración está en un detalle del anuncio: Google advierte que algunos casos vienen de las librerías que incluye el sitio o de su plataforma de anuncios. Un rediseño es justo el momento en que se cambian plantillas, se instalan scripts de terceros nuevos y se reconfiguran los anuncios. Por eso, en las revisiones previas al lanzamiento pruebo el botón «atrás» desde una página interna a la que se llega desde Google, en móvil y en escritorio, con los anuncios y los scripts de terceros activos. Si el historial tiene entradas que el usuario no generó, hay que encontrar qué código las inserta y quitarlo. Si el sitio ya recibió una acción manual por esto, después de corregirlo se pide una reconsideración en Search Console.

Lo que cambió desde 2023 y conviene saber

• Las redirecciones se mantienen al menos un año. En la versión original de este artículo sugería eliminar redirecciones cuando dejaran de recibir visitas. Hoy no lo recomiendo: la guía de migraciones de Google pide mantenerlas, por lo general, al menos un año, y dice que para los usuarios puede ser útil dejarlas indefinidamente. Lo que sí reduce carga es actualizar los enlaces internos y pedir a los sitios externos más importantes que enlacen directo a la URL nueva.
• AI Overviews y AI Mode dependen del mismo índice. Google indica que para aparecer como enlace de apoyo en esas funciones una página tiene que estar indexada y poder mostrarse con fragmento en la Búsqueda, sin requisitos técnicos adicionales. Una URL perdida por una mala redirección deja de ser candidata tanto en los resultados clásicos como en las respuestas generadas. Desde el 31 de agosto de 2026 eso ya se puede medir: Search Console tiene un informe de rendimiento de IA generativa, disponible para todos los sitios, con las impresiones en AI Overviews y AI Mode por página, país, dispositivo y fecha.
• Bing y otros buscadores se pueden avisar al instante. El protocolo IndexNow acepta URLs redirigidas y URLs que responden 404 o 410, y su documentación considera aceptable enviar todas las URLs después de una migración o un rediseño. Google no forma parte de IndexNow; para Google, el aviso sigue siendo el sitemap nuevo en Search Console.
• La herramienta de cambio de dirección tiene un uso limitado. En Search Console sirve solo para cambios de dominio o subdominio. No aplica para pasar de HTTP a HTTPS, unificar www o cambiar rutas dentro del mismo dominio.

Cuándo lanzar: no en medio de una actualización de Google

Google publica en el Search Status Dashboard el inicio y la duración de cada actualización de ranking. En 2026 casi no hubo un trimestre tranquilo:

Una migración ya produce fluctuaciones por sí sola. Si se lanza mientras se despliega una core update, las dos causas se mezclan en los mismos datos y después nadie puede decir si una caída vino de una redirección mal hecha o de la actualización. Google no prohíbe migrar en esas fechas; la recomendación es mía y sale de su propia guía sobre core updates, que pide anotar en el dashboard la fecha de inicio y de fin, esperar al menos una semana completa después de que termine el despliegue y comparar contra una semana anterior al inicio. Con una migración en medio, esa comparación pierde sentido.

En la práctica hago tres cosas:

• Revisar el dashboard antes de fijar la fecha y suscribirse a su RSS. Si hay una actualización en curso, mover el lanzamiento unos días cuesta menos que un diagnóstico imposible.
• Anotar el lanzamiento en el mismo calendario que las actualizaciones, para que quien lea los datos después sepa qué pasó primero.
• Si una actualización arranca justo después del lanzamiento, no tocar por reflejo redirecciones que están bien. Primero se verifica la parte técnica con la rutina de abajo y, si está limpia, se espera a que termine el despliegue antes de sacar conclusiones.

Cómo verificar las redirecciones después del lanzamiento

El seguimiento es donde más rediseños fallan, porque el equipo da el proyecto por cerrado el día que el sitio sale al aire. Esta es la rutina que sigo:

1. Rastrear la lista de URLs antiguas con un rastreador en modo lista y confirmar que cada una responde 301 o 308 hacia un destino que responde 200, sin saltos intermedios.
2. Revisar el informe de indexación de páginas en Search Console. «Página con redirección» es normal para las URLs viejas; «Error de redirección» y «Soft 404» son los estados que hay que corregir.
3. Comparar canónicas con la herramienta de inspección de URLs: si aparece «Duplicada: Google ha elegido una URL canónica diferente a la del usuario», alguna señal contradice a la redirección.
4. Enviar el sitemap nuevo y retirar el viejo cuando ya no haga falta. Las advertencias por URLs redirigidas en el sitemap antiguo son esperables.
5. Cruzar registros del servidor y analítica para encontrar 404 que reciban tráfico y que no estaban en el inventario inicial.
6. Actualizar enlaces internos, canónicas y hreflang para que apunten a las URLs nuevas y no dependan de la redirección.
7. Comparar las impresiones en IA en el informe de rendimiento de IA generativa de Search Console, antes y después del lanzamiento, por página. El informe agrupa los datos por la URL final que enlaza la función de IA después de las redirecciones y, en general, los asigna a la URL canónica, así que las páginas nuevas deberían heredar las impresiones de las viejas. Si una página que aparecía en AI Overviews o AI Mode deja de figurar y su equivalente nueva no aparece, revisa la redirección y la canónica de esa URL. Ten en cuenta que el informe mide impresiones, no visitas, y que si no aparece puede ser porque el sitio tiene pocas impresiones en esas funciones o porque está excluido de ellas.

Qué esperar del tráfico

Ninguna migración es neutra. Google advierte que durante un traslado el posicionamiento puede fluctuar y que eso se estabiliza con el tiempo, y que en sitios grandes el proceso tarda más. Un buen plan de redirecciones no evita esa fluctuación: hace que sea corta y que lo que se recupere sea el tráfico que ya tenías, no uno que tienes que volver a construir. Lo que he visto en proyectos donde las redirecciones se hicieron tarde es que la recuperación tarda mucho más que el tiempo que se ahorró al aplazarlas.

Checklist rápido antes de lanzar

• Inventario completo de URLs antiguas, incluidos archivos y páginas con enlaces externos.
• Cada URL antigua con un destino equivalente, o marcada como 404/410 si no lo tiene.
• Redirecciones permanentes en el servidor (301/308) para todo cambio definitivo.
• Una sola versión del dominio, con las otras variantes redirigidas directo a ella.
• Sin cadenas ni bucles: cada regla apunta al destino final.
• Canónicas, enlaces internos, hreflang y sitemaps actualizados a las URLs nuevas.
• Fecha de lanzamiento revisada contra el Search Status Dashboard, fuera de una actualización en curso.
• Botón «atrás» probado en móvil y escritorio con anuncios y scripts de terceros activos.
• Plan de monitoreo en Search Console (incluido el informe de IA generativa), Bing Webmaster Tools y registros del servidor durante las semanas siguientes.

Johan Esteban Ortiz Zapata

Especialista SEO senior con más de 7 años en SEO técnico, estratégico y off-page para marcas de banca, retail y educación en Colombia. Más sobre mí · Agendar diagnóstico

Publicado por primera vez el 18 de julio de 2023. Actualizado y ampliado el 5 de noviembre de 2026.