¿Rediseñar una web o hacerla de nuevo? Costes, riesgos y cómo decidir

Conviene rediseñar la web existente cuando la base funciona y el problema está en el mensaje, la navegación, el diseño móvil o algunas plantillas. Conviene hacerla de nuevo cuando la tecnología impide cambios razonables, hay problemas de seguridad o mantenimiento, la estructura no representa el negocio y arreglarla cuesta casi tanto como sustituirla.

Entre ambas opciones hay una tercera que suele ser más prudente: modernizar por fases. Primero se corrigen las páginas y recorridos que afectan a ventas o contacto. Después se decide si el resto merece migrarse.

La antigüedad no basta para elegir. He visto webs veteranas con una estructura útil y webs recién publicadas que ya eran difíciles de mantener. Antes de pedir un rediseño completo, hay que separar lo que se ve de lo que sostiene el sitio.

Respuesta rápida

Situación	Opción más razonable
La web carga, se edita y conserva URLs útiles, pero se ve anticuada o explica mal la oferta	Rediseño enfocado
Hay páginas buenas junto a plantillas frágiles o recorridos confusos	Modernización por fases
El sistema no recibe actualizaciones, rompe al editar o depende de tecnología abandonada	Reconstrucción
Cambia por completo la oferta, la arquitectura y la forma de gestionar contenido	Reconstrucción con migración planificada
No hay datos sobre qué páginas funcionan	Auditoría antes de decidir

Un servicio de rediseño web debería empezar por este diagnóstico. Cambiar colores antes de entender los problemas puede dejar intacta la parte que frena contactos.

Diagnóstico: diez preguntas antes de elegir

1. ¿La plataforma sigue siendo mantenible?

Comprueba si recibe actualizaciones, si existe documentación, si otro profesional podría trabajar en ella y si publicar contenido requiere tocar partes delicadas. Una versión reciente de WordPress con un tema razonable puede rediseñarse. Un constructor abandonado con decenas de parches pide otra conversación.

2. ¿La estructura representa el negocio actual?

Quizá la empresa empezó con un servicio y ahora tiene cinco, o atiende a otro tipo de cliente. Si la navegación, las URLs y los contenidos siguen atados a la oferta anterior, el cambio va más allá de la apariencia.

3. ¿Hay contenido que ya trae visitas o consultas?

No borres una página útil porque su diseño sea antiguo. Revisa Search Console, analítica, formularios y consultas comerciales. Una página puede ser fea y seguir respondiendo exactamente a lo que busca un cliente.

4. ¿Se puede editar sin romper nada?

Pregunta a quien mantiene la web. Si cambiar una foto desplaza media página, si cada actualización necesita un parche o si nadie se atreve a tocar el menú, hay deuda técnica. La reconstrucción puede reducirla, pero primero hay que saber qué funciones y contenidos dependen de esa base.

5. ¿La versión móvil permite completar la acción principal?

No basta con que el sitio “se adapte”. Prueba llamar, reservar, pedir presupuesto, leer un servicio y enviar un formulario desde un móvil real. A veces estas rutas pueden arreglarse sin sustituir todo el sistema.

6. ¿Las integraciones están identificadas?

Formularios, CRM, reservas, pagos, newsletters, mapas, analítica y píxeles suelen vivir en lugares distintos. Una reconstrucción que no los inventaría antes del cambio puede cortar procesos silenciosamente.

7. ¿La medición es fiable?

Sin una línea base no podrás saber si el cambio mejoró algo. Anota contactos, páginas visitadas, errores de formulario, búsquedas relevantes y conversiones disponibles antes de publicar.

8. ¿La web cumple un nivel razonable de accesibilidad?

Contraste, navegación con teclado, etiquetas, orden de encabezados y mensajes de error pueden corregirse durante un rediseño. Si el tema impide tocar el HTML o genera componentes inaccesibles por defecto, la base limita el resultado.

9. ¿El rendimiento se arregla o solo se parchea?

Una imagen pesada y unas fuentes mal cargadas son problemas concretos. Una cadena de plugins duplicados, scripts incontrolables y plantillas que envían todo al navegador indica un problema más estructural.

10. ¿Quién será responsable después?

La mejor opción también depende de quién edita, actualiza y resuelve incidencias. Reconstruir con una tecnología que nadie puede mantener sustituye un problema por otro.

Cuándo basta un rediseño

Mantendría la base cuando:

• las URLs y el contenido siguen siendo útiles
• el CMS está actualizado y permite trabajar con seguridad
• las integraciones funcionan y están documentadas
• la mayoría de problemas están en jerarquía, copy, navegación o responsive
• se pueden cambiar plantillas sin rehacer todo el tema
• el negocio necesita mejorar pronto una parte concreta

En ese caso, el trabajo puede concentrarse en inicio, servicios, contacto y componentes compartidos. También se puede limpiar CSS, reducir scripts, ajustar accesibilidad y mejorar llamadas a la acción sin migrar cada página.

Este enfoque limita riesgo y suele costar menos. La contrapartida es aceptar que algunas partes antiguas seguirán ahí hasta una fase posterior.

Cuándo modernizar por fases

La modernización gradual encaja cuando el sitio tiene valor, pero no conviene seguir construyendo sobre toda su base. Por ejemplo, se puede mantener el CMS y crear un tema nuevo, sustituir primero las plantillas comerciales o mover una sección a una arquitectura más sencilla.

Un orden práctico sería:

1. inventariar páginas, integraciones y datos
2. medir el recorrido principal
3. rediseñar inicio, servicio prioritario y contacto
4. comprobar uso, formularios e indexación
5. migrar el resto por grupos
6. retirar dependencias antiguas cuando ya no tengan tráfico ni función

Es más lento que un lanzamiento único, pero reparte presupuesto y permite aprender. Exige convivir durante un tiempo con dos formas de construir páginas, algo que debe quedar documentado.

Cuándo reconstruir desde cero

La reconstrucción suele ser razonable si coinciden varios de estos puntos:

• software sin soporte o con riesgo de seguridad
• cambios simples que requieren muchas horas
• estructura de contenido incompatible con la oferta actual
• problemas recurrentes que no se pueden aislar
• tema o constructor que bloquea accesibilidad y rendimiento
• integraciones duplicadas o imposibles de verificar
• ausencia de entornos, copias o una forma segura de desplegar
• coste de reparar cercano al de una base nueva

“Desde cero” no significa ignorar todo lo anterior. El contenido, las URLs, los datos de búsqueda, los recursos de marca y las necesidades que sí eran válidas deben alimentar la nueva versión.

Coste, tiempo y riesgo

Enfoque	Inversión inicial	Tiempo	Riesgo principal
Rediseño enfocado	Menor	Semanas	Dejar problemas estructurales fuera del alcance
Modernización por fases	Repartida	Varias entregas	Mantener temporalmente dos sistemas o patrones
Reconstrucción	Mayor	Más planificación	Perder URLs, contenido, integraciones o medición durante la migración

El presupuesto depende del número de plantillas, el estado del contenido, las integraciones y la migración. La guía sobre cuánto cuesta una página web para una pyme ofrece rangos para comparar tipos de proyecto.

También cuenta el coste de oportunidad. Un rediseño de dos meses puede ser demasiado lento si una campaña empieza la semana que viene. Una landing temporal y una reconstrucción posterior pueden resolver mejor esa restricción.

Qué preservar de la web anterior

Antes de diseñar pantallas nuevas, guardaría:

• listado completo de URLs y su estado
• páginas con tráfico, enlaces externos o consultas
• títulos, metadatos y datos estructurados que siguen siendo correctos
• contenidos, imágenes y documentos con licencia clara
• mensajes y argumentos que el equipo sabe que funcionan
• envíos de formularios, eventos de analítica y objetivos
• cuentas, dominios, DNS, alojamiento y proveedores
• reglas de reservas, pagos o integraciones

No copiaría automáticamente plugins, scripts, páginas sin visitas, textos duplicados, taxonomías vacías ni decisiones que nadie puede explicar. Conservar por miedo puede arrastrar el mismo problema a la nueva web.

Cómo evitar perder SEO en la migración

Si cambian URLs, cada dirección antigua relevante necesita una nueva equivalente. No sirve enviar todo a la página de inicio. El plan debería incluir un mapa URL a URL, redirecciones permanentes, enlaces internos actualizados y un sitemap nuevo.

La documentación oficial de Google sobre migraciones recomienda preparar el sitio nuevo, crear el mapa de URLs, configurar las redirecciones y vigilar Search Console durante el cambio. La visibilidad puede fluctuar mientras Google vuelve a rastrear las páginas, por lo que la revisión no termina el día del lanzamiento.

Comprueba además:

1. canonicals y hreflang si hay idiomas
2. títulos, descripciones y encabezados
3. robots, sitemap y páginas bloqueadas
4. datos estructurados
5. códigos 404 y cadenas de redirección
6. enlaces internos y externos importantes
7. analítica, consentimientos y eventos de contacto
8. formularios y emails transaccionales

Cuando el dominio no cambia, mantener las URLs buenas reduce trabajo. No renombres cada página solo para que el slug parezca más limpio.

Una forma segura de decidir

Pediría una revisión acotada antes de comprometer el proyecto completo. El resultado debería ser un documento corto con cuatro grupos:

• conservar
• corregir en la base actual
• migrar o reconstruir
• retirar

Cada decisión necesita una razón, un riesgo y una prioridad. Con eso se puede comparar un rediseño enfocado con una reconstrucción sin pagar todavía por ambas.

Si solicitas propuestas, revisa también cómo evaluar un presupuesto de software. Aunque el encargo sea una web, siguen importando las exclusiones, la propiedad, las pruebas y el mantenimiento.

Preguntas frecuentes

¿Un rediseño web mejora el SEO?

Puede mejorar estructura, contenido, enlaces internos, experiencia móvil y aspectos técnicos. También puede empeorarlos si se eliminan páginas útiles o cambian URLs sin redirecciones. El rediseño no garantiza posiciones por sí solo.

¿Hay que cambiar de WordPress a otra tecnología?

No por defecto. Si WordPress está actualizado, el equipo necesita editar y el problema está en el tema o la estructura, puede seguir siendo una buena base. El cambio merece la pena cuando resuelve una limitación concreta.

¿Se puede rediseñar sin parar la web?

Sí. El trabajo debe hacerse en un entorno separado, con datos representativos y una ventana de publicación. Los formularios, reservas y cambios de contenido durante la transición necesitan un plan.

¿Cuánto tiempo hay que mantener las redirecciones?

En la práctica, conviene mantener las redirecciones permanentes mientras las URLs antiguas sigan recibiendo visitas o enlaces. También hay que actualizar enlaces propios para no depender de ellas en cada navegación.

¿Cuál es el primer paso si no sé qué opción necesito?

Una auditoría pequeña de páginas, tecnología, contenido, integraciones y datos. Debería permitir decidir una primera intervención sin convertir el diagnóstico en un proyecto interminable.