Pantalla en blanco. Cinco dígitos: 500. Sin panel de administración, sin sitio, sin pista de la causa. ¿Le suena familiar?

El error interno del servidor 500 de WordPress es el más silencioso de todos los errores. No le dice qué se rompió exactamente, lo que solo empeora el pánico. Pero la realidad es mundana: en 9 de cada 10 casos el culpable es un plugin, un tema o una sola línea mal formada en .htaccess. El servidor no se ha vuelto loco; simplemente encontró código que no puede ejecutar.

Analicemos los tres escenarios principales y arreglemos cada uno paso a paso. Sin pánico, sin llamar a su hosting a las tres de la mañana. Con sus propias manos, en 15 minutos.

💡 Resumen rápido:

• Desactive todos los plugins a la vez renombrando la carpeta plugins por FTP; si el error desaparece, el culpable está entre ellos
• Restablezca .htaccess a la plantilla estándar de WordPress: una directiva de caché o redirección rota puede tumbar su sitio al instante
• Active WP_DEBUG en wp-config.php para ver el archivo y la línea exactos con el error fatal
• Si su sitio acaba de mudarse a un nuevo hosting, verifique la versión de PHP: WordPress a partir de 2026 requiere PHP 8.3 o superior, y los plugins antiguos suelen ser incompatibles

Códigos de respuesta HTTP: lo que el servidor intenta decirle

Antes de sumergirse en la depuración, ayuda entender los fundamentos de las respuestas HTTP. El servidor siempre responde al navegador con un código de tres dígitos, y el primer dígito ya le indica dónde buscar el problema.

• 1xx, informativo: «se está estableciendo la conexión, por favor espere». Estos no tienen nada que ver con errores.
• 2xx, éxito. El famoso 200 OK significa que el servidor entregó la página sin quejas.
• 3xx, redirecciones. Por ejemplo, 301 (redirección permanente) o 307 (temporal). El navegador navega a la nueva dirección silenciosamente; esto es una orden, no un error.
• 4xx, error del lado del cliente. 404 Not Found significa que la página fue eliminada o la URL se escribió mal. El servidor está activo; el contenido simplemente no existe.
• 5xx, error del lado del servidor. Aquí es donde comienza nuestro territorio.

Entre los códigos 5xx, hay tres «pacientes» principales: 503 Service Unavailable (el servidor está sobrecargado; se soluciona con caché o actualizando a un plan más potente), 502 Bad Gateway (PHP-FPM falló o perdió la conexión con el servidor web; un problema de configuración), y finalmente **500 **Internal Server Error, el más genérico y por lo tanto el más traicionero. De eso hablaremos.

Tres causas principales del error 500 y soluciones paso a paso

El error 500 no es misterioso; solo es genérico. El servidor dice: «No pude ejecutar el código, pero no le diré cuál». El diagnóstico significa repasar metódicamente a tres sospechosos habituales.

1. Incompatibilidad de versión de PHP al migrar un sitio

Un escenario clásico: movió su sitio de un hosting antiguo que ejecutaba PHP 7.4 a uno nuevo con PHP 8.3 u 8.4. E inmediatamente obtuvo una pantalla en blanco.

La razón es simple: un plugin o tema antiguo usa funciones que han quedado obsoletas o han sido eliminadas por completo en versiones más recientes de PHP. El intérprete se niega a ejecutarlas y el sitio falla.

Cómo solucionarlo. Haga una copia de seguridad completa de las carpetas wp-content/plugins/ y wp-content/themes/. Luego renombre la carpeta plugins a plugins_old por FTP o mediante el gestor de archivos de su hosting; esto desactiva instantáneamente todos los plugins a la vez. ¿Desapareció el error? El culpable está entre los plugins. Restáurelos uno por uno, verificando el sitio cada vez. Aquel tras el cual regrese el error 500 es el problema.

La misma lógica se aplica a los temas: cambie a un tema estándar de WordPress (Twenty Twenty-Five o más reciente). ¿El sitio volvió a la vida? El problema está en su tema; actualícelo o reemplácelo.

Este escenario aparece con mayor frecuencia al migrar un sitio entre hostings con diferentes versiones de PHP. La mayoría de los hostings ya no ofrecen PHP 7.x en sus paneles de control, y los requisitos mínimos de WordPress desde 2026 comienzan con PHP 8.3. El código antiguo sin actualizaciones está condenado en ese entorno.

2..Htaccess corrupto, el asesino invisible

Configuró un plugin de caché, activó redirecciones o añadió sus propias reglas a .htaccess, y el sitio se cayó. Al instante y sin previo aviso.

El archivo .htaccess (Apache) controla el servidor web sobre la marcha: se escribe una directiva, se ejecuta una directiva. Un error de sintaxis, una bandera incorrecta o un conflicto de reglas, y todo el sitio responde con un 500.

Cómo solucionarlo. Conéctese a su sitio por FTP o a través del gestor de archivos de su hosting. Encuentre .htaccess en la carpeta raíz (public_html, www o htdocs). Copie su contenido a un archivo de texto como respaldo. Luego reemplace todo con la plantilla estándar de WordPress:

1
 # BEGIN WordPress
2
 
3
<IfModule mod_rewrite.c>
4
RewriteEngine On
5
RewriteBase /
6
RewriteRule ^index\.php$ - [L]
7
RewriteCond %{REQUEST_FILENAME} !-f
8
RewriteCond %{REQUEST_FILENAME} !-d
9
RewriteRule . /index.php [L]
10
</IfModule>
11
 
12
 # END WordPress

Este código restaura las reglas estándar de reescritura de URL (enlaces permanentes bonitos) y elimina todo lo extra. El sitio debería volver a la vida de inmediato. Puede reconfigurar su plugin después, pero ahora sabe dónde buscar si algo sale mal.

