Relanzamiento web sin pérdida de posicionamiento: planificación, redirecciones y monitorización

Imaginemos una empresa de servicios cuya web se creó hace ocho años. Desde entonces tres personas han añadido contenidos, se empezó un blog y se descuidó de nuevo, y algunas páginas de servicios se copiaron y se modificaron ligeramente. La web parece anticuada, carga despacio y resulta incómoda de usar en el móvil. El relanzamiento está decidido.

Lo que suele faltar es una imagen de lo que la web antigua rinde realmente. La página de inicio la conoce todo el mundo. Pero ¿cuáles de las cuatrocientas direcciones traen visitantes, cuáles están enlazadas desde otras webs, cuáles llevan años en el índice sin que nadie las vea? Sin esa respuesta, cualquier decisión sobre la nueva estructura es una apuesta.

La preocupación por las pérdidas está justificada. Para los buscadores, un relanzamiento no es una actualización estética, sino una obra en los cimientos: las direcciones cambian, los textos se acortan, la navegación y los enlaces internos se crean de nuevo. Tras el lanzamiento, Google evalúa en principio una web nueva que debe enlazar con la historia de la antigua.

Las causas rara vez son exóticas. Lo más frecuente es que faltan redirecciones: la web nueva tiene otras direcciones y las antiguas no llevan a ninguna parte o acaban en bloque en la página de inicio. Google no lo interpreta como un traslado, sino como la desaparición de páginas. Las señales que dependían de esas direcciones se pierden, igual que los enlaces de otras webs hacia ellas.

Casi igual de frecuentes son los contenidos que se «ordenan» durante el rediseño. Un texto que llevaba años en la primera página para una búsqueda concreta se acorta porque en el nuevo diseño parece demasiado largo. Los encabezados se redactan en un tono más publicitario y desaparece el término que la gente realmente busca.

A ello se suman errores técnicos que solo se notan tras el lanzamiento: un bloqueo de indexación del entorno de staging que se ha trasladado también, un robots.txt que lo excluye todo, canonicals ausentes, datos estructurados perdidos, un sitemap con direcciones antiguas. Ninguno de estos errores es difícil de evitar. Ocurren cuando nadie lleva una lista.

Antes de rediseñar nada hace falta un inventario fiable. Combina tres fuentes, porque cada una por sí sola tiene puntos ciegos. Un rastreo, por ejemplo con Screaming Frog, proporciona todas las direcciones accesibles con código de estado, título, encabezados, canonical y enlaces internos. Muestra lo que la web es técnicamente.

Search Console muestra lo que Google hace con ella: qué páginas reciben impresiones y clics, para qué búsquedas y en qué posición. Aquí suele verse que unas pocas páginas sostienen la mayor parte de la visibilidad y que subpáginas aparentemente poco importantes aportan consultas en silencio. Un período de al menos doce meses suaviza las fluctuaciones estacionales.

La tercera fuente es el perfil de backlinks. ¿A qué direcciones enlazan otras webs, directorios o páginas de prensa? Una página con poco tráfico pero con varios enlaces de calidad merece más cuidado del que su tráfico hace suponer. Para ello bastan los informes de Search Console, completados con una herramienta de backlinks de su elección.

El resultado es una tabla en la que cada URL conocida figura con código de estado, clics, impresiones, enlaces entrantes y búsqueda principal. Es el documento de trabajo para todo lo demás.

De la tabla de inventario surge la auditoría de contenidos. Cada página recibe una de cuatro decisiones. Mantener: la página funciona, la dirección y el contenido se quedan. Revisar: el tema es sólido, pero el texto o la estructura son débiles. Fusionar: varias páginas similares compiten por la misma búsqueda y se convierten en una más fuerte. Eliminar: la página ya no tiene función.

Eliminar no significa borrar sin dejar rastro. También para las páginas que desaparecen se busca un destino razonable, normalmente la página más cercana por temática. Si no hay ninguno y la dirección no tiene ni tráfico ni enlaces, un código de estado 410 o 404 limpio es una respuesta más honesta que una redirección a una página inadecuada. Según la experiencia, Google trata una redirección a contenido irrelevante como un soft 404.

A la hora de decidir si la estructura de direcciones debe cambiarse siquiera, conviene la prudencia. Una navegación nueva o un diseño nuevo no necesitan URL nuevas. Cada dirección que puede mantenerse es un riesgo menos. Cambie las direcciones solo si el sistema de gestión de contenidos lo obliga o si la estructura actual causa problemas de forma demostrable.

