Cómo rediseñar tu sitio web sin perder SEO en Google

Checklist para rediseñar o migrar un sitio sin perder SEO: inventario de URLs, redirects 301, Search Console, paridad de contenido, CWV, staging y monitoreo post-lanzamiento.

Art Department

Portada: Rediseñar sin perder SEO — tipografía grande Rediseñar/sin perder/SEO, fases Antes Durante Después, isologo AD abajo a la izquierda, sin barra amarilla

Cómo rediseñar tu sitio web sin perder SEO en Google no es “cambiar el look y rezar”. Es un proyecto de producto + SEO: mismas (o mejores) URLs útiles, redirects permanentes donde haga falta, Search Console en orden, paridad de contenido y experiencia de página medible. Google documenta cómo mover un sitio con cambios de URL y deja claro que puede haber fluctuaciones temporales mientras recorre e indexa de nuevo. La buena noticia: un redirect permanente (301 o 308) no “quema” el PageRank por sí solo; el daño suele venir de inventarios incompletos, soft 404, noindex olvidados o landings que ya no responden la misma intención.

En ARTDEPARTMENT el rediseño se trata como migración controlada: checklist antes del go-live, staging que no se indexe, día de lanzamiento con dueños claros y monitoreo después. Esta nota es esa checklist, en español neutro, para equipos de marketing, producto y agencias en Argentina y LATAM.

Por qué un rediseño puede costar posiciones (y cómo no)

Un rediseño “solo visual” rara vez toca solo CSS. Cambia plantillas, rutas, CMS, menús, hreflang, canonicals, sitemaps, scripts de medición y a veces el hosting. Google resume el riesgo en una regla simple: cambiar una cosa a la vez cuando sea posible —dominio, CMS y layout no deberían pelearse el mismo día— y esperar fluctuación mientras el índice se actualiza (site moves).

Los fallos típicos que vemos en auditorías previas al lanzamiento:

  1. URLs que desaparecen sin 301 al destino equivalente (o con redirect a la home: soft 404).
  2. Contenido más fino en la URL que antes ganaba la consulta: menos respuesta, menos prueba, menos utilidad.
  3. Bloqueos de staging (noindex, robots.txt, auth) que se copian al entorno de producción.
  4. Canonicals y sitemaps que siguen apuntando al mundo viejo, o al nuevo con paths rotos.
  5. Experiencia de página peor (LCP, INP, CLS) en plantillas pesadas, justo cuando Google mide Core Web Vitals como parte de la experiencia de página.

Nada de esto se arregla con un plugin en verde el viernes previo al lanzamiento. Se arregla con inventario, mapa de redirects y pruebas.

Si todavía estás eligiendo quién hace el sitio, la matriz de alcance (incluido SEO técnico y migración) está en cómo elegir una agencia de diseño web. El mapa del canal orgánico, en qué es el SEO y cómo funciona en 2026.

El mapa en tres tiempos: antes, durante y después

Piensa el rediseño como una migración con tres fases. No hace falta que cambien todas las URLs: aunque mantengas paths, las plantillas nuevas pueden crear duplicados, parámetros o páginas vacías. El mismo checklist sirve para “solo look”, cambio de CMS o dominio nuevo.

Proceso de rediseño y migración SEO: antes (inventario y mapa), durante (staging y go-live) y después (monitoreo).

*Antes preparas el mapa; durante pruebas sin indexar de más; después monitoreas índice, errores y consultas. Rediseñar es producto + SEO.*

Antes: inventario, mapa y baseline

  • Inventario de URLs que importan (tráfico, conversiones, backlinks, sitemap).
  • Mapa viejo → nuevo (1:1 cuando exista equivalente; 404/410 cuando el contenido muere de verdad).
  • Propiedades verificadas en Search Console (variantes www/no-www, HTTP/HTTPS si aplica).
  • Baseline de rendimiento: consultas, páginas top, Core Web Vitals de campo si hay datos.
  • Decisión explícita: ¿cambian paths? ¿cambia dominio? ¿cambia solo el HTML?

Durante: staging, redirects y capacidad

  • Staging con noindex / auth / robots restringido —y un plan escrito para quitar esos bloqueos en producción.
  • Redirects permanentes server-side probados (idealmente sin cadenas largas).
  • Canonicals auto-referenciales en las URLs nuevas; internos actualizados al mundo nuevo.
  • Sitemap de URLs nuevas listo para enviar; capacidad de servidor para el pico de rastreo post-migración.

Después: monitoreo y paciencia operativa

  • Cobertura de índice, 404, soft 404 y errores de servidor en ambos mundos (viejo y nuevo).
  • Impresiones y clics por URL nueva vs. caída del viejo.
  • Ajustes de redirects mal mapeados en las primeras 2–8 semanas (sitios medianos suelen necesitar semanas; grandes, más —según Google).

Inventario de URLs: qué listar antes de tocar el diseño

Sin inventario no hay migración: hay esperanza. Google sugiere armar el listado a partir de sitemaps, logs, analytics, CMS y enlaces a tu sitio en Search Console. Incluye HTML, imágenes, PDFs, JS y CSS que reciban tráfico o enlaces: también se mueven.

