Hace cuatro años acompañé un proceso de rediseño web sin perder posicionamiento que, sobre el papel, era impecable. Mismo dominio, mismas URLs, mismo CMS. Nadie tocó la estructura de carpetas. El rediseño era puramente estético: tipografías nuevas, una paleta más limpia, un header que por fin funcionaba en móvil. A los once días, el tráfico orgánico había caído un 34%.
¿Dónde estaba el error? En ninguna redirección. No hubo ni una sola implicada, porque no hizo falta crearlas.
Y ahí está el problema de cómo se habla de este tema. La conversación entera gira alrededor de un solo mecanismo técnico, como si conservar la visibilidad en buscadores dependiera de un archivo de reglas bien escrito. Después de unos cuantos proyectos de este tipo, tengo bastante claro que el mapa de redirecciones es la parte fácil. La parte difícil es todo lo que nadie inventaría la noche antes del lanzamiento porque nadie lo apuntó meses atrás.
El mito del 301 perfecto
La creencia dominante dice algo así: si cada dirección antigua apunta a su equivalente nueva con un código 301, la autoridad viaja y no pasa nada. Es cierto en la parte mecánica. Google transfiere señales de enlace a través de esas redirecciones con bastante fiabilidad desde hace años, y Gary Illyes lleva tiempo repitiendo que no hay pérdida significativa de PageRank en el proceso.
Lo que ese mito omite es que una redirección solo garantiza que el usuario y el rastreador lleguen a algún sitio. No garantiza que el sitio al que llegan merezca la misma posición. Si la página de destino tiene 400 palabras donde antes había 1.800, si perdió los tres enlaces internos que la sostenían, si el H1 cambió de intención, el 301 ha funcionado y el ranking se ha ido igualmente. Total, que el archivo de reglas no es un seguro. Es un puente. Lo que importa es qué hay al otro lado.
¿Por qué cae el tráfico si las URLs no cambian?
El posicionamiento puede caer con las direcciones intactas porque Google no evalúa la dirección, sino lo que contiene. Si la plantilla nueva recorta texto, elimina enlaces internos entrantes o cambia la intención del encabezado principal, la página deja de responder la consulta igual de bien y pierde posiciones sin que nada se haya movido.
Vuelvo al caso de la caída del 34%. Cuando revisé los logs del servidor y comparé el rastreo pre y post lanzamiento con Screaming Frog, el patrón era evidente y bastante vergonzoso: no había desaparecido ninguna dirección, pero sí habían desaparecido unas 11.000 palabras repartidas por el sitio. Nadie las borró a propósito. El diseñador había construido unas maquetas preciosas que, simplemente, no contemplaban determinados bloques de texto.
Este es el escenario que más veces he visto y el que menos se documenta. El proyecto se evalúa como un cambio visual, se audita como un cambio visual, y resulta que era un cambio de contenido disfrazado.
El contenido que el nuevo diseño se come
Las maquetas modernas tienden al aire. Más espacio en blanco, bloques más cortos, secciones con tres frases y una imagen grande. Estéticamente funciona. El problema es que los textos largos que se escribieron para la versión anterior no caben en esas cajas, y lo que no cabe se recorta sin acta de defunción.
En el proyecto de 2021 que mencionaba, una ficha de servicio pasó de 1.240 palabras a 390 porque el nuevo diseño tenía un campo de descripción con límite visual. Esa página sostenía 14 consultas en posiciones 3-7. Cinco semanas después estaba en la página dos para casi todas. Recuperarla costó dos meses y reescribir el contenido desde el archivo de Wayback Machine, que fue lo único que nos salvó porque, y aquí viene mi parte favorita de la anécdota, nadie había guardado una copia del texto original.
Enlaces internos que desaparecen
¿Cuántos enlaces internos apuntan ahora mismo a tu página más rentable? Si no sabes la cifra exacta, el relanzamiento te la va a cambiar sin avisar.
Los menús desplegables de tres niveles, los bloques de «artículos relacionados», los enlaces contextuales dentro de párrafos largos, los widgets de sidebar: todo eso es enlazado interno, y todo eso tiende a simplificarse cuando se rediseña. Una navegación nueva, más limpia, con seis entradas en lugar de veintidós, elimina de golpe cientos de enlaces.
En un ecommerce de material eléctrico con el que trabajamos en 2023, la maqueta nueva eliminó el módulo de productos relacionados. Resultado: 1.870 enlaces internos menos. Las fichas de catálogo profundo pasaron de recibir 4-6 enlaces cada una a recibir 1, el que venía de su categoría padre. En siete semanas, el 23% de esas fichas había salido del top 20. El diseño era objetivamente mejor. La arquitectura de enlazado era objetivamente peor. Esa es exactamente la clase de decisión que conviene auditar antes de dar el visto bueno a una maqueta, y no después: nuestro trabajo de consultoría web cuesta infinitamente menos en esa fase que recuperar posiciones una vez publicado el sitio.
Lo que nadie inventaría antes
Aquí está la sección que me interesa de verdad, y es la que casi nunca aparece en las guías sobre este asunto.
Mi hipótesis inicial, cuando empecé a trabajar en migraciones allá por 2016, era que lo determinante estaba en la ejecución técnica del día del lanzamiento. Después de unos quince proyectos, los datos me dijeron otra cosa bastante incómoda: las migraciones que salieron bien no se diferenciaban de las que salieron mal por lo que se hizo el día D, sino por lo que se había documentado tres meses antes. Cambié completamente el orden de mi metodología a partir de ese momento.
Lo llamo inventario de activos orgánicos (sí, con ese nombre tan poco glamuroso), que suena pomposo pero consiste en una hoja de cálculo. Antes de que el diseñador abra Figma, se congela una fotografía del estado actual con estos datos por cada dirección relevante:
- Tráfico orgánico de los últimos 12 meses
- Consultas posicionadas en top 20 y su posición media
- Recuento exacto de palabras del cuerpo
- Número de enlaces internos entrantes
- Número de dominios de referencia externos
- Estructura de encabezados completa
- Datos estructurados implementados
- Conversiones atribuidas en los últimos 6 meses
Ese documento es lo que nadie puede reconstruir después. Search Console guarda 16 meses de datos de rendimiento, cierto, pero no guarda cuántas palabras tenía tu ficha de servicio en febrero ni qué enlaces internos apuntaban a ella. Esa información se pierde en el momento exacto en que se publica la versión nueva, y es precisamente la información que necesitas para diagnosticar una caída.
¿Funciona siempre? No. En proyectos de menos de 40 páginas es sobredimensionado y he visto equipos abandonar el inventario a mitad por puro agotamiento. Pero en cualquier sitio que pase de 200 direcciones indexadas, es la diferencia entre diagnosticar un problema en cuatro horas o pasar tres semanas adivinando.
Un apunte práctico sobre el recuento de palabras: hazlo con el crawler, no a mano. Screaming Frog exporta la columna de word count en el mismo informe que las métricas de rastreo, y comparar dos exportaciones (antes y después) con un BUSCARV te da en diez minutos la lista completa de páginas que han adelgazado. Es, con diferencia, el chequeo con mejor relación esfuerzo-resultado de todo el proceso.
¿Tu staging está indexado?
Pregunta incómoda. Hazte un site: del subdominio de pruebas ahora mismo, antes de seguir leyendo.
De los proyectos que he auditado en los últimos cinco años, aproximadamente uno de cada cinco tenía el entorno de desarrollo total o parcialmente accesible para los rastreadores. Los motivos se repiten con una monotonía casi cómica: el robots.txt del staging bloquea el rastreo pero alguien enlazó esas páginas desde fuera, o la protección por contraseña se levantó temporalmente para que el cliente revisara, o el noindex se aplicó por maqueta y la maqueta cambió.
El daño no es catastrófico pero sí molesto: duplicación de contenido entre dos entornos, canibalización de consultas y, en los casos peores, el buscador prefiriendo la versión de pruebas para alguna consulta de marca. Mira, lo que pasa es que esto se arregla en diez minutos antes del lanzamiento y en tres semanas después. La protección correcta es autenticación HTTP a nivel de servidor, no un meta robots. Un noindex no impide que el entorno sea accesible ni que acumule enlaces; la contraseña sí.
Caída normal o problema real
Va a bajar. Asúmelo antes de lanzar y comunícaselo a quien tenga que aprobar el proyecto, porque la peor decisión que puedes tomar es revertir un relanzamiento correcto por pánico en el día cinco.
Estas son las seis señales que uso para separar una oscilación esperable de una pérdida estructural:
- Caída superior al 25% del tráfico orgánico.
- Descenso que sigue profundizando en la segunda semana.
- Impacto asimétrico: unas páginas se desploman y otras aguantan.
- Páginas con menos del 70% de sus palabras anteriores.
- Pérdida de más de la mitad de los enlaces internos entrantes.
- Respuestas distintas de 200 en direcciones que antes funcionaban.
Una oscilación esperable, en mi experiencia, tiene este perfil: descenso de entre el 8% y el 18% del tráfico orgánico en las dos primeras semanas, recuperación progresiva a partir del día 12-15, y vuelta al nivel previo entre la semana cuatro y la seis. El rastreo aumenta durante esos días (Google está revisitando el sitio entero) y las posiciones fluctúan en bandas de dos o tres puestos sin salir del top 20.
El perfil de un problema estructural es distinto y bastante reconocible. La caída supera el 25%, no se estabiliza en la segunda semana sino que sigue profundizando, y afecta de forma desigual: hay un grupo de páginas que se desploma mientras el resto aguanta. Esa asimetría es la pista más útil que existe. Un descenso uniforme suele ser reindexación. Un descenso concentrado en el 15% de las páginas es casi siempre contenido recortado o enlazado interno roto en esa parte concreta del sitio.
El tercer perfil, el que más miedo da, es la caída que empieza en la semana tres cuando ya habíais celebrado que todo iba bien. Normalmente significa que el rastreador tardó en llegar a la parte profunda del sitio. Con un portal de 8.000 direcciones que migramos en octubre de 2022, el tráfico de categorías se recuperó en doce días y el de fichas individuales empezó a caer el día diecinueve. Ni se nos había ocurrido mirar la segmentación por tipo de página hasta que la gráfica agregada se torció otra vez.
Los primeros 30 días
Día 1, antes de nada: verifica en Search Console que el archivo robots nuevo no bloquea lo que no debe. He visto dos proyectos en los que el Disallow: / del entorno de pruebas viajó al servidor de producción. Uno estuvo así cuatro días. El otro, nueve.
Entre el día 1 y el 3, lanza un rastreo completo y crúzalo contra el inventario previo. Buscas tres cosas concretas: páginas con menos del 70% de las palabras que tenían, páginas que han perdido más de la mitad de sus enlaces internos entrantes, y códigos de respuesta distintos de 200 en direcciones que antes respondían bien. Con esos tres filtros detectas, calculo, el 80% de los problemas graves.
A partir de la segunda semana el trabajo es de vigilancia segmentada, nunca agregada. Separa el rendimiento por tipo de maqueta (categorías, fichas, artículos, páginas de servicio) y revísalo por separado dos veces por semana. La gráfica global miente: un 5% de descenso total puede esconder un 40% de desplome en un tipo de página compensado por el crecimiento estacional de otro. Y aquí está el quid: cuanto más grande es el sitio, más miente el agregado.
El orden correcto importa más
Si tuviera que quedarme con una sola idea de todo esto, sería esta: la secuencia de ejecución determina el resultado más que la calidad de cada fase por separado.
El orden que aplico desde 2019 y que sigo usando en los proyectos de este último año va así. Inventario de activos primero, siempre, antes de que nadie diseñe nada. Definición de maquetas después, con una regla innegociable: cada tipo de maqueta debe poder contener el contenido más extenso que exista hoy en esa categoría de página. Luego construcción en entorno protegido con contraseña. Después volcado de contenido con verificación de recuento palabra por palabra. Penúltimo, la tabla de correspondencias entre direcciones si hace falta. Último, lanzamiento en el día de menor tráfico de la semana.
Fíjate en dónde queda el mapa de redirecciones en esa lista. Penúltimo. Es la tarea que concentra el 90% de la conversación sobre este tema y ocupa el 5% del esfuerzo real. Cuando se invierte el orden (maquetas primero, contenido adaptado a las maquetas después) lo que ocurre es que el diseño dicta el contenido, y el contenido es lo que te posiciona. No al revés.
Una última cosa, y conecta con el arranque de todo esto. Aquel proyecto de la caída del 34% recuperó su nivel en noventa y un días. Caro, pero recuperable. Lo que no habría sido recuperable es haber perdido el registro de lo que teníamos antes. Si estás empezando ahora y no arrastras historial, el enfoque cambia bastante y conviene revisar cómo se plantea posicionar una web desde cero, porque sin activos previos que conservar las prioridades son otras. Pero si ya tienes visibilidad construida, tu trabajo esta semana no es elegir tipografía. Es abrir una hoja de cálculo.
Preguntas frecuentes
¿Cuánto tiempo tarda una web en recuperar posiciones tras un rediseño?
Entre cuatro y seis semanas cuando la ejecución ha sido correcta y el descenso se queda en la banda del 8-18%. Si hubo pérdida real de contenido o de enlazado interno, el plazo se alarga: el caso de la caída del 34% que cuento arriba tardó noventa y un días en volver a su nivel previo, y buena parte de ese tiempo fue reescribir textos.
¿Las redirecciones 301 conservan todo el posicionamiento?
Conservan las señales de enlace, no el ranking. El 301 lleva al usuario y al rastreador hasta la página nueva con bastante fiabilidad, pero si esa página tiene menos texto, menos enlaces internos entrantes o un encabezado con otra intención, la posición cae igual. El mecanismo técnico funciona; lo que falla es el destino.
¿Se pierde posicionamiento al cambiar de dominio?
Sí, de forma temporal y casi siempre recuperable, siempre que se use la herramienta de cambio de dirección de Search Console, se mantengan las redirecciones activas al menos un año y se conserve el contenido íntegro. El riesgo real de un cambio de dominio no está en la transferencia de autoridad, sino en que suele aprovecharse para rehacer las maquetas a la vez. Dos variables, un solo diagnóstico posible: ninguno.
¿Qué revisar después de lanzar una web rediseñada?
Tres comprobaciones en las primeras 72 horas: que el archivo robots de producción no arrastre el Disallow: / del entorno de pruebas, que ninguna página haya perdido más del 30% de sus palabras, y que no haya direcciones devolviendo códigos distintos de 200 cuando antes funcionaban. A partir de ahí, vigilancia segmentada por tipo de página dos veces por semana durante un mes.
