What an HTTP 405 code means on WordPress and how to fix it

Your contact page loads fine, but clicking Submit returns “405 Method Not Allowed”. Or the store looks normal until an integration tries to update a product and gets the same answer. The site isn’t down. One request is being refused, and the code tells you what kind of refusal it is.

What does a 405 tell you, and what doesn’t it tell you?

Every web request is a URL plus a method. GET reads. POST submits. PUT and PATCH update, DELETE removes, and OPTIONS asks what is allowed. A 405 means the server reached the URL and recognised the method, but that resource doesn’t accept it. RFC 9110, the HTTP standard, defines the status this way. It also requires the server to send an Allow header that lists the methods the resource does support.

That narrows the problem down without naming a culprit. On a WordPress site, the refusal can come from the request itself, WordPress routing, a plugin, leftover custom code, a cache, a security layer or the web server’s configuration. The fix depends on which of those said no.

Status	What it means	Where to look
404 Not Found	The URL doesn’t resolve to anything	Permalinks, rewrite rules, the address itself
403 Forbidden	The request reached something that refused access	Permissions, security rules, logins
405 Method Not Allowed	The URL exists but rejects this method	The method sent versus the Allow header
501 Not Implemented	The server doesn’t support the method anywhere	Server software and configuration

The 404 comparison is the one people get wrong most often. Much of the standard WordPress troubleshooting advice is written for 404s, and editing your custom WordPress 404 page won’t touch a method mismatch.

How do you find the request that is failing?

Capture the request before you change any setting. If you change settings first, you can lose the evidence and leave the cause where it was.

1. Open the page in Chrome, Firefox or Edge and press F12. Choose the Network tab.
2. Repeat the failing action once: submit the form, click Publish, add to cart.
3. Find the request with status 405. It usually isn’t the page address. Look for admin-ajax.php, something under /wp-json/, or the form’s own handler.
4. Note four things: the request URL, the method, the response headers (especially Allow) and the time.

WooCommerce’s guide to troubleshooting AJAX issues uses the same Network-tab method. Then compare the method with the Allow list. If the request sent POST and the header says Allow: GET, HEAD, the request went to a URL that was never meant to take a submission, or something in front of WordPress answered for it.

If you’re comfortable in a terminal, repeat the exchange outside the browser:

curl -i -X POST https://example.com/wp-admin/admin-ajax.php

The -i flag prints the response headers. A bare curl request has no form body, cookies or nonce, so it only shows which layer answers, not whether the real submission would succeed. If Allow is missing, or the response headers name a cache or a firewall, then something other than WordPress probably produced the 405. MDN’s 405 reference covers the header in more detail.

Two cautions. Don’t keep resubmitting a checkout while you investigate. And don’t “fix” the request by switching POST to GET. A method that is allowed is only correct if it matches what the endpoint is for.

When is a 405 not a problem at all?

A browser address bar always sends GET. Paste wp-comments-post.php, admin-ajax.php or a form’s processing script into it, and a 405 or an error page is normal behaviour, because those URLs exist to receive POST. A 405 only matters when it shows up during the real action: the comment form submitting, the editor saving, the integration calling.

What causes a 405 on a WordPress site?

Nobody has published figures on which cause is most common, so be wary of any guide that claims to know. The list below runs from cheapest to check to most involved, and leans on cases where someone reached a confirmed fix.

The request uses the wrong method for that endpoint

WordPress REST routes are specific to each method. The REST API Handbook’s key concepts page explains that one route maps to separate endpoints by method. The posts route lists posts on GET and creates one on an authenticated POST. A route that accepts POST doesn’t automatically accept PUT or DELETE. Check the documentation for that exact endpoint.

For WooCommerce integrations, check three things in the WooCommerce REST API documentation. The permalink structure can’t be Plain. The API key needs Write or Read/Write permission to change data. And the integration must not depend on the legacy REST API, which was removed from WooCommerce core in version 9.0. Install the separate WooCommerce Legacy REST API plugin only if the integration really calls the legacy API. It isn’t a general 405 fix. Seeing JSON at /wp-json/ only proves the API index responds. It doesn’t prove the route you need works.

A cache is answering a POST with a static page

