No rediseñes una web solo porque parece antigua, porque a alguien de la empresa no le gusta o porque una agencia ha enseñado una maqueta atractiva. Rediseña cuando puedas demostrar qué problema de negocio, experiencia o tecnología necesita resolverse, qué parte de la web ya funciona y cómo comprobarás el resultado después.
La decisión útil no es «web vieja frente a web nueva». Es elegir entre cuatro movimientos: mantener, corregir, rediseñar o reconstruir. Cada uno tiene un coste y un riesgo diferentes. Si no existe una línea base, cualquier cambio posterior puede parecer un éxito o un fracaso según la métrica que se elija.
Puedes descargar el checklist de auditoría antes de rediseñar. Es un CSV abierto para Excel o Google Sheets. Incluye la prueba, la evidencia mínima, la decisión cuando falla, el responsable, el estado y la fecha. No pide correo y no contiene datos de clientes.
Esta guía aplica dos señales expertas como hipótesis de trabajo, no como autoridad automática. Peep Laja, fundador de CXL, defiende investigar conversión antes de un rediseño radical en Website Redesign for Higher Conversions? Tread Lightly. Aleyda Solís explica que una migración compleja requiere criterios, pasos y herramientas en How to win SEO in complex web migrations scenarios. YAG cruza ambas ideas con documentación primaria de Google, W3C y web.dev, y las convierte en un proceso que termina en una decisión verificable.
La respuesta corta: el rediseño es una decisión, no el punto de partida
Empieza por una auditoría pequeña que responda seis preguntas:
- ¿Qué acciones de negocio debe facilitar la web?
- ¿Qué páginas atraen demanda, enlaces o visitas cualificadas?
- ¿Dónde se pierde la persona antes de contactar, reservar o comprar?
- ¿Qué problemas afectan a móvil, accesibilidad, velocidad o mantenimiento?
- ¿Qué elementos deben conservarse porque ya cumplen su función?
- ¿Qué cambio mínimo permite aprender sin arriesgar todo el sitio?
Si la web recibe visitas pero el teléfono, el formulario y las reservas no se miden, el primer trabajo no es dibujar una home. Es reparar la medición y comprobar la entrega. Si una sola página concentra el problema, corrige esa página. Si la arquitectura impide explicar el catálogo real o la tecnología ya no permite trabajar con seguridad, entonces un rediseño o una reconstrucción tienen sentido.
Este enfoque evita dos errores opuestos. El primero es mantener durante años una web que bloquea el negocio porque «todavía funciona». El segundo es sustituirla entera sin saber qué se estaba tirando. Una auditoría previa no busca defender la web antigua. Busca proteger información, demanda y recorridos que costaron tiempo o dinero.
Paso 1: define qué significa que la web funcione
Una web de servicios no vende de la misma forma que una tienda. Una clínica puede necesitar una solicitud de cita. Un despacho puede valorar una consulta cualificada. Una empresa industrial puede necesitar que un comprador descargue una ficha y pida una reunión. El rediseño debe empezar con esa acción, no con una paleta de colores.
Escribe una frase que pueda comprobarse: «Una persona que entra buscando el servicio X debe entender para quién es, contrastar pruebas, conocer el siguiente paso y completar una consulta desde móvil». Después asigna una evidencia a cada parte.
| Pregunta | Evidencia posible | Lo que no demuestra |
|---|---|---|
| ¿Nos encuentran? | Search Console, consultas, páginas de entrada | Que la visita sea cualificada |
| ¿Entienden la propuesta? | Pruebas con usuarios, consultas comerciales, grabaciones consentidas | Que vayan a contratar |
| ¿Pueden actuar? | Envío real de formulario, llamada, reserva o compra de prueba | Que el lead tenga valor |
| ¿Medimos la acción? | Evento, registro en CRM, correo entregado | Que la atribución sea perfecta |
| ¿La web responde bien? | Datos de campo, navegador móvil, logs | Que una mejora técnica aumente ventas |
No sumes estas capas en una puntuación opaca. Una visita no es un contacto y un contacto no es una venta. Si falta la unión entre analítica y CRM, el resultado comercial es desconocido, no cero.
Antes de contratar diseño, acuerda también las restricciones: páginas que no pueden desaparecer, campañas que dependen de una URL, formularios conectados a sistemas internos, idiomas, accesibilidad, propiedad del dominio y fecha máxima de lanzamiento. Las restricciones tardías son una fuente habitual de sobrecoste.
Paso 2: audita claridad, confianza, fricción y acción
La conversión no se arregla colocando un botón más grande en todas las páginas. CXL propone combinar análisis heurístico, investigación cualitativa, pruebas con usuarios, comportamiento y analítica. Para una pyme no hace falta montar un laboratorio. Hace falta observar con disciplina y no convertir una opinión interna en una verdad sobre el cliente.
Revisa las páginas prioritarias con cuatro lentes.
Claridad
Una persona debe poder responder, sin abrir cinco pestañas, qué ofrece la empresa, para quién, en qué zona, qué problema resuelve y cuál es el siguiente paso. La claridad no exige frases infantiles. Exige reducir ambigüedad.
Comprueba el primer bloque en móvil y escritorio. ¿El titular identifica el servicio o se limita a una frase de marca? ¿La explicación diferencia la empresa? ¿El CTA describe una acción concreta? ¿Los términos que usa ventas coinciden con los que usa la web? Anota la duda exacta, no «el copy no convence».
Confianza
La confianza procede de elementos que se pueden contrastar: proyectos públicos, equipo identificable, procesos, condiciones, fechas, dirección cuando existe, propiedad de las cuentas y límites del servicio. Logos sin contexto, reseñas anónimas y cifras sin fuente pueden producir el efecto contrario.
Pregunta al equipo comercial qué dudas se repiten antes de contratar. Si siempre preguntan quién será dueño del dominio, cuánto tarda el proyecto o qué ocurre con el SEO, la web debe responderlo antes del formulario. Esa respuesta puede evitar un rediseño completo: a veces falta información, no una interfaz nueva.
Fricción
Recorre la tarea principal con una mano y una conexión móvil normal. Comprueba si hay elementos flotantes que cubren campos, menús que no cierran, validaciones que borran datos, textos que obligan a ampliar, PDFs imposibles de leer y pasos que piden información antes de explicar el valor.
La prueba debe incluir el estado de error y el de confirmación. Un formulario que muestra «enviado» pero no entrega el correo es una pérdida comercial. Una llamada que no conserva la página de origen limita el diagnóstico. Un enlace de WhatsApp sin contexto obliga a la persona a repetir todo lo que estaba leyendo.
Acción
Cada página necesita una acción principal coherente con su intención. Un artículo puede llevar a una guía, un recurso o una página de servicio. Una landing comercial debe permitir hablar del proyecto sin enviar a la persona por un laberinto. Ofrecer cinco CTA con el mismo peso no añade opciones: añade competencia interna.
Paso 3: construye una línea base SEO por URL
Google procesa páginas y URLs, no la idea abstracta de «la web». Antes de mover una ruta, necesitas saber qué señales conserva y qué destino será realmente equivalente.
Exporta al menos:
- URLs con impresiones, clics y consultas durante una ventana suficiente.
- Páginas de entrada y acciones de negocio, si la analítica es legible.
- Enlaces externos que apuntan a URLs concretas.
- Estado indexable, canonical, title, description y H1.
- Enlaces internos hacia cada página prioritaria.
- Recursos descargables, imágenes o documentos que reciben visitas o enlaces.
- Campañas, perfiles y directorios que usan URLs antiguas.
No elimines una página solo porque tuvo pocos clics en el último mes. Puede tener estacionalidad, enlaces, utilidad contractual o una consulta muy específica. Tampoco conserves todas por miedo. La decisión correcta se toma URL por URL: mantener, mejorar, consolidar con un equivalente, retirar con un estado correcto o dejar fuera de índice por una razón documentada.
La documentación de Google sobre movimientos de sitio con cambios de URL recomienda preparar el sitio nuevo, probarlo, crear el mapeo de URLs, activar redirecciones y vigilar el tráfico antiguo y nuevo. También aconseja cambiar una cosa cada vez cuando sea posible. Una redirección masiva de todo hacia la home no es un mapa de migración y puede terminar tratada como un error blando.
Si la URL no cambia, una redirección no es necesaria. Si cambia, el destino debe responder a la misma necesidad o a una consolidación defendible. Después hay que actualizar canonical, enlaces internos, sitemap, anuncios, perfiles y enlaces de alto volumen que estén bajo control de la empresa.
Paso 4: comprueba rendimiento, móvil y accesibilidad antes de diseñar
Una captura de PageSpeed no describe por sí sola la experiencia de negocio. Google define los Core Web Vitals actuales como LCP para carga, INP para respuesta y CLS para estabilidad visual. Sus umbrales recomendados son LCP de 2,5 segundos o menos, INP de 200 milisegundos o menos y CLS de 0,1 o menos, evaluados en el percentil 75 cuando hay datos de campo suficientes. Puedes revisar la definición vigente en Core Web Vitals de Google Search Central.
Guarda la línea base por tipo de página y dispositivo. Una home rápida no compensa un formulario lento o un checkout inestable. Distingue datos de usuarios reales y prueba de laboratorio. Si no hay tráfico suficiente para datos de campo, la ausencia de métricas no significa que la página sea rápida.
web.dev recomienda relacionar velocidad y métricas de negocio mediante medición y experimentos, no asumir causalidad por una correlación general. Su guía Relating site speed and business metrics explica cómo conectar rendimiento con resultados propios. En un rediseño, la pregunta útil es si la nueva versión mejora o degrada el recorrido principal en condiciones comparables.
La accesibilidad tampoco es un control final. W3C propone integrarla durante planificación, implementación y seguimiento en Planning and Managing Web Accessibility. Prueba teclado, foco, labels, contraste, mensajes de error, tamaño de objetivos táctiles, orden de lectura y adaptación a varios anchos. Las herramientas automáticas detectan una parte de los problemas; no sustituyen una revisión manual ni pruebas con personas.
Paso 5: decide entre corregir, rediseñar o reconstruir
Con la evidencia reunida, clasifica el movimiento. Esta matriz no es una fórmula automática, pero evita que «hacer una web nueva» sea la respuesta a cualquier problema.
| Situación observada | Movimiento inicial | Por qué |
|---|---|---|
| Mensaje confuso en una o dos páginas | Corregir contenido y recorrido | Permite aprender sin alterar todo el sitio |
| Formularios o medición fallan | Reparar entrega e instrumentación | Sin línea base no se puede evaluar el rediseño |
| Móvil tiene fricción localizada | Corregir componente y probar | El problema puede no ser estructural |
| Arquitectura no representa servicios actuales | Rediseñar información y navegación | La estructura limita claridad y descubrimiento |
| CMS sin soporte o deuda técnica grave | Reconstruir con migración controlada | El riesgo técnico no se resuelve con una capa visual |
| Dominio o marca cambian | Migración específica | Requiere inventario, mapeo, comunicación y seguimiento |
| Todo cambia a la vez por obligación | Programa por fases y rollback | Reduce causas y protege continuidad |
Un rediseño incremental suele ser preferible cuando la base funciona, hay usuarios recurrentes y se pueden aislar cambios. Un rediseño más amplio tiene sentido cuando la tecnología, la arquitectura y la propuesta están bloqueando objetivos que no pueden alcanzarse con ajustes razonables.
La decisión debe incluir una condición de parada. Por ejemplo: «No se aprueba el desarrollo completo hasta que el prototipo permita completar las tres tareas prioritarias sin bloqueos». O: «No se publica si el mapa de URLs prioritarias, los formularios y el rollback no están verificados». Sin criterios de salida, el calendario acaba imponiéndose a la calidad.
Paso 6: convierte el presupuesto en un contrato de resultado verificable
Un presupuesto útil no vende «diseño premium» como una caja negra. Explica qué se investiga, qué se entrega, qué queda fuera y cómo se aprueba.
Pide que se separen estas partidas:
- Diagnóstico de objetivos, usuarios, contenido y tecnología.
- Arquitectura de información y recorridos prioritarios.
- Contenidos que se mantienen, reescriben, consolidan o crean.
- Diseño de componentes y estados, incluidos móvil y errores.
- Desarrollo, integraciones y dependencias de terceros.
- Migración de URLs, contenido, archivos y datos.
- Analítica, consentimiento y eventos acordados.
- Rendimiento, accesibilidad y seguridad dentro del alcance.
- Pruebas, aceptación, backup, publicación y rollback.
- Propiedad, documentación, mantenimiento y soporte posterior.
También deben aparecer las exclusiones. «SEO incluido» no explica si habrá inventario de URLs, redirecciones, Search Console, datos estructurados o seguimiento. «Responsive» no explica qué dispositivos y recorridos se probarán. «Analítica» no explica si solo se inserta una etiqueta o si se verifica un evento y su destino.
Para comparar rangos de proyecto sin convertir esta guía en otra página de precios, consulta cuánto cuesta una web para empresa en Madrid. La página comercial de diseño web en Madrid explica el servicio, los modelos de alcance y el proceso de YAG. Esta guía conserva una intención distinta: decidir qué necesita tu web antes de pedir un presupuesto.
Paso 7: prepara la migración antes de tocar producción
El plan de migración debe existir antes del lanzamiento. Como mínimo incluye inventario, responsables, backup, mapa de URLs, pruebas, comunicación, ventana de publicación y rollback.
Antes del lanzamiento
- Congela el inventario de URLs y contenido prioritario.
- Decide qué métricas forman la línea base y guarda la fecha máxima disponible.
- Verifica que el entorno de prueba no sea indexable, sin bloquear la futura configuración de producción.
- Prueba formularios, reservas, pagos, llamadas y correos con destinos controlados.
- Valida enlaces internos, canonical, sitemap, datos estructurados y estados HTTP.
- Revisa recursos, imágenes, PDFs y metadatos sociales.
- Ejecuta pruebas móviles, accesibilidad y rendimiento en páginas representativas.
- Prepara backup y procedimiento de restauración que otra persona pueda seguir.
El día de publicación
- Comprueba que la versión aprobada es la que se va a desplegar.
- Activa redirecciones y verifica una muestra crítica antes de abrir tráfico.
- Retira bloqueos de indexación que solo correspondían al entorno de prueba.
- Prueba la acción de negocio en producción y confirma su entrega.
- Comprueba analítica y consentimiento sin generar contactos falsos.
- Envía el sitemap actualizado cuando corresponda.
- Vigila errores del servidor, 404, recursos y capacidad.
Después
- Mantén las redirecciones permanentes y actualiza enlaces bajo tu control.
- Compara páginas, consultas y acciones con ventanas equivalentes.
- Separa oscilaciones temporales de fallos reproducibles.
- Corrige primero bloqueos de rastreo, entrega o medición.
- Documenta cada intervención para no atribuir el resultado a una sola causa.
Si necesitas configurar la propiedad y el sitemap, consulta cómo dar de alta una web en Google Search Console. Enviar un sitemap ayuda al descubrimiento, pero no garantiza indexación ni posiciones.
Paso 8: mide a 14, 28 y 56 días sin inventar causalidad
El control del lanzamiento empieza en minutos, pero el efecto SEO necesita tiempo y ventanas comparables. Usa tres revisiones con objetivos diferentes.
Día 14: disponibilidad y regresiones
Comprueba URLs críticas, formularios, eventos, redirecciones, canonical, sitemap, errores, consultas tempranas y páginas de entrada. La prioridad es detectar algo roto. Una subida o bajada aislada no demuestra todavía el efecto del rediseño.
Día 28: recorrido y cobertura
Revisa si las personas completan la acción principal, si existen pérdidas por dispositivo, si Google está procesando las URLs y si las consultas siguen llegando a la página correcta. Investiga canibalización o destinos inesperados antes de crear contenido nuevo.
Día 56: decisión de negocio
Compara periodos equivalentes y segmenta marca y no marca, móvil y escritorio, página y consulta. Si existen datos de negocio, une sesiones con contactos válidos y oportunidades. Si no existe esa unión, declara el límite. La decisión puede ser continuar, corregir o revertir una parte, no «esperar porque el diseño es nuevo».
Evita dos atajos. El primero es atribuir cualquier crecimiento al rediseño aunque hayan cambiado campañas, estacionalidad o demanda. El segundo es exigir que toda mejora sea visible en ranking para considerar útil una corrección de accesibilidad, entrega o seguridad.
Qué aplicó YAG antes de publicar esta guía
Este método se utilizó sobre el propio clúster de diseño web de YAG antes de reescribir el artículo. La comprobación produjo tres decisiones concretas.
Primera: conservar intacta la intención principal de /diseno-web-madrid/. Los datos vivos de Search Console mostraron que la demanda comercial llega a esa landing, incluida una consulta de precios situada mucho más cerca de la primera página que las variantes generales. Crear otro artículo orientado a «precios de diseño web Madrid» habría competido con la URL que ya concentra esa intención.
Segunda: actualizar esta URL en lugar de crear una nueva. La versión anterior no recibió impresiones en la ventana observada, mezclaba Madrid y Tenerife, incluía ejemplos y cifras sin evidencia trazable y convertía recomendaciones generales en reglas absolutas. Se conservaron slug y portada local para no introducir una migración innecesaria, pero se retiraron las afirmaciones no demostrables.
Tercera: aportar una herramienta original. El checklist descargable obliga a asignar evidencia, responsable, estado y fecha a cada prueba. No garantiza que el rediseño mejore posiciones o contactos. Sí hace más difícil publicar sin saber qué se debía conservar y qué debe verificarse después.
La fuente experta permanece como Pilar 2: sirve para descubrir y contrastar hipótesis. Las reglas de migración proceden de documentación oficial, y la decisión de YAG procede de datos propios. Ninguna de esas capas sustituye a las demás.
Checklist final para decidir esta semana
Si solo tienes una hora, haz estas diez pruebas:
- Completa la acción principal desde un móvil sin ayuda.
- Confirma que el contacto llega al destino correcto.
- Identifica las cinco páginas con más demanda orgánica.
- Anota qué consulta responde cada página prioritaria.
- Revisa qué dudas repite ventas antes de cerrar.
- Comprueba teclado, foco, labels, contraste y errores.
- Guarda una línea base de rendimiento y acciones.
- Decide qué URLs y contenidos no pueden perderse.
- Clasifica cada problema como ajuste, rediseño o reconstrucción.
- Pide un alcance que incluya pruebas, propiedad y rollback.
Si no puedes completar los puntos 2, 3, 7 y 8, todavía no estás preparado para publicar una web nueva. Estás preparado para diagnosticar. Esa es una buena noticia: corregir el orden cuesta menos que recuperar demanda, datos o contactos después.
Puedes usar el checklist descargable como documento de trabajo y visitar diseño web en Madrid cuando tengas claro si necesitas un ajuste, un rediseño o una reconstrucción. Si prefieres que revisemos el caso contigo, envía el dominio y el objetivo desde contacto. La primera decisión debe ser qué problema merece inversión, no qué plantilla parece más nueva.
Respuesta directa
Preguntas frecuentes sobre este tema
¿Cómo sé si mi web necesita un rediseño completo?
Necesitas un rediseño completo cuando varios problemas estructurales se acumulan y no pueden resolverse con cambios aislados: tecnología sin soporte, navegación que no admite el catálogo real, experiencia móvil deficiente, medición rota y una propuesta que ya no representa el negocio. Si el problema está concentrado en una página, un formulario o el mensaje, suele ser más seguro corregir esa parte y medir antes de rehacerlo todo.
¿Qué debo medir antes de rediseñar una web?
Como mínimo, páginas de entrada, consultas orgánicas por URL, acciones de negocio, formularios entregados, llamadas o reservas, recorridos móviles, rendimiento de campo y páginas con enlaces externos. La línea base debe conservar fuente, periodo y limitaciones para poder comparar después del lanzamiento.
¿Un rediseño mejora automáticamente la conversión?
No. Un aspecto más actual no demuestra que más personas contacten o compren. El rediseño debe responder a problemas observados, conservar lo que ya funciona y definir una acción principal medible. Cuando hay tráfico suficiente, conviene comparar cambios de forma incremental o mediante un experimento controlado.
¿Cómo evito perder posicionamiento al cambiar URLs?
Inventaría las URLs actuales, identifica cuáles reciben impresiones, clics o enlaces, asigna un destino equivalente a cada URL que cambie e implementa redirecciones permanentes. Después actualiza enlaces internos, canonical y sitemap, prueba las redirecciones y vigila rastreo, indexación y consultas durante varias semanas.
¿Debo cambiar diseño, CMS, hosting y dominio a la vez?
No es lo recomendable. Separar cambios reduce el número de causas posibles si algo falla. Google aconseja cambiar una cosa cada vez cuando sea viable. Si el proyecto obliga a combinar cambios, el inventario, el backup, el mapa de URLs, las pruebas y el rollback deben ser mucho más estrictos.
¿Cuánto tiempo debo vigilar una web después del rediseño?
La comprobación técnica empieza el mismo día y continúa de forma intensiva durante las primeras semanas. Para decisiones de SEO y negocio conviene comparar ventanas equivalentes a 14, 28 y 56 días, teniendo en cuenta la estacionalidad y la fecha máxima disponible en cada fuente. No existe un plazo fijo en el que Google deba procesar todas las URLs.
¿Qué debe incluir el presupuesto de un rediseño web?
Debe separar diagnóstico, alcance, contenidos, diseño, desarrollo, migración, redirecciones, analítica, accesibilidad, rendimiento, pruebas, propiedad de cuentas, soporte y exclusiones. También debe decir quién toma cada decisión, qué evidencia se entrega y qué ocurre si el lanzamiento no supera los criterios acordados.
¿YAG puede revisar mi web antes de presupuestar un rediseño?
Sí. La revisión inicial separa ajustes, rediseño y reconstrucción técnica para que el presupuesto responda al problema real. Puedes empezar en la página de diseño web en Madrid o enviar el dominio y el objetivo desde contacto.