Pantalla blanca. Cinco caracteres: 500 Internal Server Error. El sitio está caído, el cliente le está escribiendo y usted no tiene idea de por dónde empezar.

El error 500 es el código de estado HTTP más frustrante. A diferencia del 404 («página no encontrada») o el 403 («acceso denegado»), no señala a un culpable. Solo dice «algo salió mal en el servidor». A partir de ahí, usted está solo: un plugin, un tema, PHP defectuoso, hosting, .htaccess corrupto. Hay docenas de posibilidades y cada una requiere una solución distinta.

La buena noticia: un error 500 siempre se puede arreglar. Sin pánico, sin reinstalar WordPress desde cero y, en la mayoría de los casos, sin un desarrollador. En 7 pasos (desde diagnósticos de 30 segundos hasta el reemplazo quirúrgico de archivos del sistema) encontrará la causa y pondrá su sitio de nuevo en línea. Cada método incluye archivos específicos, líneas de código y capturas de pantalla.

💡 Resumen rápido:

• Paso 1: active WP_DEBUG y lea los registros para ver de inmediato qué archivo tiene la falla
• Paso 2: descarte problemas de hosting mientras revisa el código
• Paso 3: corrija .htaccess, la causa número uno según las estadísticas de soporte
• Paso 4: aumente el límite de memoria de PHP, un culpable frecuente al subir medios o iniciar sesión en el administrador
• Paso 5: vuelva a subir el núcleo de WordPress cuando los archivos se corrompan por una actualización automática fallida
• Paso 6: desactive plugins vía FTP, un método que resuelve más de la mitad de todos los casos
• Paso 7: restablezca el tema predeterminado, un paso que a menudo se pasa por alto

Qué es el error 500 y de dónde viene

HTTP 500 es una respuesta del servidor que significa «error interno». La solicitud del navegador llegó, Apache o Nginx la aceptaron, PHP empezó a ejecutarse y entonces tropezó. A diferencia del 404 o 403 (donde el servidor responde conscientemente «no»), un cinco al inicio del código significa que algo se rompió dentro del script y el servidor no sabe qué.

En WordPress, el error 500 ocurre en cuatro escenarios típicos:

• Instaló o actualizó un plugin y este entra en conflicto con otro código del sistema.
• Modificó .htaccess y un error de sintaxis hizo fallar a Apache.
• Un script PHP agotó su memoria asignada (pantalla blanca con Allowed memory size of X bytes exhausted en los registros).
• Los archivos del núcleo están corruptos: una actualización automática fallida, una transferencia FTP interrumpida, un plugin con mal comportamiento que alteró las carpetas del sistema.

Con menos frecuencia: un tema con un error fatal en functions.php, problemas del lado del hosting (sobrecarga, módulo PHP deshabilitado) o un shortcode roto de un plugin eliminado dentro del contenido de la página.

Antes de empezar: haga una copia de seguridad completa de su sitio. Sin una copia de seguridad, cualquier acción sobre los archivos del servidor es un riesgo. La mayoría de los hosts ofrecen un botón de copia de seguridad en el panel de control (cPanel, ISPmanager, aaPanel) con solo dos clics.

1. Active WP_DEBUG y lea los registros

La forma más rápida de encontrar la causa es hacer que WordPress la revele. Por defecto, el núcleo oculta los errores de PHP tras una pantalla blanca (este es el modo «no asustar a los visitantes»). Pero WordPress tiene un mecanismo de depuración integrado: las constantes WP_DEBUG.

Activar el modo de depuración

Abra wp-config.php en la raíz de su sitio vía FTP o con el administrador de archivos de su host. Busque esta línea:

1
/* That's all, stop editing! Happy blogging. */

Antes de ella, inserte este bloque:

1
// Enable debug mode
2
define( 'WP_DEBUG', true );
3
 
4
// Write errors to /wp-content/debug.log
5
define( 'WP_DEBUG_LOG', true );
6
 
