¿Cómo solucionar el error 500 Internal Server Error en WordPress?

El error 500 Internal Server Error en WordPress tiene una virtud casi artística: aparece cuando menos conviene y explica casi nada. Una pantalla blanca, un mensaje seco, el sitio caído. Es el equivalente digital de una puerta cerrada con un cartel que dice “algo salió mal”. Muy amable el servidor, desde luego.

Pero no hay que rendirse. El error 500 no es una condena: es un síntoma. Puede venir de un plugin con mala memoria, de un archivo .htaccess corrupto, de un límite PHP insuficiente, de permisos mal configurados, de una versión de PHP incompatible, de reglas de seguridad demasiado celosas o de un servidor saturado como una estación de tren en vísperas de vacaciones. El reto consiste en no golpear la web a ciegas, sino diagnosticarla con método.

En esta guía encontrarás un proceso ordenado para arreglar el error 500 en WordPress, desde las verificaciones rápidas hasta el análisis de logs, con ejemplos prácticos para cPanel, FTP/SFTP, WordPress, WP-CLI y servidores Apache o Nginx. La idea es simple: apagar el incendio sin quemar la casa. 🔥

Contenido rápido

• Qué significa realmente el error 500 en WordPress
• Qué hacer antes de tocar archivos
• Causas más frecuentes
• Pasos para solucionar el error 500
• Cómo leer los logs y activar depuración
• Casos especiales: WooCommerce, admin-ajax, REST API y migraciones
• Cómo prevenir que vuelva a ocurrir

Qué significa el error 500 Internal Server Error en WordPress

El código HTTP 500 indica un fallo interno del servidor. Es decir, el servidor recibió la petición del navegador, intentó procesarla y, en algún punto del camino, tropezó. No siempre significa que el servidor esté roto; a menudo el problema nace en la aplicación, en este caso WordPress, o en alguno de sus componentes.

En términos simples: el navegador pregunta “¿puedo ver esta página?” y el servidor responde “no sé cómo decírtelo, pero no”. Es una respuesta genérica, y precisamente por eso resulta frustrante. A diferencia de un error 404, que suele apuntar a una página inexistente, el 500 es una niebla. Densa, incómoda, a veces perfumada con PHP fatal errors.

La paradoja es evidente: WordPress es una plataforma diseñada para facilitar la publicación, pero su error más temido no publica nada, ni siquiera una pista decente. Democracia editorial por fuera; laberinto de dependencias por dentro.

Antes de tocar nada: tres reglas que evitan tragedias 🧯

Una vez, hace años, vi a alguien “solucionar” un error 500 eliminando media carpeta de plugins por FTP. El sitio volvió. También desapareció el sistema de reservas. Aquello fue una victoria parecida a curar un dolor de cabeza rompiendo el despertador: técnicamente había silencio, sí, pero no salud.

Antes de modificar archivos, sigue estas reglas:

1. Haz una copia de seguridad completa: archivos y base de datos. Si el hosting ofrece snapshots, úsalos. Si no, descarga por SFTP y exporta la base desde phpMyAdmin o una herramienta equivalente.
2. No pruebes diez cambios a la vez: cambia una cosa, verifica, documenta. El caos también sabe disfrazarse de productividad.
3. Si es un sitio crítico, trabaja en staging: una tienda WooCommerce, una web de reservas o un portal con usuarios no debería operarse directamente en producción salvo emergencia real.

⚠️ Importante: si no puedes acceder al panel de WordPress, no significa que todo esté perdido. La mayoría de soluciones se pueden aplicar desde el administrador de archivos del hosting, FTP/SFTP, SSH o WP-CLI.

Causas más frecuentes del error 500 en WordPress

El error 500 puede tener muchas caras. Algunas son banales; otras, más retorcidas. Lo útil es conocer el mapa antes de internarse en el bosque.

Cómo solucionar el error 500 Internal Server Error en WordPress, paso a paso

1. Recarga, prueba en incógnito y descarta cachés demasiado entusiastas 🔄

Parece básico, pero conviene empezar por lo simple. Recarga la página, prueba en una ventana de incógnito y revisa desde otro navegador o conexión. Si usas Cloudflare, un plugin de caché, Varnish, LiteSpeed Cache o caché del hosting, purga la caché.

