Cómo rediseñar una web sin perder SEO, tráfico ni contactos: checklist de migración

Primero, clasifica el cambio: no todos los rediseños son una migración

Cambiar tipografía y componentes manteniendo URLs, contenido y plataforma no tiene el mismo riesgo que sustituir el CMS, reorganizar servicios o mover el dominio. Cuantas más capas cambien a la vez, más difícil será atribuir una caída y revertirla. Conviene separar cuatro decisiones: interfaz, tecnología, arquitectura de información y dominio o protocolo.

Antes: crea una línea base de descubrimiento y captación

El inventario no debe salir solo del sitemap. Un sitemap puede omitir páginas antiguas que todavía reciben visitas o enlaces.

1. 01

   Une las fuentes de URLs

   Combina un rastreo del sitio, sitemaps, informes de indexación y rendimiento de Search Console, páginas de entrada de analítica, URLs enlazadas desde campañas y backlinks importantes. Conserva también PDFs, imágenes y otros activos con demanda propia.

2. 02

   Guarda la evidencia editorial

   Para cada página relevante registra title, descripción, H1, texto principal, datos estructurados, canonical, status, enlaces internos y propósito de búsqueda. No hace falta congelar errores, pero sí entender qué elemento satisface hoy la consulta.

3. 03

   Documenta la captación completa

   Lista formularios, teléfonos, correos, reservas, descargas y CTA. Sigue cada formulario desde la página hasta el destino final: validación, endpoint, bandeja o CRM, aviso, consentimiento y evento analítico.

4. 04

   Fija una referencia medible

   Anota por URL consultas, clics y páginas de entrada con un periodo comparable, además de envíos válidos y errores conocidos. Segmenta marca y no marca cuando ayude. La línea base sirve para diagnosticar; no convierte una correlación posterior en causalidad.

La revisión de páginas que ya atraen intención comercial complementa la guía sobre cómo una web para pymes convierte visitas en conversaciones útiles. El rediseño debe preservar esa función, aunque cambie su presentación.

Convierte el inventario en un registro de migración

La hoja decisiva no es una lista de redirecciones escrita al final. Es un registro compartido que obliga a decidir el destino de cada URL antes de borrar contenido. Añade propietario y estado de validación para que una decisión editorial no quede escondida dentro de una tarea técnica.

• Conservar cuando la URL y su intención siguen siendo válidas; una plantilla nueva no exige una dirección nueva.
• Consolidar solo si existe un destino que responde sustancialmente a la misma necesidad. No redirijas todas las páginas eliminadas a la portada.
• Retirar cuando no hay sustituto honesto. Una respuesta 404 o 410 intencional es más clara que una redirección irrelevante.

Durante: implementa señales coherentes, no parches aislados

• Redirecciones: usa 301 o 308 permanentes del origen al destino final, evita cadenas y bucles, y prueba variantes con parámetros o barras cuando existan. Google recomienda mantenerlas generalmente al menos un año; operativamente pueden conservarse más si siguen recibiendo tráfico o enlaces.
• Canonicals: apunta cada página indexable a su versión preferida real. Un canonical no sustituye una redirección cuando una URL ha cambiado ni corrige destinos contradictorios.
• Navegación y enlaces: actualiza menús, breadcrumbs, enlaces dentro del contenido, hreflang si existe y referencias a assets. No obligues a usuarios y rastreadores a pasar por URLs antiguas.
• Rastreo e indexación: revisa robots.txt, meta robots, cabeceras X-Robots-Tag y autenticación. Staging debe estar protegido; producción no puede heredar un noindex temporal.
• Tracking: conserva identificadores y consentimiento cuando corresponda, vuelve a configurar eventos y evita duplicar pageviews en aplicaciones con navegación cliente.