7
// Do not show errors to visitors on screen
8
define( 'WP_DEBUG_DISPLAY', false );
9
@ini_set( 'display_errors', 0 );

Lo que sucede aquí:

• WP_DEBUG es el interruptor principal; sin true, las otras constantes no funcionan.
• WP_DEBUG_LOG dirige todos los errores a wp-content/debug.log en lugar de a la pantalla. Los visitantes no ven mensajes alarmantes.
• WP_DEBUG_DISPLAY + @ini_set oculta forzosamente los errores de la salida de la página.

Guarde el archivo, actualice la página problemática de su sitio y descargue wp-content/debug.log vía FTP. En el registro verá el archivo y la línea específicos: Fatal error: Cannot redeclare my_function() in /home/user/public_html/wp-content/plugins/broken-plugin/broken.php on line 42.

Desactive la depuración después del diagnóstico. Comente o elimine las líneas que agregó. WP_DEBUG en un sitio en vivo reduce el rendimiento y debug.log puede crecer hasta gigabytes con el tiempo.

2. Contacte a su proveedor de hosting

Si los registros están vacíos o no se crearon, el error podría estar del lado del servidor y no en el código de WordPress. Esto es especialmente común en planes de hosting compartido económicos con límites de procesos estrictos.

Abra un ticket de soporte y adjunte tres cosas:

• La hora exacta en que apareció el error, con la zona horaria del servidor.
• La URL de la página donde se reproduce el error.
• Una captura de pantalla del error, si está disponible.

El soporte revisará los registros del servidor Apache o Nginx, la carga de CPU y memoria, y los módulos PHP disponibles. Los problemas a menudo se resuelven en este paso: un administrador del host reinicia PHP-FPM o ajusta el límite de procesos.

Cómo saber de qué lado está el problema

Cree un archivo llamado info.php con una sola línea:

1
<?php phpinfo(); ?>

Súbalo a la raíz de su sitio vía FTP y abra your-site.com/info.php. Si ve una tabla con parámetros de PHP, el servidor funciona y el error está en el código de WordPress. Si ve un 500, el error está a nivel del servidor; proporcione esta URL al soporte.

Después de la prueba, **elimine **info.php. phpinfo() expone versiones del servidor, rutas y módulos, lo que crea un agujero de seguridad.

3. Corrija el archivo.htaccess

.htaccess es un archivo de configuración de Apache en la raíz de su sitio. WordPress lo usa para URLs legibles, redirecciones y reglas básicas de seguridad. Un corchete de más, un conflicto entre reglas de dos plugins y todo el sitio se cae con un error 500. Según las estadísticas de tickets de soporte, .htaccess resulta ser la causa número uno.

Comprobación rápida: renombre .htaccess a .htaccess_old vía FTP y actualice el sitio. Si funciona, el problema está definitivamente en este archivo.

Ahora restaure .htaccess: vaya a administración de WordPress, Ajustes → Enlaces permanentes y haga clic en «Guardar cambios» sin modificar la estructura. WordPress generará un nuevo .htaccess limpio con las reglas estándar:

1
RewriteEngine On
2
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
3
RewriteBase /
4
RewriteRule ^index\.php$ - [L]
5
RewriteCond %{REQUEST_FILENAME} !-f
6
RewriteCond %{REQUEST_FILENAME} !-d
7
RewriteRule . /index.php [L]

Si tenía reglas personalizadas en .htaccess (redirecciones, caché, seguridad), añádalas de nuevo una por una y compruebe el sitio después de cada una. Así identificará la línea causante del problema.

4. Aumentar el límite de memoria de PHP

Los scripts PHP de WordPress necesitan RAM. Cuando un plugin o un tema solicita más de la asignada, el script se interrumpe. El resultado: un error 500 o una página en blanco con Allowed memory size of X bytes exhausted.