La caché es maravillosa cuando acelera una web; cuando conserva un error, es como un museo dedicado al desastre. Bello, inútil y persistente.

• Limpia caché del navegador.
• Purge cache en Cloudflare o CDN.
• Vacía caché del plugin: LiteSpeed Cache, WP Rocket, W3 Total Cache, SG Optimizer, etc.
• Desactiva temporalmente optimizaciones agresivas si el error apareció tras minificar CSS/JS.

2. Revisa si el error afecta a todo el sitio o solo a una parte

Antes de operar, observa. No es lo mismo un error 500 en toda la web que uno limitado al área de administración, al checkout de WooCommerce o a una URL concreta.

• Todo el sitio caído: sospecha de .htaccess, plugins globales, tema, PHP o servidor.
• Solo wp-admin: puede ser plugin de seguridad, memoria PHP, conflictos de admin, cookies o reglas de acceso.
• Solo una página: revisa shortcode, constructor visual, plantilla, consulta pesada o contenido embebido.
• Solo al guardar: posible ModSecurity, firewall, límite de variables PHP o problema con REST API.
• Solo en WooCommerce checkout: pasarelas de pago, impuestos, envíos, hooks personalizados o falta de recursos.

3. Renombra el archivo .htaccess y regenera enlaces permanentes

En servidores Apache o LiteSpeed, WordPress utiliza el archivo .htaccess para gestionar reglas de reescritura, enlaces permanentes, redirecciones, seguridad y caché. Un pequeño error ahí puede derribar el sitio entero. Un punto y coma mal colocado no tiene épica, pero puede comportarse como un sabotaje.

Cómo probarlo:

1. Accede por FTP/SFTP o al administrador de archivos del hosting.
2. Entra en la carpeta raíz de WordPress, normalmente public_html, www o el directorio del dominio.
3. Busca el archivo .htaccess. Si no aparece, activa “mostrar archivos ocultos”.
4. Renómbralo a .htaccess_old.
5. Intenta cargar el sitio.

Si la web vuelve, el archivo estaba corrupto o contenía reglas conflictivas. Luego entra en WordPress y ve a Ajustes > Enlaces permanentes. Sin cambiar nada, pulsa Guardar cambios. WordPress generará un .htaccess limpio.

Contenido básico de .htaccess para una instalación WordPress estándar:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

📌 Nota: si usas WordPress en subdirectorio, multisitio, WooCommerce con reglas especiales, plugins de caché o redirecciones manuales, tu .htaccess puede necesitar reglas adicionales. No copies y pegues a ciegas si no conoces el entorno.

4. Desactiva todos los plugins sin entrar al panel

Los plugins son el gran milagro de WordPress y, a veces, su pequeña maldición. Permiten crear tiendas, academias, reservas, membresías y formularios con unos clics. También pueden declarar la guerra entre sí por una función duplicada, una librería vieja o una llamada PHP incompatible.

Si no puedes acceder a wp-admin, desactiva todos los plugins desde FTP/SFTP:

1. Ve a wp-content.
2. Renombra la carpeta plugins como plugins_old.
3. Crea una nueva carpeta vacía llamada plugins.
4. Prueba si el sitio carga.

Si funciona, el culpable está entre los plugins. Para encontrarlo:

1. Elimina la carpeta vacía plugins.
2. Renombra plugins_old de nuevo a plugins.
3. Entra a WordPress, donde los plugins deberían aparecer desactivados.
4. Actívalos uno por uno, comprobando el sitio tras cada activación.

También puedes desactivar un plugin concreto renombrando su carpeta interna. Por ejemplo:

wp-content/plugins/plugin-problematico
wp-content/plugins/plugin-problematico_old

5. Usa WP-CLI si tienes acceso SSH

Para desarrolladores o administradores con SSH, WP-CLI es una herramienta rápida y elegante. Un bisturí, no un martillo.

Desactivar todos los plugins:

wp plugin deactivate --all

Listar plugins y su estado:

wp plugin list

Activar uno por uno:

wp plugin activate nombre-del-plugin