Prioriza en cuatro capas:

  1. Dinero y leads: landings comerciales, pricing, contacto, demos, fichas que convierten.
  2. Demanda orgánica: URLs con impresiones/clics estables en Search Console (12–16 meses si hay estacionalidad).
  3. Autoridad entrante: páginas con backlinks externos (Links en Search Console).
  4. Operativas: legales, ayuda, blog evergreen, locales si aplica.

Para cada fila del inventario guarda: URL actual, estado HTTP, title/H1, intención, tráfico/conversión relativa, ¿existe equivalente en el sitio nuevo?, URL destino propuesta, tipo de redirect o 404/410, owner.

Regla de oro: no redirijas en masa a la home. Google advierte que muchos redirects irrelevantes a una sola URL confunden al usuario y pueden tratarse como soft 404. Si fusionas tres guías en una, las tres viejas pueden apuntar a la consolidada; si una URL muere sin equivalente, un 404 o 410 limpio es más honesto que un “todo a home”.

Redirects 301 (y 308): el puente, no el adorno

Para decirle a Google y a las personas que una URL se movió de forma permanente, la recomendación oficial es un redirect del lado del servidor: 301 o 308. Los temporales (302, etc.) no son el default de un rediseño definitivo.

Buenas prácticas que importan en go-live:

  • Directo al destino final. Googlebot puede seguir cadenas, pero la guía pide evitar hops innecesarios (idealmente ≤3, mejor 1).
  • Permanentes mientras haya tráfico. En site moves, Google pide mantener redirects el mayor tiempo posible, en general al menos un año.
  • Prueba masiva, no solo la home: scripts, crawlers o la herramienta de inspección de URL sobre una muestra representativa.
  • Misma intención. Un redirect de “precio” a “nosotros” no es migración: es pérdida de relevancia.

Si cambia el dominio o subdominio, además de los 301 usa la herramienta Cambio de dirección en Search Console después de tener redirects activos. No aplica a HTTP→HTTPS solo, ni a www↔no-www en el mismo dominio, ni a cambios de path dentro del mismo host: ahí el trabajo duro son redirects y canonicals.

Search Console: el panel del día D (y de las semanas siguientes)

Verifica todas las variantes relevantes (www, apex, http, https) del sitio viejo y del nuevo antes de mover. Revisa que el método de verificación siga vivo tras el cambio (archivo HTML, meta, Analytics, DNS). Google lista settings a rehacer en la propiedad nueva: tasa de rastreo en “dejar que Googlebot decida”, disavow si existía, limpieza de removals o acciones manuales heredadas en un dominio comprado.

En el día de corte:

  1. Activa redirects.
  2. Confirma canonicals y ausencia de noindex indeseado en producción.
  3. Envía el sitemap de URLs nuevas.
  4. Si aplica dominio nuevo: presenta Cambio de dirección desde la propiedad vieja.
  5. Mira Cobertura / páginas indexadas, Sitemaps y, en los días siguientes, consultas e impresiones.

Para una URL concreta, el flujo “rastreable → indexable → relevante” está en cómo posicionar una página en Google. En un rediseño multiplicas ese checklist por el inventario.

Paridad de contenido: el rediseño no puede vaciar la respuesta

SEO no es solo status code. Si la URL que respondía “cómo funciona X” pasa a un hero vacío y tres bullets de marketing, el índice puede conservar la URL y perder la consulta. Los fundamentos de Search y la guía de contenido útil, confiable y people-first empujan a páginas que ayudan de verdad: no a shells bonitos.

Checklist de paridad (viejo vs. nuevo) por URL clave:

  • ¿La intención principal sigue siendo la misma?
  • ¿El H1 y el primer bloque útil nombran el problema sin rodeos?
  • ¿Se conservan pruebas, datos, pasos, FAQs reales o se reemplazaron por eslóganes?
  • ¿Los módulos legales / confianza / precios que convertían siguen accesibles sin tres clics extra?
  • ¿Hay texto crítico solo en imagen o en un carousel no legible para el bot?

Mejorar el diseño y conservar (o mejorar) la utilidad es el objetivo. Recortar “porque el layout nuevo no tiene espacio” es una decisión de producto: trátala como tal, con owner y aceptación —no como efecto colateral del Figma.

Cuando midas el stack con IA (briefs, variantes, review humano), el checklist de IA en el stack de marketing 2026 ayuda a no generar 40 landings genéricas el mismo día del cutover.

Core Web Vitals y experiencia de página en el nuevo front

Un front nuevo puede lucir impecable en el notebook del diseñador y degradar LCP/INP/CLS en campo. Google recomienda buenos Core Web Vitals —LCP ≤ 2,5 s, INP < 200 ms, CLS ≤ 0,1— alineados con lo que los sistemas de ranking buscan recompensar en experiencia de página. Usa el informe de CWV en Search Console (datos reales) y laboratorios (Lighthouse / web.dev) para depurar; no sustituyas uno por el otro.