Forms or add-to-cart buttons that fail only when caching is on point here. The server hands a cached HTML file to a request that is trying to submit data, and a static file can’t accept POST. In one WordPress.org support thread, Gravity Forms and WooCommerce AJAX requests returned 405 on a server running WP Rocket behind WordOps Nginx rules. The owner fixed it by replacing those Nginx rules with the SatelliteWP rocket-nginx configuration, and kept WP Rocket.

That is one case, not proof that WP Rocket causes 405s. The lesson is narrower: when switching off a cache plugin “fixes” it, the real fault may be the server rules around the plugin. If you can’t change the server rules, exclude the affected URL. In WP Rocket that is Advanced Rules, then Never cache URL(s), one URL or path per line. WP Rocket notes that an excluded page also loses its other optimizations. Keep the exclusion narrow, and remember that a pattern like /(.*) excludes every URL. If your host runs the cache, ask the host to add the exclusion.

A firewall or security rule is refusing the method

ModSecurity, a host firewall, Cloudflare rules or a security plugin can return a 405 that looks like a WordPress fault. Typical signs: the block editor or Elementor fails to save, widgets won’t update, or plugin updates fail with “Download failed. Method Not Allowed.” If the same failure appears on several sites on one server at once, the block is almost certainly upstream of WordPress.

WordPress’s loopback guidance gives a sensible order. Test plugin and theme conflicts first. If that changes nothing, ask the host about firewall or security rules, DNS, SSL and HTTP authentication. If you switch a security layer off to test, do it briefly, on staging where you can, and switch it back on. Leaving protection off is not a fix. The fix is a rule that allows the specific path and method.

The web server only allows certain methods

Server software can restrict methods directly. On IIS, the PHP handler in web.config lists the verbs it accepts. In a WordPress.com forum case, a WooCommerce setup-wizard 405 cleared once the handler allowed all verbs (verb="*"). An earlier attempt with a stripped-down web.config broke the site until the inherited handler settings came back. On Apache, look for Limit or LimitExcept blocks. Nginx has its own method rules.

Edit only the rule that covers the failing path. Don’t paste .htaccess examples into an Nginx or IIS server, because they won’t be read. Our guide to Apache web server security covers which directives belong where.

A plugin, a theme or leftover custom code

Plugins can register routes with narrow methods or filter REST requests. Test the way the Manage Plugins documentation describes: deactivate, then reactivate one plugin at a time, then try a default theme. Do this on staging for a live store. Our guide to fixing plugins that aren’t working walks through it.

On sites with history, also check code a previous developer left behind: snippets in the theme’s functions.php, a must-use plugin, or a filter on rest_pre_dispatch or rest_authentication_errors. “The host says nothing is blocked” doesn’t end the search. Custom code can block PUT and DELETE while GET and POST still work.

Which popular fixes don’t fix a 405?

Saving permalinks. Visiting Settings > Permalinks and clicking Save flushes rewrite rules. If .htaccess is writable, WordPress also updates it, according to the Permalinks screen documentation. That repairs broken pretty URLs, which show up as 404s. It’s harmless to try, but it doesn’t change which methods a URL accepts.

Disabling the REST API. The REST API Handbook’s FAQ warns against it, because WordPress admin features depend on the API. You would swap one broken request for a broken editor.

Editing core files or turning off auto-updates. Core edits disappear at the next update, and turning off updates leaves known security holes open.

Deactivating everything on a live store. This tells you a combination fails, not which layer is at fault, and customers see the broken site while you test.

Why does a 405 on a public page hurt search?

Google’s documentation on how HTTP status codes affect its crawlers says Google doesn’t index URLs that return a 4xx status other than 429. Indexed URLs that start returning one are removed over time. A 405 on a form endpoint doesn’t matter for search. A 405 on a product or landing page, caused for example by a firewall rule that misfires on GET, takes that page out of Google.

When should you stop and get help?

Hand it over when the evidence points outside WordPress (no Allow header, a firewall or cache signature, many sites failing together), when the fix means editing server configuration you can’t easily undo, or when the failing action takes money. Send the host or developer the request URL, method, response headers, timestamp, and a list of what you already tried. That turns a vague ticket into a five-minute log lookup.

If you would rather not trace it yourself, SiteSelf can diagnose and fix broken site errors on request through chat. Code, server and cache work needs hosting (SSH) access, not just the connector plugin.