Cambiar a un tema predeterminado:

wp theme activate twentytwentyfour

Comprobar la versión de WordPress:

wp core version

Verificar archivos del núcleo:

wp core verify-checksums

💡 Consejo técnico: si wp core verify-checksums detecta archivos modificados en el núcleo de WordPress, revisa si hay corrupción, una actualización incompleta o incluso malware. Los archivos core no deberían editarse manualmente.

6. Cambia temporalmente a un tema predeterminado

Un tema no solo define apariencia. En WordPress, un tema puede contener funciones PHP, plantillas, integraciones, constructores visuales, hooks, llamadas a APIs y dependencias. Puede ser una fachada bonita con una sala de máquinas bastante temperamental.

Si sospechas del tema, accede por FTP/SFTP a:

wp-content/themes/

Renombra la carpeta del tema activo. Por ejemplo:

mi-tema
mi-tema_old

WordPress intentará cargar otro tema disponible. Lo ideal es tener instalado un tema oficial reciente como twentytwentyfour o twentytwentyfive, según la versión disponible en tu instalación.

Si tienes acceso a la base de datos, también puedes cambiar el tema desde la tabla wp_options, editando los valores template y stylesheet. Ojo: el prefijo puede no ser wp_; muchas instalaciones usan prefijos personalizados por seguridad o por simple herencia histórica.

7. Aumenta el límite de memoria PHP, pero no lo uses como aspirina universal

WordPress puede fallar con error 500 si el proceso PHP se queda sin memoria. Esto es común en webs con WooCommerce, constructores visuales, plugins de membresía, importadores, sitios multilingües o paneles con muchas consultas. Aumentar memoria puede resolver el síntoma, aunque no siempre la causa. Dar más memoria a un plugin desbocado es como ampliar una autopista para un conductor que va en dirección contraria: ayuda un rato, hasta que deja de ayudar.

Abre wp-config.php y añade antes de la línea que dice /* That's all, stop editing! Happy publishing. */ o su equivalente:

define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');

En algunos hostings también puedes ajustar valores desde:

• cPanel > MultiPHP INI Editor.
• Panel del hosting > Configuración PHP.
• Archivo php.ini.
• Archivo .user.ini.
• Configuración de PHP-FPM, si administras el servidor.

Valores útiles a revisar:

memory_limit = 256M
max_execution_time = 120
max_input_time = 120
max_input_vars = 3000
post_max_size = 64M
upload_max_filesize = 64M

⚠️ Atención: si el hosting limita memoria a nivel de servidor, WordPress no podrá superar ese techo aunque lo definas en wp-config.php. En hosting compartido, la libertad técnica a veces es una habitación con paredes acolchadas.

8. Revisa la versión de PHP y compatibilidad

WordPress recomienda usar versiones modernas y mantenidas de PHP por seguridad y rendimiento. Sin embargo, no todos los plugins y temas avanzan al mismo ritmo. Ahí aparece una antítesis incómoda: el servidor quiere futuro; el plugin abandonado exige pasado.

Un error 500 puede aparecer tras cambiar de PHP 7.4 a PHP 8.1, 8.2 o 8.3 si algún componente utiliza funciones obsoletas, código incompatible o dependencias antiguas. También puede ocurrir lo contrario: un WordPress moderno funcionando sobre una versión PHP demasiado vieja.

Qué hacer:

• Consulta la versión PHP desde el panel del hosting.
• Comprueba los requisitos de WordPress, tema y plugins críticos.
• Actualiza plugins y tema antes de subir versión PHP.
• Prueba el cambio en staging si es posible.
• Revisa el log de errores para identificar funciones incompatibles.

Errores típicos en logs relacionados con compatibilidad:

PHP Fatal error: Uncaught Error: Call to undefined function
PHP Fatal error: Uncaught TypeError
PHP Deprecated: Creation of dynamic property
PHP Parse error: syntax error

No todos los avisos Deprecated provocan un error 500, pero sí indican deuda técnica. Y la deuda técnica, como la humedad en una pared, rara vez mejora si se la mira con optimismo.

9. Corrige permisos de archivos y carpetas

