Actualizar WordPress debería ser una tarea rutinaria. Con copia de seguridad, revisión previa y un mínimo de control, no tendría que convertirse en una tarde de pánico. Pero a veces pasa.
Hace poco, tras actualizar una web de un cliente a WordPress 7, la página empezó a devolver un error 403 Forbidden. De primeras, la sospecha era bastante lógica: “Ha sido actualizar WordPress y la web se ha roto.”
Pero no. El problema no era WordPress 7.
El problema estaba en una regla del archivo .htaccess que bloqueaba el acceso a un archivo que WordPress necesitaba usar durante el proceso de actualización: upgrade.php.
Y me parece un caso muy interesante para contarlo, porque resume muy bien algo que veo a menudo en mantenimiento WordPress: una medida de seguridad mal planteada puede acabar rompiendo justo lo que intenta proteger.
💥 Qué pasó tras actualizar a WordPress 7
El síntoma era claro: después de actualizar WordPress, la web devolvía un error 403.
Un 403 significa, simplificando mucho, que el servidor ha entendido la petición, pero no permite acceder al recurso solicitado. No es exactamente lo mismo que un error 500, donde suele haber un fallo interno de ejecución, ni que un 404, donde el recurso no se encuentra.
Aquí el servidor decía algo así como: “Sé lo que me estás pidiendo, pero no te dejo pasar.”
Cuando esto ocurre justo después de actualizar WordPress, es normal pensar que la actualización ha provocado el fallo. De hecho, en mi guía sobre cómo actualizar WordPress y plugins sin romper nada ya insisto mucho en esto: actualizar es necesario, pero no hay que hacerlo a ciegas.
Ahora bien, una cosa es que el error aparezca después de actualizar y otra muy distinta es que la actualización sea la causa real.
En este caso, WordPress 7 solo fue el disparador. La causa estaba antes.
🚫 Por qué un error 403 en WordPress puede tener varias causas
Antes de tocar nada, lo importante era no asumir demasiado rápido.
Un error 403 en WordPress puede venir de muchos sitios:
- permisos incorrectos en archivos o carpetas
- reglas demasiado agresivas en
.htaccess - bloqueo de ModSecurity o del firewall del hosting
- un plugin de seguridad
- una regla de CDN, por ejemplo Cloudflare
- protección específica sobre
/wp-admin/ - archivos del core bloqueados por error
Por eso, cuando alguien me dice “no puedo acceder a WordPress”, no me voy directo a borrar plugins o cambiar cosas sin criterio. De hecho, este caso conecta muy bien con otro artículo donde explico qué revisar cuando no puedes acceder a WordPress.
La clave es ir descartando capas. Primero hay que saber si el bloqueo viene de WordPress, del servidor, del .htaccess, de un plugin o del hosting.
🔍 Las pruebas que hice para acotar el problema
El proceso fue bastante sencillo, pero muy útil.
Primero comprobé si el error afectaba a toda la web o solo a zonas concretas:
- /
- /wp-admin/
- /wp-login.php
- /wp-json/
- /wp-admin/upgrade.php
Esto ayuda mucho, porque si toda la web devuelve 403, suelo mirar primero permisos, .htaccess, reglas del servidor o WAF.
Pero si el error aparece al acceder al admin, al actualizar la base de datos o en una URL concreta, entonces conviene buscar una regla que esté bloqueando esa ruta o ese archivo.
Y ahí apareció la pista buena: WordPress, después de ciertas actualizaciones, puede necesitar ejecutar una actualización de base de datos desde una URL como: /wp-admin/upgrade.php
La propia documentación oficial de WordPress sobre actualizaciones explica que, si es necesario actualizar la base de datos tras una actualización, WordPress puede llevarte a una URL de ese tipo: wp-admin/upgrade.php.
Así que el siguiente paso era evidente: revisar el .htaccess.
⚙️ La regla del .htaccess que estaba provocando el 403
Dentro del .htaccess había un bloque de protección para archivos no públicos de WordPress. La intención era buena: evitar que ciertos archivos sensibles o innecesarios fueran accesibles desde el navegador.
El problema estaba en esta parte:
<FilesMatch "^(install\.php|upgrade\.php|license\.txt|licencia\.txt|readme\.html|debug_log|error_log|access_log)$">
Require all denied
</FilesMatch>A simple vista puede parecer una regla razonable. Pero no lo era.
El problema concreto estaba aquí: upgrade.php. Esa regla impedía el acceso a cualquier archivo llamado upgrade.php. Y como WordPress puede necesitar cargar: /wp-admin/upgrade.php el servidor respondía con un 403.
Es decir, WordPress intentaba completar su flujo normal de actualización, pero Apache lo bloqueaba antes de que WordPress pudiera hacer nada.
La documentación de Apache sobre FilesMatch deja claro que esta directiva aplica reglas a archivos cuyo nombre coincide con la expresión indicada. En este caso, la expresión coincidía demasiado bien: bloqueaba justo el archivo que WordPress necesitaba.
🔓 Por qué upgrade.php no debería bloquearse así
Este es el punto importante. upgrade.php puede sonar a archivo delicado. Y en cierto modo lo es. Pero eso no significa que haya que bloquearlo globalmente desde .htaccess.
En WordPress, no todo archivo que “parece sensible” debe ser inaccesible siempre.
Hay archivos que el propio core puede necesitar en momentos concretos. Y si los bloqueas desde Apache, WordPress ni siquiera llega a decidir qué hacer: el servidor corta la petición antes.
Eso fue exactamente lo que pasó aquí. El error no venía de WordPress 7. El error venía de una regla demasiado agresiva.
Y este matiz es importante, porque muchas veces veo configuraciones de seguridad copiadas de internet que añaden capas y capas de bloqueo sin valorar el contexto real del sitio.
Proteger una web no es poner muchas reglas. Proteger una web es poner las reglas correctas.
✅ Cómo corregí la regla
La solución fue quitar upgrade.php de ese bloqueo. También aproveché para simplificar la regla y dejarla centrada en archivos que sí tiene sentido proteger de forma permanente.
La versión problemática era esta:
<FilesMatch "^(install\.php|upgrade\.php|license\.txt|licencia\.txt|readme\.html|debug_log|error_log|access_log)$">
Require all denied
</FilesMatch>Y la versión corregida quedó así:
<FilesMatch "^(license\.txt|licencia\.txt|readme\.html|debug_log|error_log|access_log)$">
Require all denied
</FilesMatch>Con este cambio, WordPress pudo volver a acceder a wp-admin/upgrade.php y completar el proceso.
Después de eso, conviene hacer las comprobaciones habituales:
- /wp-admin/
- /wp-admin/upgrade.php
- /wp-login.php
- /wp-json/
Y, si todo está correcto, entrar en el panel y guardar de nuevo los enlaces permanentes desde: Ajustes > Enlaces permanentes > Guardar cambios
También es buena idea purgar caché si se usa WP Rocket, LiteSpeed Cache, Cloudflare o cualquier sistema similar.
⚠️ Ojo con bloquear archivos comprimidos desde .htaccess
En este caso concreto, el problema era upgrade.php. Pero ya que estaba revisando el .htaccess, había otra regla que merecía atención:
<FilesMatch "\.(bak|old|orig|save|sql|zip|tar|gz)$">
Require all denied
</FilesMatch>Bloquear archivos .bak, .old, .orig, .save o .sql tiene sentido. Pero bloquear siempre .zip, .tar o .gz puede darte problemas según cómo trabaje tu sistema de caché, backups, descargas o despliegues. No digo que haya que permitirlos siempre. Digo que no conviene meterlos en una regla global sin pensar qué hace esa web exactamente.
Una alternativa más prudente sería:
<FilesMatch "\.(bak|old|orig|save|sql)$">
Require all denied
</FilesMatch>Y si hay que proteger backups o paquetes concretos, prefiero hacerlo en una carpeta específica, no bloqueando extensiones de forma indiscriminada en toda la instalación.
🔧 El .htaccess puede arreglar una web… o romperla
El .htaccess es uno de esos archivos que parecen pequeños, pero pueden tirar abajo una web entera. Sirve para gestionar redirecciones, enlaces permanentes, cabeceras, caché, compresión, reglas de seguridad y muchas otras cosas. Pero precisamente por eso hay que tratarlo con respeto.
En otros errores, como el error 500 en WordPress, el .htaccess también suele aparecer como sospechoso habitual. Una regla mal escrita, una directiva no soportada por el hosting o un bloqueo excesivo pueden generar errores muy distintos.
En este caso no fue un 500. Fue un 403. Pero la lógica era la misma: una regla del servidor estaba interfiriendo con el comportamiento normal de WordPress.
💡 Lo interesante del caso: WordPress 7 no tuvo la culpa
Para mí, esta es la parte más importante del caso. La actualización a WordPress 7 no rompió la web por sí misma. Lo que hizo fue sacar a la luz una configuración incorrecta que ya estaba ahí. Y esto pasa mucho.
Una web puede funcionar aparentemente bien durante meses o años con una configuración frágil. Hasta que un día actualizas WordPress, cambias PHP, actualizas un plugin, activas una caché, migras de hosting o modificas una regla de seguridad.
Entonces aparece el error. Y es muy fácil culpar al último cambio. Pero en mantenimiento WordPress, culpar al último cambio sin investigar es una mala práctica. El último cambio puede ser la causa. O puede ser solo el detonante. Aquí fue lo segundo.
📋 Qué haría antes de actualizar una web crítica
Este caso refuerza algo que aplico siempre que una web tiene cierta importancia comercial. Antes de actualizar WordPress, plugins o tema, conviene tener como mínimo:
1. Copia de seguridad reciente y restaurable
No basta con “tener backups”. Hay que saber si se pueden restaurar. Parece obvio, pero cuando una web falla, descubrir que el backup no sirve es una faena seria.
2. Revisión de plugins, tema y versión de PHP
No todo conflicto viene del core. Muchas veces el problema real está en un plugin abandonado, una plantilla antigua o una versión de PHP que ya no encaja.
3. Control del .htaccess
No hace falta revisar cada línea en cada actualización menor, pero si una web tiene reglas personalizadas de seguridad, redirecciones o caché, hay que saber qué hacen.
Copiar reglas sin entenderlas es una mala estrategia.
4. Pruebas después de actualizar
No basta con ver que la home carga. Después de una actualización importante, reviso como mínimo:
- Home
- /wp-admin/
- login
- formularios
- checkout si hay WooCommerce
- buscador
- páginas clave
- REST API
- sitemap
- consola del navegador
- logs de errores
5. Método para aislar el error
Si algo falla, no se trata de tocar diez cosas a la vez. Se trata de probar por capas: plugins, tema, .htaccess, permisos, caché, WAF, servidor y logs.
🛡️ La regla buena: menos “seguridad decorativa” y más criterio
Me gusta reforzar esto porque es una fuente habitual de problemas.
Hay muchas recomendaciones de seguridad para WordPress que se copian sin contexto:
- Bloquea este archivo
- Desactiva esta ruta
- Añade esta regla
- Oculta esto
- Deniega aquello
Algunas son útiles. Otras son innecesarias. Y algunas, directamente, pueden romper funcionalidades legítimas.
La seguridad no debería ser una colección de reglas pegadas en .htaccess. Debería ser una combinación de:
- actualizaciones controladas
- copias de seguridad fiables
- permisos correctos
- monitorización
- firewall bien configurado
- contraseñas y accesos seguros
- plugins mantenidos
- criterio técnico
Una regla que bloquea upgrade.php puede parecer protectora, pero si impide que WordPress actualice la base de datos después de una actualización, acaba siendo un problema.
✔️ Conclusión: no era WordPress 7, era una mala regla
Este caso empezó como muchos otros: “He actualizado WordPress y ahora la web da error.” Pero terminó con una conclusión bastante diferente: “La actualización ha dejado al descubierto una regla del .htaccess que no debería estar bloqueando upgrade.php.”
La solución no fue deshacer WordPress 7. Tampoco fue desactivar todos los plugins a lo loco. Ni restaurar una copia sin investigar. La solución fue diagnosticar, acotar y corregir la regla exacta que estaba provocando el 403. Y esa es la diferencia entre apagar fuegos y mantener una web con criterio.
🆘 ¿Quieres evitar que una actualización acabe en una caída?
Si tu web WordPress genera contactos, ventas o reservas, no deberías depender de actualizaciones improvisadas ni de reglas copiadas sin revisar.
Porque mantener WordPress no es darle al botón de actualizar. Es asegurarse de que, cuando algo cambia, la web sigue funcionando como debe.