Criterio · · 9 min de lectura

Tu web envejece aunque no la toques

Una web parada no está estable. Se deteriora en silencio. Velocidad, seguridad, posicionamiento: cómo pierde valor sin que nadie lo note y cuándo actuar.

Tu web envejece aunque no la toques

Hay un momento que reconocen casi todos los responsables de negocio con los que hablamos. Lo cuentan de la misma forma: abrieron su propia web desde el móvil, esperaron, esperaron un poco más, y la cerraron sin llegar al final. No porque estuviera rota. Porque algo no iba bien, aunque no pudieran decir exactamente qué.

La web seguía funcionando. Las páginas cargaban. El formulario de contacto tenía respuesta automática. Desde dentro del panel de WordPress, todo parecía en orden. Ningún aviso rojo, ningún error en pantalla, ningún cliente que se hubiera quejado directamente.

El problema es que ese silencio no es estabilidad. Es deterioro que no hace ruido.

Lo que ocurre en doce meses sin mantenimiento web

Una web no es un cartel en la fachada. No se queda igual porque tú no la toques. El ecosistema a su alrededor se mueve, y lo que antes era una ventaja se convierte, sin intervención, en un punto flaco.

Los plugins de WordPress sacan actualizaciones constantemente. Hay parches de seguridad, correcciones de compatibilidad, mejoras de rendimiento. Muchos no se aplican porque la última vez que alguien actualizó algo el sitio se rompió, o porque no hay tiempo, o porque nadie tiene esa tarea asignada. Las versiones antiguas acumulan vulnerabilidades conocidas y documentadas públicamente. No hace falta que nadie te ataque específicamente: hay bots que recorren internet de forma industrial buscando instalaciones desactualizadas. Es automático. Es barato para quien lo hace. Y cuando encuentran una entrada, el objetivo no suele ser hacerte daño — suele ser usar tu servidor para enviar spam o alojar contenido de otros. Tu web como infraestructura de otra cosa.

El servidor migra de PHP. Hostinger, SiteGround, el proveedor que sea, actualiza su entorno porque las versiones antiguas llegan a fin de vida y ya no reciben soporte. PHP 7.4 era perfectamente válido hace tres años. Está oficialmente sin mantenimiento. La migración a PHP 8.x no siempre es invisible: funciones que antes funcionaban en silencio ahora generan avisos o dejan de ejecutarse. No siempre ves el error en pantalla. Pero puede estar en el HTML, y los rastreadores de Google Search Console sí lo detectan.

Los competidores trabajan mientras tanto. Esto es lo más difícil de aceptar porque no produce ninguna alarma. No hay ningún algoritmo que te penalice por quedarte quieto. Simplemente, la empresa que estaba tres posiciones por debajo en los resultados de búsqueda ha añadido contenido, mejorado su velocidad y conseguido algunos enlaces. No hiciste nada mal. Te pasaron por encima mientras esperabas.

Y la velocidad se degrada. Este cambio es tan gradual que casi nadie lo detecta a tiempo. La configuración de caché que pusiste al lanzar la web ya no es la óptima. Las imágenes que subiste no se optimizaron. El tema tiene versiones nuevas que mejoran el rendimiento. Google mide Core Web Vitals de forma continuada — un 74 de hace dos años puede ser hoy un 58, sin que hayas cambiado ni una línea de código.

El lunes que todo explota

Hay una versión dramática de este deterioro y hay una versión lenta. La versión dramática todos la conocen: el lunes por la mañana alguien llama porque la web está caída, porque sale un aviso de seguridad en el navegador, o porque Google ha marcado el sitio como peligroso y las visitas han caído a cero de un día para otro.

Esa versión existe. Es real. Pero no es la más frecuente.

La más frecuente es la lenta: la web sigue funcionando pero ya no convierte. Los clientes llegan y se van. El tráfico orgánico baja un poco cada mes, tan despacio que nadie lo nota hasta que miras los números del año anterior y la diferencia es del treinta por ciento. El formulario de contacto lleva semanas sin recibir mensajes y nadie lo ha comprobado porque se asume que funciona.

La versión lenta es más cara que la dramática. No produce un momento de quiebre que obligue a actuar. El deterioro se convierte en la nueva normalidad, y cuando alguien finalmente decide hacer algo, hay que sumar el coste de la intervención al coste acumulado de meses perdidos.

Señales que ya están ahí

En los proyectos de rescate que llegan a Reveled, los síntomas se repiten con una regularidad que ya no sorprende. No todos aparecen juntos, pero siempre hay alguno.

La web tarda más de tres segundos en cargar en móvil. No de forma que haga imposible usarla — lo suficiente para que el usuario que llega de Google vuelva atrás antes de leer nada. En Search Console, si está configurado, aparece como una tasa de rebote que nadie ha investigado.