Antes del go-live:

  • Define un presupuesto de performance por plantilla (home, listing, ficha, blog, landing comercial).
  • Mide staging con dispositivos y redes realistas, no solo Wi‑Fi de oficina.
  • Cuidado con fuentes, carousels, embeds de terceros y JS que bloquea el LCP.
  • Si el hosting o el stack no dan margen, el cuello de botella puede ser infraestructura: en ese caso tiene sentido mirar opciones de hosting o WordPress administrado cuando la migración o los CWV lo pidan de forma natural —no como “pack” genérico.

Performance no reemplaza contenido útil; tampoco al revés. Ambos entran en el mismo go-live.

Riesgos de rastreo e índice (staging incluido)

Los errores clásicos que Google lista en troubleshooting de site moves:

  • Dejar noindex o robots.txt restrictivo en producción.
  • Redirects a URLs inexistentes (pico de 404).
  • Otros errores de cobertura que explotan en la semana del cutover.
  • Servidor sin capacidad para el rastreo extra (el viejo redirige + el nuevo se descubre).
  • Sitemaps desactualizados.

Staging seguro:

  • Auth básica o allowlist de IPs más noindex en HTML/headers mientras el entorno sea público por accidente.
  • robots.txt de staging que no sea el que irá a producción (ten el archivo “final” listo en el repo).
  • Nunca clonar producción a staging sin scrub de canonicals absolutos que apunten al dominio real indexable por error —o al revés.

Indexación prematura del staging compite contigo. Indexación bloqueada de producción te deja invisible. El runbook del lanzamiento debe tener una línea explícita: “quitar bloqueos de indexación en prod / confirmar 200 + indexable en muestra A”.

Día de lanzamiento: secuencia mínima

Orden sugerido (ajusta a tu stack):

  1. Congela contenidos críticos y confirma el mapa 301 firmado.
  2. Deploy a producción con canonicals, medición y formularios vivos.
  3. Enciende redirects del mundo viejo → nuevo.
  4. Smoke test: top 50 URLs de dinero, top 50 orgánicas, 20 assets, 10 404 esperados.
  5. Quita noindex / auth de prod si existían.
  6. Envía sitemap nuevo; presenta Cambio de dirección solo si cambió dominio/subdominio.
  7. Actualiza enlaces internos, campañas Ads, perfiles sociales y landings de email al path nuevo (menos hops = mejor UX y menos carga).
  8. Deja un canal de incidentes 48–72 h con dueño técnico y dueño SEO.

Si en paralelo sostienes demanda con pauta mientras el orgánico se reacomoda, el marco de cuándo combinar canales está en SEO o Google Ads. No es “Ads para rankear”: es continuidad comercial durante la recrawl.

Después del go-live: qué mirar (y por cuánto)

Monitorea viejo y nuevo. Lo saludable: tráfico y rastreo del viejo bajan; del nuevo, suben. En Search Console: Sitemaps (indexadas nuevas ↑), informe de páginas, errores 404/5xx, consultas con URLs nuevas. En analytics: landings, conversiones, embudos. En logs: Googlebot y códigos raros.

Paciencia operativa: Google indica que sitios medianos pueden tardar semanas (más si son grandes) en mostrar de forma estable las URLs nuevas. “Bajó todo el lunes” no prueba por sí solo un desastre; “404 en las 30 URLs que más convertían” sí exige hotfix el mismo día.

Semana 1–2: corrige redirects rotos, soft 404, bloqueos y titles claramente mal migrados.

Semana 3–8: consolida canibalizaciones nuevas, refuerza internos, recupera paridad de contenido donde el layout se quedó corto.

Mes 3+: evalúa si el rediseño mejoró tarea de usuario y descubribilidad; itera como producto, no como “fase SEO aparte”.

¿Cuándo pedir ayuda?

Pide ayuda externa cuando el inventario supera lo que el equipo puede mapear con rigor, cuando cambia CMS y dominio a la vez, cuando hay revenue claro atado a URLs orgánicas, o cuando ya sufriste un cutover fallido. Un partner útil aporta runbook, ownership de redirects y criterio de aceptación —no promesas de “recuperar el tráfico en 7 días”.

Para el trabajo de sitio y front, la landing comercial de diseño y desarrollo web describe el encaje de producto. Para el tramo de descubribilidad e índice, la landing comercial de SEO y posicionamiento web. Si el problema es operación continua (no solo el lanzamiento), el modelo liviano de acompañamiento está en qué es un growth partner.

Cierre: rediseño como sistema, no como screenshot

Un sitio nuevo que se ve bien y pierde el mapa de URLs no es un rediseño terminado: es una deuda. ARTDEPARTMENT lo aborda como sistema —inventario, 301, Console, paridad, CWV, staging, lanzamiento, monitoreo— porque el SEO vive en el HTML servido y en las decisiones de producto, no en un slide de “después hacemos SEO”.

Empieza por el inventario. Firma el mapa. Prueba los redirects. Mide el día después. El resto es disciplina.

Fuentes

Otras notas