L’errore 405 Method Not Allowed indica che il server ha riconosciuto la risorsa richiesta, ma non accetta il metodo con cui è stata chiesta. È un errore meno intuitivo di un 404 o di un 403, perché tira in ballo un aspetto delle richieste web che di solito resta invisibile: ogni richiesta, oltre all’indirizzo, dichiara anche che cosa vuole fare con quella risorsa. Quando l’azione non è prevista, il server risponde 405.
In questa guida vediamo che cosa sono i metodi HTTP, come si presenta l’errore, quali sono le cause tipiche sui siti web e nelle applicazioni, e come risolverlo.
Cosa sono i metodi HTTP
Ogni richiesta che il browser invia a un server inizia con un verbo, chiamato metodo, che indica l’operazione richiesta. I più comuni sono GET, usato per leggere una pagina o un file, e POST, usato per inviare dati, come quando compili un modulo di contatto o fai il login. Le applicazioni web e le API usano anche PUT e PATCH per modificare dati, DELETE per cancellarli, HEAD per chiedere solo le intestazioni e OPTIONS per sapere quali metodi sono disponibili.
Non tutte le risorse accettano tutti i metodi. Una normale pagina statica risponde a GET, ma non ha senso inviarle dati con POST; un endpoint che riceve i dati di un modulo, al contrario, potrebbe accettare solo POST. Il 405 è la risposta corretta quando la combinazione tra risorsa e metodo non è prevista.
Cosa significa errore 405
Il 405 fa parte degli errori 4xx. Secondo lo standard, il server che lo restituisce deve includere un’intestazione Allow con l’elenco dei metodi ammessi per quella risorsa, per esempio:
HTTP/1.1 405 Method Not Allowed
Allow: GET, HEADQuesta intestazione è un indizio prezioso: ti dice esattamente quali operazioni il server è disposto ad accettare su quell’indirizzo.
Il 405 si distingue da altri errori simili. Con il 403 il server rifiuta l’accesso in generale; con il 404 la risorsa non esiste; con il 405 la risorsa esiste, ma non si può trattare in quel modo.
Come si presenta
I messaggi più comuni sono 405 Method Not Allowed, HTTP Error 405, The requested method POST is not allowed for this URL sui server Apache e 405 Not Allowed con la scritta nginx in fondo alla pagina. Nelle applicazioni e nelle API il 405 compare spesso come risposta in formato JSON, visibile solo negli strumenti per sviluppatori o nei log dell’integrazione.
Per i visitatori, il caso più frequente è quello di un modulo che, una volta inviato, porta a una pagina di errore 405 invece della conferma.
Le cause più comuni
Modulo che invia i dati all’indirizzo sbagliato
Un modulo di contatto, di iscrizione o di ricerca invia i dati con POST a un indirizzo indicato nel codice della pagina. Se quell’indirizzo è sbagliato, cambiato dopo una migrazione o punta a una pagina statica, il server risponde 405. È la causa più frequente sui siti realizzati a mano o migrati da una piattaforma all’altra.
File statici serviti da Nginx
Nginx, per impostazione predefinita, non accetta richieste POST verso file statici come pagine HTML o immagini e risponde con un 405. Succede quando un sito statico contiene moduli pensati per un server che li elaborava, o quando la configurazione non passa correttamente le richieste a PHP.
Regole di sicurezza
Firewall applicativi, plugin di sicurezza e regole del server possono bloccare deliberatamente alcuni metodi. Disabilitare PUT, DELETE o TRACE sui siti che non li usano è una buona pratica di sicurezza, ma una regola troppo ampia può bloccare anche funzioni legittime, come l’API REST di WordPress usata dall’editor a blocchi.
Integrazioni e API usate nel modo sbagliato
Se un’applicazione invia un GET dove l’API si aspetta un POST, o viceversa, la risposta è un 405. Capita dopo aggiornamenti di plugin o di servizi esterni che cambiano le specifiche delle loro interfacce.
Reindirizzamenti che cambiano il metodo
Un caso subdolo: un modulo invia i dati con POST a un indirizzo che viene reindirizzato, per esempio da HTTP a HTTPS o dalla versione senza www a quella con www. Con alcuni tipi di reindirizzamento, come il 301 e il 302, molti browser trasformano la richiesta in GET e perdono i dati; se la destinazione accetta solo POST, il risultato è un 405. La soluzione è far puntare il modulo direttamente all’indirizzo definitivo.
Come risolvere se sei un visitatore
Ricarica la pagina del modulo, ricompilalo e invialo di nuovo: se la pagina era rimasta aperta a lungo o era in cache, potrebbe contenere un indirizzo non più valido. Controlla di essere sulla versione corretta del sito, perché a volte i moduli funzionano solo sull’indirizzo con https e www. Se l’errore persiste, segnalalo al gestore del sito: un modulo che restituisce 405 non sta funzionando per nessuno.
Come risolvere se il sito è tuo
1. Individua la richiesta che fallisce
Apri gli strumenti per sviluppatori del browser con il tasto F12, vai nella scheda Rete e riproduci l’errore. Troverai la richiesta con stato 405, il metodo usato e l’indirizzo di destinazione. Nelle intestazioni della risposta, se presente, l’intestazione Allow ti dice quali metodi sarebbero accettati.
2. Controlla la destinazione del modulo
Verifica nell’HTML del modulo l’attributo action e confrontalo con l’indirizzo che dovrebbe elaborare i dati. Assicurati che punti all’indirizzo definitivo, con il protocollo e il dominio corretti, per evitare reindirizzamenti intermedi.
3. Leggi i log e le regole di sicurezza
Il log del server conferma se la richiesta è stata rifiutata dal server web, da una regola del file .htaccess o da un firewall applicativo. Cerca direttive come LimitExcept o regole che filtrano i metodi. Trovi come leggere i log nella guida ai log del server.
4. Su WordPress, verifica l’API REST e i plugin
Se il 405 compare salvando articoli o usando l’editor a blocchi, il problema è quasi sempre nell’API REST, che usa metodi come POST e PUT. Disattiva temporaneamente i plugin di sicurezza e verifica che il server non blocchi i metodi necessari. Anche i moduli gestiti da plugin possono smettere di funzionare dopo un aggiornamento: il metodo per isolare il componente responsabile è descritto nella guida agli errori di WordPress.
5. Su Nginx, controlla come vengono passate le richieste
Se un indirizzo che dovrebbe essere elaborato da PHP viene invece servito come file statico, Nginx risponderà 405 alle richieste POST. Verifica che la configurazione del sito passi correttamente a PHP gli indirizzi dell’applicazione, in particolare dopo una migrazione o un cambio di struttura degli URL.
Un esempio concreto: il modulo dopo il passaggio a HTTPS
Immagina un sito vetrina realizzato qualche anno fa, con un modulo di contatto scritto a mano che invia i dati a http://esempio.it/invia.php. Il sito passa a HTTPS e alla versione con www, e viene aggiunto un reindirizzamento 301 da tutti i vecchi indirizzi ai nuovi. Le pagine funzionano perfettamente, ma il modulo smette di arrivare.
Che cosa succede? Il visitatore compila il modulo e il browser invia un POST al vecchio indirizzo. Il server risponde con il 301 verso https://www.esempio.it/invia.php e il browser segue il reindirizzamento, ma trasformando la richiesta in un GET senza dati. Lo script, che si aspetta un POST, risponde con un 405, oppure riceve una richiesta vuota e non invia nulla. Il visitatore vede un errore o una pagina bianca, il gestore non riceve alcun messaggio e per settimane nessuno se ne accorge.
La correzione richiede un minuto: basta aggiornare l’attributo action del modulo con l’indirizzo definitivo, oppure usare un indirizzo relativo come /invia.php. La lezione più utile è un’altra: dopo ogni migrazione, cambio di dominio o passaggio a HTTPS, prova a inviare ogni modulo del sito almeno una volta.
Errore 405 e SEO
I motori di ricerca scansionano le pagine con richieste GET, quindi un 405 legato all’invio dei moduli non ha effetti diretti sul posizionamento. Diventa un problema solo se il server rifiuta anche le richieste GET verso pagine pubbliche, cosa che può succedere con regole di sicurezza configurate male: in quel caso Search Console segnalerà gli indirizzi coinvolti. L’impatto indiretto, però, può essere notevole: un modulo di contatto o di acquisto che non funziona fa perdere contatti e vendite senza che nessuno se ne accorga, finché qualcuno non prova a usarlo.
Domande frequenti
Il 405 è un errore del server o del browser?
Formalmente è un errore della richiesta, perché usa un metodo non ammesso. Nella pratica, però, la richiesta la costruisce il sito stesso, attraverso i suoi moduli e script, quindi la correzione spetta quasi sempre a chi gestisce il sito.
Perché il modulo funziona in locale e dà 405 online?
Di solito perché il server di produzione è configurato diversamente, per esempio con Nginx al posto di Apache o con regole di sicurezza più rigide, oppure perché l’indirizzo di destinazione del modulo era scritto in modo relativo al vecchio ambiente.
Devo disabilitare i metodi che non uso?
È una buona pratica di sicurezza, ma va fatta con attenzione: WordPress e molte applicazioni moderne usano metodi diversi da GET e POST per funzioni interne. Prima di bloccarli, verifica che nessuna funzione del sito ne abbia bisogno.