El diseño ya no representa al negocio. La empresa ha evolucionado, los servicios han cambiado, los precios son otros. La web cuenta la historia de hace dos años. Hay clientes que preguntan por servicios que ya no existen o no encuentran los que sí existen.

Los formularios fallan en silencio. Esto es más frecuente de lo que parece y más difícil de detectar porque nadie comprueba que los mensajes lleguen. El plugin de formularios tuvo un conflicto con una actualización, la configuración de SMTP cambió con el proveedor de hosting, el captcha caducó. Los mensajes van a spam, llegan con retraso o directamente no llegan. La empresa sigue pensando que simplemente no hay interesados.

El posicionamiento baja sin razón aparente. Nadie ha hecho nada mal. No hay penalización. Solo la entropía acumulada mientras otros se movían.

Las actualizaciones de WordPress llevan meses pendientes en el dashboard. Nadie las aplica por miedo a romper algo. Ese miedo es razonable — una actualización sin copia de seguridad verificada puede ser un problema — pero la solución no es no actualizar. Es actualizar con protocolo.

Por qué el deterioro gradual sale más caro

Cuando algo se rompe de golpe, alguien actúa. Hay un coste claro, un momento de intervención, una solución y un cierre. Es un gasto visible, concreto, fácil de entender como necesario.

El deterioro gradual no produce ese momento de cierre. Produce meses de pérdida silenciosa: visitas que se van sin dejar rastro, clientes que no contactan porque el formulario falló, posicionamiento que cede posición a posición. Y cuando alguien finalmente decide actuar, hay que sumar el coste de la intervención a todo lo que se perdió mientras el problema crecía en silencio.

Una web que lleva doce meses sin mantenimiento web no es una web estable a coste cero. Es una web que lleva doce meses generando pérdidas invisibles. La diferencia es que nadie las ve en una factura, así que nadie las atribuye al mismo problema.

Hay una regla simple que usamos como criterio: si la web lleva más de doce meses sin revisión, hay que revisarla. No necesariamente intervenirla. Auditarla. Ver en qué estado real está antes de decidir qué hacer.

Mantener o rehacer: cómo se toma esa decisión

La tentación cuando algo va mal en una web es pensar en rediseño. Es una solución visible, con inicio y final claros, con resultado tangible. Cierra un ciclo mentalmente. Y es exactamente la solución equivocada en muchos casos, porque una web nueva sin estrategia de mantenimiento tendrá los mismos problemas en dieciocho meses.

Hay webs que con mantenimiento y optimización pueden aguantar perfectamente tres años más y ofrecer un rendimiento completamente diferente del que tienen hoy. Y hay webs donde la arquitectura está tan comprometida — plugins acumulados sin criterio, código custom que nadie entiende, un tema de hace siete años sin soporte — que mantenerlas sale más caro que construir algo limpio desde cero.

La diferencia entre las dos la muestra una auditoría honesta, no una presentación de ventas.

En Reveled, cuando alguien llega con esta pregunta, lo primero que hacemos es mirar. No proponer. Mirar la velocidad real, el estado de la seguridad, el tráfico de los últimos doce meses, si los formularios funcionan, si el contenido representa al negocio actual. De ahí sale una evaluación con dos posibles conclusiones: intervención sobre lo que hay, o reconstrucción. Y cuál de las dos tiene sentido depende de los datos, no de lo que sea más fácil de vender.

Cuando la conclusión es construir de nuevo, el stack que usamos para webs corporativas es Astro. Páginas que cargan en menos de un segundo sin capas de plugins, con el código en archivos de texto que cualquier herramienta puede leer y modificar. El coste de mantenimiento a lo largo del tiempo es radicalmente menor que el de una web en WordPress con constructor visual. Eso no es marketing — es la diferencia estructural entre los dos enfoques.

Lo que hacemos en Reveled

El punto de entrada habitual es una consultoría. Una sesión donde miramos el estado real: velocidad, seguridad, posicionamiento, coherencia del contenido con el negocio actual. Sin venta incorporada. Solo diagnóstico honesto con los datos encima de la mesa.

A partir de ahí el camino puede ir en dos direcciones. La primera es un plan de mantenimiento web para webs con arquitectura sana que solo necesitan cuidado regular: actualizaciones controladas con backup previo, optimización de velocidad, revisión periódica de formularios y copias de seguridad verificadas. La segunda es un proyecto de reconstrucción cuando la auditoría muestra que el coste de mantener lo que hay supera el de empezar de cero.

Lo que no hacemos es llegar con una solución antes de entender el problema.

Una web no tiene que romperse para estar costándote clientes. El deterioro silencioso no tiene alarma. Cuando alguien decide actuar, generalmente ya lleva meses perdiendo sin saberlo.


Si tu web lleva tiempo parada y no tienes claro en qué estado está real, ese es el punto de partida. Escríbenos y lo miramos sin compromiso.

mantenimiento web web obsoleta velocidad web diseño web wordpress renovar página web
David Pire

David Pire

Fundador de Reveled