Estabas trabajando con normalidad en WordPress, haces un cambio aparentemente pequeño y de repente aparece un mensaje: 403 Forbidden.
O quizá ocurre sin que hayas tocado nada. La web deja de cargar, wp-admin tampoco funciona o, en una situación todavía más desconcertante, puedes entrar al escritorio de WordPress pero los visitantes reciben un error 403 al intentar abrir la página.
Lo primero que conviene saber es esto:
un error 403 no significa automáticamente que WordPress esté hackeado, ni que hayas roto la web.
Tampoco identifica por sí solo la causa.
Un 403 indica que el servidor ha recibido y entendido una petición, pero está rechazando el acceso al recurso solicitado.
El trabajo consiste, por tanto, en averiguar quién está rechazando esa petición y por qué.
Puede intervenir WordPress, pero también el servidor, un firewall, una regla de seguridad, los permisos de los archivos o una configuración situada por delante de la propia instalación.
Dos errores que muestran exactamente el mismo mensaje pueden tener causas completamente diferentes.
Haz primero unas comprobaciones sencillas.
Prueba:
/wp-admin/;/wp-login.php;No necesitas resolver todavía el problema. Solo quieres saber hasta dónde llega.
Si no puedes abrir ni la parte pública ni la administración, es especialmente importante revisar las capas que actúan antes de que WordPress llegue a ejecutarse normalmente.
Por ejemplo:
.htaccess, cuando el servidor utiliza este archivo.En esta situación, cambiar la contraseña de WordPress probablemente no sea la primera medida útil.
La situación es diferente.
Sabemos que al menos una parte de WordPress continúa siendo accesible, por lo que conviene investigar qué está bloqueando las peticiones del frontal.
Puede haber reglas específicas, configuraciones de seguridad, permisos o algún componente que trate de forma diferente las peticiones públicas y las del administrador.
No empieces desactivando plugins al azar. Primero anota qué cambió recientemente y revisa los registros disponibles.
Si la web funciona desde otra conexión pero no desde la tuya, la instalación puede estar perfectamente operativa para el resto de usuarios.
Tu dirección IP podría haber sido bloqueada por:
Este detalle cambia completamente el diagnóstico.
También puede ocurrir que la web funcione pero falle algo específico: guardar un formulario, abrir una página determinada, utilizar una función del administrador o enviar una petición concreta.
En esos casos resulta especialmente útil anotar:
Esa información puede permitir encontrar la petición concreta en los registros del servidor.
No existe una única causa.
Estas son las capas que conviene revisar.
Es una de las posibilidades que más fácilmente se pasa por alto.
Tu web puede estar protegida por diferentes sistemas:
Estos sistemas analizan las peticiones e intentan bloquear comportamiento malicioso.
El problema es que una regla también puede considerar sospechosa una petición legítima.
Cloudflare, por ejemplo, documenta que algunas reglas de su WAF y otras funciones de seguridad pueden responder expresamente con un HTTP 403. También señala que un 403 generado por el servidor de origen puede estar relacionado con reglas de permisos, ModSecurity o bloqueos de IP.
Por eso, si el error apareció justo después de una determinada acción, no conviene concluir automáticamente que esa acción “rompió WordPress”.
Puede haber activado una regla de protección.
Si utilizas Cloudflare o una herramienta de seguridad cuyo panel conoces, revisa si existen eventos de seguridad correspondientes a la hora exacta del error.
Si no sabes qué firewall utiliza tu web, pregunta al hosting.
Una pregunta mucho más útil que «¿por qué no funciona WordPress?» sería:
“Estoy recibiendo un HTTP 403 desde las 11:35. ¿Podéis comprobar en los logs si alguna regla del firewall, ModSecurity o algún bloqueo de IP está rechazando las peticiones?”
Eso proporciona al soporte un punto de partida concreto.
Los servidores utilizan permisos para decidir qué usuarios y procesos pueden leer, modificar o ejecutar determinados archivos.
WordPress necesita poder acceder a sus propios archivos, pero no todos deberían ser modificables por cualquiera.
Si esos permisos están mal configurados, el servidor puede impedir el acceso.
Aquí hay una precaución importante: no copies números de permisos de cualquier tutorial y los apliques recursivamente a toda la instalación.
La documentación oficial de WordPress advierte de que los permisos dependen de la configuración del alojamiento y que establecerlos incorrectamente puede dejar la web fuera de servicio.
En una instalación típica pueden encontrarse valores como 755 para determinados directorios y 644 para archivos, pero eso no convierte esos números en una receta universal. También intervienen el propietario de los archivos, los grupos y la forma en que está configurado el servidor.
Dar permisos 777 significa conceder unos privilegios extremadamente amplios.
No debería utilizarse como método de diagnóstico simplemente porque una página diga que “soluciona errores de permisos”.
La propia documentación de WordPress advierte de los riesgos de utilizar permisos excesivamente abiertos.
Si sospechas de un problema de permisos y nunca has trabajado con ellos, esta es una de las comprobaciones que merece la pena dejar al soporte del alojamiento.
.htaccess está bloqueando el acceso.htaccess es un archivo utilizado en determinadas configuraciones de servidor, especialmente en entornos Apache y compatibles, para aplicar reglas sobre URLs, redirecciones, accesos y otros comportamientos.
WordPress puede utilizarlo, por ejemplo, para determinadas configuraciones de enlaces permanentes.
Plugins de seguridad, caché y otras herramientas también pueden añadir sus propias reglas.
Una regla incorrecta puede impedir el acceso a una URL, una carpeta o incluso una parte importante de la web.
Pero hay dos errores habituales al diagnosticarlo.
.htaccessNo es así.
La configuración depende del servidor. Un alojamiento que utiliza Nginx, por ejemplo, no gestiona estas reglas del mismo modo.
Antes de modificarlo, averigua qué servidor utiliza tu alojamiento.
.htaccess para “probar”No deberías borrar un archivo de configuración sin conservar una copia y sin saber qué reglas contiene.
Puede haber configuraciones añadidas por:
Si necesitas intervenir sobre archivos como este y no estás acostumbrado a hacerlo, crea primero una copia. En nuestra guía sobre wp-config.php en WordPress explicamos por qué los archivos de configuración deben modificarse de forma controlada y reversible.
Una extensión de seguridad puede bloquear una IP cuando detecta demasiados intentos de acceso, peticiones consideradas sospechosas u otros patrones definidos por sus reglas.
Eso no significa necesariamente que el plugin esté funcionando mal.
Puede haber:
Si todavía puedes entrar en WordPress, revisa los eventos del plugin antes de desactivarlo.
Si no puedes entrar, comprueba primero si el hosting puede identificar el origen del 403.
Desactivar herramientas de seguridad desde FTP únicamente porque aparece un error 403 puede eliminar una protección sin demostrar que esa protección sea la causa.
Una web puede empezar a devolver 403 aunque tú no hayas modificado WordPress.
El proveedor puede haber cambiado:
También puede haberse activado automáticamente una protección.
Por eso es tan importante preguntar por los logs.
Decir al soporte «WordPress no funciona» aporta poca información.
Es mejor proporcionar:
/wp-admin/;Y pedir que comprueben específicamente el HTTP 403 en los registros.
No.
Un 403 por sí solo no demuestra una intrusión.
Puede aparecer en una web completamente limpia debido a una regla del firewall, permisos o configuración del servidor.
La situación cambia si, además del 403, encuentras indicios independientes como:
En ese caso no deberías limitarte a conseguir que desaparezca el 403.
Hay que investigar también un posible incidente de seguridad.
Por ejemplo, borrar un usuario desconocido y continuar trabajando no explica cómo apareció esa cuenta ni permite saber qué pudo hacer mientras tuvo acceso.
Si encuentras este tipo de señales, consulta qué comprobar cuando un WordPress ha sido hackeado incluso aunque estuviera actualizado.
Y si confirmas que existe malware, el proceso cambia por completo: hay que identificar el alcance de la infección y la posible vía de entrada, no simplemente eliminar el archivo que parece sospechoso. Puedes ampliar ese proceso en cómo eliminar malware en WordPress sin romper la web.
Si gestionas tú mismo los contenidos de tu WordPress pero no administras servidores, seguiría este orden.
Si el error apareció después de una acción concreta, anótala.
No empieces inmediatamente a:
.htaccess.Cuantos más cambios hagas antes de conocer la causa, más difícil será reconstruir qué ocurrió.
Prueba portada, página interior, wp-admin y wp-login.php.
Después prueba desde otra conexión.
Con estas cuatro comprobaciones ya puedes diferenciar muchos escenarios.
Algunas páginas de error muestran claramente el nombre o diseño del proveedor que las está generando.
Por ejemplo, un error identificado como Cloudflare proporciona una pista distinta de una página creada directamente por el servidor de alojamiento.
No siempre podrás identificarlo visualmente, pero si puedes hacerlo, anótalo.
Pregunta:
La coincidencia temporal no demuestra cuál es la causa, pero ayuda a acotar la investigación.
Si estás ante una instalación que lleva años prácticamente sin tocarse, no conviene convertir la recuperación en una actualización masiva. En cómo actualizar un WordPress antiguo sin romperlo explicamos por qué primero hay que revisar versiones, plugins, PHP, tema y copias.
Este suele ser el paso que más información aporta.
Los registros pueden indicar:
Dependiendo de tu hosting tendrás acceso directo a esos logs o tendrás que pedirlos al soporte.
No necesitas saber interpretarlos todos. Basta con conseguir que el técnico busque el evento concreto.
Si finalmente hay que cambiar permisos, editar archivos o desactivar componentes, crea antes una copia recuperable.
No porque todo cambio vaya a salir mal, sino porque necesitas una forma de volver al punto inicial.
Tener un botón de «backup» no garantiza que esa copia pueda restaurarse. En cómo saber si las copias de seguridad de WordPress realmente funcionan explicamos qué conviene comprobar antes de depender de ellas.
Si modificas simultáneamente permisos, plugins, .htaccess y configuración del hosting y la web vuelve a funcionar, no sabrás qué solucionó el problema.
Y si sigue fallando, tampoco sabrás qué cambio ha introducido un problema nuevo.
Diagnosticar consiste precisamente en reducir incógnitas.
No necesariamente.
Depende del origen.
Una restauración puede ayudar si el error procede de archivos o configuraciones de WordPress que han cambiado y dispones de una copia anterior válida.
Pero no solucionará necesariamente un bloqueo situado fuera de esa copia.
Por ejemplo, si el 403 lo está generando:
puedes restaurar todos los archivos de WordPress y encontrarte exactamente con el mismo error.
Por eso restaurar debería ser una decisión basada en el diagnóstico, no el primer botón que se pulsa.
También puede ser completamente normal.
Tu contraseña de WordPress sirve para autenticarte dentro de WordPress.
Pero un error 403 puede producirse antes de que esa autenticación llegue siquiera a procesarse.
Si el firewall del servidor está rechazando tu IP, cambiar la contraseña de WordPress no modifica esa regla.
Si los archivos no pueden ser leídos correctamente, tampoco.
Y si Cloudflare u otro WAF está bloqueando la petición, la contraseña de tu usuario de WordPress es irrelevante para esa decisión.
No necesariamente.
La proximidad temporal es una pista, no un diagnóstico.
Si realizas una acción en WordPress y el servidor la considera sospechosa, una regla automática puede bloquearla. También puede coincidir con un problema que ya existía.
Anota exactamente lo que estabas haciendo y la hora.
Con esa información, el hosting puede comprobar si la petición activó una regla concreta.
Lo importante es evitar esta conclusión:
“Hice clic aquí, apareció un 403, por tanto esa opción ha destruido WordPress”.
Todavía falta investigar qué componente devolvió realmente la respuesta.
Si administras contenidos habitualmente, hay una parte del diagnóstico que puedes hacer con bastante seguridad:
A partir de ahí empieza una zona más técnica.
Conviene tener cuidado si la solución requiere:
.htaccess;No necesitas aprender administración de sistemas para poder gestionar los textos, imágenes y páginas de tu negocio.
Una cosa es administrar contenidos en WordPress y otra diferente mantener la infraestructura sobre la que funciona.
Si tienes que abrir un ticket, puedes evitar varios intercambios de mensajes proporcionando la información desde el principio.
Indica:
/wp-admin/ y /wp-login.php;Y pregunta expresamente:
Estas preguntas son mucho más útiles que pedir simplemente que «revisen WordPress».
Conseguir que la web vuelva a cargar resuelve la urgencia.
No siempre resuelve la causa.
Antes de dar el problema por terminado, intenta dejar registrado:
Si la web llevaba años funcionando sin mantenimiento y el 403 ha sido la primera señal de alarma, puede ser buen momento para revisar su estado general.
En qué debería incluir realmente el mantenimiento de una web WordPress explicamos qué tareas conviene controlar aunque solo entres en la web de vez en cuando para modificar contenidos.
Ante un error 403 es fácil empezar a cambiar cosas porque el mensaje parece decir muy poco.
Precisamente por eso conviene hacer lo contrario.
Primero determina qué está fallando.
Después identifica qué capa está rechazando la petición.
Y solo entonces modifica aquello que tenga relación con la causa.
Un firewall que te ha bloqueado no se arregla cambiando permisos. Un problema de permisos no se soluciona cambiando la contraseña. Y encontrar un administrador desconocido no debería reducirse a borrar esa cuenta y olvidar el asunto.
Si no tienes experiencia administrando el servidor, tu mejor aportación al diagnóstico no consiste en probar veinte soluciones de Internet.
Consiste en recoger bien las pistas, conservar una copia antes de intervenir y conseguir que cada cambio responda a una causa concreta.