Después de una migración, restauración o subida por FTP, los permisos pueden quedar mal asignados. Si el servidor no puede leer o ejecutar lo necesario, WordPress puede responder con error 500.

Como regla general en muchos entornos Linux:

• Carpetas: 755
• Archivos: 644
• wp-config.php: 640 o 600, si el servidor lo permite

Evita permisos 777. Sí, a veces “funciona”. También funciona dejar la puerta de casa abierta para no perder las llaves. No por eso es una estrategia brillante.

Comandos orientativos por SSH, ejecutados desde la raíz de WordPress:

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

Si administras el servidor, revisa también propietario y grupo. En servidores con PHP-FPM, Apache o Nginx, un propietario incorrecto puede impedir escritura en wp-content/uploads, caché o actualizaciones.

10. Reinstala los archivos del núcleo de WordPress

Una actualización interrumpida, archivos dañados o una infección pueden corromper el núcleo de WordPress. La solución no es borrar todo y rezar, sino reinstalar los archivos core sin tocar wp-content ni la base de datos.

Desde el panel de WordPress, si puedes acceder:

1. Ve a Escritorio > Actualizaciones.
2. Haz clic en Reinstalar la versión actual.

Con WP-CLI:

wp core download --force

Manual por FTP/SFTP:

1. Descarga WordPress desde wordpress.org.
2. Descomprime el paquete.
3. Sube y reemplaza carpetas wp-admin y wp-includes.
4. Sube archivos raíz de WordPress, excepto wp-config.php.
5. No sobrescribas wp-content.

📌 Precaución: antes de reinstalar, haz copia de seguridad. El procedimiento es seguro si se ejecuta bien, pero el exceso de confianza tiene una larga carrera como villano silencioso.

11. Revisa reglas de seguridad, ModSecurity y firewall

Algunos errores 500 no vienen de WordPress, sino de filtros del servidor. ModSecurity, WAF del hosting, reglas anti-inyección, protección contra bots o firewalls de aplicaciones pueden bloquear peticiones legítimas. A veces ocurre al guardar una página con cierto código, al enviar formularios, al actualizar opciones de un constructor visual o al llamar a la REST API.

Señales típicas:

• El error aparece solo al guardar cambios.
• El contenido incluye scripts, iframes, JSON, reglas CSS largas o palabras que activan falsos positivos.
• Ocurre en Elementor, Divi, WPBakery, formularios o ajustes de plugins de seguridad.
• En logs aparecen referencias a ModSecurity, Access denied o reglas con ID.

Solución: contacta con el hosting y pide revisión del log de ModSecurity para la hora exacta del error. No conviene desactivar un firewall entero por comodidad; mejor ajustar la regla concreta si es un falso positivo.

12. Comprueba límites de CPU, procesos, I/O y base de datos

En hosting compartido, un sitio puede recibir un error 500 si supera límites de recursos: CPU, RAM, entrada/salida de disco, procesos PHP simultáneos o conexiones a base de datos. Esto suele manifestarse de forma intermitente: ahora funciona, ahora no, como una bombilla cansada en un pasillo antiguo.

Qué revisar en el panel del hosting:

• Uso de CPU.
• Uso de memoria física.
• Procesos de entrada.
• I/O y IOPS.
• Errores PHP.
• Consultas lentas MySQL/MariaDB.

Posibles medidas:

• Activar caché de página.
• Configurar object cache con Redis o Memcached si el hosting lo soporta.
• Optimizar consultas pesadas.
• Eliminar plugins redundantes.
• Revisar tareas cron internas.
• Usar CDN para archivos estáticos.
• Actualizar plan de hosting si la web ya superó la etapa de “pequeño proyecto”.

13. Revisa el cron de WordPress y tareas programadas

WordPress usa wp-cron.php para ejecutar tareas programadas: publicar entradas, enviar correos, sincronizar pedidos, limpiar caché, procesar suscripciones. En sitios con tráfico irregular o plugins pesados, WP-Cron puede generar picos de consumo.

Si el error 500 aparece en ciertos momentos o después de acciones concretas, revisa eventos cron con plugins especializados o WP-CLI:

wp cron event list

