Solución al error 405 Method Not Allowed en WordPress

Contexto del error 405 Method Not Allowed en WordPress

El código HTTP 405 indica que el servidor ha entendido la solicitud, pero no permite el método usado para ese recurso. En WordPress esto suele aparecer cuando una URL acepta lectura, pero rechaza acciones como POST, PUT o DELETE. El problema no siempre está en el núcleo de WordPress. Puede originarse en reglas del servidor, un cortafuegos, un plugin de seguridad, una caché inversa, un WAF del hosting o una configuración del tema o plugin que hace llamadas a endpoints no permitidos.

Su impacto depende de dónde falle. Si el error afecta a wp-admin, la edición de contenidos se vuelve incierta. Si alcanza formularios, checkout, REST API o AJAX, el sitio puede parecer operativo y, sin embargo, perder envíos, pedidos o tareas automáticas. En un ámbito general, y también en España, este tipo de error exige revisar tanto WordPress como la infraestructura que lo rodea, porque la causa real puede estar fuera del panel.

• Puede aparecer al enviar formularios de contacto, comentarios o registros de usuario.
• Es frecuente en llamadas a admin-ajax.php o a rutas de la REST API.
• También puede producirse tras endurecer reglas de seguridad sin validar compatibilidades.
• En WooCommerce puede bloquear acciones de carrito, checkout o webhooks.
• Un 405 repetido deja trazas útiles en logs, cabeceras HTTP y herramientas del navegador.

Diagnóstico inicial y señales útiles

La forma más segura de empezar es identificar exactamente qué URL devuelve el 405, con qué método y en qué contexto. No es lo mismo un 405 al iniciar sesión que al enviar un formulario o al guardar una entrada desde el editor. Revise si el fallo ocurre para todos los usuarios, solo en administración, solo en móvil, o solo con sesión iniciada. Conviene anotar la hora exacta de los intentos fallidos para cruzarla con los registros del servidor y del hosting.

Las señales útiles suelen ser verificables: mensaje 405 visible, respuestas distintas según navegador, picos de CPU en el panel de hosting, cambios recientes de plugins o reglas, alertas del proveedor, incidencias de certificados, avisos de Search Console si se bloquean recursos, o errores en consola del navegador al llamar a endpoints de WordPress. El primer criterio debe ser no empeorar el problema. Por eso conviene evitar cambios simultáneos, limpiezas agresivas o restauraciones parciales sin copia previa.

• Abra las herramientas del navegador y revise la pestaña Red para ver la URL exacta, el método HTTP y la respuesta.
• Compruebe si el error afecta a GET, POST u otro método, y si aparece en admin-ajax.php, wp-json o una ruta personalizada.
• Revise avisos del hosting sobre WAF, límites de recursos, reglas ModSecurity, PHP o incidencias de seguridad.
• Consulte cambios recientes: actualización automática, instalación de plugin, ajuste de caché, migración o edición de .htaccess.
• Haga comprobaciones prudentes en staging o en ventanas de baja actividad, manteniendo copia y registro de cada paso.

Causas habituales y cómo confirmarlas

Las causas más frecuentes del error 405 en WordPress combinan aplicación y servidor. A menudo hay reglas que permiten consultar una URL pero niegan operaciones de escritura o acciones AJAX. Esto puede deberse a configuraciones de Nginx o Apache, reglas del cortafuegos, plugins de seguridad, snippets en functions.php, restricciones del proxy inverso, o endpoints personalizados mal definidos. También ocurre cuando una integración externa intenta usar un método no previsto por el sitio o por una capa intermedia.

La confirmación debe basarse en evidencia. Si desactivar temporalmente una capa de seguridad en staging elimina el 405, el foco ya está acotado. Si la respuesta incluye cabeceras del proxy o del WAF, probablemente el bloqueo no viene del núcleo de WordPress. Si el problema empezó justo tras actualizar un plugin que usa AJAX o REST API, conviene revisar su changelog y su compatibilidad. El objetivo no es adivinar, sino aislar la causa con el menor impacto posible.