El límite estándar en muchos alojamientos sigue siendo 64 MB. Para un sitio WordPress moderno con una docena de plugins, eso es catastróficamente bajo. El mínimo recomendado es 256 MB.

Método 1: mediante wp-config.php (recomendado)

Añada esto a wp-config.php antes de /* That's all, stop editing! */:

1
define( 'WP_MEMORY_LIMIT', '256M' );

Esta constante anula el límite de PHP para la parte pública del sitio. Para el área de administración, WordPress eleva automáticamente el techo a WP_MAX_MEMORY_LIMIT (256 MB por defecto).

Método 2: mediante php.ini (si su proveedor no le permite editar wp-config)

Cree un archivo php.ini con este contenido:

1
memory_limit = 256M

Súbalo a la raíz del sitio y a la carpeta wp-admin/. Si eso no funciona, cree o edite .user.ini en la raíz del sitio con la misma línea.

Si ninguno de los dos métodos funciona, su plan de alojamiento limita físicamente la memoria. Es momento de ampliar su plan o cambiar de proveedor.

5. Vuelva a subir los archivos del núcleo de WordPress

Un archivo del núcleo corrupto es una causa poco común pero insidiosa. Un fallo en una actualización automática, una transferencia FTP interrumpida, un plugin que modificó archivos del sistema, y wp-admin o wp-includes contienen basura.

Procedimiento:

• Descargue un archivo ZIP nuevo de WordPress desde wordpress.org.
• Extraiga el archivo en su computadora.
• Vía FTP, vaya a la raíz de su sitio y elimine las carpetas wp-admin y wp-includes (solo esas dos; ¡no toque wp-content!).
• Suba las carpetas wp-admin y wp-includes del archivo nuevo.
• No sobrescriba wp-content; ahí es donde residen sus temas, plugins y archivos subidos.

Los archivos raíz (wp-settings.php, index.php y otros) también pueden reemplazarse con los nuevos del archivo. **Excepto **wp-config.php; no lo toque porque contiene las credenciales de su base de datos. Tras el reemplazo, refresque el sitio; el error desaparecerá si la causa eran archivos del sistema corruptos.

6. Desactive los plugins

Un plugin asesino es la causa más probable de un error 500. Actualizó varios plugins a la vez y uno colisionó con otro: hola, pantalla blanca.

Si el área de administración funciona

Vaya a Plugins → seleccione todos → acción en lote "Desactivar" → "Aplicar". Si el error desaparece, active los plugins uno por uno, refrescando el sitio después de cada uno. Cuando encuentre al culpable, elimínelo o reporte el problema al desarrollador.

Si el área de administración es inaccesible

Conéctese al servidor vía FTP y renombre la carpeta wp-content/plugins a plugins_off. WordPress dejará de cargar todos los plugins y el sitio volverá a la vida. Devuelva la carpeta a su nombre original y renombre las subcarpetas de los plugins una a la vez; de esta forma encontrará el problemático sin entrar al administrador.

Qué vigilar: los plugins de caché (W3 Total Cache, WP Rocket) a veces escriben sus propias reglas en .htaccess y wp-config.php. Después de desactivar un plugin así, el error podría persistir; revise estos archivos y elimine las líneas entre marcadores como # BEGIN W3TC y # END W3TC o similares.

7. Cambie al tema predeterminado

El tema activo es una fuente subestimada pero real de errores 500. Especialmente si añadió un fragmento de código con un error fatal en functions.php.

La comprobación es simple: vía FTP, renombre la carpeta del tema activo en wp-content/themes/ (por ejemplo, mytheme → _mytheme). WordPress detectará que el tema activo falta y cambiará automáticamente a uno estándar: Twenty Twenty-Five u otro tema predeterminado instalado en el sistema.

Si el sitio funciona con el tema predeterminado, el problema está en el suyo. Devuelva el nombre original al tema, abra functions.php y busque errores en el código personalizado. Si usted no añadió el código, contacte al desarrollador del tema.