En sitios de alto tráfico, suele ser mejor desactivar WP-Cron interno y ejecutar un cron real desde el servidor:

define('DISABLE_WP_CRON', true);

Luego programar en el servidor una tarea como:

*/5 * * * * wget -q -O - https://tudominio.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Esto no es obligatorio para todos los sitios, pero en proyectos grandes aporta estabilidad. Orden frente a improvisación; reloj frente a estampida.

Cómo activar depuración y leer los logs de error en WordPress 🔍

Si el error 500 es una habitación a oscuras, los logs son la linterna. No siempre iluminan todo, pero casi siempre muestran dónde está el primer mueble contra el que vas a golpearte.

Activar WP_DEBUG correctamente

Edita el archivo wp-config.php y añade o modifica estas líneas antes de “Happy publishing”:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

Con esta configuración, WordPress guardará errores en:

wp-content/debug.log

No es recomendable mostrar errores en pantalla en un sitio público, porque pueden revelar rutas internas, nombres de plugins o información sensible. La transparencia es una virtud humana; en producción, a veces es una vulnerabilidad.

Dónde encontrar logs del servidor

Además de debug.log, revisa los logs del servidor. La ubicación depende del hosting:

• cPanel: Métricas > Errores, o archivos error_log en directorios del sitio.
• Plesk: Dominios > Logs.
• Apache: /var/log/apache2/error.log o /var/log/httpd/error_log.
• Nginx: /var/log/nginx/error.log.
• PHP-FPM: logs específicos del pool PHP, según configuración.
• Cloudflare: eventos de firewall, si el bloqueo ocurre antes de llegar al servidor.

Cómo interpretar un error fatal

Un registro típico puede verse así:

PHP Fatal error:  Uncaught Error: Call to undefined function ejemplo()
in /home/usuario/public_html/wp-content/plugins/mi-plugin/includes/class-main.php:127

Qué nos dice:

• Tipo de error: PHP Fatal error, capaz de provocar error 500.
• Función problemática: ejemplo().
• Ruta: el fallo está dentro de un plugin.
• Línea: archivo class-main.php, línea 127.

Con esa información, el camino se estrecha. Ya no persigues fantasmas: persigues un archivo, una función, una versión, una incompatibilidad.

✅ Buena práctica: cuando encuentres un error fatal en un plugin o tema comercial, envía al soporte el mensaje exacto del log, versión de WordPress, versión PHP y pasos para reproducirlo. “Mi web no funciona” es comprensible, pero “fatal error en archivo X línea Y con PHP 8.2” abre puertas más rápido.

Casos especiales donde el error 500 se disfraza mejor

Error 500 en WooCommerce

WooCommerce convierte WordPress en una tienda, pero también aumenta la complejidad: carrito, sesiones, pagos, correos, inventario, impuestos, envíos, webhooks. Es una pequeña ciudad comercial dentro de una web. Si algo falla en una avenida principal, el tráfico se atasca.

Revisa especialmente:

• Pasarelas de pago recientemente actualizadas.
• Plugins de facturación, impuestos o envíos.
• Hooks personalizados en functions.php.
• Plantillas sobrescritas en el tema.
• Memoria PHP y tiempo máximo de ejecución.
• Webhooks fallidos.
• Errores en checkout, carrito o página “Mi cuenta”.

Herramientas útiles:

• WooCommerce > Estado > Registro: logs propios de WooCommerce.
• WooCommerce > Estado del sistema: versiones, plantillas, límites PHP.
• Modo sandbox en pasarelas de pago para reproducir sin afectar pedidos reales.

Error 500 en admin-ajax.php

admin-ajax.php se utiliza para muchas acciones asíncronas en WordPress. Un error 500 ahí puede afectar formularios, constructores visuales, filtros, carritos dinámicos o paneles de administración.

Diagnóstico:

• Abre las herramientas de desarrollador del navegador.
• Ve a la pestaña Network o Red.
• Reproduce la acción que falla.
• Busca la petición a admin-ajax.php con estado 500.
• Revisa respuesta, payload y logs PHP.

Normalmente el problema no está en admin-ajax.php en sí, sino en una función enganchada a una acción AJAX por un plugin o tema.

