¿Por qué WordPress se cae o muestra un error 500?

Un error 500 indica que el servidor encontró un problema y no pudo completar la solicitud. El mensaje es intencionalmente general: confirma que ocurrió un fallo, pero no identifica su origen.

En WordPress, las causas frecuentes incluyen plugins o temas incompatibles, errores de PHP, falta de memoria, reglas incorrectas en .htaccess, permisos inadecuados, problemas en la base de datos o límites del servidor.

La solución no consiste en probar cambios al azar. Primero hay que preservar el estado del sitio, consultar los registros y relacionar el error con los cambios recientes.

Qué significa un error HTTP 500

El código HTTP 500 corresponde a un error interno del servidor. Puede aparecer en todo el sitio, únicamente en el administrador, en una página concreta o durante una acción como guardar, importar o procesar un pedido.

También puede mostrarse con mensajes similares:

• Internal Server Error.
• HTTP 500.
• La página no puede procesar la solicitud.
• Pantalla en blanco o mensaje genérico del servidor.

Antes de intervenir, registre la URL afectada, la hora aproximada, la acción realizada y cualquier cambio reciente. Esa información permite encontrar la entrada correspondiente en los registros.

Si el sitio todavía responde, pero lo hace con lentitud, el diagnóstico es diferente. La guía sobre causas comunes de un WordPress lento ayuda a revisar PHP, plugins, imágenes, base de datos, caché, consultas y recursos antes de que el problema se convierta en una caída.

Antes de modificar: haga una copia y conserve evidencia

Un sitio caído genera presión por restaurarlo rápidamente, pero borrar registros, actualizar todo o restaurar inmediatamente puede eliminar pistas importantes.

Antes de realizar cambios:

1. Compruebe si existe una copia reciente de archivos y base de datos.
2. Descargue o conserve los registros relacionados con el momento del error.
3. Anote actualizaciones, instalaciones y cambios realizados recientemente.
4. Confirme si el fallo afecta a todo el sitio o solo a una función.
5. Realice una copia del estado actual si todavía es posible.

Una restauración puede recuperar el servicio, pero no siempre explica la causa. Si el origen permanece, el error puede reaparecer.

1. Plugins incompatibles o con errores

Un plugin puede provocar un error fatal después de actualizarse, entrar en conflicto con otro componente o ejecutar una función incompatible con la versión de PHP.

Las señales más claras son:

• El error comenzó después de instalar o actualizar un plugin.
• Solo falla una página o función asociada a ese plugin.
• El registro de PHP menciona archivos dentro de wp-content/plugins.
• El escritorio deja de cargar, pero algunos archivos estáticos siguen disponibles.

Si puede entrar al administrador, desactive primero el componente relacionado con el error. Si no puede acceder, un técnico puede deshabilitar temporalmente el plugin desde el sistema de archivos o mediante herramientas de administración.

No conviene eliminar el plugin de inmediato. Conservar sus archivos y registros facilita identificar la versión afectada y recuperar su configuración.

2. Problemas con el tema

El tema activo también ejecuta PHP. Una función incorrecta, una plantilla modificada o una incompatibilidad con WordPress puede provocar un error 500.

Para comprobarlo de forma segura, utilice un entorno de staging o active temporalmente un tema predeterminado, siempre que exista una copia y se conozca el impacto sobre el diseño y las funciones.

Si el error desaparece, revise el tema hijo, el archivo functions.php, las plantillas modificadas y cualquier cambio reciente. Sustituir el tema en producción sin preparación puede alterar menús, widgets o configuraciones visuales.

3. Error o incompatibilidad de PHP

WordPress, los plugins y el tema dependen de PHP. Una función inexistente, un error de sintaxis o una incompatibilidad entre versiones puede detener la ejecución.

El registro suele mostrar el archivo, la línea y el tipo de error. Esa información permite saber si el fallo pertenece al núcleo, a un plugin, al tema o a código personalizado.

