Mi web no carga o da error 500: cómo saber si es el hosting o un ataque

Tu web ha dejado de cargar y en su lugar sale un error 500. Lo primero que necesitas saber: la inmensa mayoría de estos errores no son un ataque, son una actualización que ha salido mal, un límite del servidor o un fichero de configuración roto, y se arreglan en menos de media hora sin ayuda de nadie. Lo segundo, igual de importante: hay cuatro señales concretas que sí apuntan a una intrusión, y si aparecen conviene parar antes de tocar nada. Esta guía te lleva por las dos cosas en el orden correcto, sin que borres por el camino las pistas que después harían falta.

Primero, mira exactamente qué error es

«La web no carga» son varias averías distintas, y cada una apunta a un sitio. Antes de nada, fíjate en el mensaje literal:

• Error 500 / «Error interno del servidor»: el servidor ha intentado ejecutar tu web y el código ha fallado. Es problema tuyo (de tu WordPress o de tu configuración), no de la red.
• Error 503: servicio no disponible. Suele ser saturación, mantenimiento o un límite de procesos de tu plan.
• Error 502 o 504: pasarela incorrecta o tiempo agotado. Casi siempre es del lado del alojamiento o del cortafuegos intermedio.
• «Error al establecer una conexión con la base de datos»: el problema es la base de datos o las credenciales de wp-config.php, no PHP.
• Pantalla completamente en blanco: es un error fatal de PHP con los mensajes ocultos. Se trata como un 500.
• Aviso rojo del navegador o la web suspendida por el proveedor: eso ya no es un error técnico. Si tu proveedor ha desactivado la cuenta, tienes el procedimiento en la guía sobre qué hacer cuando el hosting suspende tu web por malware.

Comprueba también si falla la web entera o solo una parte. Si la portada carga pero /wp-admin/ da error, o al revés, esa asimetría es información valiosa y la vas a necesitar dentro de un momento.

Dónde está el error real: cinco minutos y lo sabes

El 500 que ves en el navegador es un mensaje genérico a propósito. El mensaje útil está en el servidor, y llegar a él es lo que separa arreglarlo de estar adivinando.

Busca por este orden:

1. Un fichero llamado error_log en la raíz de tu web o en la carpeta donde falla. Ábrelo y mira las últimas líneas.
2. En cPanel, el apartado Métricas > Errores, que te muestra los últimos errores registrados.
3. Si no encuentras nada, activa el registro de WordPress. Edita wp-config.php, y justo antes de la línea que dice /* Eso es todo, deja de editar */ añade:

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

Recarga la web y aparecerá el fichero wp-content/debug.log. Es fundamental que WP_DEBUG_DISPLAY esté en false: así los errores se guardan pero no se muestran a los visitantes ni a nadie que pase por ahí. Acuérdate de volver a poner todo en false cuando termines.

Lo que buscas es una línea de tipo PHP Fatal error seguida de una ruta de fichero. Esa ruta te dice el culpable: si acaba en wp-content/plugins/nombre-del-plugin/, ya tienes el responsable; si menciona Allowed memory size exhausted, es memoria; si habla de syntax error, alguien ha editado un fichero y lo ha roto.

Las causas que no son un ataque (y son la mayoría)

Por frecuencia, esto es lo que suele haber detrás de un 500 en un WordPress:

• Un plugin o una plantilla recién actualizados. La causa número uno con diferencia. Piensa qué pasó justo antes: ¿se actualizó algo anoche en automático?
• Memoria PHP agotada. Se resuelve añadiendo define('WP_MEMORY_LIMIT', '256M'); en wp-config.php, y si no basta, pidiendo al proveedor que suba el límite de PHP.
• El fichero .htaccess corrupto. Un plugin de caché o de seguridad ha escrito reglas incompatibles.
• Cambio de versión de PHP. Si tu proveedor ha migrado el servidor a una versión más nueva, el código antiguo deja de funcionar de golpe.
• Cuota de disco llena. Cuando no queda espacio, PHP no puede ni escribir sus temporales y todo revienta. Míralo en el panel de tu alojamiento: es una causa boba y sorprendentemente común.
• Límite de procesos simultáneos en alojamiento compartido, por una punta de visitas o por un robot rastreando.

Las dos pruebas que aíslan el problema

Si tienes acceso por FTP o por el administrador de ficheros del panel, estas dos pruebas resuelven la mayoría de los casos sin necesidad de entrar al escritorio de WordPress.

Prueba del .htaccess: renombra el fichero .htaccess de la raíz a .htaccess-old y recarga. Si la web vuelve, el problema estaba ahí; entra en Ajustes > Enlaces permanentes y pulsa Guardar cambios para que WordPress genere uno limpio.

