El rediseño se ve bien en staging. El viernes se publica. El lunes Search Console enseña un valle y ventas o leads que no cuadran. No es «el algoritmo». Es una migración que cambió URLs, títulos y plantillas sin un plan para migrar web sin perder SEO.
Google no premia el rediseño. Premia que la URL que ya tenía autoridad siga respondiendo, que el contenido no se haya diluido y que la página nueva no sea más lenta que la antigua. Si fallas una de las tres, el posicionamiento se mueve. A veces en días. A veces en las dos semanas siguientes, cuando el crawl termina de enterarse.
Este es el plan que usamos en Truman cuando un proyecto de desarrollo web implica cambiar dominio, CMS o plantilla. Redirects, indexación, Core Web Vitals y el checklist que miramos antes de tocar producción.
Por qué migrar web sin perder SEO no es un plugin de redirects
Un plugin de redirecciones es una herramienta, no un plan. El plan es saber, URL a URL, qué página antigua se convierte en cuál nueva, qué contenido se fusiona, qué se retira y qué se canibaliza si dos URLs nuevas pelean por la misma intención.
Hay tres migraciones que se venden igual y no lo son. Cambio de diseño en la misma URL. Cambio de CMS o de estructura. Cambio de dominio. La primera puede hacerse con un checklist corto si no tocas slugs. Las otras dos son un proyecto SEO con fecha, no un «detalle del lanzamiento».
Google documenta el traslado de sitios con y sin cambio de URL. La idea central no ha cambiado: 301, sitemap nuevo, Search Console y paciencia de crawl. Lo que sí ha cambiado es el peso de la experiencia de página. Una migración «correcta» en redirects y torpe en INP o LCP sigue perdiendo posiciones. El detalle de medición está en Core Web Vitals e INP.
301
Un redirect permanente por URL que se mueve. Cadenas, 302 «por si acaso» y reglas comodín a la home son la forma más rápida de tirar autoridad.
Fuente: documentación de Google Search Central sobre traslados de sitios
El mapa de URLs: lo que hay que hacer tres semanas antes
Tres semanas no es burocracia. Es el tiempo mínimo para exportar la web actual, cruzarla con Search Console y Analytics, y no redirigir a ciegas. Si lanzas el lunes y empiezas el mapa el viernes, estás improvisando.
Exporta todas las URLs indexables: páginas, posts, fichas, PDFs que posicionen, parámetros que Google esté tratando como canónicos. Quédate con las que tienen impresiones, clics o backlinks. El resto también se redirige, pero no con la misma urgencia de QA.
| Situación | Riesgo SEO | Qué hacer |
|---|---|---|
| Misma URL, mismo contenido, nueva plantilla | Bajo | Conservar title, H1 e intent; medir CWV antes y después |
| Slug nuevo, misma intención | Medio | 301 1:1, actualizar internos y sitemap el día D |
| Varias URLs viejas → una nueva | Medio-alto | Elegir canónica, 301 de todas, no dejar 404 «menores» |
| Cambio de dominio o de protocolo mal cerrado | Alto | 301 en servidor, Search Console de ambos, no 302 |
| Comodín a la home o 302 temporales | Crítico | Prohibido. Es borrar el mapa y fingir que no pasa nada |
El error clásico es redirigir todo lo que no encaja a la home. Google lo lee como soft-404 masivo. El usuario también: pedía un servicio y aterriza en un hero. Si una URL muere de verdad, 410 o 404 limpio después de un 301 a la página más cercana, no a la portada.
Otro error: cambiar slugs «porque quedan más limpios» el mismo día que cambias el diseño. Si no hay ganancia de negocio, no toques la URL. Un rediseño ya es suficiente variable. Sumar vanity slugs es pedir dos migraciones a la vez.
El día D: indexación, noindex y el orden que sí importa
El orden no es cosmética. Primero redirects en servidor. Después DNS o cutover. Después sitemap nuevo enviado. Después petición de recrawl de las URLs que mueven el negocio. Si publicas, «ya redirigiremos» y el sitemap viejo sigue vivo, estás pidiendo a Google que recuerde direcciones que ya no existen.
El noindex de staging es sagrado. El de producción, un accidente frecuente. Clonar la web, dejar el plugin de «no indexar» activo y publicar es una forma elegante de desaparecer. El día D tiene un responsable que comprueba: HTML servido, cabeceras, robots.txt y una URL de prueba en Inspección de URL.
Si mañana Search Console muestra 200 URLs 404, ¿tienes el mapa para saber cuáles importaban?
Contenido, CWV y lo que el rediseño se come sin querer
Una migración «técnica» perfecta puede perder SEO si el contenido útil baja de la primera pantalla o se sustituye por un claim vacío. Conserva la intención de las URLs que ya ranquean. Puedes reescribir. No puedes borrar el H1 que respondía la query y sustituirlo por una metáfora.
Core Web Vitals no se «optimizan después». Se miden en staging con datos de lab y se contrastan con el campo de la web vieja. Un LCP que pasa de 2,1 s a 4,8 s no es un detalle de frontend. Es una regresión de producto. En Truman no damos por cerrada una migración si las URLs de dinero empeoran el umbral bueno sin una razón escrita.
Internamente, actualiza los enlaces. Un 301 interno funciona; un sitio lleno de 301 internos es deuda. El menú, el footer, los módulos de casos y el blog tienen que apuntar ya a las URLs nuevas el día D. Los backlinks externos no los controlas: por eso el 301 tiene que ser limpio y permanente.
Tip técnico: no encadenes redirects
http → https → www → slug-nuevo es cuatro saltos para una página. Google sigue la cadena, pero pierdes presupuesto de crawl y das más superficie al error. La regla vieja apunta directo a la URL final canónica. Prueba con curl o con un crawler: un solo 301, un 200. Si ves 302, 307 o un bucle, no lances.
Cómo lo hacemos en proyectos que ya tenían tráfico
En Grupo Candela la web no era un folleto: era un grupo con varias líneas y URLs que ya trabajaban. El trabajo no fue «poner la marca nueva». Fue no romper el mapa de servicios mientras se reconstruía el frente. El rediseño se mide también por lo que no se cae.
En Clínica Eleya las fichas de tratamiento y el equipo son páginas de decisión, no decorado. Migrar una clínica sin conservar esas intenciones es perder las queries que traen cita. El plan parte de esas URLs, no de la home.
Si estás decidiendo si el rediseño va sobre WordPress o sobre código propio, esa decisión cambia el tipo de migración. El criterio está en WordPress frente a desarrollo a medida. Y si el board pregunta solo por el look, el marco para hablar de resultado está en cómo medir el ROI de un rediseño.
Una migración no se celebra el día del lanzamiento. Se celebra a las tres semanas, cuando las URLs que pagaban el tráfico siguen pagándolo. Si solo miras el diseño el viernes, estás jugando a la ruleta con años de Search Console.
Antes de migrar, verifica esto
- ¿Tienes inventario de URLs indexables cruzado con Search Console y backlinks?
- ¿Cada URL que se mueve tiene un 301 1:1 o una fusión consciente, nunca un comodín a la home?
- ¿Staging está noindex y producción, el día D, no hereda ese noindex?
- ¿El sitemap nuevo se envía el mismo día y el viejo deja de servirse?
- ¿Titles, H1 e intención de las 50 URLs críticas se han comparado uno a uno?
- ¿Los CWV de esas URLs no empeoran el umbral bueno sin una razón escrita?
- ¿Los enlaces internos del menú, footer y contenidos apuntan ya a la URL final?
- ¿Hay un responsable de cobertura y 404 en D+3, D+14 y D+30?
Preguntas frecuentes sobre migrar una web sin perder SEO
¿Cuánto tarda Google en reconocer una migración?
En sitios pequeños, días. En sitios con miles de URLs, semanas. No hay un botón de «aplicar migración». Hay crawl. Por eso el mapa 301 y el sitemap tienen que estar bien el día uno: cada recrawl en error retrasa la foto estable.
¿Se pierde siempre tráfico al rediseñar?
No. Se pierde cuando cambias URLs sin 301, cuando recortas el contenido que respondía la query o cuando la página nueva es claramente peor de usar. Un rediseño en las mismas URLs, con la misma intención y mejor CWV, no tiene por qué bajar. Si baja, casi nunca es «el rediseño»: es una de esas tres.
¿Hace falta un 301 aunque solo cambie el diseño?
Si la URL no cambia, no. El 301 es para recursos que se mueven. Lo que sí hace falta es no romper canonicals, no dejar noindex y no servir la misma intención en dos plantillas distintas durante el cutover.
¿Cuándo conviene cambiar de dominio y cuándo no?
Cambia de dominio cuando la marca lo exige de verdad (fusión, nombre nuevo, TLD que confunde). No lo hagas para «parecer más premium» el mismo mes del rediseño. Es la migración de más riesgo: dos propiedades en Search Console, backlinks que tardan y un periodo en el que parte del mundo sigue enlazando lo viejo.