El mapeo de URL es la tabla que asigna cada dirección antigua exactamente a una nueva. Suena a trabajo de hormiga, y lo es, pero aquí se decide si las señales se transfieren. Cada fila contiene la URL antigua, la URL de destino, el código de estado deseado y una nota con la justificación. Donde se han fusionado varias páginas antiguas, varias filas apuntan al mismo destino.

El destino debe tratar el mismo tema, no un parentesco temático aproximado. Una página antigua sobre «mantenimiento de calefacción» debe ir a la nueva página de mantenimiento, no a un resumen general de servicios. Además se comprueba que la propia URL de destino responde con estado 200 y no redirige a su vez.

Aquí está el peligro de las cadenas. Si un relanzamiento anterior redirigió la dirección A a B y la nueva B va a C, resulta A, B, C. Cada paso intermedio cuesta tiempo de carga y aumenta el riesgo de que algo se rompa. La regla es: cada URL antigua redirige en un solo paso directamente al destino final. Para ello, también los lastres de redirecciones anteriores deben entrar en la tabla.

El estándar para los traslados permanentes es el código de estado 301 (alternativamente 308). Google ha confirmado que también un 302 transmite señales pasado un tiempo, pero un traslado permanente debería señalizarse también como permanente.

Se construye en un entorno de staging que debe ser invisible para los buscadores. La solución más fiable es una protección de acceso por contraseña o restricción de IP. Una indicación noindex es la segunda salvaguarda, pero un robots.txt con Disallow por sí solo no basta, porque las direcciones bloqueadas pueden aparecer igualmente en el índice si se enlazan. Además, Google no puede leer un noindex si no se le permite acceder a la página.

En el staging no solo se diseña, también se compara. Títulos, metadescripciones, encabezados principales, canonicals, hreflang (si es multilingüe) y datos estructurados del rastreo de la web antigua se contrastan con los de la nueva. Un informe de diferencias muestra cada desviación. No todas son un error, pero cada una debería ser una decisión consciente.

Para la estructura de encabezados rige una regla sencilla: una página tiene exactamente un H1 que expresa el tema y, debajo, un esquema comprensible. Las plantillas nuevas suelen usar los encabezados como recurso de diseño y destruyen así la estructura. También los enlaces internos deben apuntar en el nuevo sistema a las nuevas direcciones, no a las antiguas que solo se corrigen mediante redirección.

Los datos estructurados, como Organization, LocalBusiness, FAQPage o Article según schema.org, rara vez se trasladan solos. Se generan de nuevo en la plantilla nueva y se comprueban con la prueba de resultados enriquecidos.

El lanzamiento es un proceso con puntos de control fijos, no pulsar un botón. La víspera, la tabla de mapeo está lista como reglas de redirección en el servidor o en el sistema y se ha probado en el staging contra cada URL antigua. El mismo día se activa primero la web nueva, después se retira el bloqueo de indexación y por último se comprueba. El orden es importante, porque ningún paso sustituye la comprobación del anterior.

El bloqueo es especialmente crítico. La protección por contraseña, la metaetiqueta noindex y la cabecera X-Robots-Tag deben desaparecer, y el robots.txt no debe excluir nada que deba indexarse. No lo compruebe en el back-end, sino en la dirección real: código fuente de la página de inicio, cabeceras de respuesta, robots.txt, inspección de URL en Search Console.

A continuación se envía el nuevo sitemap XML con las direcciones definitivas, no el antiguo. Muestras tomadas del mapeo confirman que las redirecciones llevan en un solo paso a un destino con 200. Las páginas más importantes se solicitan una a una para su indexación en Search Console.

Si el dominio sigue siendo el mismo, el relanzamiento es una reforma en la misma casa. Si cambia, por ejemplo por un cambio de nombre, es una mudanza a otra casa y el riesgo es claramente mayor. Además del mapeo de URL, hacen falta entonces redirecciones del dominio antiguo al nuevo, también para la variante con y sin www y para http y https.

En Search Console se dan de alta ambos dominios como propiedad y se utiliza la herramienta de cambio de dirección para el dominio antiguo. Las redirecciones deberían mantenerse al menos un año, mejor más tiempo, mientras haya enlaces o usuarios que sigan accediendo a la dirección antigua. Quien desactiva pronto el dominio antiguo corta señales que todavía están en camino.