• Reglas del servidor que limitan métodos HTTP en rutas sensibles o directorios concretos.
• Plugins de seguridad o firewalls que bloquean POST por firmas, país, agente o patrón de solicitud.
• Configuraciones de caché o CDN que alteran cabeceras, rutas o comportamiento de formularios y API.
• Conflictos en endpoints personalizados de plugins, temas o integraciones con terceros.
• Permisos, reescrituras o restauraciones parciales que dejan una configuración incoherente.

Seguridad, malware y spam

Aunque un 405 no significa por sí mismo que haya malware, sí puede estar relacionado con medidas de seguridad o con actividad maliciosa. Algunos plugins y firewalls bloquean métodos HTTP para proteger rutas sensibles, frenar abuso de formularios o cortar intentos de explotación. El problema aparece cuando el bloqueo es demasiado amplio o cuando una vulnerabilidad, unas credenciales filtradas o una inyección previa han obligado a endurecer la configuración sin revisar el funcionamiento normal del sitio.

Los síntomas a vigilar incluyen usuarios desconocidos, cambios no autorizados, redirecciones extrañas, picos de peticiones POST, formularios que dejan de enviar, llamadas a wp-json bloqueadas o archivos modificados sin trazabilidad. La respuesta prudente pasa por hacer copia, revisar usuarios y roles, rotar contraseñas, comprobar integridad de plugins y temas, y aplicar hardening básico. Sin alarmismo, pero sin borrar evidencias. Si se elimina un archivo o se desactiva una regla antes de tomar notas y copias, puede perderse información útil para entender el origen.

• Revise si el bloqueo lo provoca un plugin de seguridad, un WAF del hosting o reglas antiabuso demasiado estrictas.
• Compruebe usuarios administradores, contraseñas, claves de acceso y permisos de archivos.
• Analice si existen plugins vulnerables, abandonados o instalados fuera del repositorio oficial sin control.
• Guarde copia de archivos y base de datos antes de limpiar, restaurar o eliminar componentes sospechosos.
• Aplique hardening razonable: mínimos privilegios, actualizaciones planificadas y supervisión periódica.

Rendimiento y estabilidad

El error 405 suele asociarse a permisos de método, pero también conviene revisar la estabilidad general del entorno. Cuando una web acumula cachés en varias capas, reglas automáticas, optimizadores de scripts y proxies, una petición legítima puede llegar transformada o interceptada. El resultado no siempre es un error uniforme. A veces solo falla bajo carga, en ciertas rutas o cuando interviene un sistema de seguridad adicional.

Desde el punto de vista operativo, una web estable necesita coherencia entre caché de página, caché de objeto, compresión, reglas del proxy y comportamiento de plugins dinámicos. Si el sitio envía peticiones AJAX frecuentes o usa WooCommerce, membresías o formularios complejos, las exclusiones de caché deben estar bien definidas. En ámbito general, un 405 intermitente merece revisar también cabeceras, cookies, sesiones y si hay peticiones bloqueadas por sobreprotección o por límites del servidor.

• Revise si el error aparece solo cuando hay caché activa o tras pasar por CDN o proxy inverso.
• Compruebe exclusiones de caché en rutas dinámicas, formularios, carrito, checkout y administración.
• Analice si hay picos de CPU o memoria que coincidan con reintentos, bots o tareas automáticas.
• Verifique cabeceras de respuesta y diferencias entre usuarios anónimos y autenticados.
• Evite optimizaciones agresivas sin prueba previa en staging y monitorización posterior.

Plugins, temas y actualizaciones

Una parte importante de los errores 405 aparece tras cambios aparentemente rutinarios. Un plugin puede modificar rutas AJAX, un tema puede añadir lógica en functions.php, y una actualización puede exigir nuevas reglas de servidor o versiones de PHP compatibles. Por eso conviene trabajar con staging, control de cambios y un criterio simple: tocar una variable cada vez y validar. Si se actualiza WordPress, varios plugins y el tema a la vez, luego será más difícil saber qué rompió la compatibilidad.

