0 Comentarios
Un error 500 en PrestaShop indica que el servidor no ha podido completar correctamente una petición, pero el código HTTP no explica por sí solo qué ha fallado. Puede haber un error de PHP, un módulo incompatible, un problema de permisos, una configuración incorrecta del servidor o varias causas distintas que terminan mostrando el mismo mensaje.
Por eso, empezar cambiando permisos, borrando archivos o aumentando la memoria PHP sin saber qué ocurre suele ser una mala estrategia. Primero hay que obtener el error real mediante el modo debug y los logs; después, corregir la causa que indiquen esos datos.
PrestaShop define el HTTP 500 como un error del lado del servidor y señala precisamente su carácter genérico: el mensaje puede aparecer por problemas de configuración PHP, programación o permisos, entre otros motivos.
Antes de modificar archivos o desactivar componentes, intenta reconstruir qué ocurrió justo antes del fallo.
Anota:
La secuencia temporal no demuestra que ese cambio sea necesariamente el culpable, pero sí establece por dónde conviene empezar a investigar.
También deberías disponer de una copia de seguridad recuperable de los archivos y la base de datos antes de realizar cambios relevantes. En una tienda en producción, restaurar una copia anterior puede implicar perder pedidos, altas de clientes, cambios de stock o modificaciones realizadas después de generar ese backup.
| Situación | Qué conviene investigar primero | Primera comprobación |
|---|---|---|
| Error tras instalar o actualizar un módulo | Incompatibilidad, archivos incompletos, conflicto de código o caché | Modo debug y logs; revisar el módulo modificado |
| Error después de actualizar PrestaShop | Compatibilidad de módulos, tema, PHP y proceso de actualización | Logs y requisitos de la versión instalada |
| Error después de una migración | PHP, permisos, configuración del servidor, rutas o archivos trasladados | Comparar entorno anterior y nuevo y revisar logs |
| Solo falla el back office | Módulo o controlador administrativo, caché, PHP | Reproducir la URL concreta con debug activo |
| Solo falla el front office | Tema, módulo del frontal, plantilla o caché | Logs y componente que interviene en esa página |
| El error es intermitente | Límites de recursos, tiempo de ejecución o procesos concretos | Relacionar la hora del fallo con los logs del servidor |
La tabla sirve para priorizar hipótesis, no para diagnosticar el problema sin comprobarlo.
El modo debug no arregla el error 500. Su función es proporcionar información que normalmente PrestaShop oculta al visitante: excepciones, archivos implicados, mensajes de PHP y otros datos que ayudan a localizar el origen.
Si puedes acceder al back office, en las versiones actuales puedes activarlo desde:
Parámetros avanzados > Rendimiento > Modo depuración
Si el back office también devuelve un 500, puedes activarlo desde el administrador de archivos o mediante el acceso técnico que te proporcione tu proveedor de hosting. En este caso, lo más recomendable es consultar el procedimiento específico para tu versión de PrestaShop o pedir al soporte del alojamiento que active temporalmente el modo debug.
Después, reproduce exactamente la acción que provoca el error.
En lugar de limitarte a ver una pantalla con «HTTP ERROR 500», podrías encontrar una excepción o un mensaje que apunte a un archivo, módulo, función o problema concreto.
No dejes el modo debug activo en una tienda en producción. Puede mostrar información técnica que no debe quedar expuesta y también afectar al rendimiento. Cuando hayas terminado el diagnóstico, desactívalo desde el back office o solicita al proveedor que lo desactive.
Documentación oficial de PrestaShop sobre el modo debug
Si el modo debug no ofrece información suficiente, el siguiente paso son los registros.
En versiones modernas de PrestaShop encontrarás logs de la aplicación dentro del área de registros de la instalación. La ubicación exacta puede variar según la versión y la configuración del servidor.
A eso se suman los registros de:
La ubicación concreta depende del servidor y del proveedor, por lo que no conviene asumir una ruta universal. Si no sabes dónde encontrarlos, solicita al hosting los registros de errores correspondientes a la hora en la que se produjo el fallo.
Busca entradas que coincidan con la misma hora en la que has reproducido el error. Algunas expresiones pueden dar una pista especialmente útil:
Lo importante no es localizar la palabra «500», sino encontrar el error anterior que ha provocado que el servidor termine respondiendo con ese código.
Este es uno de los escenarios más sencillos de acotar porque existe un cambio reciente muy concreto.
PrestaShop señala entre las posibles causas la incompatibilidad entre módulos o con la versión instalada, conflictos de código, caché desactualizada y actualizaciones que no se han completado correctamente.
Empieza comprobando el modo debug y los logs. Si apuntan al módulo que acabas de modificar, verifica que su versión sea compatible tanto con tu versión de PrestaShop como con PHP.
Si todavía tienes acceso al back office, puedes desactivar únicamente el componente sospechoso y comprobar si desaparece el fallo. Hacerlo módulo por módulo tiene mucho más sentido que desactivar indiscriminadamente todos los complementos de una tienda en producción.
Aquí ya conviene actuar con más cuidado. Renombrar carpetas, modificar la base de datos o eliminar archivos de un módulo puede tener efectos adicionales si ese componente interviene en el checkout, pagos, pedidos o integraciones externas.
Antes de hacerlo:
Si no tienes experiencia administrando archivos y bases de datos de PrestaShop, es preferible pedir ayuda al hosting o a un técnico especializado antes de realizar cambios manuales.
Tras una actualización de módulo, una caché antigua puede mantener información incompatible.
Si tienes acceso al back office, utiliza la opción de limpieza disponible en:
Parámetros avanzados > Rendimiento
Cuando no puedas acceder al panel, consulta con tu proveedor de hosting o con un técnico el procedimiento adecuado para limpiar únicamente la caché de PrestaShop correspondiente a tu versión.
No confundas esto con borrar carpetas completas de PrestaShop. Limpiar caché debe limitarse a los directorios generados para ese propósito.
Si al vaciarla el error reaparece inmediatamente, la caché probablemente no sea la causa original: vuelve a los logs.
Un fallo ligado al tema puede afectar únicamente al front office mientras el panel administrativo continúa funcionando.
Reproduce varias páginas antes de sacar conclusiones:
Si el error solo aparece en una de ellas, el dato es relevante: puede existir una plantilla concreta o un módulo asociado a ese punto de la tienda que esté provocando la excepción.
El modo debug debería indicar el componente implicado. No cambies de tema a ciegas en producción si hacerlo puede alterar configuraciones, posiciones de módulos o personalizaciones. Cuando sea posible, reproduce primero el problema en una copia de pruebas.
Una tienda que funcionaba correctamente puede empezar a fallar si cambia el entorno del servidor.
La compatibilidad con PHP depende de la versión exacta de PrestaShop. No existe una versión de PHP adecuada para todas.
Por ejemplo, las versiones de PrestaShop 8 y 9 tienen requisitos diferentes. Además, los módulos y temas pueden exigir versiones concretas de PHP aunque el núcleo de PrestaShop sea compatible.
Por eso, ante un error después de:
comprueba la versión exacta de PrestaShop y contrástala con su tabla oficial de compatibilidad.
Requisitos oficiales de PrestaShop
Una versión incompatible puede afectar también a módulos y temas, aunque el núcleo de PrestaShop sea compatible. Revisa por separado los requisitos de los componentes de terceros.
«Sube la memoria PHP» es una respuesta habitual ante un error 500, pero no sirve como diagnóstico.
Tiene sentido investigar este parámetro cuando el registro del servidor indica que se ha agotado la memoria disponible durante la ejecución de una petición.
En ese caso sí hay evidencia de que un proceso ha alcanzado el límite configurado. Sin embargo, aumentar la memoria puede ocultar temporalmente otro problema: una consulta demasiado pesada, un módulo defectuoso o un proceso que consume más recursos de lo debido.
Consulta con tu proveedor de hosting qué valores son compatibles con tu versión de PrestaShop y con el plan contratado. No modifiques este límite sin comprobar antes el mensaje exacto del registro.
Un error 500 que aparece solo durante una importación, generación de miniaturas, copia de seguridad o proceso similar tiene un contexto diferente al de una tienda que devuelve el código en todas sus páginas.
Algunos procesos largos pueden superar el tiempo máximo permitido por el servidor, entre ellos:
Si los registros muestran que se ha superado el tiempo de ejecución, consulta la configuración con el proveedor de hosting.
Aumentar el tiempo de ejecución sin haber encontrado antes esa evidencia no debería ser la primera medida.
La configuración de reescritura de URLs puede provocar un error interno cuando contiene una directiva inválida o existe un problema con las reglas del servidor.
Este tipo de incidencia debe investigarse especialmente si:
No elimines archivos de configuración sin conservar antes una copia. Si tienes acceso al back office y el problema está relacionado con las URLs amigables, utiliza las opciones de PrestaShop para regenerar la configuración en lugar de reconstruir reglas manualmente.
Ten en cuenta que los servidores Nginx no utilizan el mismo sistema de configuración que Apache. Por eso, el procedimiento depende del servidor web que utilice tu alojamiento.
Los permisos incorrectos pueden impedir que PHP o el servidor web lean o escriban determinados archivos. PrestaShop los contempla entre las posibles causas del HTTP 500.
Eso no significa que debas aplicar un cambio general sobre toda la tienda.
PrestaShop necesita permisos de escritura en determinados directorios, pero en producción deben ajustarse cuidadosamente y teniendo en cuenta el propietario y el grupo de los archivos.
Evita utilizar permisos completamente abiertos como arreglo genérico. Concede únicamente los permisos que necesite el usuario bajo el que se ejecutan PHP y el servidor.
Si no conoces la configuración del hosting, consulta sus valores recomendados antes de aplicar cambios masivos.
Cuando el error aparece al pasar de una versión a otra, no conviene tratar la actualización como una única pieza.
Comprueba por separado:
Los módulos obsoletos o incompatibles pueden provocar errores 500 al actualizar una tienda.
Si acabas de migrar de un servidor a otro, compara además ambos entornos. Una migración aparentemente idéntica puede terminar ejecutándose con otra versión de PHP, extensiones distintas o una configuración diferente.
Restaurar un backup puede ser adecuado cuando conoces con precisión el momento en que comenzó la incidencia y dispones de una copia válida inmediatamente anterior.
En una tienda online, esta decisión requiere más cuidado que en una web puramente informativa.
Imagina que la copia es de las 8:00 y el error aparece a las 13:00. Durante esas cinco horas pueden haberse registrado pedidos, pagos, clientes y cambios de stock. Restaurar directamente toda la base de datos a las 8:00 podría borrar esa actividad.
Antes de restaurar una copia:
El objetivo no es simplemente conseguir que vuelva a cargar, sino recuperar el servicio sin crear una segunda incidencia en los datos.
Si has llegado hasta aquí y el error continúa, entregar un «mi PrestaShop da error 500» obliga al técnico a empezar prácticamente desde cero.
Una incidencia bien documentada debería incluir:
Antes de compartir logs, elimina contraseñas, tokens, claves API, credenciales de base de datos y cualquier otro dato sensible.
Si la tienda está en producción y el diagnóstico ya requiere intervenir en servidor, módulos, código o base de datos, seguir haciendo cambios sin un punto claro de restauración puede aumentar el problema. En ese punto puedes recurrir al servicio de mantenimiento PrestaShop de Webtec para revisar la incidencia con el contexto técnico recopilado.
Ese contexto (el error real, los logs y el cambio que lo precedió) es mucho más útil que el código 500 por sí solo.
¿Qué te ha parecido este artículo?