El tráfico baja tras una puesta en marcha, y se espera. Es incluso lo razonable durante los primeros días: Google necesita tiempo para volver a rastrear las nuevas URLs, reevaluarlas y reindexarlas. El informe «Indexación de páginas» de Google Search Console muestra una curva que se mueve, se la observa remontar, y uno se tranquiliza.
Solo que una curva agregada nunca dice qué páginas se quedaron por el camino. ¿Cuántas URLs antiguas encontraron realmente su sustituta? ¿Cuántas páginas nuevas están indexadas tres semanas después del cambio? Y entre las que no lo están, ¿cuáles descartó Google, y por qué motivo?
Ahí es donde los rediseños mejor preparados suelen perder más terreno.
Qué es un rediseño SEO logrado
Un rediseño SEO logrado conserva las posiciones y el tráfico orgánico del sitio anterior, y después los supera. Se apoya en tres pilares: un inventario exhaustivo de las URLs existentes, un plan de redirecciones sin huecos ni cadenas, y una verificación posterior a la puesta en marcha, página a página, de lo que Google realmente conservó del nuevo sitio.
El tercer pilar es el que la mayoría de las checklists despacha en una línea, cuando es el único capaz de confirmar que los dos primeros surtieron efecto.
Rediseño o migración: la distinción que hace Google
En español, «rediseño» abarca dos operaciones que Google trata por separado, en dos páginas de documentación distintas: el traslado de sitio con cambio de URLs y el traslado sin cambio de URLs. Los riesgos y las verificaciones no se parecen en nada.
Sin cambio de URLs, el sitio cambia de apariencia, de plantillas, a veces de alojamiento, pero las direcciones siguen siendo las mismas. No hace falta plan de redirecciones. El riesgo se desplaza a otro sitio: contenido recortado al rehacer las plantillas, etiquetas perdidas por el camino, enlazado interno reconstruido que entierra páginas antes accesibles en dos clics, bloqueos de preproducción olvidados en producción. Google documenta además un efecto propio del cambio de alojamiento: una caída temporal de la tasa de rastreo justo después del lanzamiento, seguida de una remontada progresiva, a veces por encima del nivel anterior.
Con cambio de URLs, todo depende de la correspondencia entre lo antiguo y lo nuevo. El plan de redirecciones se convierte en la pieza central, y aparece una pregunta nueva: ¿conservará Google tu destino de redirección como dirección canónica, o preferirá otra? Ambos casos se combinan a menudo, cuando un cambio de plataforma llega acompañado de un rediseño gráfico.
Saber en qué caso te encuentras determina la checklist que hay que desplegar. Un rediseño puramente gráfico que conserva las URLs no necesita un plan de redirecciones de trescientas líneas; necesita comprobar que el contenido no se ha reducido y que el rastreo ha vuelto a arrancar.
Por qué un rediseño hace perder tráfico
Un rediseño hace perder tráfico cuando Google ya no encuentra, en las nuevas direcciones, aquello que justificaba las posiciones de las antiguas: el contenido, los enlaces que apuntaban a ellas y la posibilidad de rastrearlas con rapidez. Las causas se repiten de un proyecto a otro, y admiten una jerarquía.
Las URLs olvidadas en el plan de redirecciones encabezan la lista con diferencia. Un rediseño se prepara casi siempre a partir del sitemap o de un rastreo del sitio. Ninguna de esas dos fuentes lo contiene todo: páginas antiguas desconectadas del enlazado, landing pages gestionadas fuera del CMS, variantes con parámetros que sí recibían clics. Esas direcciones no figuran en ninguna lista, y nadie repara en su desaparición hasta ver bajar el tráfico.
Las cadenas de redirecciones vienen después. Una URL antigua redirige a una dirección intermedia, que a su vez redirige a la nueva. Cada eslabón diluye la señal y ralentiza el tratamiento, y las cadenas se alargan en silencio cuando un rediseño sucede a otro anterior.
El contenido recortado es más insidioso. La página nueva existe, responde con un 200, todo parece en orden. Pero la plantilla rehecha ha suprimido una sección de texto, ha sustituido un párrafo por una imagen o ha trasladado las respuestas a un acordeón que se carga después. Google vuelve a rastrear, encuentra menos materia, y la página retrocede. En los casos extremos pasa a Soft 404: el servidor responde correctamente, pero Google considera la página vacía.
La arquitectura aplanada o reconstruida desplaza la profundidad de las páginas. Una ficha de producto accesible en dos clics que pasa a estar a cuatro recibe menos enlaces internos, y por tanto menos atención. Eso es invisible en un informe de tráfico y muy visible en uno de rastreo.
El propio plazo de re-rastreo, por último, explica una parte de la caída inicial, y esa parte es normal. La dificultad consiste precisamente en distinguir ese bache esperado de un problema real, y de eso trata la última parte de esta checklist.
Antes del cambio: el inventario de URLs
El inventario consiste en establecer la lista completa de las direcciones que existen hoy y que merece la pena preservar. Se suman tres fuentes, y la tercera es la que se olvida.
El sitemap XML da lo que el sitio declara. Es el punto de partida, rara vez el perímetro real: un sitemap refleja lo que el CMS sabe generar, no lo que Google conoce.
Un rastreo del sitio completa la lista con lo accesible mediante enlaces. Añade las páginas presentes pero no declaradas, y revela la profundidad actual de cada una, un dato valioso para comprobar después que la nueva arquitectura no la ha degradado.
La exportación de Search Console aporta lo que las otras dos no pueden dar: las URLs que reciben realmente clics e impresiones, incluidas las que no figuran en ningún sitemap y a las que ya no llega ningún enlace interno. Esa es la lista que de verdad cuenta. Una página olvidada en el plan de redirecciones solo importa si aportaba algo, y únicamente Search Console lo sabe.
Así pues, las direcciones que hay que proteger primero son las que reciben clics, y no solo las que declara el sitemap. Ambas listas se solapan en gran medida, y es en la diferencia entre ellas donde se alojan la mayoría de las sorpresas desagradables de un rediseño.
Queda añadir las páginas que reciben enlaces externos, aunque no tengan tráfico: arrastran un valor que desaparece con ellas.
El plan de redirecciones
El plan de redirecciones asocia cada URL antigua con la dirección que mejor la sustituye en el nuevo sitio. Una correspondencia por línea, sin intermediarios, y una decisión explícita para cada página que no vaya a ser sustituida.
Una redirección permanente, no temporal. Google trata la redirección 301 como una señal fuerte de canonicalización: indica que la dirección ha cambiado definitivamente y que la señal debe transferirse. La 302 anuncia lo contrario, un traslado provisional, y deja la dirección antigua como candidata a la indexación. En un rediseño, la 301 es la norma; la 302 se reserva para cambios realmente temporales. Las direcciones antiguas aparecerán después bajo el estado Página con redirección en el informe de indexación, que es el comportamiento esperado.
Hacia el equivalente más próximo, nunca hacia la home. Redirigir en masa páginas suprimidas a la página de inicio es el atajo más habitual y uno de los más costosos. Google considera esas redirecciones como Soft 404, puesto que el destino no responde a la intención de partida. Una página sin equivalente gana con devolver un 404 asumido, o un 410 si la supresión es definitiva, antes que una redirección engañosa.
Sin cadenas. Si el sitio antiguo ya contenía redirecciones, hay que aplanarlas: la dirección más antigua debe apuntar directamente al destino final, no a un eslabón intermedio a su vez redirigido.
Con los recursos. Las imágenes, los PDF, los feeds y los sitemaps antiguos también tienen direcciones. Faltan con regularidad en los planes de redirección aunque algunos se posicionen por sí solos.
💡 En un rediseño de unos cientos de URLs, este trabajo se lleva a mano. Más allá, la cuestión ya no es redactar el plan sino comprobar que ha surtido el efecto previsto, dirección por dirección. Es exactamente para eso que sirve una verificación de indexación masiva.
El día del cambio
El orden de las operaciones cuenta tanto como su contenido. Hay cuatro puntos que se comprueban en la hora siguiente a la puesta en marcha.
Levantar los bloqueos de preproducción. El robots.txt que lo prohibía todo, la etiqueta noindex colocada sobre el conjunto de la plantilla, la autenticación HTTP que protegía el entorno de pruebas: los tres están concebidos para impedir la indexación, y los tres se olvidan con regularidad en producción. Un rediseño bloqueado por su propio robots.txt durante una semana cuesta mucho más que el propio rediseño. El estado Bloqueada por robots.txt aparece entonces en el informe de indexación, a menudo con varios días de retraso.
Enviar dos sitemaps. Es la recomendación explícita de Google, y rara vez se aplica: conservar temporalmente el sitemap de las URLs antiguas además del de las nuevas. El primero debe ver caer progresivamente a cero su número de URLs indexadas, y el segundo verlo subir. Ese cruce es la medida más legible del avance de la transferencia. Los avisos de redirección sobre el sitemap antiguo son normales y pueden ignorarse.
Comprobar en directo una muestra de redirecciones, siguiendo la cadena completa y verificando el código de estado realmente devuelto, no solo la página que se muestra.
Actualizar los enlaces internos, en lugar de confiar en las redirecciones. Una redirección funciona, pero un enlace interno que apunta directamente a la dirección correcta funciona mejor, y no dependerá de cuánto dure el plan de redirecciones.
Después del cambio: verificar qué decidió Google sobre tus nuevas URLs
Es el paso más decisivo de la checklist, y el que la mayoría de las guías resume en una línea. La razón es sencilla: hasta aquí, todo lo anterior se controla desde tu propio sitio. A partir de aquí, la única respuesta válida viene de Google.
¿Están indexadas tus nuevas URLs, y cuáles no lo están?
El informe «Indexación de páginas» de Search Console da contadores agregados, con varios días de retraso. Muestra que el número de páginas indexadas se ha movido. No dice cuáles de tus nuevas direcciones han fallado, ni por qué.
La herramienta de inspección de URLs sí da el veredicto oficial completo: el estado exacto, el motivo cuando la página no está indexada, la canónica elegida por Google, la fecha del último paso de Googlebot. Lo da de una URL cada vez. En un rediseño de trescientas páginas, la verificación se vuelve tediosa; en varios miles, sencillamente no se hace.
Ese desfase explica que un rediseño pueda darse por bueno mientras una parte del catálogo nunca ha vuelto al índice. Los estados observados tras un cambio son variados — entre los más frecuentes, Explorada, actualmente no indexada en páginas que Google sí ha visto pero no ha retenido, y los estados de canónica que se tratan más abajo.
Es precisamente este trabajo el que IndexProbe automatiza: el veredicto oficial de Google, para toda la lista de tus nuevas URLs, en un solo análisis.
¿Ha conservado Google tu destino de redirección como canónica?
Una redirección 301 constituye una señal fuerte de canonicalización, sin garantizar por ello el resultado. Google cruza varias señales — la redirección, las etiquetas canónicas declaradas, los enlaces internos y externos, la similitud de los contenidos — y retiene la dirección que le parece más representativa. No siempre es la que tú pretendías.
El caso se produce sobre todo en dos configuraciones. Cuando varias direcciones antiguas redirigen a una misma página nueva, Google debe arbitrar entre señales que compiten. Y cuando la página nueva se parece mucho a otra página del nuevo sitio, una ficha de producto y su variante, una categoría y su versión filtrada, puede consolidar ambas bajo una dirección única que no es forzosamente la prevista.
El resultado tiene un nombre en Search Console: Duplicada: Google ha elegido una canónica distinta de la del usuario. La página redirigida llega a alguna parte, pero no adonde pensabas, y las posiciones siguen al destino real, no al previsto.
La verificación consiste en comparar, para cada nueva URL, la canónica que declaras y la que Google ha retenido efectivamente. La diferencia entre ambas columnas es la señal. Observada segmento a segmento, revela por lo general un problema estructural más que una serie de casos aislados: una plantilla, una familia de páginas, una regla de generación de URLs.
El bache de rastreo: normal, ¿pero hasta cuándo?
Google documenta explícitamente este fenómeno para los cambios de alojamiento: es normal constatar una caída temporal de la tasa de rastreo justo después de la puesta en marcha, seguida de una remontada progresiva en los días siguientes, eventualmente a un nivel superior al anterior. La explicación está en cómo se determina la tasa de rastreo: se apoya en señales ligadas a la infraestructura, y esas señales cambian cuando cambia el alojamiento.
La consecuencia práctica es que un bache de rastreo tras un cambio no tiene nada de inquietante en sí mismo. Lo que debe alertar es la ausencia de remontada en los días siguientes, y constatarlo supone haber medido la tasa de rastreo tanto antes como después.
Google recomienda para ello leer los registros del servidor y localizar en ellos los pasos de Googlebot. Es el método más completo, y supone acceso a los logs, una infraestructura para tratarlos y alguien que los lea, tres condiciones que rara vez se dan justo cuando un equipo sale de un rediseño.
Existe una vía más corta: los datos de rastreo que el propio Google expone para cada URL inspeccionada, es decir la fecha del último paso de Googlebot. Agregados sobre una lista de direcciones, dan una tasa de rastreo a treinta días, una frecuencia media y una distribución de los intervalos entre dos pasos. Seguidos por segmento, muestran si la remontada se produce en todas partes o si una familia de páginas se queda atrás. Es el mismo razonamiento que el del presupuesto de rastreo, aplicado en el momento en que resulta más útil.
Medir la recuperación: comparar el antes y el después
La única forma de saber si un rediseño ha vuelto a su nivel consiste en comparar dos estados del mismo perímetro con unas semanas de diferencia. Una curva de tráfico no basta, ya que mezcla la indexación, el posicionamiento y la estacionalidad. Lo que hay que confrontar son dos estados de indexación tomados sobre la misma lista de URLs.
La comparación responde a tres preguntas que el tráfico por sí solo deja abiertas. ¿Ha vuelto el número de páginas indexadas a su nivel anterior al cambio? ¿Se han desplazado los estados en el buen sentido, o algunas páginas han pasado de indexadas a no indexadas? ¿Y es homogénea la recuperación, o se concentra en ciertos segmentos?
Esta lectura segmentada suele ser la que desbloquea un diagnóstico. Un sitio cuya indexación global ha vuelto al 94 % puede haber dejado atrás un tercio de sus fichas de producto, y la media oculta la diferencia hasta que se observa por familia de páginas.
Los errores que salen más caros
Redirigir todas las páginas suprimidas a la home. El destino no responde a la intención inicial, Google trata la redirección como un Soft 404, y la señal de la página antigua se pierde en lugar de transferirse. Un 404 asumido vale más, o un 410 para una supresión definitiva.
Cortar las redirecciones demasiado pronto. El plan de redirecciones no es una operación de unas semanas. Google sigue solicitando las direcciones antiguas mucho después del cambio, y los enlaces externos nunca se actualizarán. Un año es un mínimo razonable; en las páginas que reciben enlaces, conviene conservarlas indefinidamente.
Dejar que se instalen cadenas. Cada eslabón añade una etapa, diluye la señal y aumenta el riesgo de que uno de ellos se rompa.
Olvidar los 404 aparecidos tras el cambio. Un rediseño produce siempre un lote de direcciones no encontradas no previstas: enlaces internos obsoletos, URLs mal reescritas, recursos desplazados. Aparecen en el informe de indexación y se tratan como cualquier error 404 en Search Console, con la diferencia de que tras un rediseño llegan por centenares.
Esperar el regreso del tráfico para verificar la indexación. El tráfico es un indicador retardado: cuando la caída se hace evidente en los informes, las páginas afectadas llevan semanas fuera del índice, y el tiempo de corrección se suma a ese plazo. El estado de indexación de cada página, en cambio, puede consultarse desde los primeros días posteriores al cambio.
Preguntas frecuentes
¿Cuánto tiempo baja el tráfico tras un rediseño?
Una caída de unos días a unas semanas es normal, el tiempo que Google necesita para volver a rastrear las nuevas direcciones, tratar las redirecciones y reevaluar las páginas. La magnitud depende del tamaño del sitio y del número de URLs modificadas. Más allá de seis u ocho semanas sin recuperación, ya no se trata del plazo normal sino de un problema que hay que diagnosticar, y lo primero que hay que comprobar es la indexación de las páginas nuevas, no las posiciones.
¿Hay que usar redirecciones 301 o 302 en un rediseño?
- Google trata la redirección permanente como una señal fuerte de canonicalización, que es exactamente la intención en un rediseño: indicar que la dirección ha cambiado definitivamente. La 302 anuncia un traslado temporal y deja la dirección antigua como candidata a la indexación. Solo se justifica para un cambio realmente provisional, por ejemplo durante una prueba.
¿Se pueden redirigir todas las páginas antiguas a la página de inicio?
No, es uno de los atajos más costosos. Cuando el destino no corresponde a la intención de la página de origen, Google considera la redirección como un Soft 404 y la señal de la página antigua no se transfiere. Cada dirección antigua gana apuntando a su equivalente más próximo, y las que no lo tienen ganan devolviendo un 404, o un 410 si la supresión es definitiva.
¿Cuánto tiempo hay que conservar las redirecciones?
Un año como mínimo. Google sigue solicitando las direcciones antiguas mucho después del cambio, y los enlaces externos que apuntan a ellas nunca serán actualizados por sus autores. En las páginas que reciben enlaces entrantes de valor, más vale conservar las redirecciones sin límite de tiempo: su coste técnico es insignificante frente a la señal que transmiten.
¿Conviene conservar las URLs antiguas cuando es posible?
Sí, cuando el rediseño es gráfico o funcional y ninguna razón seria obliga a cambiar la estructura de las direcciones. Un rediseño sin cambio de URLs elimina de entrada el riesgo más importante, el del plan de redirecciones incompleto. Las verificaciones se concentran entonces en el contenido, el enlazado interno y la reanudación del rastreo.
¿Cómo saber si un rediseño ha funcionado?
Comparando la indexación antes y después sobre el mismo perímetro de URLs, en lugar de vigilar la curva de tráfico. Bastan tres indicadores: si el número de páginas indexadas ha vuelto a su nivel anterior, si los estados se han desplazado en el buen sentido y si la recuperación es homogénea entre los segmentos del sitio. Una media satisfactoria puede ocultar una familia entera de páginas que sigue fuera del índice.
Verifica tu rediseño página a página
Un rediseño moviliza semanas de trabajo, y su resultado depende de lo que Google haya retenido del nuevo sitio. IndexProbe interroga la API oficial de Search Console para la lista de URLs que le facilitas y devuelve, para cada página, el estado de indexación, el motivo de no indexación, la canónica que Google ha elegido realmente y la fecha del último paso de Googlebot. La vista Comparación mide después la diferencia entre dos análisis, para saber si la recuperación se ha producido, y dónde no.
Verificar la indexación de tu nuevo sitio — prueba gratuita de 10 días, sin tarjeta.