Deriva web: por qué se rompen las webs aunque nadie las toque
¿Tu web se rompió tras una actualización, o dejó de funcionar sin que nadie actualizara nada? Eso es deriva web. «No hemos cambiado nada» es la frase más habitual en el soporte web, y casi nunca es cierta. Alguien, o algo, cambió: una actualización automática se ejecutó por la noche, un asistente de IA reescribió un componente, un script de terceros publicó una nueva versión, una regla de firewall se endureció. Esta guía repasa las diez causas de deriva web que más vemos, qué rompe cada una y cómo detectarla antes que tus clientes.
Qué es la deriva web
La deriva web es la distancia entre la web que probaste y la web que reciben hoy tus visitantes. Se acumula con cambios que nadie revisó en conjunto: aquí una actualización de plugin, allí un ajuste del CDN, un script que carga una versión más nueva de sí mismo. Ninguno parece peligroso por separado, y la mayoría se aplican automáticamente.
La deriva rara vez aparece como una caída total. La página de inicio sigue cargando, así que la monitorización de disponibilidad sigue en verde. Lo que se rompe es un camino: el botón de añadir al carrito que ya no responde, un campo del checkout que desapareció, un correo de confirmación de pedido que dejó de llegar, una imagen de producto que devuelve un 404. Son los fallos que cuestan ventas, y justo los que un simple ping no ve.
Por qué «nadie lo ha tocado» casi nunca es verdad
Una web moderna no es un único software. Una tienda WordPress típica ejecuta el núcleo de WordPress, un tema, entre veinte y cincuenta plugins, un entorno PHP, un servidor web, una caché, un CDN, un firewall, una pasarela de pago y una docena de scripts de terceros — cada uno mantenido por un equipo distinto, con su propio calendario de versiones, y muchos configurados para actualizarse solos.
Una web hecha con herramientas de IA o con un framework moderno tiene la misma forma: código generado, dependencias de npm, valores por defecto del hosting, configuración en el edge y APIs externas. Cuando algo se rompe, la pregunta no es si algo cambió, sino cuál de estas capas cambió y cuándo. Las diez causas siguientes son los primeros sitios donde mirar.
1. Actualizaciones del núcleo de WordPress, plugins y temas
Las actualizaciones son la mayor fuente de deriva web en WordPress — están detrás de la mayoría de los casos de «una actualización de WordPress rompió mi web» — y la mayoría ocurren sin supervisión: las versiones menores del núcleo se instalan solas, y desde WordPress 5.5 los plugins y temas también pueden actualizarse automáticamente. Una actualización que funciona bien por sí sola puede chocar con otro plugin, cambiar un hook del que depende tu tema o renombrar las clases CSS a las que apuntan tus personalizaciones.
WooCommerce añade su propia trampa: los temas sobrescriben plantillas de WooCommerce, y cuando WooCommerce actualiza una plantilla, la copia desactualizada de tu tema sigue mostrándose. El carrito o el checkout pueden perder un campo o un nonce sin ningún error visible. La solución no es dejar de actualizar — los plugins desactualizados son un riesgo de seguridad —, sino volver a probar los caminos importantes — el checkout, la estructura de la página y el diseño — justo después de cada actualización. Relvato hace justo eso: su plugin de WordPress informa de cada actualización de plugins, temas y núcleo en cuanto ocurre, y Relvato vuelve a ejecutar tus comprobaciones de checkout, visuales y de estructura en cuestión de minutos.
2. Código generado por IA y regresiones del vibe coding
Las herramientas de programación con IA hacen cambios rápidos y amplios. Pide a un asistente que «ordene el formulario de registro» y quizá también renombre una ruta, elimine un campo oculto que tu CRM necesitaba, quite el atributo de seguimiento del que dependía tu analítica o regenere un componente desde cero sin el caso especial que corregiste el mes pasado. Herramientas como Lovable, Bolt, v0 y Cursor pueden reescribir decenas de archivos con un solo prompt.
El resultado es una regresión que parece intencionada: el código está limpio, compila y la página se muestra. Nada falla; simplemente un botón ya no envía, o un enlace apunta a una ruta que se movió. La revisión de código detecta parte, pero no lo que ocurre a lo largo de un recorrido completo. Volver a ejecutar tus journeys clave tras cada push a GitHub — no solo los tests unitarios — es lo que lo saca a la luz. La GitHub App de Relvato lo hace en cada push: vuelve a ejecutar tus recorridos reales en un navegador, así que un campo eliminado o una ruta movida se detectan antes de que los encuentren tus clientes.
3. Scripts de terceros y recursos externos
Mucho de lo que ejecutan tus visitantes no lo alojas tú: widgets de chat, SDK de pagos y antifraude, gestores de etiquetas, analítica, herramientas de pruebas A/B, fuentes, mapas, insignias de reseñas e imágenes en un CDN. Se actualizan según su propio calendario, y si los cargas desde la URL del proveedor, recibes la nueva versión en cuanto la publica — o nada, si la retira.
El incidente de polyfill.io en 2024 mostró el caso extremo: un script muy extendido cambió de dueño y empezó a servir código malicioso a más de 100.000 webs. Los casos cotidianos son más discretos — un widget de chat que ahora tapa el botón del checkout en móvil, un contenedor del gestor de etiquetas que alguien editó, un endpoint obsoleto de un SDK que devuelve un error, una imagen borrada de un CDN. Vigila los errores de JavaScript no capturados, las imágenes externas rotas y los nuevos orígenes de scripts en tus páginas clave.
4. Cambios en el firewall, el WAF y la protección contra bots
Las capas de seguridad cambian sin ningún despliegue: se endurece una regla de Cloudflare, el hosting activa Imunify360 o reglas de ModSecurity más estrictas, un plugin de seguridad actualiza su lista de bloqueo, se activa el modo contra bots. Cada cambio puede empezar a desafiar o bloquear tráfico legítimo — callbacks de pago, webhooks, peticiones de API de tu propia app, buscadores y rastreadores de IA, o clientes reales con VPN.
Estos fallos son difíciles de ver desde dentro: tienes la sesión iniciada, estás en la lista blanca o usas una IP de confianza, así que a ti todo te funciona. Los visitantes ven una página «Please wait while your request is being verified» o un 403. Cuando también se bloquea la monitorización, una buena herramienta te dice qué capa lo hizo — el edge del CDN, el firewall del servidor del hosting o un plugin de WordPress —, porque cada una se arregla en un sitio distinto (así se permite la monitorización).
5. Cambios de hosting, PHP y servidor
Los proveedores de hosting actualizan versiones de PHP, mueven cuentas a servidores nuevos, cambian límites de memoria y modifican la configuración del servidor web — a veces con un correo que no leíste. Cada versión de PHP marca funciones como obsoletas o las elimina, así que un plugin que ayer funcionaba puede empezar a mostrar avisos «Deprecated» por todas tus páginas, o lanzar un error fatal que sustituye el checkout por la pantalla de WordPress «Ha habido un error crítico en esta web».
Las migraciones traen su propia deriva: una ruta de servidor distinta, una extensión de PHP que falta, un cron que ya no se ejecuta y deja atascados los correos programados y las renovaciones de suscripciones, o permisos de archivos que impiden las subidas. Revisa tus páginas clave en busca de errores visibles de PHP y WordPress tras cualquier cambio de hosting, y comprueba que las tareas en segundo plano se siguen procesando.
6. Configuración de caché y CDN
La caché es invisible hasta que guarda lo que no debe. Una caché de página completa o una regla del CDN que almacena el checkout, el carrito o una página con sesión iniciada puede servir la sesión de un cliente a otro, mostrar un carrito vacío o romper el inicio de sesión y los cupones para todos. Las optimizaciones automáticas de plataforma de Cloudflare y las reglas de caché agresivas son culpables habituales cuando se activan sin exclusiones.
También ocurre lo contrario: purgar la caché tras un despliegue deja al descubierto una página lenta que estaba oculta, o un ajuste de minificación estropea un script. Como el fallo depende de quién pidió la página primero, puede aparecer y desaparecer — por eso hace falta un navegador real que compruebe el recorrido del cliente — como un checkout con sesión iniciada o el inicio de sesión —, no solo un código de estado.
7. Ediciones cotidianas de contenido y ajustes
No todas las averías vienen del código. Alguien renombra una página y todos los enlaces del menú a la URL antigua devuelven ahora un 404. Se borra un producto y su imagen desaparece de tres páginas de categoría. La casilla «Disuadir a los motores de búsqueda de indexar este sitio» marcada en el entorno de pruebas sigue marcada tras el lanzamiento. El checkout como invitado se desactiva para una prueba y nunca se vuelve a activar.
Estas ediciones ocurren en el panel de administración, a menudo por personas que no las ven como cambios en la web. También son las más fáciles de detectar automáticamente: enlaces e imágenes rotos en páginas clave, un noindex inesperado y un checkout que de repente obliga a los invitados a iniciar sesión son comprobaciones deterministas.
8. Cosas que caducan en silencio
Algunas averías quedan programadas el mismo día en que configuras algo. Los certificados SSL caducan cuando la renovación automática falla sin avisar. Los dominios vencen cuando caduca la tarjeta registrada. Las claves de API y las credenciales de la pasarela de pago se rotan o se revocan. Las licencias de plugins premium expiran y el plugin deja de recibir las actualizaciones de seguridad y compatibilidad que el resto de tu sistema da por hechas.
La caducidad es la deriva más evitable porque la fecha se conoce de antemano. Revisar el periodo de validez del certificado y probar los métodos de pago que tus clientes usan de verdad convierte una caída inesperada en un recordatorio.
9. Cambios en proveedores de pago, envío y APIs
Tu checkout depende de servicios que no controlas. Los proveedores de pago retiran versiones de su API, cambian formatos de webhook y endurecen las reglas de autenticación reforzada de clientes; los servicios de envío e impuestos cambian tarifas y endpoints; los proveedores de correo ajustan límites de envío y requisitos de autenticación. Una pasarela puede desaparecer en silencio del checkout porque su plugin ahora exige un ajuste más reciente.
El síntoma suele ser parcial: la mayoría de los pedidos siguen entrando, pero falta un método de pago, 3-D Secure falla con algunas tarjetas o los correos de confirmación dejan de llegar. Comprobar que cada método de pago esperado se sigue ofreciendo, y que los correos de confirmación llegan de verdad a la bandeja de entrada, lo detecta sin hacer cargos reales.
10. Compromisos de seguridad
Los atacantes provocan deriva a propósito e intentan que pase desapercibida. Se explota un plugin vulnerable para inyectar un skimmer de tarjetas en el checkout, se deja un archivo con puerta trasera en la carpeta de subidas, se modifica una plantilla del tema o se asciende en silencio una cuenta de cliente a administrador. La web sigue funcionando — de eso se trata.
Detectarlo exige comparar con un estado conocido y limpio: los archivos del núcleo y de los plugins con sus sumas de verificación oficiales, los archivos de tu tema con una línea base aprobada, la lista de administradores con la esperada, y los orígenes externos que cargan scripts en el checkout con los aprobados. Combínalo con un análisis de vulnerabilidades para parchear antes del ataque, no después.
Cómo detectar la deriva antes que tus clientes
El patrón es el mismo en las diez causas: algo fuera de tu proceso de revisión cambió y un recorrido de usuario se rompió sin un error que notaras. Las comprobaciones programadas ayudan, pero dejan un hueco entre el cambio y la siguiente ejecución. Lo más eficaz es volver a verificar justo después de los cambios que causan deriva — una actualización de plugin, tema o núcleo, un push a tu repositorio, un cambio de configuración — y mantener un calendario fijo para todo lo demás.
Relvato está diseñado en torno a esa idea. En WordPress, su plugin informa de las actualizaciones en cuanto ocurren y Relvato vuelve a ejecutar las comprobaciones que podrían verse afectadas: los recorridos de checkout e inicio de sesión, la regresión visual y la deriva estructural, las revisiones de errores y enlaces rotos, y la integridad de archivos y del tema. En cualquier stack, un push a un repositorio de GitHub conectado hace lo mismo. Cuando un firewall bloquea las comprobaciones, Relvato indica la capa para que sepas dónde permitirlo, y las líneas base aprobadas evitan que los cambios intencionados alerten dos veces.
Las 10 causas de la deriva web de un vistazo
| Causa | Qué cambia | Síntoma típico | Cómo detectarlo |
|---|---|---|---|
| Actualizaciones de WordPress | Núcleo, plugins, temas, plantillas de WooCommerce | Campo del checkout ausente, conflicto de plugins, diseño alterado | Comprobaciones de checkout, visuales y de estructura tras cada actualización |
| Código generado por IA | Componentes, rutas, formularios, atributos de seguimiento | Botón que ya no envía, ruta movida, campo eliminado | Volver a ejecutar los journeys clave en cada push |
| Scripts de terceros | Widgets, SDK, gestores de etiquetas, recursos en CDN | Errores de JavaScript, botones bloqueados, imágenes rotas, nuevos orígenes de scripts | Revisión de errores, enlaces rotos, comprobación de orígenes de scripts |
| Firewall y WAF | Reglas del CDN, firewall del servidor, plugins de seguridad | Páginas de verificación, errores 403, webhooks y rastreadores bloqueados | Comprobaciones que indican la capa que bloquea |
| Hosting y PHP | Versión de PHP, servidor, cron, extensiones | Avisos Deprecated, pantalla de error crítico, tareas atascadas | Revisión de errores y de tareas en segundo plano |
| Caché y CDN | Caché de página, reglas de caché, minificación | Carrito vacío, inicio de sesión roto, sesiones mezcladas | Journeys de checkout e inicio de sesión en un navegador real |
| Contenido y ajustes | Páginas, menús, productos, ajustes de indexación y checkout | Enlaces 404, imágenes ausentes, noindex, checkout de invitado desactivado | Comprobaciones de enlaces rotos, SEO y checkout |
| Cosas que caducan | SSL, dominios, claves de API, licencias | Avisos de certificado, caídas, actualizaciones que faltan | Comprobaciones de caducidad SSL y de métodos de pago |
| Proveedores de pago y API | APIs de pasarela, webhooks, envío de correo | Método de pago ausente, 3-D Secure fallido, sin correo de confirmación | Comprobaciones de métodos de pago y entrega de correo |
| Compromisos de seguridad | Archivos del núcleo y del tema, administradores, scripts del checkout | Skimmer en el checkout, administrador intruso, puerta trasera | Integridad de archivos y tema, lista de administradores, análisis de vulnerabilidades |
Preguntas frecuentes sobre la deriva web
¿Qué es la deriva web?
La deriva web es la diferencia gradual entre la web que probaste por última vez y la que reciben ahora los visitantes, causada por cambios que nadie revisó en conjunto — actualizaciones automáticas, scripts de terceros, cambios de hosting y firewall, ediciones de contenido. Normalmente rompe un recorrido, como el checkout o el registro, en lugar de tumbar toda la web.
¿Por qué se ha roto mi web si no he cambiado nada?
Porque otra cosa cambió. Los culpables más habituales son las actualizaciones automáticas del núcleo de WordPress, plugins o temas, un script de terceros con nueva versión, una actualización de hosting o de PHP, un cambio en una regla del firewall o del CDN, o un certificado o una clave de API caducados. Revisa qué se actualizó o cambió en las horas previas al problema.
¿Debería desactivar las actualizaciones automáticas de WordPress para evitar la deriva?
Normalmente no. Los plugins desactualizados son una de las principales vías por las que se comprometen las webs, así que desactivar las actualizaciones cambia deriva por riesgo de seguridad. Es más seguro seguir actualizando y volver a probar automáticamente los recorridos clave — checkout, inicio de sesión, formularios — justo después de cada actualización.
¿Cómo detecto fallos causados por código generado por IA?
Trata cada cambio asistido por IA como un despliegue: ejecuta los recorridos reales de usuario, no solo la compilación. Las comprobaciones que comparan la estructura de la página y las capturas con una línea base aprobada detectan campos eliminados y botones movidos, y lanzarlas en cada push a tu repositorio detecta la regresión antes que los usuarios.
¿Con qué frecuencia hay que comprobar una web?
Justo después de cada cambio y, además, con un calendario regular. Las comprobaciones activadas por eventos detectan la deriva minutos después de una actualización o un despliegue; un calendario diario o semanal cubre los cambios que no ves venir, como un certificado a punto de caducar o la actualización de un script de terceros.