Error 500 en la REST API

El editor de bloques, WooCommerce, aplicaciones externas y muchos plugins dependen de la REST API de WordPress. Si falla, puedes ver mensajes como “La actualización falló” o “Respuesta no válida”.

Prueba esta URL:

https://tudominio.com/wp-json/

Si devuelve error 500, revisa:

• Plugins de seguridad bloqueando REST API.
• Reglas .htaccess.
• Permalinks mal regenerados.
• Errores PHP en plugins que registran endpoints.
• Autenticación, cabeceras o reglas del servidor.

Error 500 después de migrar WordPress

Las migraciones son mudanzas digitales. Todo parece estar en cajas, pero siempre falta un tornillo de la cama o aparece una taza rota dentro de una bota. Tras mover WordPress a otro hosting o dominio, el error 500 puede venir de:

• Rutas absolutas antiguas en configuración.
• .htaccess incompatible con el nuevo servidor.
• Versión PHP distinta.
• Extensiones PHP faltantes.
• Permisos o propietarios incorrectos.
• Base de datos importada con prefijo diferente.
• URLs serializadas mal reemplazadas.

Para reemplazar URLs en WordPress, evita búsquedas manuales en SQL si hay datos serializados. Usa herramientas que respeten serialización, como WP-CLI:

wp search-replace 'https://dominio-antiguo.com' 'https://dominio-nuevo.com' --skip-columns=guid

Error 500 después de instalar un certificado SSL

Al activar HTTPS, pueden aparecer redirecciones en bucle o reglas conflictivas. No siempre se muestran como error 500, pero puede ocurrir si .htaccess, Cloudflare y WordPress intentan imponer HTTPS cada uno por su cuenta, como tres porteros peleando por abrir la misma puerta.

Revisa:

• URLs del sitio en Ajustes > Generales.
• Reglas de redirección HTTP a HTTPS.
• Modo SSL de Cloudflare: evita combinaciones incorrectas como “Flexible” cuando el servidor ya tiene SSL válido.
• Plugins de SSL duplicados o innecesarios.

Soluciones avanzadas para administradores y desarrolladores

Revisar configuración Nginx

En Nginx no se utiliza .htaccess. Las reglas están en archivos de configuración del servidor. Si el error 500 aparece tras cambios en Nginx, PHP-FPM o reglas de reescritura, revisa la configuración del bloque del sitio.

Ejemplo básico de bloque para WordPress:

location / {
    try_files $uri $uri/ /index.php?$args;
}

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
}

Comprueba sintaxis y recarga:

nginx -t
systemctl reload nginx

Si usas PHP-FPM:

systemctl status php8.2-fpm
journalctl -u php8.2-fpm --since "30 minutes ago"

Revisar extensiones PHP necesarias

WordPress y sus plugins pueden requerir extensiones como:

• mysqli o mysqlnd
• curl
• mbstring
• xml
• zip
• gd o imagick
• intl
• openssl

Una extensión faltante puede romper importadores, pasarelas, generación de imágenes, traducciones o integraciones externas. El error final puede ser 500, aunque la causa real sea una pieza ausente del motor.

Desactivar temporalmente object cache

Si usas Redis, Memcached u object cache persistente, una caché corrupta o una conexión fallida puede producir errores inesperados. Prueba a desactivar temporalmente el drop-in:

wp-content/object-cache.php

Renómbralo a:

object-cache.php_old

Después purga Redis o Memcached si tienes acceso. En WP-CLI:

wp cache flush

Revisar drop-ins de WordPress

En wp-content pueden existir archivos especiales llamados drop-ins, cargados por WordPress para funciones avanzadas:

• advanced-cache.php
• object-cache.php
• db.php
• maintenance.php
• sunrise.php en algunos multisitios

Plugins de caché, bases de datos avanzadas o multisitio pueden depender de ellos. Si un drop-in queda huérfano tras desinstalar un plugin, puede provocar errores. Renombrarlo temporalmente ayuda a descartar.

Qué hacer si el error 500 aparece solo en el administrador de WordPress