Prueba de los plugins: renombra la carpeta wp-content/plugins a wp-content/plugins-off y recarga. Si la web vuelve, es un plugin. Deshaz el cambio y ve renombrando plugins uno a uno hasta dar con el culpable. Es un método tosco pero funciona sin panel de administración y no borra nada.

Si con estas dos pruebas la web vuelve a la vida y el registro de errores señalaba a un plugin concreto, has terminado: era una avería, no un ataque. No hace falta que llames a nadie ni que restaures nada.

Señales de que sí hay un ataque detrás

Estas son las que cambian la conversación. Si ves alguna, el 500 es un síntoma, no la enfermedad:

• El error apunta a un fichero PHP con nombre raro (letras al azar, o algo tipo wp-cache-config.php) en una carpeta donde no debería haber código: wp-content/uploads/, la raíz, o dentro de wp-includes/.
• El registro muestra un error de sintaxis en un fichero del núcleo de WordPress que tú no has tocado nunca.
• La web falla solo para las visitas que llegan desde Google, o solo desde el móvil, y a ti te carga bien.
• Hay un usuario administrador nuevo, tu correo de administración ha cambiado, o hay ficheros modificados con fecha de hoy sin que nadie haya publicado nada.

Dos comprobaciones rápidas que confirman o descartan. La primera, buscar código PHP donde solo debería haber imágenes; por SSH:

find wp-content/uploads -name "*.php"

Ese comando debería devolver cero resultados. Cualquier cosa que salga ahí hay que mirarla con lupa.

La segunda, los ficheros modificados recientemente:

find . -type f -name "*.php" -mtime -7

Si aparecen decenas de ficheros PHP modificados en los últimos siete días y tú no has actualizado nada, eso no es una avería. Para ir más allá y ver quién ha estado pidiendo qué justo antes de la caída, en la guía sobre cómo leer los registros de tu web tienes cómo interpretar el access.log.

Qué no hacer mientras investigas

Aquí se pierden la mitad de los casos. Cuatro cosas que parecen sensatas y empeoran la situación:

1. No borres los registros de error ni de acceso. Son la única forma de saber cuándo y por dónde entraron. Sin ellos, limpias la web y vuelven a entrar por la misma puerta a los tres días.
2. No restaures una copia de seguridad a ciegas. Si la intrusión es de hace tres semanas y restauras la copia de anteayer, estás restaurando el problema. Antes de restaurar hay que saber la fecha de la intrusión.
3. No reinstales WordPress «encima» sin más. Sustituye el núcleo, sí, pero deja intactas las puertas traseras que casi siempre están en plugins, temas o uploads, y además destruye evidencias.
4. No cambies solo la contraseña y des el asunto por cerrado. Si hay una puerta trasera en el código, la contraseña ya no hace falta para volver.

Lo que sí puedes hacer sin riesgo mientras decides: descargar una copia completa de ficheros y base de datos tal como está ahora y guardarla aparte. Esa copia sucia no sirve para restaurar, pero es exactamente lo que necesita cualquiera que investigue después.

Cuándo llamar al hosting y cuándo a un profesional

Llama a tu proveedor de alojamiento si el error es 502, 503 o 504, si la caída coincide con un cambio que ellos han anunciado, si has llegado al límite de disco, memoria o procesos, o si en su panel aparecen avisos de bloqueo. Pídeles algo concreto: «necesito el registro de errores del servidor de las últimas 24 horas para mi cuenta». Si el problema es suyo, esa petición lo destapa enseguida.

Y ahora la parte honesta, en las dos direcciones. Si el registro te ha señalado un plugin, has renombrado su carpeta y la web ha vuelto, ya está: no pagues a nadie, actualiza o sustituye ese plugin y sigue con tu vida. Ese es el desenlace más frecuente.

Pero si has encontrado ficheros PHP en uploads, ficheros del núcleo modificados, administradores que no reconoces o el error vuelve cada vez que lo arreglas, deja de tocar. Ahí ya no estás ante una caída sino ante una web comprometida, y lo que toca es determinar el alcance: por dónde entraron, qué se llevaron y si hay datos de clientes de por medio, que además tiene implicaciones legales. En la guía completa sobre qué hacer cuando tu web ha sido hackeada tienes el proceso ordenado, y si prefieres hacerlo tú mismo con método, el procedimiento paso a paso para limpiar un WordPress hackeado explica qué se revisa y en qué orden.

Si lo que quieres ahora mismo es una respuesta rápida y objetiva sobre en cuál de los dos escenarios estás, puedes comprobar tu web gratis con PathScan: analiza tu sitio desde fuera, sin registro y sin instalar nada, y te dice si lo que se ve desde internet apunta a una avería o a algo que alguien ha dejado ahí.