Por qué se cae tu web y cómo evitarlo

Hace poco entré en la web de un cliente que llevaba ocho años sin tocarse. WordPress 4.9.26, la versión de 2018. Para el dueño del negocio, la web «funcionaba»: estaba ahí, se veía, nadie se había quejado nunca. Hasta que un día quiso cambiar un texto y el panel de administración empezó a fallar. Probé a actualizar algo, cualquier cosa, y WordPress devolvía siempre el mismo error:

cURL error 60: SSL certificate problem: unable to get local issuer certificate.

Ese error tiene una explicación muy concreta. Y le pasa a más webs de las que parece, sobre todo a las que llevan años sin mantenimiento. Si tienes una web en WordPress y hace tiempo que nadie la toca, puede que le esté ocurriendo lo mismo sin que lo sepas todavía.

Qué es lo que falla de verdad

Cuando WordPress necesita conectarse con otro servidor por HTTPS, por ejemplo para comprobar si hay una actualización disponible en WordPress.org, tiene que verificar que ese servidor es de fiar. Para eso compara su certificado de seguridad contra una lista de entidades de confianza reconocidas mundialmente, las llamadas «autoridades de certificación».

Esa lista no se consulta en internet en tiempo real. Vive dentro de tu propia instalación de WordPress, en un archivo interno llamado ca-bundle.crt. Ahí es donde WordPress guarda a quién puede confiar y a quién no.

Y ese archivo caduca. Las entidades de certificación cambian, algunas dejan de ser de confianza, otras renuevan sus propios certificados. Si el archivo no se actualiza, con el tiempo deja de reconocer como válidas las conexiones seguras actuales, aunque el servidor de destino esté perfectamente bien.

Normalmente esto no debería preocuparte nunca, porque WordPress lo actualiza solo, como parte de cada actualización de núcleo. Si mantienes la web al día, el archivo se mantiene al día con ella.

La trampa circular

El problema de una web abandonada durante años es este: el archivo de certificados solo se renueva como consecuencia de actualizar WordPress. Si la web lleva ocho años sin actualizarse, ese archivo también lleva ocho años sin actualizarse, y termina caducando.

El día que por fin alguien intenta actualizar algo, WordPress necesita conectarse por HTTPS con WordPress.org para descargar esa actualización. Y para verificar que esa conexión es segura, usa el mismo archivo de certificados que ya ha caducado. No puede verificarla, la conexión falla, y la actualización nunca llega a descargarse.

La web no se puede actualizar porque no se ha actualizado. Cuanto más tiempo pasa sin tocarla, más difícil es sacarla de ahí con un simple clic en «Actualizar ahora».

La solución no está dentro del panel de WordPress. Hay que entrar en el servidor y sustituir ese archivo a mano por una versión actualizada del paquete de certificados raíz que mantiene el propio proyecto cURL, disponible en curl.se/ca. En la web de este cliente hicimos justo eso: en cuanto se reemplazó el archivo, WordPress volvió a poder verificar la conexión y las actualizaciones empezaron a funcionar con normalidad.

El intento que casi la remata del todo

Antes de dar con la causa real, probamos algo que parecía razonable: subir la versión de PHP del hosting, por si el problema venía de ahí. La web se cayó entera, con un error 500, hasta que revertimos el cambio.

No fue mala suerte. Cambiar el entorno de ejecución (PHP) sin haber resuelto antes un problema de base, como el de los certificados caducados, puede desencadenar fallos que hasta ese momento quedaban ocultos. El servidor pasó a ejecutar el código con una versión de PHP más exigente, y todo lo que hasta entonces funcionaba de milagro dejó de funcionar de golpe.

La lección vale para cualquier actualización: el orden en el que arreglas las cosas importa tanto como arreglarlas. Subir la versión de PHP antes de resolver el problema de fondo no es avanzar, es meter una variable nueva en un sistema que ya estaba fallando.

No es un caso raro

Suena a avería puntual y rebuscada, pero el fondo del asunto (una web que se abandona y cada mes que pasa cuesta más arreglarla) es de lo más habitual que hay. Algunos números lo dejan claro. Según el informe The State of WordPress Security 2026 de GuardingWP, en 2025 se hicieron públicas 11.334 vulnerabilidades conocidas en el ecosistema WordPress, y el 91% eran de plugins, no del núcleo. Uno de cada dos sitios WordPress corre al menos un plugin con una vulnerabilidad conocida en el momento del escaneo (52,8%). Los plugins desactualizados son responsables del 52% de todas las infecciones, y el 67% de los sitios comprometidos tenían alguno sin actualizar. Y cuando se hace pública una vulnerabilidad crítica, los ataques automatizados empiezan a explotarla en apenas 5 horas.

Sucuri, que audita webs hackeadas cada año, encontró que el 39,1% de los gestores de contenido estaban desactualizados en el momento de la infección en 2023 (frente al 50,58% de 2022). Los componentes más detectados en los sitios comprometidos: Contact Form 7 desactualizado, en el 27,44% de los casos, la librería Freemius en el 20,85% y WooCommerce en el 14,51%.

Estos números pesan porque WordPress no es un sistema minoritario. Mueve el 41,2% de todas las webs del mundo, el 59,1% de las que usan algún gestor de contenido identificable (W3Techs, agosto 2026). Cuantas más webs hay, más webs abandonadas se acumulan.

Las causas más habituales de que una web se caiga

El error de certificados es solo una forma de que una web WordPress deje de funcionar. No hay una estadística oficial que las ordene por porcentaje exacto, cualquier cifra así estaría inventada, pero las principales guías técnicas del sector coinciden bastante en cuáles son las más frecuentes:

Kinsta, en su análisis sobre por qué se rompen los sitios WordPress, apunta algo que suele sorprender: la mayoría de los problemas vienen de cambios hechos en el propio sitio, no de picos de tráfico ni de fallos del hosting. Lo que más tumba una web casi nunca es que llegue mucha gente de golpe. Es tocarla sin cuidado. O no tocarla nunca, que es justo lo que le pasó a este cliente.

Cómo enterarte antes de que te lo diga un cliente

En este caso, nadie supo que había un problema hasta que alguien intentó entrar al panel para hacer un cambio. Con monitorización activa, ese aviso llega antes.

Sin ningún tipo de monitorización, lo habitual es tardar entre 15 y 60 minutos en enterarte de que tu web está caída, casi siempre porque un cliente te avisa o porque entras a mirar por casualidad. Con un servicio de monitorización activo ese tiempo baja a 1 o 2 minutos, con comprobaciones cada 30 o 60 segundos.

Un apunte práctico si buscas algo gratuito para esto: UptimeRobot, la herramienta más conocida, dejó de permitir uso comercial gratuito en octubre de 2024, su plan gratis quedó limitado a uso personal. Si la web es de un negocio, StatusCake sí permite uso comercial sin coste, con hasta 10 monitores.

Checklist antes de actualizar cualquier cosa

Para que una actualización rutinaria no acabe como el incidente que hemos contado, el proceso que recomiendan las guías técnicas de referencia sigue siempre este orden:

1. Backup completo antes de tocar nada, guardado fuera del propio servidor de hosting.
2. Comprobar la versión de PHP actual y qué versión necesitaría el cambio que vas a hacer.
3. Revisar la compatibilidad de cada plugin activo: en su ficha figura la línea «Tested up to», que indica hasta qué versión lo ha probado su desarrollador. Si lleva más de un año sin actualizarse, es una señal de alarma.
4. Probar el cambio en un entorno de pruebas (staging), una copia del sitio, antes de aplicarlo en la web real.
5. Aplicar el cambio en producción y comprobar rápido que todo sigue funcionando: formulario de contacto, checkout si es tienda, páginas principales.

Siguiendo este orden, el proceso completo suele llevar entre 30 y 90 minutos según la complejidad del sitio. Es tiempo, sí. Pero es mucho menos que el que cuesta reconstruir una web que se ha caído a medio actualizar.

Por qué esto importa más de lo que parece

No hace falta que tu web esté técnicamente caída para que te esté costando clientes. Según una encuesta a cerca de mil personas entre consumidores, autónomos y pequeñas empresas españolas, los negocios sin web pueden perder hasta un 25% de clientes potenciales, y solo el 48% de las empresas encuestadas tenía página web propia, frente al 98% de los consumidores que reconoce que la presencia online de un negocio le importa. Y no basta con tenerla: un análisis más reciente calcula que el 80% de las webs de pymes en España no cumple su función de atraer y convertir clientes.

No hay ningún estudio específico sobre cuántas webs caídas hay en España en un momento dado, esa cifra concreta no existe, así que no la vamos a inventar. Pero el patrón general está claro: una web que no funciona, ya sea porque está caída o porque simplemente no convierte, es dinero que se queda sobre la mesa sin que el dueño del negocio se entere.

Qué hacer si tu web ya está en esta situación

Si al leer esto te ha sonado a tu propia web (llevas años sin tocarla, te da miedo actualizar por si se rompe, o ya te ha fallado algo parecido), la señal ya está ahí. Cuanto más tiempo pasa, más se acumula, y más cara sale la solución cuando por fin hay que abordarla.

Si quieres que le echemos un vistazo antes de que se convierta en una urgencia, en mantenimiento web tienes el servicio con el que resolvemos este tipo de situaciones, desde webs que solo necesitan ponerse al día hasta casos ya bloqueados como el de este artículo. Y si prefieres el checklist completo, qué revisar cada semana, cada mes y cada trimestre, lo tienes en esta guía de mantenimiento WordPress.

Preguntas frecuentes

¿Por qué me sale el error «cURL error 60» al intentar actualizar WordPress?

Porque el archivo interno de certificados que usa WordPress para verificar conexiones HTTPS, ca-bundle.crt, ha caducado. Es habitual en instalaciones que llevan mucho tiempo sin actualizarse, ya que ese archivo solo se renueva como parte de las propias actualizaciones de WordPress.

¿Puedo arreglar esto sin acceso técnico al servidor?

Normalmente no. Cuando el archivo de certificados está tan desactualizado que impide incluso conectar con WordPress.org, hace falta sustituirlo a mano entrando al servidor por FTP o SSH, y eso requiere ayuda técnica.

¿Es peligroso tener una web WordPress desactualizada aunque «funcione bien»?

Los números dicen que sí: el 91% de las vulnerabilidades de WordPress publicadas en 2025 eran de plugins, y los ataques masivos llegan en cuestión de horas tras hacerse públicas. Que la web se vea bien no significa que esté a salvo.

¿Cada cuánto debería actualizar mi web WordPress?

Al menos una vez al mes conviene revisar plugins y núcleo, y aplicar cualquier actualización de seguridad en cuanto esté disponible, siempre con un backup previo. Dejarlo acumular durante años es justo lo que provoca casos como el de este artículo.

¿Qué hago si mi web ya se ha caído y no sé por qué?

Empieza por identificar el error exacto, pantalla blanca, error 500, error de base de datos, aviso de conexión no segura, porque cada uno apunta a una causa distinta. Si no tienes backup reciente ni acceso técnico al servidor, mejor pedir ayuda antes de intentar arreglarlo a ciegas.