Otros casos especiales son los sitios multilingües con hreflang, en los que cada versión de idioma debe enlazar correctamente con las demás, las URL con parámetros y las páginas de filtros, los archivos multimedia y PDF enlazados desde el exterior, así como los subdominios. También conviene revisar los servicios incrustados y los formularios, porque algunas fuentes importantes de consultas dependen de una dirección en la que nadie había pensado.

Otro obstáculo es el propio cambio de sistema. Los nuevos sistemas de gestión de contenidos suelen generar sus propios patrones de direcciones, añaden o eliminan barras finales, convierten las direcciones a minúsculas o sirven la misma página bajo varias rutas. Esto genera duplicados que Google tiene que fusionar con esfuerzo. Defina de antemano qué grafía es la válida y hágala cumplir mediante redirecciones y la etiqueta canonical.

También merece una revisión el contenido que solo se genera en el navegador mediante JavaScript. Si el nuevo sistema renderiza textos y enlaces solo en el cliente, un rastreador puede ver muy poco en la primera consulta. Comparar el código fuente con el resultado renderizado, por ejemplo con la inspección de URL de Search Console, muestra rápidamente si el contenido esencial llega de forma fiable.

Una recomendación sincera: si es posible, no combine el cambio de dominio, el cambio de sistema y la reestructuración completa del contenido en un solo paso. Cuantas menos variables cambien a la vez, con más claridad se podrán atribuir después las fluctuaciones.

Aquí no hay garantías, y quien las promete promete demasiado. Google tiene que volver a rastrear la nueva estructura, seguir las redirecciones y reevaluar las páginas. Según la experiencia, en los primeros días y semanas se producen fluctuaciones en posiciones y clics, incluso con una ejecución limpia. Es normal y no es motivo de pánico.

Lo decisivo es poner el movimiento en contexto. Un ligero sube y baja en búsquedas concretas es algo distinto de la caída de grupos enteros de páginas. Lo segundo apunta a un problema concreto que se puede encontrar en los datos: un área que no se indexa, un patrón de errores 404, una regla de redirección defectuosa.

Se mide con los informes de Search Console: estado de indexación, estadísticas de rastreo, errores 404, clics e impresiones en comparación con el periodo anterior al relanzamiento. Además, los registros del servidor muestran si Googlebot solicita las nuevas direcciones. Debería prever un periodo de varias semanas a pocos meses hasta que se obtenga una imagen estable.

Tiempos de carga mejores, una estructura limpia y contenidos más claros pueden llevar a una mejor visibilidad tras el relanzamiento. No es posible hacer promesas serias al respecto, porque intervienen la competencia y los algoritmos.

El principio más importante: un relanzamiento es un proyecto de migración con una parte de diseño, no al revés. Quien incorpora el SEO solo antes de la puesta en marcha ya solo puede rescatar. Quien lo incorpora al principio puede decidir qué se conserva y orientar la estructura de páginas hacia lo que los visitantes ya encuentran.

Segundo: conservar es una estrategia legítima. No todas las direcciones, títulos y textos tienen que ser nuevos. Lo que funciona bien en Google se mantiene intacto por ahora. Puede mejorarlo más adelante, en pequeños pasos, con una comparación limpia de antes y después.

Tercero: la documentación protege. La tabla de correspondencias, el rastreo del estado anterior y la lista de comprobación de la puesta en marcha no son burocracia, sino el archivo con el que, dentro de tres meses, podrá explicar por qué una página es distinta de antes. Así los errores se acotan rápidamente en lugar de buscar entre una niebla de suposiciones.

El miedo a perder posiciones es fundado, pero controlable. La mayoría de las pérdidas no se deben a lo nuevo, sino a lo que se pierde sin que nadie lo note: direcciones sin redirección, contenidos eliminados, bloqueos que se quedaron activos. Para eso existe un método que consta de inventario, correspondencias, comparación con el entorno de pruebas, lista de comprobación y seguimiento.

Por eso empezaríamos un relanzamiento así con el inventario, antes de que exista ningún diseño. El resultado es una base de decisión sobria: qué páginas sostienen el sitio y cuáles no, dónde tiene sentido una nueva estructura y dónde basta con un nuevo aspecto. Después se puede decir con honestidad cuál es el riesgo.

Un siguiente paso razonable es una revisión breve de su sitio web actual: rastreo, análisis de Search Console y una valoración de qué páginas merecen especial protección. De ahí se deduce si es necesario un relanzamiento, en qué alcance y con qué esfuerzo.