⁉️🤔 Preguntas frecuentes

¿Qué debo hacer si el error 500 aparece solo al iniciar sesión en el administrador?

Lo más probable es que el límite de memoria PHP no sea suficiente específicamente para el panel de administración, que carga todos los plugins a la vez y es más pesado que la parte pública. Añada la línea define( 'WP_MAX_MEMORY_LIMIT', '512M' ); a wp-config.php; este es un límite separado para el administrador, más alto que WP_MEMORY_LIMIT de la parte pública. Revise también su carpeta de plugins: en nuestra experiencia, los culpables más comunes son los plugins de seguridad como Wordfence o los plugins de respaldo que consumen memoria al cargar la barra de administración. Desactívelos vía FTP (la carpeta plugins_off del paso 6) y compruebe.

¿Puedo arreglar un error 500 sin acceso FTP?

Sí. La mayoría de los hosts ofrecen un administrador de archivos en el panel de control: cPanel → Administrador de archivos, ISPmanager → Archivos. A través de él puede renombrar .htaccess, las carpetas de plugins y temas, y editar wp-config.php; todos los pasos son los mismos. Sin ningún acceso a archivos, su única opción es el equipo de soporte del host. Consejo profesional: si tiene instalado un plugin de fragmentos (Code Snippets, WPCode) y su última acción fue añadir un fragmento, intente abrir your-site.com/?code_snippets_safe_mode=1 o una URL de modo seguro similar para su plugin. Esto desactiva todos los fragmentos sin FTP.

El error 500 aparece solo en una página. ¿Cuál es la causa?

Una función o shortcode roto dentro del contenido de esa página específica. Abra la página en el editor de WordPress (si el administrador funciona) y elimine temporalmente todos los shortcodes, bloques de Gutenberg e incrustaciones de código. Si el administrador es inaccesible, encuentre la entrada en la base de datos vía phpMyAdmin (la tabla wp_posts), copie el contenido a un editor de texto y elimine los shortcodes sospechosos. Los culpables más comunes: shortcodes de plugins eliminados ([dead_plugin] permanece pero el plugin ya no está), PHP roto en bloques de contenido o bloques de Gutenberg anidados incorrectamente.

Después de la recuperación, el error 500 regresa tras unas horas. ¿Cómo encuentro la causa?

Un error cíclico con un intervalo es casi siempre uno de tres escenarios: una tarea cron de WordPress ejecuta un proceso roto según lo programado, un plugin de caché genera caché corrupta o el host alcanza periódicamente los límites de procesos (especialmente en planes compartidos baratos). Instale WP Crontrol y revise la lista de tareas cron; encuentre la que coincide con la hora del fallo. Limpie la caché de su plugin de caché. Pregunte a su host sobre el límite de Entry Processes o PHP Workers; en planes compartidos a menudo se reducen a 5-10, y un pico de tráfico tumba el sitio.

¿Necesito seguir los 7 pasos o puedo saltarme algunos?

Los dos primeros pasos (WP_DEBUG y hosting) son de diagnóstico: no rompen nada y proporcionan información. En nuestra experiencia dando soporte a sitios WordPress, el paso 3 (.htaccess) y el paso 6 (plugins) resuelven la gran mayoría de los casos. El resto se reduce a la memoria PHP, el núcleo corrupto y el tema. En una situación típica resolverá el problema en los pasos 3 o 6 sin recorrer toda la cadena.

Por dónde empezar ahora mismo

No repita el escenario típico: pánico → borrar todo al azar → empeorar las cosas. Siga el orden del diagnóstico a la solución:

La regla principal para las reparaciones en WordPress: una acción, una comprobación. Nunca haga dos arreglos a la vez; no sabrá cuál funcionó. Y anote exactamente qué plugin o edición causó el error. La próxima vez lo arreglará todo en 30 segundos.