Un error 500 en PrestaShop puede dejar la tienda inaccesible. A veces aparece solo en el back-office, en una ficha de producto, en el carrito o en el momento del pago. El problema es que el mensaje Internal Server Error dice muy poco por sí solo.

El buen reflejo no es modificarlo todo a la vez. Primero debe obtener el mensaje real, y luego probar en un orden lógico: modo debug, logs, última modificación, módulos, caché y entorno servidor. Al final de esta guía sabrá qué comprobar, en qué orden y cuándo conviene dejar de experimentar para no agravar la caída.

Lo que realmente significa un error 500 en PrestaShop

El código 500 es un síntoma genérico. Antes de tocar ficheros o el servidor, empiece por precisar el perímetro exacto de la incidencia.

Entender por qué el código 500 no basta por sí solo

Según MDN, a 20 de octubre de 2026, el código HTTP 500 significa que el servidor encontró una condición inesperada y no pudo devolver un código 5xx más preciso. Dicho de otro modo, el 500 no es una causa. Es el síntoma visible de un error más concreto que debe localizar usando el modo debug o los logs.

Un mismo síntoma puede venir de un módulo incompatible, de una caché obsoleta, de un cambio de PHP, de un .htaccess inválido, de falta de memoria o de permisos incorrectos. Si restaura todo demasiado pronto, perderá tiempo y añadirá una reversión pesada cuando la corrección podía ser puntual.

Identificar si la incidencia afecta a todo el sitio, al back-office o a una acción concreta

Antes de cualquier prueba, anote qué es exactamente lo que falla:

Este paso le ahorra tiempo, porque no buscará en el mismo sitio si se cae todo el sitio o solo un paso del embudo. Si desea ampliar el diagnóstico más allá del 500, también puede consultar las causas frecuentes de una tienda PrestaShop en fallo.

Hacer aparecer el mensaje real con el modo debug y los logs

Mientras no tenga el mensaje real, avanzará a ciegas. El objetivo de este paso es simple: hacer que PrestaShop hable y cruzar esa información con los registros PHP y del servidor.

Activar el modo debug si el back-office es inaccesible

Por defecto, PrestaShop oculta los errores en el front. La documentación oficial indica, a 20 de octubre de 2026, activar el modo debug poniendo _PS_MODE_DEV_ a true en /config/defines.inc.php, o desde el back-office si aún es accesible: documentación PrestaShop 9.

Haga esta prueba solo durante el diagnóstico. La misma documentación señala que el modo debug impacta mucho en el rendimiento y debe desactivarse tras el análisis. El objetivo es obtener el mensaje preciso, el fichero, la clase, el módulo o la función implicada, y luego volver a la configuración normal.

Si su administración no responde en absoluto, el diagnóstico rápidamente supera la simple lectura de errores. En ese caso, puede comparar sus síntomas con la página dedicada a un back-office PrestaShop inaccesible.

Leer los logs útiles: PrestaShop, PHP, Apache o Nginx

El modo debug ayuda, pero suelen ser los logs los que aportan la causa explotable. Reproduzca la incidencia, anote la hora exacta y luego lea las entradas correspondientes en:

El manual de PHP recuerda que en producción no hay que dejar el display de errores activado, y que log_errors permite registrar errores en el log definido por error_log. En el lado servidor, los registros de errores son un activo de diagnóstico mayor. Lo que busca no es un historial largo, sino la primera entrada útil en el momento exacto en que reproduce el 500.

Concretamente, anote el fichero implicado, el módulo citado, un error de memoria, una incompatibilidad de versión, una directiva denegada o un error de sintaxis. Sin esa línea precisa, corre el riesgo de corregir un efecto secundario en lugar de la causa.

Empezar por la última modificación realizada en la tienda

La pregunta correcta suele ser simple: ¿qué cambió justo antes de la incidencia? A menudo es el mejor punto de entrada, mucho antes que hipótesis generales.

Probar los módulos instalados o actualizados justo antes del 500

El centro de ayuda de PrestaShop indica, a 18 de julio de 2025, que un error 500 tras instalar o actualizar un módulo puede venir de incompatibilidades entre módulos, incompatibilidad con la versión de PrestaShop, caché obsoleta, conflicto de código o actualización incompleta: ayuda PrestaShop sobre error 500 tras actualizar un módulo.

Empiece por la lista de cambios recientes:

El método útil es simple: compruebe la compatibilidad anunciada y desactive los módulos instalados o actualizados recientemente uno por uno para identificar al culpable. Si debe elegir un único punto de control prioritario tras leer los logs, empiece por el último módulo modificado. Para evitar este tipo de interrupciones, puede también leer cómo detectar un módulo PrestaShop mal codificado antes de instalarlo.

Vaciar la caché correctamente antes de seguir

Vaciar la caché puede ser suficiente si la incidencia apareció tras una instalación, una actualización o una modificación de código que no se aplicó correctamente. PrestaShop recomienda eliminar la carpeta ./var/cache/prod por FTP, o hacerlo desde el back-office si este sigue accesible.

Sin embargo, no convierta esto en un reflejo universal. Si sus logs muestran claramente una incompatibilidad de PHP, un error de memoria o una directiva servidor inválida, vaciar la caché no arreglará la causa. Úselo como prueba dirigida, no como respuesta automática a cualquier 500.

Verificar la base del servidor: .htaccess, versión PHP, memoria y permisos

Si la incidencia no proviene de un módulo reciente, suba un nivel: el entorno de ejecución. A menudo ahí se esconden errores surgidos tras un cambio de hosting o de configuración del servidor.

Controlar el fichero .htaccess sin convertirlo en la causa universal

PrestaShop cita un .htaccess mal configurado entre las posibles causas de un error 500, sobre todo alrededor de la reescritura de URL y las Friendly URLs. Pero este control solo es pertinente si su tienda funciona sobre Apache. La documentación de sistema de PrestaShop 9 recuerda, a 20 de octubre de 2026, que PrestaShop puede ejecutarse sobre Apache o sobre Nginx.

En Apache la sintaxis del .htaccess es estricta. Una directiva no permitida o un error de sintaxis puede provocar una 500, generalmente visible en el error log. Si la incidencia apareció justo después de modificar reglas de reescritura, pegar reglas o regenerar el fichero de forma insegura, compruebe ese fichero rápidamente. Si está en Nginx, no pierda tiempo en este punto: busque antes la configuración del servidor y los logs correspondientes.

Comparar la versión de PHP y la memoria disponible con los requisitos de PrestaShop

Un cambio de versión PHP puede romper una tienda que funcionaba el día anterior. Es típico tras un cambio de hosting, una actualización desde el panel o un incremento de versión sin verificar compatibilidades.

Según los requisitos de sistema de PrestaShop 9, a 20 de octubre de 2026, PrestaShop 9.0 soporta PHP 8.1 a 8.4. La rama 9.1 soporta PHP 8.1 a 8.5, con PHP 8.5 recomendado para 9.1. La misma documentación recomienda un memory_limit mínimo de 512M.

Dos puntos prácticos:

No mezcle los requisitos de PrestaShop 9 con los de otra rama. Un diagnóstico correcto depende de su versión real.

Comprobar los permisos sin abrir excesivamente los derechos

El centro de ayuda de PrestaShop también incluye permisos incorrectos entre las causas posibles de un error 500. Lo importante es mantener la medida: unos permisos demasiado restrictivos impiden la ejecución, pero unos permisos demasiado abiertos degradan la seguridad.

Si la incidencia aparece tras un despliegue manual, una transferencia FTP, una migración o una intervención sobre ficheros, compare lo que cambió. Y no tome chmod 777 como solución estándar. Los permisos esperados dependen del servidor y de su configuración. De nuevo, el log del servidor suele ser el mejor árbitro.

Avanzar en el orden correcto según la zona afectada

No necesita el mismo camino de diagnóstico si se cae toda la tienda o si solo falla una acción. Aquí el orden más rentable para evitar rodeos.

Si toda la tienda devuelve una 500

Cuando todo el sitio está afectado, proceda en este orden:

  1. reproducir la incidencia y anotar la hora exacta;
  2. activar brevemente el modo debug para sacar el mensaje real si es posible;
  3. leer los logs PHP y del servidor en la misma franja horaria;
  4. verificar la última modificación: módulo, actualización, cambio de PHP, intervención en el servidor;
  5. vaciar la caché solo si el contexto lo justifica;
  6. comprobar a continuación .htaccess, versión PHP, memoria y permisos.

Lo que debe evitar: restaurar una copia de seguridad como primer reflejo sin haber identificado la causa. Es una reversión pesada, no una herramienta de diagnóstico. Mientras no tenga una pista precisa, concéntrese en los logs y en el último cambio realizado.

