Una tienda PrestaShop puede caer aunque nadie haya tocado el código la noche anterior. Sin actualización visible, sin módulo nuevo, y sin embargo el sitio se vuelve inaccesible, el pago falla o los emails de pedido dejan de enviarse.

El objetivo útil no es solo reparar después del incidente. Hay que diferenciar lo que corta toda la tienda, lo que rompe una función crítica y lo que permanece discreto hasta que llega el primer cliente bloqueado.

En este artículo encontrará una checklist sencilla, fechada el 16 de septiembre de 2026, para saber qué vigilar automáticamente y qué comprobar cada mes con el fin de anticipar una caída de PrestaShop antes de que sea visible para sus clientes.

Una tienda PrestaShop puede caer sin actualización visible

Muchos contenidos hablan sobre todo del post-mortem: error 500, pantalla en blanco, módulo roto. Eso es útil una vez que el sitio está parado. En la operación diaria, el reflejo correcto es clasificar los incidentes por nivel de gravedad para vigilar los puntos adecuados en cada momento.

Ahorrará tiempo si separa tres escenarios: la interrupción total, la función crítica rota y la caída silenciosa. Los controles prioritarios no son los mismos en cada caso.

Lo que corta todo el sitio

Aquí el síntoma es claro: la tienda no responde, el front no carga, el back-office queda inaccesible o aparece un error de servidor. Este tipo de incidente puede venir de un problema de hosting, disco saturado, dominio vencido o de un cambio técnico aplicado fuera de su radar.

Si ya está en esta situación, puede comparar los síntomas con las causas más frecuentes de una tienda PrestaShop caída. El punto importante es simple: una caída total no siempre está ligada a un despliegue reciente.

Lo que solo rompe una función clave

En este segundo caso, la tienda parece seguir en línea. Las fichas de producto se muestran, la página de inicio responde, pero una función esencial no funciona: el carrito, el checkout, el pago, el acceso cliente o el back-office.

Este escenario es traicionero, porque el problema puede persistir mientras el sitio sigue respondiendo. Ve tráfico, pero los pedidos no se completan correctamente.

Lo que permanece invisible hasta el primer cliente bloqueado

El tercer escenario es el más engañoso. El sitio sigue visible, pero los emails transaccionales no se envían, ciertos recursos dejan de cargarse en HTTPS o una dependencia externa ligada a un módulo no responde.

En una página servida por HTTPS, los navegadores bloquean los contenidos mixtos críticos. Tras una renovación de SSL o un cambio de dominio mal finalizado, algunos scripts o hojas de estilo llamados todavía por HTTP pueden romper una función sin tumbar todo el sitio.

Las expiraciones silenciosas a vigilar en prioridad

Los plazos olvidados provocan cortes evitables. Suelen ocurrir fuera de las ventanas de actualización, en el momento en que nadie espera un incidente.

Su objetivo no es memorizar esas fechas, sino sacarlas de la cabeza humana e integrarlas en una rutina documentada.

Certificado SSL público y certificado de origen

Un certificado SSL público vencido sigue siendo un clásico. Let’s Encrypt recuerda que sus certificados tienen una validez de 90 días y que su modelo se basa en el renovación automatizada, no en la manual: duración de los certificados Let’s Encrypt. Si la automatización falla y nadie controla la fecha de expiración, la tienda puede bloquearse de un día para otro.

Punto a menudo olvidado: si utiliza un CDN o un proxy, el certificado visible para el visitante no siempre es el único a vigilar. El certificado de origen también puede expirar en silencio. El error clásico es comprobar solo el candado en el navegador. Evítelo: compruebe también el certificado usado entre el proxy y el servidor.

Nombre de dominio y renovación

Un dominio vencido no corta necesariamente el sitio de la misma forma en todos los registrars. ICANN indica que puede existir un periodo de gracia, pero su efecto visible puede variar. La decisión correcta es tratar la fecha de expiración del dominio como una fecha firme, no como un margen de seguridad.

Que debe comprobar cada mes: la fecha de expiración, el modo de renovación, el método de pago asociado y la persona realmente responsable de la cuenta en el registrador. Caso típico: un dominio aún vinculado a una agencia anterior, a un empleado que se fue o a una dirección de email poco vigilada.

Licencia de módulo y dependencias externas

Una licencia de módulo vencida no siempre tumba toda la tienda. Sin embargo, puede bloquear una función crítica, un acceso API o impedir una actualización necesaria. Es típicamente el tipo de incidente que deja el front accesible mientras una pieza de negocio queda inservible.

El buen reflejo es llevar un inventario sencillo: nombre del módulo, rol en el negocio, fecha de expiración de la licencia, dependencia externa eventual, responsable y prueba a ejecutar tras la renovación. Sin ese inventario, descubre a menudo el problema el día en que el pago, el transportista o la sincronización dejan de responder.

