Rediseñar un sitio web puede mejorar su comunicación, administración y experiencia de uso. También puede interrumpir consultas, eliminar páginas que recibían visitas o dejar la medición incompleta si el proyecto se trata solamente como un cambio visual.
El riesgo es mayor cuando la web ya está posicionada, recibe campañas, contiene documentos enlazados o utiliza formularios conectados con procesos comerciales. En esos casos, el punto de partida no debería ser elegir colores: primero hay que identificar qué activos deben conservarse, qué problemas necesitan solución y cómo se comprobará el resultado.
Un rediseño seguro no empieza borrando la web anterior: empieza entendiendo qué valor produce y qué piezas sostienen ese valor.
1. Definí qué debe mejorar y qué no se puede perder
Antes de diseñar pantallas, registrá una línea de base. No hace falta medir todo, pero sí aquello que permitirá comparar la versión anterior con la nueva.
- Objetivo principal: recibir consultas, presentar servicios, generar reservas, captar postulaciones o facilitar trámites.
- Páginas valiosas: URL con tráfico orgánico, enlaces externos, conversiones o información crítica.
- Acciones importantes: formularios enviados, clics de contacto, descargas, llamadas o solicitudes.
- Fuentes de tráfico: buscadores, anuncios, redes, directorios, campañas de correo o accesos directos.
- Problemas actuales: navegación confusa, edición difícil, lentitud, errores móviles, contenido desactualizado o baja accesibilidad.
Esta revisión ayuda a escribir un alcance verificable. “Modernizar la web” es ambiguo; “reducir pasos para consultar, conservar las páginas con tráfico y permitir que el equipo actualice servicios” orienta decisiones concretas.
2. Creá un inventario antes de modificar contenidos y URL
Prepará una planilla con las URL actuales y clasificá cada una: conservar, actualizar, combinar, redirigir o eliminar. Incluí páginas, imágenes importantes, archivos descargables y destinos utilizados por campañas.
Si una dirección cambia, debe existir una correspondencia lógica entre la URL antigua y la nueva. La guía oficial de Google Search Central sobre migraciones recomienda preparar ese mapa, actualizar enlaces internos, configurar redirecciones permanentes del lado del servidor y controlar el tráfico después del cambio.
No envíes todas las páginas eliminadas al inicio
Una redirección debe llevar a un contenido equivalente o claramente relacionado. Enviar decenas de páginas diferentes a la portada desorienta al visitante y no conserva necesariamente la intención de la URL anterior. Si no existe un reemplazo útil, corresponde evaluar una respuesta de página no encontrada en lugar de inventar una equivalencia.
Conservá también los componentes menos visibles
- Títulos y descripciones relevantes para buscadores.
- Etiquetas canónicas y, si corresponde, referencias entre idiomas.
- Datos estructurados que sigan siendo válidos.
- Archivos de verificación de servicios externos.
- Códigos de analítica, píxeles y medición de eventos.
- Integraciones de formularios, CRM, correo o automatizaciones.
3. Probá la nueva web como un sistema, no como una maqueta
La aprobación visual es solo una parte. Antes de publicar, la nueva versión debería funcionar en un entorno de prueba protegido de la indexación y ser revisada con dispositivos, navegadores y recorridos diferentes.
- Navegación: comprobar menús, buscador, enlaces, botones y páginas de error.
- Formularios: enviar casos reales de prueba y verificar recepción, validaciones, mensajes y registros.
- Contenido: revisar teléfonos, horarios, condiciones, responsables, descargas e información legal.
- SEO técnico: validar URL, títulos, descripciones, canónicas, sitemap y reglas de indexación.
- Analítica: confirmar que las visitas y acciones importantes llegan a la propiedad correcta.
- Accesibilidad: probar teclado, foco visible, etiquetas de campos, alternativas de imágenes, jerarquía y contraste.
- Rendimiento: comprobar páginas representativas, no solo la portada.
La Web Accessibility Initiative del W3C propone integrar la accesibilidad en todo el proceso, evaluar temprano y regularmente, asignar responsabilidades y sostener el seguimiento. Dejarla para la última revisión suele convertir problemas estructurales en correcciones costosas.
Para rendimiento, web.dev mantiene como referencias buenas un LCP de hasta 2,5 segundos, un INP de hasta 200 milisegundos y un CLS de hasta 0,1, evaluados en el percentil 75. Son referencias técnicas útiles, pero también conviene observar si las personas pueden leer, navegar y completar acciones sin bloqueos.
4. Prepará un lanzamiento reversible y controlado
Elegí una franja de menor actividad y definí responsables para contenido, infraestructura, formularios, analítica y control posterior. Si se modifica dominio, gestor de contenidos, estructura de URL y diseño, separar cambios cuando sea viable facilita detectar la causa de un problema.
Checklist para el día de publicación
- Generar una copia de seguridad verificable de archivos y datos.
- Confirmar que existe un procedimiento de reversión.
- Activar y probar las redirecciones previstas.
- Eliminar bloqueos de indexación utilizados solo durante el desarrollo.
- Revisar canónicas, enlaces internos y sitemap de la versión pública.
- Probar formularios desde conexiones y dispositivos reales.
- Controlar certificados, recursos, imágenes y descargas.
- Revisar en tiempo real visitas, eventos y errores del servidor.
- Registrar la fecha y los cambios incluidos en el lanzamiento.
Las anotaciones de Google Analytics 4 permiten marcar el lanzamiento en los informes. Esto ayuda a interpretar aumentos o caídas posteriores sin depender de la memoria del equipo.
5. Evaluá la nueva versión con datos y recorridos reales
Publicar no cierra el proyecto. Durante las primeras horas conviene comprobar disponibilidad, formularios y errores críticos. En los días siguientes, revisá indexación, tráfico, consultas y páginas de destino. Después, compará períodos equivalentes y contemplá estacionalidad, campañas activas y fluctuaciones normales.
Un control práctico puede dividirse así:
- Primer día: disponibilidad, formularios, analítica, errores y redirecciones prioritarias.
- Primera semana: rastreo, indexación, páginas 404, velocidad y comportamiento móvil.
- Primer mes: tráfico orgánico, acciones comerciales, calidad de consultas y páginas con variaciones relevantes.
No toda caída indica un problema técnico ni toda mejora visual produce mejores resultados. La evaluación debe relacionar datos con objetivos: una web puede recibir menos visitas irrelevantes y generar más consultas adecuadas, o puede cargar rápido y aun así explicar mal la propuesta.
Conclusión: convertí el rediseño en un proyecto de continuidad
Antes de contratar o iniciar el trabajo, reuní cuatro elementos: objetivos medibles, inventario de URL, lista de integraciones y criterios de aceptación. Con esa base será más fácil estimar el alcance, evitar pérdidas y decidir qué debe conservarse, corregirse o reconstruirse.
Si necesitás renovar una web existente con planificación de estructura, contenido, desarrollo y publicación, podés consultar los planes de sitios web de Ideasweb. El primer paso debería ser relevar la situación actual, no reemplazarla a ciegas.