Si el problema comenzó después de cambiar PHP, compruebe la compatibilidad de todos los componentes. Volver temporalmente a la versión anterior puede servir para restaurar el servicio, pero no debería reemplazar la corrección o actualización del software incompatible.

4. Memoria PHP agotada

Un proceso puede detenerse cuando supera la memoria disponible. Esto puede ocurrir durante importaciones, generación de informes, copias, edición con constructores visuales o procesos de WooCommerce.

El registro puede incluir un mensaje de memoria permitida agotada. Aumentar el límite puede recuperar una operación legítima, pero también puede ocultar un plugin que consume recursos de forma excesiva.

Antes de ampliar memoria, revise:

• Qué proceso estaba ejecutándose.
• Qué plugin o archivo aparece en el error.
• Si el consumo se repite con una acción concreta.
• Los límites reales de la cuenta de hosting.

Los valores configurados dentro de WordPress no pueden superar necesariamente los límites establecidos por PHP o el proveedor.

5. Archivo .htaccess incorrecto

En servidores compatibles, WordPress puede utilizar .htaccess para gestionar enlaces permanentes y otras reglas. Una directiva no admitida, una regla duplicada o una modificación de seguridad puede provocar un error interno.

La prueba habitual consiste en conservar una copia, renombrar temporalmente el archivo y comprobar si el sitio responde. Si vuelve a funcionar, se puede generar una configuración básica de enlaces permanentes y añadir después las reglas necesarias de una en una.

No todos los servidores utilizan .htaccess. Además, el archivo puede contener reglas de seguridad o redirecciones importantes, por lo que no debe borrarse sin conservar una copia.

6. Permisos o propietarios de archivos

Los permisos controlan qué puede leer, modificar o ejecutar el servidor. Valores demasiado restrictivos pueden impedir el acceso; valores excesivamente abiertos crean un riesgo de seguridad.

Como referencia general, muchos entornos utilizan permisos 755 para directorios y 644 para archivos, pero la configuración correcta depende del servidor y de cómo ejecuta PHP.

No aplique permisos recursivos sin confirmar la estructura. Archivos sensibles y entornos específicos pueden necesitar valores diferentes. El proveedor debería revisar también el propietario y el grupo, no solo el número de permiso.

7. Base de datos inaccesible o dañada

Los problemas de base de datos suelen mostrar un mensaje específico, pero algunas operaciones o plugins pueden terminar en un error 500 si una consulta falla.

Conviene revisar:

• Disponibilidad del servicio de base de datos.
• Credenciales configuradas en WordPress.
• Tablas con errores.
• Consultas lentas o bloqueadas.
• Espacio disponible.
• Conexiones simultáneas.

Reparar o modificar tablas debe realizarse después de crear una copia. En una tienda, membresía o sitio activo, una restauración puede sobrescribir pedidos, usuarios o cambios recientes.

8. Recursos o procesos del servidor

El error puede originarse fuera del código de WordPress. Falta de CPU, memoria, procesos disponibles, espacio o capacidad de entrada y salida puede impedir que el servidor complete la solicitud.

También deben revisarse servicios detenidos, reinicios, reglas de seguridad, límites de PHP y fallos en componentes del servidor web.

Si el problema aparece solo durante picos de tráfico o tareas específicas, compare la hora del error con las métricas de recursos. Ampliar el plan tiene sentido cuando existe una limitación sostenida y comprobada, no como primera respuesta ante cualquier error 500.

9. Una actualización reciente rompió el sitio

Cuando el fallo comienza inmediatamente después de actualizar WordPress, un plugin o el tema, la relación temporal es una pista importante. No significa necesariamente que la actualización esté defectuosa: también puede haber revelado una incompatibilidad existente.

En ese caso, el proceso correcto incluye comprobar registros, identificar el componente, restaurar el servicio y corregir la incompatibilidad antes de volver a actualizar. La guía sobre qué hacer cuando una actualización de WordPress rompe el sitio desarrolla ese procedimiento paso a paso.

Cómo obtener información útil del error

