Logo
WP Fix by Blimx

Error 500 Servidor Interno en WordPress — Guía Completa

Actualizado:
ErrorsDiagnostics

Qué significa realmente "500 Internal Server Error"

Un 500 es un reconocimiento del lado servidor de que algo fatal pasó durante la petición. El navegador muestra la página genérica porque el mensaje de error real podría filtrar información útil a los atacantes. La historia real siempre está en tu log del servidor — y una vez que lees el log, el 500 deja de ser misterioso.

Este artículo recorre las ocho causas específicas que vemos producir errores 500 en WordPress en 2026, ordenadas por frecuencia.

Causa 1 — Agotamiento de memoria PHP

La más común hoy. PHP se queda sin memoria a mitad de petición, el script termina, el servidor web devuelve 500.

Firma en el log

PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate X bytes) in /path/to/file.php on line N

Por qué pasa

  • Un bucle WP_Query grande cargando todo el post meta
  • Un plugin de imágenes procesando una subida enorme
  • Reconstrucción del sitemap de Yoast SEO con miles de URLs
  • Una operación de importación (WP All Import, CSV de WooCommerce)

El arreglo

Sube WP_MEMORY_LIMIT en wp-config.php a un valor sensato:

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

Reinicia PHP-FPM. La constante WP_MEMORY_LIMIT aplica a peticiones del front-end; WP_MAX_MEMORY_LIMIT aplica a operaciones del lado admin. Configurar ambas previene los 500 más comunes del lado admin.

Causa 2 — .htaccess corrupto tras plugin o migración

.htaccess controla el enrutamiento de Apache. WordPress, plugins de seguridad, plugins de caché y herramientas de migración escriben en él. Cuando esa escritura falla (race condition, problema de permisos, escritura parcial), Apache tropieza en la siguiente petición.

Firma en el log

Invalid command 'XYZ', perhaps misspelled or defined by a module not included in the server configuration

El arreglo

cd /var/www/yoursite
cp .htaccess .htaccess.broken

Reemplaza .htaccess con el bloque WordPress por defecto:

# 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

Luego reactiva el plugin que estaba escribiendo reglas custom (seguridad, caché) para que regenere sus reglas limpiamente.

Causa 3 — Error de sintaxis en un archivo PHP

Alguien editó una función del tema, un archivo de plugin o wp-config.php directamente. La edición introdujo sintaxis mala. PHP rehúsa ejecutar el archivo.

Firma en el log

PHP Parse error: syntax error, unexpected token "..." in /path/to/file.php on line N

El arreglo

  1. Identifica el archivo del log
  2. Entra por SSH y corre php -l /path/to/file.php para confirmar
  3. Compara con backup o historial git para ver qué cambió
  4. Revierte el cambio

Prevención: configura define('DISALLOW_FILE_EDIT', true); en wp-config.php para deshabilitar el editor de tema/plugin en admin. Fuerza ediciones a través de control de versiones apropiado.

Causa 4 — Conexión a base de datos cae a mitad de petición

La petición arranca, la conexión MySQL funciona. A mitad de petición MySQL crashea, se queda sin conexiones, o el socket se cae. PHP atrapa la excepción y muere.

Firma en el log

PHP Warning: mysqli_connect(): (HY000/2002): No such file or directory

o

WordPress database error MySQL server has gone away

El arreglo

Corto plazo: incrementa mysql.connect_timeout y wait_timeout en my.cnf. Reinicia MySQL.

Largo plazo: monitorea max_connections de MySQL y reduce fugas de conexiones (queries lentas, scripts PHP de larga duración manteniendo conexiones).

Causa 5 — Permisos de archivos equivocados tras backup/restore

Una restauración de backup puso ownership a root:root en lugar de www-data:www-data. Algunos hostings compartidos también marcan archivos world-writable (777) como riesgos de seguridad y rehúsan ejecutarlos.

Firma en el log

[error] (13)Permission denied: failed to open script "/var/www/yoursite/index.php"

El arreglo

cd /var/www/yoursite
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 600 wp-config.php
chown -R www-data:www-data .

Ajusta usuario/grupo para que coincida con tu entorno de hosting (a menudo nobody, apache o tu usuario cPanel).

Causa 6 — Plugin que llama una función eliminada en WordPress nuevo

WordPress periódicamente deprecia y elimina funciones. Plugins que no se han actualizado en años llaman funciones que ya no existen; llamar produce un fatal.

Firma en el log

PHP Fatal error: Uncaught Error: Call to undefined function wp_old_function() in /path/to/plugin.php

El arreglo

  1. Renombra la carpeta del plugin ofensor vía FTP para desactivarlo
  2. Encuentra un reemplazo mantenido
  3. Si debes mantenerlo, hace un fork y parchea la llamada

Largo plazo: audita plugins mensualmente. Cualquier cosa no actualizada en 12 meses es una responsabilidad.

Causa 7 — Versión PHP equivocada para el software instalado

WordPress 6.5+ requiere PHP 7.4 mínimo, recomienda 8.1+. Algunos hostings configuran cuentas nuevas con PHP 8.2 por defecto, lo cual rompe plugins aún no compatibles.

Firma en el log

PHP Fatal error: Uncaught Error: Cannot use object of type X as array

o

Deprecated: Required parameter $arg follows optional parameter $opt

El arreglo

En el panel del hosting, configura la versión PHP a la que tu stack soporta. Para la mayoría de sitios WordPress en 2026, PHP 8.1 es el punto óptimo — moderno suficiente para estar soportado, conservador suficiente para que la mayoría de plugins funcionen.

Causa 8 — Sin memoria a nivel del pool PHP-FPM

Diferente de la causa 1. Aquí PHP-FPM mismo se queda sin memoria porque demasiados workers se generan simultáneamente, cada uno con cientos de MB.

Firma en el log

WARNING: [pool www] server reached pm.max_children setting (X), consider raising it

El arreglo

No subas pm.max_children a ciegas. Calcula correctamente:

pm.max_children = (RAM Total - RAM OS - RAM MySQL) / RAM promedio por worker

Mide la RAM promedio por worker:

ps --no-headers -o "rss,cmd" -C php-fpm8.1 | awk '{ sum += $1 } END { print sum / NR / 1024 " MB" }'

Configura pm.max_children a ese valor calculado. Reinicia PHP-FPM.

El flujo diagnóstico en 4 pasos

Cuando aparezca el próximo 500:

  1. Lee el log, las top 50 entradas. No adivines.
  2. Compara la firma del log con las 8 causas de arriba.
  3. Aplica el arreglo dirigido, no un reflejo genérico de "subir memoria".
  4. Verifica la resolución con curl -I desde fuera de tu red.

Esta secuencia resuelve el 95% de errores 500 de WordPress en menos de 30 minutos.

Errores comunes durante el diagnóstico de 500

  • Reiniciar Apache/Nginx a ciegas — enmascara el problema hasta la siguiente petición, no arregla nada
  • Subir límites de memoria a 2GB — no arregla una fuga de memoria, solo la demora
  • Reinstalar el core de WordPress — no ayudará a menos que los archivos del core estén realmente corruptos (raro)
  • Editar `wp-config.php` sin hacer backup primero — un typo y creas un segundo 500 superpuesto al primero

Cuándo llamar a un especialista

Si has leído el log y la causa no coincide con las 8 de arriba, el problema es más exótico — código custom, una mala configuración a nivel servidor, o un payload de malware fingiendo ser un error normal.

Arreglo de emergencia 500 en minutos. Para 500s relacionados con base de datos ve error 500 servidor interno WordPress. Para errores críticos de WordPress más amplios ve arreglo de error crítico.