Una web puede llevar diez años online y seguir cumpliendo perfectamente su función. Otra con tres años puede haberse convertido en una colección de plugins, parches y personalizaciones que nadie se atreve a tocar.
Por eso la edad de una web no debería decidir por sí sola si hay que rehacerla.
La pregunta útil es otra:
¿Sigue siendo razonable mantener lo que tienes o estás invirtiendo cada vez más esfuerzo en sostener una base que ya no responde a las necesidades del negocio?
Antes de contratar un rediseño completo, cambiar de tecnología o seguir añadiendo arreglos, conviene separar tres posibilidades:
La decisión correcta no depende de si la web «parece vieja». Depende de su estado técnico, de lo que necesita el negocio y de cuánto cuesta mantenerla funcionando con seguridad.
Es fácil asociar antigüedad con obsolescencia.
Pero una web de varios años puede seguir teniendo:
En ese escenario no existe una razón técnica para reconstruir todo únicamente porque haya pasado tiempo.
De hecho, rehacer sin necesidad puede introducir nuevos riesgos:
La decisión debería comenzar con un diagnóstico, no con una plantilla nueva.
No todas las webs deterioradas necesitan el mismo tratamiento.
Reparar significa corregir problemas concretos manteniendo la arquitectura general.
Por ejemplo:
Tiene sentido cuando la instalación es razonablemente mantenible y el problema está localizado.
Si una web funciona bien salvo por una incidencia concreta, reconstruirla entera suele ser una respuesta desproporcionada.
Modernizar significa conservar la parte que todavía aporta valor y sustituir aquello que se ha quedado atrás.
Puede incluir:
Esta opción es especialmente interesante cuando el contenido, las URLs y buena parte de la estructura siguen siendo válidos.
No es necesario elegir siempre entre «no tocar nada» y «tirarlo todo».
Rehacer significa construir una nueva implementación porque conservar la existente deja de resultar razonable.
Puede mantenerse el mismo dominio, contenido e incluso buena parte de la estructura, pero cambia sustancialmente la base técnica.
Es una opción que merece estudiarse cuando existen varios problemas estructurales a la vez, no simplemente porque una página sea lenta o visualmente anticuada.
Uno de los indicadores más importantes es si la instalación puede seguir recibiendo mantenimiento.
WordPress considera que una instalación saludable debería mantenerse actualizada, utilizar un entorno adecuado y recibir mantenimiento periódico. La propia herramienta Salud del sitio permite revisar problemas críticos y obtener información sobre WordPress, temas, plugins, servidor y otros componentes.
En WordPress puedes encontrarla en:
Herramientas → Salud del sitio
No necesitas comprender todos los datos técnicos.
Lo importante es detectar señales como:
Pero Salud del sitio es solo una pieza del diagnóstico.
Una web puede no mostrar errores graves ahí y seguir dependiendo de componentes difíciles de mantener.
Conservar la instalación tiene bastante sentido cuando se cumplen varias de estas condiciones.
El tema, los plugins importantes y las herramientas utilizadas continúan recibiendo actualizaciones.
Esto reduce considerablemente la incertidumbre.
Puede que haya trabajo pendiente, pero existe un camino razonable desde el entorno actual hasta versiones mantenidas.
Si la instalación lleva años sin tocarse, ese proceso debería planificarse y probarse.
En Cómo actualizar un WordPress antiguo sin romper la web explicamos precisamente cómo abordar ese escenario sin convertir producción en un banco de pruebas.
Existe código propio, pero sabemos qué hace y dónde está.
No ocurre lo mismo cuando nadie puede determinar qué partes dependen de modificaciones realizadas hace años.
Los servicios están correctamente organizados, las URLs tienen sentido y no existe una necesidad empresarial de replantear completamente la web.
Por ejemplo:
Una web lenta, por ejemplo, no debería conducir automáticamente a una reconstrucción.
Antes merece la pena distinguir si el problema está en el alojamiento o en la propia web. En ¿WordPress lento por el hosting? Cómo saberlo antes de migrar desarrollamos precisamente ese diagnóstico.
Hay un escenario intermedio muy común.
La web tiene valor, pero algunas de sus piezas han envejecido peor que otras.
No necesitas necesariamente rehacer textos, URLs y estructura porque el tema haya dejado de recibir mantenimiento.
Puede tener más sentido sustituir la capa visual.
A veces una web ha ido acumulando extensiones durante años.
Un plugin para un botón.
Otro para una redirección.
Otro para insertar código.
Otro para una pequeña modificación visual.
Otro que nadie sabe para qué sirve.
La modernización puede consistir en reducir dependencias y simplificar la instalación.
Un constructor antiguo o una implementación especialmente compleja puede hacer que cada cambio resulte peligroso.
Eso no obliga siempre a reconstruir el proyecto completo.
Puede plantearse una migración progresiva de plantillas o secciones.
Una web corporativa sencilla puede haber evolucionado hasta incorporar:
En ocasiones el problema no es que la web antigua esté «mal».
Es que fue diseñada para un negocio diferente.
Ninguna de estas señales, por separado, obliga a rehacer.
La decisión empieza a ganar peso cuando aparecen varias simultáneamente.
Si una función esencial depende de un plugin o tema que lleva mucho tiempo sin mantenimiento, existe una dependencia que conviene resolver.
Mantener indefinidamente versiones antiguas de WordPress o PHP para conservar una extensión obsoleta suele trasladar el problema hacia el futuro.
Cambias PHP y falla el tema.
Actualizas WordPress y falla un plugin.
Actualizas el plugin y deja de funcionar una personalización.
Cada cambio abre una nueva incompatibilidad.
En ese punto ya no estás ante una actualización aislada, sino ante una cadena de dependencias que necesita analizarse como sistema.
Es una situación habitual en webs heredadas.
Han trabajado varias personas.
El desarrollador original ya no está.
Hay fragmentos de código en distintos lugares.
Existen plugins cuya función nadie conoce.
Las cuentas pertenecen a antiguos proveedores.
Hay licencias asociadas a correos externos.
Antes de intervenir conviene recuperar además el control de dominio, hosting, WordPress, DNS, licencias y copias.
En Qué accesos de WordPress debe controlar tu empresa detallamos qué debería permanecer bajo control del negocio.
Una incidencia puntual no justifica rehacer.
Pero una web que requiere reparaciones constantes puede estar generando una deuda técnica importante.
Conviene preguntarse:
¿Estamos invirtiendo en mejorar la web o simplemente en conseguir que continúe igual?
Quizá técnicamente WordPress funciona.
Pero la empresa ha cambiado:
En ese caso el problema no es exclusivamente tecnológico.
La web original responde a unas necesidades que han dejado de existir.
Esta es una señal especialmente importante.
Una web puede continuar funcionando y, sin embargo, bloquear cualquier evolución.
Cada nueva función requiere un parche.
Cada modificación visual cuesta demasiado.
Una integración aparentemente sencilla se convierte en un proyecto.
Actualizar genera miedo.
Cuando la propia arquitectura impide evolucionar, estudiar una reconstrucción resulta razonable.
Puedes analizar la situación mediante cuatro áreas.
| Área | Reparar | Modernizar | Rehacer |
|---|---|---|---|
| WordPress/PHP | Actualizable con normalidad | Requiere plan de actualización | Mantener compatibilidad resulta muy complejo |
| Tema y plugins | Actuales y mantenidos | Algunos deben sustituirse | Varias dependencias críticas están obsoletas |
| Personalizaciones | Conocidas y controladas | Algunas necesitan revisión | Nadie conoce muchas dependencias |
| Estructura | Sigue respondiendo al negocio | Necesita cambios parciales | Ya no representa procesos ni objetivos actuales |
| Rendimiento | Problema localizado | Varios elementos mejorables | Deuda técnica generalizada |
| Funciones críticas | Estables | Algunas necesitan renovación | Recurrentemente frágiles |
| SEO/URLs | Conviene conservar | Se mantienen mayoritariamente | Puede necesitar una migración controlada |
| Coste futuro | Mantenimiento previsible | Inversión puntual + mantenimiento | Seguir reparando puede superar el coste de reconstruir |
No se trata de contar columnas y elegir automáticamente la que tenga más marcas.
La tabla sirve para identificar dónde se concentra el problema.
Aquí aparece una de las decisiones más difíciles.
Imagina dos alternativas.
Opción A
Reparar ahora cuesta relativamente poco.
Pero dentro de seis meses habrá que sustituir otro componente.
Después probablemente haya que cambiar el tema.
Y nadie sabe qué ocurrirá al actualizar PHP.
Opción B
Reconstruir requiere una inversión inicial mayor, pero elimina varias dependencias y deja una base mantenible.
En ese escenario comparar solo «reparación de 500 €» contra «reconstrucción de 3.000 €» sería incompleto.
La comparación debería incluir:
También hay que evitar el error contrario.
Que alguien proponga una reconstrucción más cara no demuestra que sea la decisión adecuada.
Primero tiene que existir una razón técnica o empresarial.
Una empresa debería saber qué tiene antes de decidir qué conserva.
Como mínimo:
Este inventario evita descubrir demasiado tarde que una pequeña función dependía de un sistema que nadie había tenido en cuenta.
Antes de realizar cambios importantes necesitas una copia de seguridad.
La documentación oficial de WordPress recomienda realizar backups regularmente y específicamente antes de actualizaciones o traslados.
Pero una copia guardada no demuestra que pueda restaurarse correctamente.
Conviene saber:
En Copias de seguridad en WordPress: cómo saber si funcionan explicamos por qué la restauración es la verdadera prueba de un backup.
Precaución: no pruebes una restauración sobrescribiendo directamente una web activa si recibe pedidos, formularios, reservas o datos de usuarios. Podrías sustituir información reciente por datos más antiguos.
Cuando sea posible, las pruebas deben realizarse en un entorno separado.
Esta es una de las razones más importantes para no considerar una reconstrucción simplemente como «hacer una web nueva».
Si una página ya recibe tráfico, tiene enlaces o aparece en Google, su URL forma parte de un activo que merece protegerse.
Cuando sea posible, conservar URLs relevantes simplifica mucho el proceso.
Si las URLs tienen que cambiar, hace falta una migración planificada.
Google recomienda preparar una correspondencia entre las URLs antiguas y sus nuevos destinos, utilizar redirecciones permanentes adecuadas, actualizar enlaces internos, revisar canonical, sitemap y reglas de indexación, y monitorizar posteriormente el traslado.
Un error típico sería eliminar veinte páginas y redirigirlas todas a la portada.
Google desaconseja redirigir muchas URLs antiguas a un destino que no sea relevante para ellas, ya que puede generar una mala experiencia e incluso tratarse como soft 404.
Por tanto, antes de rehacer deberías saber:
Una reconstrucción puede mejorar la web y, al mismo tiempo, provocar un problema de visibilidad si esta parte se ignora.
Son decisiones distintas.
Puedes reconstruir completamente una web manteniendo:
Incluso puedes cambiar de hosting sin cambiar las URLs públicas.
Google dispone de recomendaciones específicas para migraciones de infraestructura en las que las URLs no cambian: preparar el nuevo alojamiento, probarlo, modificar DNS, supervisar el tráfico y retirar el servidor anterior solo cuando el traslado esté verificado.
Cambiar dominio, hosting, diseño, estructura y CMS simultáneamente introduce muchas más variables.
Cuando no existe una necesidad real de hacerlo todo a la vez, suele ser preferible reducir cambios innecesarios.
Una web empresarial activa no debería convertirse en el entorno donde se descubre si la reconstrucción es compatible con todos los procesos.
Antes de sustituirla conviene comprobar en un entorno de pruebas:
La portada cargando correctamente no significa que la migración haya terminado bien.
Lo que importa es que continúen funcionando los procesos que utiliza el negocio.
Si un proveedor recomienda rehacer la web, merece la pena pedir respuestas concretas.
«La web es antigua» no es suficiente.
Deberían poder explicarte qué problemas actuales justifican la intervención.
Contenido, URLs, clientes, pedidos, SEO, integraciones, imágenes y otras partes pueden tener valor.
Esta pregunta ayuda a distinguir una mejora opcional de un problema que realmente necesita resolverse.
Quizá pueda cambiarse el tema.
O sustituirse el constructor.
O modernizar únicamente una parte.
Debería existir un plan para:
Si la respuesta es simplemente «publicamos la nueva y borramos la vieja», faltan demasiadas piezas.
Repararía cuando:
Modernizaría cuando:
Para muchas webs empresariales antiguas, esta puede ser la opción más equilibrada.
Estudiaría una reconstrucción cuando coinciden varios factores:
Incluso entonces, «rehacer» debería significar reconstruir lo que necesita cambiar y proteger lo que sigue teniendo valor.
Es fácil que un proyecto de este tipo se convierta en una discusión sobre diseños, constructores, temas o tecnologías.
Pero una empresa necesita responder a algo más sencillo.
Después de intervenir:
Una web no necesita ser nueva.
Necesita ser mantenible.
Si la instalación actual puede llevarse a ese estado con una reparación o modernización razonable, no existe obligación de empezar desde cero.
Si llegar hasta ahí exige conservar demasiadas dependencias obsoletas, asumir incompatibilidades o seguir acumulando parches, entonces una reconstrucción puede ser la decisión más sensata.
Pero esa conclusión debería aparecer después del diagnóstico.
No antes.