Cuando el fallo empieza justo después de actualizar, lo prudente es reproducirlo, revisar changelogs, comprobar compatibilidades y aislar el conflicto sin borrar datos. En muchos casos basta con desactivar temporalmente el plugin implicado en un entorno de pruebas, regenerar enlaces permanentes si procede y revisar si el endpoint afectado depende de una función o clase que ya no existe. Si se trata de un plugin crítico para negocio, el enfoque debe ser conservador y trazable.

• Use staging antes de aplicar cambios en plugins, tema, snippets o configuración del servidor.
• Documente fecha, versión y motivo de cada actualización o ajuste relevante.
• Revise changelogs y notas de compatibilidad cuando el fallo coincida con una actualización.
• Aísle conflictos desactivando componentes de forma controlada y con copia previa.
• Evite editar functions.php en producción sin control de versiones ni plan de reversión.

Hosting, dominio y correo en España

En muchos casos, la clave está en la capa de hosting. Proveedores distintos aplican WAF, reglas de Apache o Nginx, límites de recursos, cachés de servidor y políticas antiabuso diferentes. En España esto varía bastante según el servicio contratado, si hay panel administrado, si existe CDN integrada o si el proveedor aplica reglas de seguridad automáticas. Por eso un sitio puede funcionar en un entorno y devolver 405 en otro tras una migración o una simple clonación.

También conviene revisar DNS, SSL y correo transaccional cuando el error afecta a formularios o integraciones. Un 405 no es un error de correo, pero puede cortar el proceso de envío si la petición al plugin o a una API queda bloqueada. Revise versión de PHP, límites de memoria y procesos, reglas de caché de servidor, certificados, redirecciones entre HTTP y HTTPS, y si el dominio principal y el de administración resuelven de forma coherente. Si hay CDN o proxy, conviene comprobar en qué capa se genera la respuesta.

• Solicite al hosting confirmación sobre reglas WAF, ModSecurity, limitaciones de métodos y registros asociados.
• Verifique DNS, SSL, redirecciones y coincidencia entre dominio, subdominio y rutas administrativas.
• Compruebe versión de PHP, límites de memoria, procesos y tiempos de ejecución.
• Revise cachés de servidor y exclusiones necesarias para wp-admin, formularios, WooCommerce y API.
• Si el sitio envía correo transaccional, confirme que la solicitud llega al plugin o servicio sin bloqueo previo.

Pruebas, accesos y documentación técnica

Resolver un error 405 con rapidez depende de la calidad de las pruebas disponibles. No basta con decir que la web falla. Es mucho más útil aportar una URL exacta, el método HTTP afectado, capturas de la respuesta, hora del incidente, cambios previos y acceso a logs. En proyectos donde intervienen varias personas o proveedores, la documentación evita duplicar acciones, reduce tiempos muertos y permite decidir si el problema está en WordPress, en el servidor o en una capa externa.

Desde un enfoque técnico y preventivo, conviene reunir información antes de corregir. En España, como en cualquier otro entorno, el acceso disponible condiciona el análisis. Si solo se tiene acceso a WordPress, la revisión será parcial. Si además hay panel de hosting, logs, DNS y copia consistente, el diagnóstico mejora mucho. La trazabilidad técnica ahorra tiempo y reduce el riesgo de repetir errores al restaurar o cambiar ajustes.

• Trazabilidad de cambios recientes: registro de actualizaciones, lista de plugins activos, theme en uso y changelog de cambios aplicados.
• Evidencias técnicas: logs de acceso y error, capturas, URLs afectadas, respuesta HTTP, export de base de datos y copia de seguridad reciente.
• Accesos mínimos para diagnóstico: WordPress, panel de hosting, gestor de archivos, base de datos y, si existe, CDN o firewall.
• Pruebas controladas: reproducir el error en staging, desactivar temporalmente una sola capa y documentar el resultado.
• Datos operativos: fecha de inicio, alcance real, usuarios afectados, impacto en formularios, ventas o tareas automatizadas.

Plan de acción ordenado

Para abordar un 405 en WordPress conviene seguir un orden lógico. Primero, contención. Después, copia. Luego, diagnóstico. Más tarde, corrección y verificación. Por último, monitorización. Saltarse este orden puede hacer que el sitio vuelva a funcionar de forma aparente, pero deje una configuración inestable o una causa latente sin resolver. El objetivo razonable es restaurar el servicio con el menor riesgo y con capacidad de explicar qué se cambió.

