Cómo rediseñar tu sitio web sin perder tus rankings

Un rediseño de sitio web es como mudarte de casa: si empacas bien, todo llega intacto y nadie nota el camión. Si empacas mal, rompes los platos buenos y pasas seis meses buscando dónde quedó el abridor de latas. La diferencia entre las dos versiones no es el diseño nuevo — es la lista de ingeniería aburrida que nadie quiere hacer antes del lanzamiento. Aquí está esa lista, completa.

Inventario de URLs: no puedes redirigir lo que no sabes que existe

Antes de tocar una sola línea del sitio nuevo, saca un inventario completo de cada URL indexada del sitio actual — no las que crees que tienes, las que Google realmente tiene en su índice. Cruza Search Console, tu sitemap actual y un rastreo completo del sitio con una herramienta de crawling. Los tres van a diferir un poco, y esa diferencia es exactamente donde se esconden las URLs olvidadas que aun así traen tráfico.

Esto suena obvio hasta que encuentras una página de landing de una campaña de 2022 que nadie recuerda, con 40 backlinks apuntándole, silenciosamente enviando autoridad al sitio. Sin inventario, esa URL simplemente desaparece en el lanzamiento y esos 40 backlinks empiezan a apuntar al vacío.

El mapa de redirecciones 301, uno a uno

Cada URL del inventario necesita un destino específico en el sitio nuevo — no una redirección genérica a la página de inicio “porque ya vamos a arreglarlo después”. Una redirección 301 de URL vieja a página de inicio le dice a Google que la página de inicio es ahora la respuesta a todo, lo cual no es cierto para nadie, y diluye exactamente la señal que estabas tratando de conservar. Construye la tabla completa — URL vieja, URL nueva, tipo de redirección — antes del día del lanzamiento, no durante.

Un detalle que se pasa por alto seguido: si estás consolidando páginas de verdad porque el contenido se solapaba, redirige a la página nueva que mejor cubre ese tema específico, no a la categoría general que lo contiene. Google sigue tratando eso como una señal razonable de continuidad. Una redirección a un contenido que no responde la misma pregunta, en cambio, se trata más como una redirección rota que como una válida.

Paridad de contenido, no solo paridad de diseño

El rediseño es tentador como excusa para “limpiar” el texto — acortar párrafos, quitar secciones que a alguien del equipo le parecían anticuadas. Antes de recortar nada, compara cada página nueva contra su versión vieja tema por tema. Si una página vieja respondía diez preguntas específicas sobre un servicio y la nueva responde tres porque el diseño “se ve más limpio”, acabas de eliminar las razones por las que esa página posicionaba en primer lugar. El diseño limpio y el contenido completo no son opuestos — solo requieren más trabajo de maquetación para convivir.

Conserva títulos, metadatos y estructura de encabezados

Si una página ya posiciona bien, su title tag, su meta description y su jerarquía de encabezados (H1, H2, H3) ya están funcionando como señal para Google — no son solo copy, son parte de por qué esa URL gana. Un rediseño no es el momento de reescribirlos “porque el redactor nuevo tiene un estilo distinto”. Si de verdad necesitas reescribir alguno, hazlo como un cambio deliberado y monitoreado, no como un efecto secundario del trabajo de diseño de otra persona en el equipo.

Higiene de noindex en staging (y el desastre clásico)

Todo entorno de staging debe llevar una etiqueta noindex o estar bloqueado por autenticación antes de que exista una sola página real dentro. Esto suena elemental y aun así es, con diferencia, el error más caro que veo repetirse: alguien construye el sitio nuevo en staging, olvida el noindex, Google lo encuentra y lo indexa como contenido duplicado del sitio en producción — y ahora tienes dos versiones del mismo sitio compitiendo entre sí en los resultados de búsqueda, semanas antes de que planeabas lanzar nada.

La segunda mitad del desastre clásico es peor: el equipo termina el sitio en staging, hace el deploy a producción copiando la configuración completa — y se les olvida quitar el noindex del sitio nuevo en vivo. El lanzamiento sale perfecto visualmente y el tráfico orgánico se cae a cero en días, porque literalmente le estás pidiendo a Google que no indexe nada. Es la falla silenciosa más común en rediseños, precisamente porque el sitio se ve completamente normal para cualquier humano que lo visite.

Core Web Vitals como condición de victoria, no como detalle técnico

Un rediseño que se ve mejor pero carga más lento no es una mejora, es un intercambio, y casi siempre un mal intercambio. Antes de dar por bueno el sitio nuevo, mide Largest Contentful Paint, Interaction to Next Paint y Cumulative Layout Shift contra los números del sitio actual — no contra un estándar genérico de la industria, contra tu propia línea base. Si el sitio nuevo es más lento en cualquiera de los tres, ese es un defecto de lanzamiento, con la misma prioridad que un enlace roto, no un “lo optimizamos en la siguiente iteración”.

La analogía que uso con los clientes: rediseñar tu sitio y hacerlo más lento es como remodelar tu restaurante y quitar la puerta de entrada — se ve mejor por dentro, pero ahora cuesta más trabajo entrar, y suficiente gente simplemente no se molesta.

Monitoreo la semana del lanzamiento

La semana del lanzamiento no es cuando terminas el trabajo — es cuando empieza la parte que confirma si hiciste bien todo lo anterior. Revisa esto todos los días, no una vez a la semana:

• Cobertura de Search Console. Busca picos repentinos en “no indexada” o “redirigida” — señal temprana de que algo en el mapa de redirecciones o el noindex de staging salió mal.
• Errores de rastreo 404. Cualquier 404 nuevo en una URL que estaba en tu inventario original es una redirección que falta o que se rompió.
• Tráfico orgánico día a día, comparado contra la misma semana antes del lanzamiento — no contra el mes pasado, contra un período comparable reciente.
• Posiciones de tus keywords principales, para detectar una caída real versus la volatilidad normal que sigue a cualquier cambio grande de sitio.

Criterios de rollback: decide el umbral antes del lanzamiento, no durante el pánico

Antes del día del lanzamiento, acuerda por escrito qué caída de tráfico o de rankings activa un rollback al sitio anterior, y quién toma esa decisión. Decidir esto en medio de una caída real, con todo el equipo mirando un dashboard rojo, produce peores decisiones que decidirlo con calma una semana antes. Un umbral razonable para la mayoría de los negocios: si el tráfico orgánico cae más de un 20% frente a la línea base y no se explica por un error identificado y corregible en menos de 48 horas, es momento de hacer rollback mientras se investiga, no de esperar a ver si se recupera solo.

Un rollback bien planeado no es una derrota — es la razón por la que un rediseño con problemas cuesta días, no meses. La alternativa, sin plan de rollback, es descubrir el problema en producción y luego improvisar la solución en vivo, que es exactamente cuando se cometen los segundos errores.

Todo esto es la parte invisible de un buen rediseño — la que nadie felicita en la presentación final, pero la única que decide si el sitio nuevo hereda los años de trabajo del sitio viejo o los tira a la basura el día del lanzamiento. Si estás por rediseñar y quieres que alguien revise el mapa de redirecciones antes de que sea demasiado tarde para corregirlo barato, así es como lo hacemos en diseño web, siempre de la mano con SEO desde el primer día del proyecto, no como una revisión de última hora.