Cuando una tienda PrestaShop cae, el riesgo no es solo la indisponibilidad. El verdadero problema suele ser la mala primera reacción: vaciar caches al azar, cambiar varios ajustes a la vez o relanzar una actualización sobre una tienda ya inestable.
Este artículo sirve para ordenar rápidamente. A 15 de septiembre de 2026, aquí tiene 10 causas frecuentes de un sitio PrestaShop caído, clasificadas por frecuencia observada en este tipo de incidentes, con para cada una dos referencias útiles: el síntoma típico y una verificación de 1 a 5 minutos que debe hacer antes de un soporte más técnico.
También sabrá distinguir una verdadera indisponibilidad de un falso positivo: modo mantenimiento activo, cache CDN engañosa o URL de administración errónea. A menudo es ese control el que ahorra más tiempo.
Empiece por distinguir una caída real de un falso positivo
Antes de buscar la causa profunda, asegure la tienda y elimine los casos simples que parecen una caída. En PrestaShop, un front-office deliberadamente cerrado, un cache externo o una URL de admin errónea pueden hacerle perder tiempo si parte demasiado pronto por la vía del servidor.
Poner la tienda a salvo sin agravar el incidente
Si la tienda responde de forma inestable, la reacción correcta es primero proteger a los visitantes. El modo mantenimiento de PrestaShop cierra temporalmente el front-office desde el back-office, en Parámetros de la tienda > Parámetros generales > Mantenimiento.
Sin acceso al back-office, PrestaShop documenta, para versiones a partir de 1.7, un cambio vía app/config/parameters.php pasando maintenance_mode de false a true. También existe un cambio vía base de datos con PS_SHOP_ENABLE, pero es un método de último recurso. No utilice esta vía sin una copia de seguridad reciente.
Si quiere evitar manipulaciones dispersas en una tienda en producción, la página sobre el mantenimiento mensual de una tienda PrestaShop presenta un marco de intervención más ordenado.
Descartar primero modo mantenimiento, cache y URL de administración
Comprobación simple inicial: ¿la tienda está realmente caída o solo desactivada? Un modo mantenimiento dejado activo tras una intervención es frecuente. Segunda comprobación: pruebe en navegación privada y, si puede, sin Cloudflare, sin CDN y sin cache servidor. PrestaShop lo recomienda para descartar un falso incidente de visualización o de acceso al back-office en su ayuda sobre la conexión al back-office.
Tercera comprobación: verifique la URL exacta de la carpeta /adminXXXX. Si esa carpeta ha sido renombrada o eliminada, la URL antigua devuelve lógicamente un 404 o una página en blanco. Si su duda es sobre el acceso de administración, empiece por el diagnóstico de un back-office PrestaShop inaccesible en lugar de correcciones más pesadas.
Las 10 causas más frecuentes de un sitio PrestaShop caído
Aquí está el núcleo del triage. La lista siguiente está ordenada por frecuencia observada en este tipo de incidentes. Para cada causa, aplique la misma metodología: identifique el síntoma dominante y luego haga una verificación corta. Si la respuesta es positiva, ya habrá reducido mucho el campo del diagnóstico.
Las causas 1 a 5 a comprobar primero
- Se ha actualizado, instalado o activado un módulo recientemente.
Síntoma típico: la caída aparece justo tras una intervención, a menudo con un error 500, una página en blanco o un back-office que no carga.
Comprobación rápida: trace la cronología exacta de las últimas acciones. PrestaShop indica que un error 500 ocurre con frecuencia tras una actualización de tema o módulos, y que módulos obsoletos o incompatibles tras una actualización mayor también pueden romper la tienda. Si el síntoma principal es ya una 500, consulte también el diagnóstico de un error 500 PrestaShop. - Se ha modificado o actualizado el tema.
Síntoma típico: el front-office se vuelve inaccesible o se muestra mal, aunque el servidor no esté necesariamente caído.
Comprobación rápida: pregunte qué se cambió justo antes de la caída: actualización del tema o intervención visual. Si la caída coincide con esa intervención, mantenga esa pista como prioritaria. - El modo mantenimiento está activo.
Síntoma típico: el front-office parece indisponible mientras el back-office sigue accesible.
Comprobación rápida: compruebe primero el estado del modo mantenimiento en PrestaShop. Es una verificación simple para hacer desde el inicio. - Un cache externo le muestra un incidente que ya no existe.
Síntoma típico: un equipo ve la caída y otro no; el acceso al back-office entra en bucle o se comporta distinto según el navegador.
Comprobación rápida: pruebe en navegación privada y luego sin Cloudflare, sin CDN o sin cache servidor si puede hacerlo rápido. Si la visualización cambia según el contexto, no concluya todavía que hay una caída del código. - La URL del back-office ya no es la correcta.
Síntoma típico: 404 o página en blanco en la dirección/adminXXXX, aunque la tienda no esté necesariamente totalmente caída.
Comprobación rápida: compare la URL usada con el nombre real de la carpeta de administración en el servidor. Un renombrado basta para hacer creer que el acceso está roto.
Las causas 6 a 10 a controlar a continuación
- La versión de PHP no es compatible con su rama de PrestaShop.
Síntoma típico: la caída aparece tras un cambio del proveedor de hosting, una migración o un intento de actualización que no arranca.
Comprobación rápida: compare la versión PHP activa con la requerida por su versión de PrestaShop. A 15 de septiembre de 2026, la documentación de sistema de PrestaShop 9 indica que la rama 9.0 soporta PHP 8.1 a 8.4 y recomienda PHP 8.4, mientras que 9.1 soporta PHP 8.1 a 8.5 y recomienda PHP 8.5. - El archivo
.htaccesscontiene un error.
Síntoma típico: error 500 aparecido tras un cambio relacionado con las URLs de la tienda.
Comprobación rápida: pregunte si el.htaccessse tocó justo antes del incidente. Su sintaxis es estricta; un único error basta para romper el acceso. - El servidor corta la ejecución antes de terminar.
Síntoma típico: la caída ocurre durante un import CSV, una copia de seguridad, la carga de traducciones, un import/export o la regeneración de miniaturas.
Comprobación rápida: verifique si el incidente empezó durante una tarea pesada. PrestaShop cita los timeouts de servidor entre las causas frecuentes de error 500 en esas operaciones. - El código y el esquema de base de datos ya no son coherentes.
Síntoma típico: una actualización se niega a arrancar o la tienda funciona mal tras una migración o una actualización incompleta.
Comprobación rápida: compruebe si una actualización fue interrumpida. La FAQ de actualización de PrestaShop indica que una discrepancia entre la versión del código y la versión del esquema en base puede bloquear el proceso. - El problema viene de los assets CSS o JavaScript, no del servidor en sí.
Síntoma típico: la tienda parece rota o inusable visualmente, aunque el servidor responde todavía.
Comprobación rápida: durante el diagnóstico de un tema o de una visualización, desactive las opciones CCC que combinan y minifican archivos CSS y JavaScript. La documentación de PrestaShop 9 lo recomienda para evitar falsos problemas de presentación.
Para el detalle técnico de una 500, de un .htaccess roto o de un timeout, la ayuda oficial sobre el error 500 PrestaShop confirma que el módulo no es la única pista: el servidor y la configuración también cuentan.
Verifique después qué cambió justo antes de la caída
Una tienda que cae de golpe suele tener un desencadenante cercano en el tiempo. Lo más útil no es comprobarlo todo, sino encontrar el evento que precedió al incidente por unos minutos u horas.
Los cambios aplicativos a comprobar primero
Empiece por la capa aplicativa: actualización de módulo, cambio de tema, intento de actualización de PrestaShop, migración o un parche entregado en urgencia. Si la caída sigue inmediatamente a uno de esos cambios, ya tiene al principal sospechoso.
Este punto es todavía más importante antes de una subida de versión. Si prepara el paso a la rama más reciente, relea lo que hay que comprobar antes de subir a PrestaShop 9: la compatibilidad de los módulos y del entorno sigue siendo el primer filtro.
Los cambios de entorno que rompen una tienda sin avisar
En el hosting, dos comprobaciones vuelven con frecuencia: la versión PHP activa y los recursos disponibles. A 15 de septiembre de 2026, los rangos de compatibilidad de PrestaShop 9 son precisos, y una versión de PHP demasiado baja o demasiado alta puede bloquear una actualización. La documentación del sistema de PrestaShop 9 recomienda también un memory_limit de al menos 512M por script.
Revise también los ajustes técnicos modificados por el proveedor de hosting o durante una migración. Esa misma documentación especifica, por ejemplo, que allow_url_fopen debe estar activado, ya que el acceso a ficheros remotos es esencial para ciertos procesos como el pago. No es la primera comprobación a hacer, pero es una pista seria cuando nada ha cambiado en el código.
Evite manipulaciones que empañen el diagnóstico
En una caída real, el tiempo se pierde a menudo menos buscándola que realizando pruebas equivocadas. El objetivo no es hacer muchas acciones, sino pocas y trazables.
No deje activado el modo debug ni cambios temporales en producción
El modo debug puede ayudar a entender un incidente, pero no debe permanecer activo en una tienda en producción. La documentación de PrestaShop aclara que tiene un impacto significativo en el rendimiento y que debe desactivarse tras el diagnóstico. En la práctica, también puede mostrar errores a los visitantes.
Otro punto olvidado con frecuencia: si modifica parameters.php, la documentación indica que hay que eliminar manualmente la caché en /var/cache/(dev|prod). Si no, corre el riesgo de probar una configuración que no es la realmente cargada por la tienda.
No multiplique modificaciones simultáneas
Evite encadenar varios cambios seguidos: desactivar un módulo, cambiar PHP, purgar cache, modificar el .htaccess y luego tocar la base de datos. Tras unos minutos, ya no sabrá qué acción tuvo efecto.
Evite también la modificación directa de la base sin una copia de seguridad reciente. PrestaShop documenta ese camino como arriesgado y de último recurso. Finalmente, no suponga que una simple purga de caché resolverá la mayoría de los casos: las causas oficiales incluyen también PHP, el esquema de la base, el .htaccess, los timeouts y módulos incompatibles.
Si la tienda sigue caída tras estas comprobaciones, pase al nivel correcto de intervención
Después de este triage, deberá poder responder a tres preguntas simples: ¿la caída es real o aparente?, ¿qué cambio probablemente la desencadenó? y ¿qué síntoma domina realmente? Si no tiene estas tres respuestas, continúe el triage. Si las tiene, detenga las pruebas improvisadas.
Los signos que imponen un soporte inmediato
No pierda más tiempo si la tienda está totalmente inaccesible, si el back-office está cortado, si el error vuelve tras cada prueba simple o si la caída sigue a una actualización, migración o cambio de entorno claramente identificado. En ese punto, la reacción correcta es priorizar la restauración antes que la búsqueda exhaustiva de causas secundarias.
Si su prioridad es la disponibilidad, opte por una intervención de urgencia en PrestaShop en lugar de una larga serie de pruebas en producción.
Accesos e información a preparar para ganar tiempo
Prepare la versión de PrestaShop, la versión de PHP activa, la hora de inicio del incidente, la última acción realizada antes de la caída y el síntoma exacto: error 500, página en blanco, back-office inaccesible, front en mantenimiento, visualización rota o timeout durante una tarea concreta. Estos elementos ahorran tiempo en los primeros minutos.
Si ha completado estas comprobaciones, el siguiente paso lógico es la restauración en línea de un sitio PrestaShop inaccesible. KLN-WEB interviene en la solución, urgencias y mantenimiento PrestaShop, con diagnóstico gratuito y un marco claro antes de cualquier intervención.
Preguntas frecuentes
¿Por qué mi PrestaShop muestra un error 500 justo tras actualizar un módulo o un tema?
Porque es una de las causas frecuentes documentadas por PrestaShop. Una actualización de módulo o tema puede introducir una incompatibilidad, especialmente tras una subida de versión. El primer paso es verificar la cronología: ¿qué se modificó, instaló o activó justo antes del error, y en qué versión exacta de PrestaShop?
¿Qué comprobar primero si el front-office no carga pero aún no he identificado la causa?
Empiece por descartar falsos positivos. Compruebe primero si el modo mantenimiento está activo. Pruebe luego en navegación privada y, si es posible, sin Cloudflare, sin CDN y sin cache servidor. Finalmente, vea si el back-office sigue accesible. Estas tres comprobaciones son rápidas y evitan avanzar prematuramente hacia una caída del servidor.
¿Cómo saber si la versión de PHP de mi hosting es incompatible con mi versión de PrestaShop?
Hay que comparar la versión PHP realmente ejecutada por el hosting con el rango soportado por su rama de PrestaShop. A 15 de septiembre de 2026, PrestaShop 9.0 soporta PHP 8.1 a 8.4 y 9.1 soporta PHP 8.1 a 8.5. Una versión demasiado baja o demasiado alta puede bloquear una actualización o provocar una caída tras un cambio de entorno.
¿Cómo poner la tienda en mantenimiento si el back-office de PrestaShop es inaccesible?
Para versiones a partir de 1.7, PrestaShop documenta un cambio vía el fichero app/config/parameters.php pasando maintenance_mode de false a true. Existe también un método vía base de datos con PS_SHOP_ENABLE, pero debe permanecer como último recurso. En ambos casos, es mejor disponer de una copia de seguridad reciente antes de actuar.
¿Por qué mi back-office devuelve un 404 o una página en blanco en la URL /adminXXXX?
La hipótesis inicial a comprobar es simplemente que la URL llamada ya no es la correcta. Si la carpeta admin se renombró o eliminó, la dirección antigua deja de funcionar. Este punto está documentado por PrestaShop y suele provocar un falso diagnóstico de caída total cuando el problema solo afecta al acceso de administración.
¿Pueden Cloudflare, el cache del servidor o un CDN hacerme creer que mi PrestaShop está caído?
Sí. PrestaShop recomienda explícitamente probar sin cache CDN, sin cache servidor o en navegación privada cuando el acceso al back-office falla. Un cache externo puede conservar un estado antiguo de error, una bucle o una visualización rota. Antes de concluir que existe una caída real, verifique siempre si el comportamiento cambia según el contexto de navegación.