La pantalla pública suele ocultar detalles por seguridad. La información necesaria se encuentra normalmente en los registros del servidor, PHP y WordPress.

WordPress dispone de un modo de depuración que puede registrar errores en un archivo. Debe activarse con precaución, evitando mostrar detalles técnicos a los visitantes y desactivándolo al terminar.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Estas líneas deben colocarse correctamente en wp-config.php y no duplicar constantes existentes. Antes de editar el archivo, cree una copia. En producción, el registro también puede contener rutas y otra información técnica que no debe quedar expuesta ni conservarse indefinidamente.

Busque el primer error fatal relacionado con el momento de la incidencia. Los avisos posteriores pueden ser una consecuencia y no la causa inicial.

Orden recomendado para diagnosticar el error 500

1. Registre la hora, la URL y la acción que produjo el error.
2. Conserve registros y confirme que exista una copia recuperable.
3. Revise cambios, instalaciones y actualizaciones recientes.
4. Consulte los errores de PHP, WordPress y el servidor web.
5. Aísle plugins o tema si los registros los señalan.
6. Compruebe PHP, memoria, .htaccess y permisos.
7. Revise base de datos, espacio y recursos del servidor.
8. Restaure si es necesario para recuperar el servicio.
9. Corrija la causa y vuelva a comprobar el sitio.

Realice un cambio por vez. Si se modifican varios componentes simultáneamente, será difícil saber cuál resolvió el problema y cuál podría haber creado otro.

Qué debería revisar el proveedor de hosting

El proveedor tiene visibilidad sobre elementos que el propietario del sitio no siempre puede consultar. Ante un error 500 debería poder revisar, dentro del alcance contratado:

• Registros del servidor web y de PHP.
• Consumo y límites de CPU, memoria, procesos y entrada/salida.
• Versión, módulos y configuración efectiva de PHP.
• Disponibilidad de la base de datos.
• Espacio e inodos disponibles.
• Permisos y propietarios de archivos.
• Reglas de seguridad que puedan estar bloqueando la solicitud.
• Estado general de los servicios de alojamiento.

El proveedor no necesariamente corregirá el código de un plugin o tema, pero sí debería ayudar a diferenciar una falla de infraestructura de una falla de la aplicación. Ese es uno de los valores de un Hosting WordPress Administrado: contar con soporte que revise el entorno de WordPress y no únicamente si el servidor está encendido.

Preguntas frecuentes

¿Un error 500 significa que el servidor está caído?

No necesariamente. El servidor puede estar funcionando, pero una solicitud concreta falla por PHP, WordPress, configuración o falta de recursos.

¿Puedo resolverlo desactivando todos los plugins?

Puede servir como prueba controlada, pero primero conviene revisar los registros y conservar una copia. Desactivar todo en producción puede interrumpir pagos, formularios y otras funciones.

¿Aumentar la memoria solucionará el error?

Solo cuando la causa sea una falta real de memoria. Si existe un error de código, incompatibilidad o bucle, ampliar el límite puede no resolverlo.

¿Debo restaurar inmediatamente un backup?

Depende del impacto y de la actividad del sitio. Restaurar puede ser la vía más rápida para recuperar el servicio, pero podría sobrescribir pedidos o cambios recientes. Conserve primero los registros y valore la pérdida de datos.

¿El error puede desaparecer solo?

Puede desaparecer si estaba relacionado con un pico temporal o un servicio reiniciado, pero eso no demuestra que la causa esté resuelta. Revise registros y recursos para evitar que se repita.

Conclusión

El error 500 en WordPress es un síntoma, no un diagnóstico. Plugins, temas, PHP, memoria, .htaccess, permisos, base de datos y recursos del servidor pueden producir el mismo resultado visible.

La forma más segura de resolverlo es conservar evidencia, consultar registros, relacionar el fallo con cambios recientes y aislar una causa a la vez. Recuperar el sitio es prioritario, pero identificar el origen es lo que evita que el problema vuelva.