Los cambios por parte del hosting que pueden romper la tienda de un día para otro

El hosting no es un decorado. Es una fuente de caída por sí misma. Una tienda estable durante meses puede perder ese equilibrio después de un cambio de versión de PHP, una memoria insuficiente o un espacio en disco saturado.

En este punto, los controles preventivos valen más que abrir un ticket después de la caída.

Versión PHP y memoria: el dúo a controlar de cerca

Un cambio de PHP aplicado por el hosting puede romper una tienda sin que usted haya modificado nada. Para PrestaShop 9, la documentación oficial recomienda PHP 8.5 y un memory_limit mínimo de 512M: requisitos del sistema de PrestaShop 9. También recuerda que hay que probar tema, módulos y personalizaciones antes de poner en producción.

Al 16 de septiembre de 2026, PHP recuerda que una rama tiene 2 años de soporte activo y luego 2 años de correcciones de seguridad. En esa fecha, PHP 8.2 ya no está en soporte activo y su fin de soporte de seguridad está fijado al 31 de diciembre de 2026: versiones PHP soportadas. Esto no significa que haya que cambiar a ciegas. Significa que una decisión sobre PHP debe estar fechada, probada y documentada.

Error típico: dejar que el hosting cambie PHP y comprobar solo si la página de inicio sigue cargando. Evítelo: pruebe también el back-office, el carrito, el funnel y los emails transaccionales. Si prepara una subida de versión, puede releer los puntos a verificar antes de actualizar PrestaShop.

Disco lleno, inodos saturados y base que no escribe

Cuando el disco está lleno, los síntomas pueden ser bruscos: escrituras imposibles en la base, back-office inestable, pedidos que no se registran correctamente. cPanel documenta por ejemplo el error MySQL «Got error 28 from storage engine» como síntoma de disco lleno: error MySQL 28 relacionado con almacenamiento.

Este problema suele permanecer discreto hasta el umbral crítico. La tienda parece normal y luego una tarea de escritura falla y aparezcan varios síntomas a la vez. El control útil no solo debe vigilar el espacio de disco global, sino también su evolución, los logs, las copias de seguridad, los ficheros de caché y los inodos si su hosting los limita.

Si la caída ya es visible en el servidor, un primer enfoque útil es lanzar un diagnóstico de error 500 en PrestaShop para distinguir un problema aplicativo de uno de infraestructura.

Por qué el sitio puede seguir abierto mientras los pedidos ya se pierden

Una tienda accesible no es necesariamente una tienda operativa. El coste aparece cuando un pedido no se confirma, no se puede restablecer una contraseña o un pago falla sin alerta inmediata.

Estas caídas parciales suelen durar más tiempo, precisamente porque ninguna página parece totalmente fuera de servicio.

Cuota de emails, colas y entregabilidad rota

Alcanzar una cuota de emails no necesariamente deja el sitio fuera de servicio. En cambio, puede bloquear el envío de emails de pedido, de creación de cuenta o de restablecimiento de contraseña. Es una diferencia importante: el cliente cree que ha pedido, pero no recibe ninguna confirmación.

Los puntos a vigilar son sencillos: volumen de envío, mensajes retrasados, fallos, buzones llenos, cuota de almacenamiento y saturación de inodos en la parte de mensajería. El error clásico es comprobar solo que el SMTP responde. Evítelo: compruebe también si los mensajes realmente salen, en qué plazos y si se acumulan rechazos o colas.

Checkout, pago y scripts bloqueados sin caída total

Tras una renovación de SSL mal finalizada, un cambio de dominio o un recurso todavía llamado por HTTP, ciertas partes del checkout pueden dejar de funcionar mientras la tienda sigue visible. El navegador bloquea entonces los contenidos mixtos críticos.

El síntoma típico es un funnel que carga parcialmente, un paso que entra en bucle, un botón de pago inactivo o un script de terceros que no se inicializa. Si observa este tipo de caída parcial, un primer paso útil es pedir un pre-audit de un pago PrestaShop que falla para aislar rápidamente el bloque en cuestión.

La monitorización mínima a implementar para ser alertado antes que sus clientes

Una monitorización eficaz no se limita a un ping de la página de inicio. Una tienda puede responder con HTTP 200 y sin embargo tener el carrito roto, un pago en error o emails que no se envían. El enfoque correcto combina alertas automáticas y un control mensual documentado.

Al 16 de septiembre de 2026, este marco puede ser sencillo: algunos puntos seguidos seriamente valen más que un dispositivo demasiado amplio que nunca se mantiene.

Las alertas automáticas a configurar

Primer nivel: la disponibilidad. Debe recibir una alerta si la página de inicio no responde o si su comportamiento cambia anormalmente.

Segundo nivel: los vencimientos. Programe recordatorios para el certificado SSL, el dominio y las licencias de los módulos críticos.