¿No funcionó? Restaure el .htaccess antiguo desde su respaldo y pase al siguiente paso. En Nginx, .htaccess no funciona; revise los registros en /var/log/nginx/error.log, el problema está en la configuración del bloque del servidor.

3. Error fatal en el código PHP

Un plugin o tema llama a una función que no existe, pasa un tipo de argumento incorrecto o hace referencia a una clase inexistente. PHP detiene la ejecución y usted se enfrenta a ese mismo 500.

Sin información de depuración, está adivinando a ciegas. Afortunadamente, WordPress puede mostrar errores; solo necesita activar el modo de depuración.

Activando WP_DEBUG

Abra el archivo wp-config.php en la raíz de su sitio. Encuentre la línea:

1
define( 'WP_DEBUG', false );

Reemplace false con true. Si esa línea no existe, agréguela antes de /* That's all, stop editing! */:

1
define( 'WP_DEBUG', true );

Después de guardar, actualice la página. En lugar de una pantalla en blanco, verá un mensaje como:

1
Fatal error: Call to undefined function wpsupercache_gc() in
2
/home/user/public_html/wp-content/plugins/wp-super-cache/wp-cache.php on line 342

El error muestra: el tipo de problema (undefined function), el archivo infractor (wp-cache.php) y la línea (342). Esta es una señal directa al plugin que causó la falla. Desactívelo renombrando la carpeta del plugin y el sitio funcionará de nuevo. Luego actualice el plugin, busque un reemplazo o contacte al desarrollador.

Asegúrese de volver a establecer WP_DEBUG en false después del diagnóstico. En un sitio en vivo, mostrar errores a los visitantes es innecesario y puede revelar rutas internas del servidor. Si desea recopilar registros sin mostrarlos en pantalla, agregue estas líneas a wp-config.php: define( 'WP_DEBUG_LOG', true ); y define( 'WP_DEBUG_DISPLAY', false );. Los errores se escribirán en wp-content/debug.log.

⁉️🤔 Preguntas frecuentes

¿Puedo simplemente reiniciar el servidor para eliminar el error 500?

No. A diferencia del 503, que a menudo desaparece después de un reinicio (cuando se alivia la carga máxima), el error 500 es causado por un problema en el código. Reiniciar el servidor no lo solucionará: después del arranque, el sitio encontrará el mismo código roto y fallará de nuevo.

¿Cómo determino si el culpable es un plugin o un tema si el panel de administración es inaccesible?

Conéctese por FTP o a través del gestor de archivos de su hosting. Renombre la carpeta wp-content/plugins; esto desactiva instantáneamente todos los plugins. ¿El sitio volvió a la vida? El problema está en los plugins. Si no, renombre la carpeta del tema activo en wp-content/themes. WordPress cambiará automáticamente al tema predeterminado. ¿Volvió a la vida? El problema está en el tema.

¿Tengo que activar WP_DEBUG en un sitio en vivo?

No, en un sitio en funcionamiento WP_DEBUG debe estar desactivado (false). Actívelo solo durante el diagnóstico y desactívelo inmediatamente después. Para la recopilación continua de errores sin mostrarlos a los visitantes, use la combinación de WP_DEBUG_LOG (escribe en wp-content/debug.log) y WP_DEBUG_DISPLAY (desactiva la salida en pantalla).

¿Qué pasa si ninguno de los tres métodos funcionó?

Verifique el límite de memoria de PHP (memory_limit en php.ini). A veces los scripts no tienen suficientes megabytes asignados y fallan con un 500. Auméntelo a 256M o 512M. Si eso no ayuda, contacte al soporte de su hosting: pídales que revisen los registros de errores del servidor (error_log para Apache/Nginx). La causa exacta estará allí, la cual no puede ver desde el lado de WordPress.

Mi sitio está en Nginx; ¿qué hago con.htaccess?

Nginx no usa .htaccess. Las reglas de reescritura se especifican en la configuración del bloque del servidor (nginx.conf o sites-available/your-site). Si está en Nginx y obtuvo un 500, revise los registros en /var/log/nginx/error.log. Un .htaccess incorrecto en un servidor Nginx no causa problemas; simplemente se ignora.

¿Cómo prevengo el error 500 en el futuro?

Tres reglas para la prevención. Primero: actualice plugins, temas y el núcleo de WordPress regularmente (cada mes, no una vez al año). Segundo: no se aferre a extensiones abandonadas; si un plugin no se ha actualizado en más de un año, busque un reemplazo vivo. Tercero: antes de instalar cualquier plugin, verifique la fecha de la última actualización y la compatibilidad con su versión de PHP en la página del plugin en el directorio de WordPress. Diez minutos de mantenimiento al mes ahorran horas de depuración de emergencia.

Qué hacer ahora mismo si su sitio está caído con un 500

El error 500 es un rompecabezas con una solución predecible. En la gran mayoría de los casos, arreglará el sitio en quince minutos siguiendo tres pasos en el orden correcto: desactive los plugins, restablezca .htaccess, active WP_DEBUG. El orden importa: del más probable y rápido al más detallado.

Si migró el sitio a un nuevo hosting, comience por verificar PHP. Si configuró caché o redirecciones, comience por .htaccess. Si actualizó plugins y el sitio falló, comience por WP_DEBUG. Y si no hizo nada y aun así apareció un 500 por sí solo, siga los tres pasos en secuencia; uno de ellos casi con toda seguridad funcionará.

No demore el diagnóstico: cada minuto de inactividad del sitio significa visitantes perdidos y posiciones en buscadores. Abra FTP, haga una copia de seguridad y comience.