Si solo falla una zona: back-office, ficha de producto, carrito o checkout

Cuando la 500 solo afecta a una zona, el diagnóstico es más rápido. Reproduzca exactamente la acción que falla y luego busque el log correspondiente al mismo momento. Una 500 en una ficha de producto no apunta a los mismos componentes que una 500 en el momento del pago.

Algunas referencias sencillas:

Si el error solo aparece en el momento de realizar un pedido, la caída puede costar inmediatamente facturación. En ese caso puede comparar sus síntomas con la página dedicada al bug de carrito o checkout PrestaShop.

Cuándo pasar la mano para volver a poner la tienda en línea sin agravar la incidencia

El momento correcto para dejar de probar es cuando las pruebas no aportan información nueva. A partir de ahí, conviene entregar un expediente limpio en lugar de multiplicar pruebas arriesgadas.

Señales que justifican una intervención técnica inmediata

Cese las manipulaciones si se encuentra en uno de estos casos:

En ese punto, el riesgo ya no es solo perder tiempo. También puede ocultar la causa inicial, crear una segunda incidencia o retrasar la vuelta a la normalidad.

La lista mínima a entregar para ahorrar tiempo

Si encarga el diagnóstico, envíe como mínimo:

Con estos elementos, el diagnóstico arranca de inmediato en la dirección correcta.

Si necesita una intervención, la página diagnóstico y corrección de un error 500 PrestaShop presenta el marco de actuación. Y si la tienda está caída o el túnel de pedido está bloqueado, también puede solicitar una asistencia urgente en PrestaShop: diagnóstico gratuito, respuesta en 24 h, presupuesto en 24 h hábiles y tarifa anunciada de 70 € HT/h.

Preguntas frecuentes

¿Cómo activar el modo debug de PrestaShop si el back-office es inaccesible?

Si el back-office no responde, puede activar el modo debug directamente en los ficheros de la tienda. La documentación de PrestaShop 9 indica cambiar la constante _PS_MODE_DEV_ a true en /config/defines.inc.php. Hágalo solo durante el diagnóstico: el objetivo es obtener el mensaje real y luego desactivar este modo cuando termine el análisis.

¿Dónde encontrar los logs útiles para una error 500: PrestaShop, PHP, Apache o Nginx?

Empiece por los logs que corresponden al instante exacto en que reproduce la incidencia. Los más útiles son los registros PHP y los del servidor web, Apache o Nginx según su hosting. Si PrestaShop muestra también un mensaje en modo debug, crúcelo con esos logs. Busque la primera entrada explotable: fichero, módulo, memoria, sintaxis o directiva denegada.

¿Un error 500 puede venir de un módulo instalado o actualizado justo antes?

Sí. El centro de ayuda de PrestaShop incluye entre las causas posibles la incompatibilidad con la versión de PrestaShop, conflicto entre módulos, caché obsoleta, conflicto de código o una actualización incompleta. La prueba adecuada es partir de la última modificación: comprobar compatibilidades y desactivar los módulos instalados o actualizados recientemente uno por uno.

¿Cómo saber si el fichero .htaccess es responsable del error 500?

El .htaccess es una vía útil solo si su tienda funciona sobre Apache. En ese servidor, un error de sintaxis o una directiva no permitida puede disparar una 500, normalmente visible en el error log. Si está en Nginx, ese fichero no es el foco correcto. Compruebe primero el tipo de servidor antes de dedicar tiempo a este punto.

¿La versión de PHP puede romper una tienda PrestaShop de un día para otro?

Sí, sobre todo tras un cambio de hosting o una modificación de versión en el servidor. Si su tienda o un módulo no es compatible con la versión PHP activa, puede aparecer de inmediato una error 500. A 20 de octubre de 2026, la documentación de PrestaShop 9 indica que la rama 9.0 soporta PHP 8.1 a 8.4 y la 9.1 PHP 8.1 a 8.5.

¿La falta de memoria PHP (memory_limit) puede provocar una error 500?

Sí. Si el proceso se queda sin memoria durante una acción pesada, la petición puede fallar y devolver una 500. Lo más fiable es confirmarlo en los logs o con el mensaje obtenido en modo debug. Para PrestaShop 9, la documentación oficial recomienda un memory_limit mínimo de 512M a 20 de octubre de 2026.