Rastrea staging como si fueras un usuario anónimo y compara el resultado con el registro. Comprueba status HTTP, destino canonical, texto renderizado, title, H1, enlaces, imágenes, datos estructurados y profundidad de navegación. Después repite sobre la compilación candidata, porque variables y reglas del entorno pueden cambiar el resultado.

Prueba contactos como una cadena de entrega, no como un botón

El navegador puede mostrar «enviado» aunque el mensaje nunca llegue a la persona que debe responder. También puede llegar el lead y faltar el evento de analítica. Son tres resultados independientes: experiencia visible, entrega operativa y medición.

1. 01

   Define casos de prueba

   Incluye envío válido, campos vacíos, formato incorrecto, adjunto cuando exista, duplicado, fallo del servidor, límite de frecuencia y móvil. Usa datos de prueba identificables y elimínalos después según el procedimiento interno.

2. 02

   Verifica el destino

   Confirma que el registro llega una sola vez a la bandeja, CRM o sistema acordado, con fuente, página, consentimiento y campos íntegros. Prueba avisos y la ruta de escalado si el destino no responde.

3. 03

   Verifica la respuesta al usuario

   El mensaje de éxito solo debe mostrarse tras una aceptación real del backend. Los errores deben permitir corregir o reintentar sin perder lo escrito y sin exponer detalles internos.

4. 04

   Verifica la medición

   Dispara el evento después del éxito confirmado, no con el clic. Revisa nombre, parámetros, consentimiento y ausencia de duplicados en la herramienta analítica.

Lanzamiento: asigna responsables, ventana y reversión

1. Congela cambios editoriales durante la ventana y guarda una copia recuperable de código, base de datos, medios, configuración DNS y reglas de redirección según la plataforma.
2. Nombra a una persona para publicar y a responsables distintos para validar SEO técnico, contenido, formularios y analítica. Cada control necesita resultado y hora, no un «parece bien» en un chat.
3. Publica en un periodo que permita observar y corregir. Comprueba primero portada, servicios, páginas con demanda, rutas de contacto y plantillas compartidas; después recorre el inventario completo.
4. Define criterios de rollback antes de empezar: qué fallo lo activa, quién decide y cómo se preservan los contactos recibidos mientras se revierte.

La herramienta de cambio de dirección de Search Console procede cuando el sitio se mueve de un dominio o subdominio a otro. No es necesaria para un simple cambio de diseño o de rutas dentro del mismo dominio. En cualquier caso, verifica las propiedades relevantes y conserva acceso a la infraestructura anterior.

Después: monitoriza señales que permitan actuar

Envía un sitemap con URLs canónicas actuales y usa la inspección de URL para muestras prioritarias; no solicites indexación manual de cientos de páginas. Revisa a diario al principio y espacia el control cuando las señales se estabilicen. Las comparaciones deben considerar estacionalidad, campañas y cambios de demanda, no solo dos totales consecutivos.

Mantén el registro de migración dentro del plan de mantenimiento de la página web y define quién revisará Search Console, formularios, backups y dependencias después del periodo intensivo. El lanzamiento no elimina esa responsabilidad.

Qué NO debe cambiarse simplemente porque el diseño sea nuevo

Un rediseño es una oportunidad para corregir problemas, no una licencia para borrar decisiones que ya cumplen una función. Cada cambio adicional necesita una hipótesis, evidencia y forma de comprobarla.

• URLs que describen bien el recurso y conservan demanda, solo para hacerlas «más limpias».
• El propósito, contenido sustantivo, title o H1 de una página que responde bien, sin investigar antes las consultas y necesidades que cubre.
• Arquitectura, breadcrumbs y enlaces internos útiles, solo para reducir el número de elementos visuales.
• Datos estructurados válidos, información empresarial y señales de confianza que el nuevo componente no haya previsto.
• CTA, campos, reglas de validación, destinatarios y rutas de seguimiento sin implicar a las personas que atienden los contactos.
• Identificadores de analítica, consentimiento, nombres de eventos y destinos de campañas sin un plan de continuidad y pruebas.