Cuando el sitio público carga, pero wp-admin muestra error 500, el diagnóstico cambia ligeramente. El área administrativa carga scripts, menús, widgets, notificaciones, actualizaciones y llamadas internas que el visitante común no ve.

Pasos recomendados:

1. Desactiva plugins de seguridad o administración pesada.
2. Aumenta WP_MAX_MEMORY_LIMIT.
3. Revisa errores en debug.log.
4. Desactiva widgets del escritorio si alguno consume APIs externas.
5. Comprueba si el error ocurre en una pantalla concreta: plugins, entradas, WooCommerce, Elementor, usuarios.
6. Revisa reglas de acceso a wp-admin o wp-login.php en .htaccess.

Si el error aparece al entrar con un usuario concreto, puede existir un problema con capacidades, metadatos de usuario, idioma del perfil o configuración personalizada de administración.

Qué hacer si aparece “There has been a critical error on this website”

Desde WordPress 5.2 existe una protección contra errores fatales que puede mostrar el mensaje: “There has been a critical error on this website” o su traducción. No es exactamente lo mismo que el error 500 genérico, pero ambos pueden compartir causa.

WordPress intenta enviar un correo al administrador con un enlace de modo recuperación. Si lo recibes, úsalo para entrar y desactivar el plugin o tema problemático. Si no llega, revisa logs.

Posibles razones por las que no recibes el correo:

• El correo administrador está desactualizado.
• El servidor no envía emails correctamente.
• No hay SMTP configurado.
• El error ocurre antes de que WordPress pueda enviar el aviso.

Lista rápida de diagnóstico: del síntoma a la causa 🧭

Errores comunes que empeoran el problema

La prisa es mala consejera, y en WordPress además suele tener acceso FTP. Evita estos errores:

• Borrar plugins en lugar de desactivarlos: puedes perder configuraciones o datos asociados.
• Editar archivos core: cualquier actualización sobrescribirá cambios, y además complica el diagnóstico.
• Dar permisos 777: abre riesgos de seguridad innecesarios.
• Desactivar todos los sistemas de seguridad sin revisar logs: arregla el síntoma y quizá invita al problema siguiente.
• Restaurar una copia antigua sin analizar: si no conoces la causa, el error puede volver.
• Actualizar todo en producción durante la caída: a veces resuelve; a veces convierte un incendio en festival pirotécnico.

Cómo prevenir futuros errores 500 en WordPress 🛡️

Una web saludable no es la que nunca falla, sino la que falla con menos frecuencia, deja rastros claros y se recupera rápido. La prevención no tiene el brillo heroico de una reparación urgente a medianoche, pero suele ser más barata, más tranquila y más profesional.

Mantén actualizaciones con criterio

• Actualiza WordPress, plugins y temas de forma regular.
• Revisa changelogs antes de actualizar componentes críticos.
• Haz backup antes de actualizaciones importantes.
• Prueba en staging si gestionas WooCommerce, membresías o LMS.

Elige plugins como quien elige socios

No instales plugins por impulso. Evalúa:

• Frecuencia de actualización.
• Compatibilidad con tu versión de WordPress y PHP.
• Soporte activo.
• Reputación y número de instalaciones.
• Impacto en rendimiento.

Menos plugins no siempre significa mejor web, pero plugins redundantes sí suelen significar problemas. Dos plugins de caché, tres constructores y cuatro suites de seguridad no crean una fortaleza; crean una asamblea ruidosa.

Implementa copias de seguridad automáticas

Una estrategia seria de backups debe incluir:

• Copias completas de archivos.
• Copias de base de datos.
• Almacenamiento externo: S3, Google Drive, Dropbox, servidor remoto.
• Retención suficiente: diaria, semanal y mensual según actividad.
• Pruebas de restauración. Un backup no probado es una promesa, no una garantía.

Monitoriza uptime y rendimiento

Usa herramientas de monitorización para detectar caídas antes que tus clientes:

• UptimeRobot.
• Better Stack.
• StatusCake.
• Pingdom.
• New Relic o similares para análisis avanzado.

También conviene revisar métricas de Core Web Vitals, tiempos de respuesta del servidor, consultas lentas y errores PHP recurrentes. Un error 500 rara vez nace de la nada; muchas veces venía dejando migas, pequeñas advertencias como hojas secas antes del incendio.