Tercer nivel: las funciones de negocio. Prevea al menos un control regular del back-office, del carrito, del pago y de un envío de email transaccional. Es este nivel el que detecta las caídas silenciosas antes que sus clientes.

Los controles mensuales a documentar

Una vez al mes, repita siempre la misma lista:

El punto decisivo es asignar un responsable a cada control. Una checklist sin propietario suele olvidarse. Si prefiere delegar este seguimiento, el mantenimiento mensual de una tienda PrestaShop permite establecer una rutina seguida en el tiempo.

Ponga en marcha una checklist anti-corte esta semana

No necesita rehacerlo todo para reducir el riesgo. Principalmente hay que sacar los puntos críticos de la improvisación. Empiece por establecer una lista de vencimientos, pruebas de negocio y personas responsables. Luego, ajuste las herramientas.

La checklist en 30 minutos para partir sobre una base sana

  1. Liste sus vencimientos: SSL, dominio, licencias de módulos críticos.
  2. Anote su versión PHP activa y el entorno de hosting realmente utilizado.
  3. Compruebe el espacio de disco disponible y las señales de saturación.
  4. Controle las cuotas de emails y el estado de los envíos transaccionales.
  5. Pruebe un recorrido corto: inicio, ficha de producto, añadir al carrito, checkout, email.
  6. Identifique quién recibe las alertas y quién interviene primero.

Esta base ya permite estructurar los controles más útiles sobre las causas silenciosas vistas más arriba. El error clásico es hacer estas comprobaciones una sola vez. El ritmo adecuado es mensual, con un registro escrito y fechado.

Cuándo pasar de un control interno a un soporte externo

Si depende de varios proveedores, un hosting, un CDN y módulos de terceros, la coordinación se convierte rápidamente en el punto débil. Desde el momento en que nadie es claramente responsable de la monitorización, es más seguro formalizar un soporte recurrente o un soporte puntual definido.

Si mantiene el control internamente, use esta checklist como procedimiento básico antes de abrir un ticket. Si este seguimiento no tiene un propietario claro, el soporte PrestaShop puntual o mensual permite encuadrar tanto el seguimiento como la intervención. En KLN-WEB, yo intervengo directamente para e-comerciantes y en marca blanca para agencias, con diagnóstico gratuito y respuesta en 24 h.

Preguntas frecuentes

¿Por qué una tienda PrestaShop puede caer sin ninguna actualización aparente?

Porque una caída no siempre procede del código desplegado. Una tienda puede fallar por un certificado SSL vencido, un dominio no renovado, un cambio de PHP aplicado por el hosting, un disco saturado o una licencia de módulo vencida. En muchos casos, nadie tocó el sitio la víspera, pero la explotación derivó hasta el punto de ruptura.

¿Cómo saber con antelación si el certificado SSL o el dominio van a expirar?

Lo más fiable es combinar un recordatorio automático con un control mensual documentado. Verifique la fecha de expiración del certificado público y, si usa proxy o CDN, controle también el certificado de origen. Para el dominio, nunca suponga que un periodo de gracia le salvará: anote la fecha, el modo de renovación y la persona responsable de la cuenta del registrador.

¿Un cambio de versión PHP por parte del hosting puede romper PrestaShop de un día para otro?

Sí. Una versión PHP modificada por el hosting puede sacar su tienda de su rango de compatibilidad o revelar una memoria insuficiente. El riesgo aumenta si el tema, los módulos o las personalizaciones no se han probado en esa versión. Por eso hay que vigilar la versión PHP activa, fechar la decisión técnica y probar front, back-office y funnel tras cualquier cambio.

¿Qué cuotas hay que vigilar para evitar una caída silenciosa: disco, inodos, emails, base de datos?

Vigile primero el espacio de disco disponible, porque un disco lleno puede impedir escrituras en la base y provocar síntomas bruscos. Compruebe también los inodos si su hosting los limita, así como las cuotas y colas de email. En cuanto a la base, lo útil no es solo su tamaño sino su capacidad de seguir escribiendo sin error en el momento de los pedidos.

¿Por qué el sitio sigue accesible aunque los emails de pedido o de contraseña no se envían?

Porque la visualización del sitio y el envío de emails transaccionales dependen de capas distintas. Una tienda puede seguir sirviendo páginas mientras se alcanza una cuota de emails, se alarga una cola o un buzón está lleno. Es una caída silenciosa clásica: el cliente ve el sitio, pero una parte del recorrido posterior al pedido ya no funciona.

¿Qué monitorización mínima implantar para ser alertado antes que los clientes?

Implante tres niveles. Primero, una alerta de disponibilidad si el sitio no responde. Luego, recordatorios de vencimiento para SSL, dominio y licencias críticas. Finalmente, un control de negocio regular del back-office, del carrito, del pago y de un email transaccional. Un simple ping a la página de inicio no basta, porque una tienda puede responder y aun así perder pedidos.