La corrección depende del hallazgo. Puede consistir en ajustar una regla de servidor, revisar un plugin de seguridad, reconfigurar caché, deshacer un cambio en functions.php, restaurar un archivo concreto o coordinar al hosting para permitir un método legítimo. Tras eso, hay que verificar el flujo afectado, revisar logs posteriores y establecer monitorización. Si el error afectaba a formularios, pedidos o APIs, conviene validar manualmente varios casos de uso y guardar evidencia de la recuperación.

• Contenga el problema y evite nuevos cambios no coordinados mientras se recopilan pruebas.
• Genere una copia consistente de archivos y base de datos antes de modificar configuraciones.
• Aísle la causa con pruebas controladas en staging o fuera de horas críticas.
• Corrija una sola capa cada vez: plugin, tema, servidor, WAF, caché o regla personalizada.
• Verifique el flujo completo, documente el cambio aplicado y mantenga monitorización posterior.

Si ya se ha tocado algo o hay urgencia

En urgencias es habitual que ya se hayan realizado acciones con buena intención: instalar un plugin de seguridad, restaurar una copia parcial, cambiar de hosting, tocar functions.php, borrar un plugin crítico o intentar limpiar malware sin copia. Estos movimientos pueden alterar síntomas, ocultar la causa o mezclar varios estados del sitio. La prioridad pasa entonces por reconstruir una cronología y evitar tocar más elementos de los necesarios hasta entender qué quedó cambiado.

Si ya se han hecho pruebas, no conviene deshacerlas al azar. Es mejor anotar qué se cambió, cuándo y con qué resultado. Si se restauró solo la base de datos o solo los archivos, puede haberse creado una incoherencia que explique el 405. Si se editó functions.php, la revisión debe incluir ese archivo y cualquier snippet añadido. Si hubo cambio de hosting, revise diferencias de servidor, WAF, PHP, SSL, DNS y reglas heredadas. La cautela principal es no perder evidencia técnica ni agravar la caída.

• No siga aplicando cambios simultáneos sin una copia nueva y sin registrar la situación actual.
• Reconstruya la secuencia: plugin de seguridad instalado, restauración parcial, migración o edición manual.
• Revise functions.php, mu-plugins, snippets y cualquier personalización fuera del repositorio habitual.
• Si se borró un plugin crítico, confirme dependencias, shortcodes, endpoints y tablas afectadas antes de reinstalar.
• Si se intentó limpiar malware sin copia, preserve el estado actual y recopile evidencias antes de continuar.

Preguntas frecuentes

Estas dudas suelen repetirse cuando aparece un error 405 en WordPress. Responderlas ayuda a priorizar acciones sin precipitar cambios innecesarios.

P: ¿El error 405 significa que WordPress está roto?

R: No necesariamente. Suele indicar que una ruta existe, pero no acepta el método HTTP usado. El origen puede estar en WordPress, en un plugin, en el servidor o en una capa de seguridad.

P: ¿Puedo solucionarlo solo desactivando todos los plugins?

R: A veces ayuda a aislar el conflicto, pero hacerlo sin copia ni orden puede ocultar la causa y afectar al negocio. Es mejor probar de forma controlada y documentar resultados.

P: ¿Un cambio de hosting puede causar este error?

R: Sí. Diferencias en WAF, reglas de Nginx o Apache, caché administrada, PHP o SSL pueden provocar un 405 tras migrar, aunque el sitio parezca estar bien copiado.

P: ¿Tiene relación con formularios o WooCommerce?

R: Sí, con frecuencia. Muchas acciones de formularios, carrito, checkout, AJAX y API usan métodos POST u otros métodos que pueden quedar bloqueados por reglas de seguridad o servidor.

P: ¿Qué prueba aporta más valor al diagnóstico?

R: La combinación de URL exacta afectada, método HTTP, hora del fallo, captura de la respuesta y logs del servidor o del hosting. Con eso es mucho más fácil localizar la capa que bloquea la petición.