Usa staging y control de versiones

Para proyectos profesionales, el flujo ideal incluye:

• Entorno local o staging.
• Control de versiones con Git para tema personalizado y plugins propios.
• Despliegues documentados.
• Rollback rápido.
• Registro de cambios técnicos.

WordPress nació con espíritu editorial, pero los proyectos serios necesitan disciplina de ingeniería. Libertad para publicar; rigor para mantener. Esa tensión, bien gestionada, es donde una web deja de ser improvisación y se convierte en infraestructura.

Checklist final para reparar el error 500 en WordPress

• Hacer copia de seguridad de archivos y base de datos.
• Comprobar si el error afecta a todo el sitio o solo a una sección.
• Purgar caché del navegador, plugin, hosting y CDN.
• Renombrar .htaccess y regenerar enlaces permanentes.
• Desactivar plugins y reactivarlos uno por uno.
• Cambiar temporalmente a un tema predeterminado.
• Activar WP_DEBUG_LOG y revisar wp-content/debug.log.
• Consultar logs del servidor: Apache, Nginx, PHP-FPM o panel del hosting.
• Aumentar memoria PHP si hay errores de agotamiento de memoria.
• Verificar compatibilidad de PHP con WordPress, plugins y tema.
• Corregir permisos de archivos y carpetas.
• Reinstalar archivos core de WordPress si hay corrupción.
• Revisar ModSecurity, WAF y reglas del firewall.
• Analizar consumo de recursos del hosting.
• Documentar la causa y aplicar prevención.

Cuándo contactar con el hosting o con un desarrollador

Hay momentos en los que insistir solo alarga la caída. Contacta con tu proveedor de hosting si:

• No tienes acceso a logs del servidor.
• El error coincide con límites de CPU, RAM, procesos o I/O.
• Sospechas de ModSecurity o firewall.
• El servidor devuelve 500 incluso con plugins desactivados y .htaccess regenerado.
• Hay errores PHP-FPM, Nginx o Apache fuera del alcance de WordPress.

Acude a un desarrollador si:

• El log apunta a código personalizado.
• El error afecta procesos críticos de negocio.
• Hay incompatibilidades complejas entre plugins.
• Necesitas depurar consultas, hooks o integraciones externas.
• La web ha sido infectada o muestra archivos sospechosos.

Cuando escribas al soporte, incluye datos concretos:

• URL afectada.
• Hora aproximada del error y zona horaria.
• Acción que lo provoca.
• Captura de pantalla si aplica.
• Fragmento del log de error.
• Cambios recientes: actualizaciones, migración, plugins, PHP, SSL.

📎 Plantilla útil para soporte:

“Mi sitio WordPress muestra error 500 al acceder a [URL] desde las [hora]. Ocurrió después de [cambio realizado]. Ya probé [acciones]. ¿Podrían revisar logs de PHP/servidor y ModSecurity en ese intervalo? Adjunto error encontrado: [mensaje del log].”

Una última mirada: reparar no es adivinar

El 500 Internal Server Error en WordPress impresiona porque parece absoluto: una pantalla sin matices, una negativa sin explicación. Pero debajo de esa superficie opaca suele haber una causa concreta, casi doméstica: un plugin incompatible, una regla torcida, una memoria insuficiente, un permiso mal puesto, un servidor exhausto.

La diferencia entre una reparación profesional y una tarde de desesperación está en el método. Mirar logs. Cambiar una variable cada vez. Entender el contexto. No confundir rapidez con precipitación. En el fondo, mantener una web WordPress se parece a cuidar un jardín mecánico: hay que podar, actualizar, vigilar plagas, regar lo justo y no sorprenderse si una raíz invisible levanta una baldosa.

Si sigues este proceso, no solo podrás solucionar el error 500 en WordPress; también conocerás mejor tu sitio. Y eso, aunque llegue disfrazado de avería, es una forma extraña de progreso. A veces la web se cae para obligarnos a mirar lo que sostenía su equilibrio. Qué detalle tan poco elegante, pero tan instructivo. 🚀