How to Fix the 405 Method Not Allowed Error

You click submit on a form. The page throws a 405 Method Not Allowed error. No stack trace, no useful hint, just a flat refusal from your server. Welcome to one of the more annoying HTTP error codes.

The HTTP 405 status code tells you one specific thing: the server found the resource, understood your request, and rejected the HTTP method you used. The page is there. The server simply won’t do what you asked it to do. This isn’t a 404. The URL is correct. Something in the server’s configuration, your application code, or a recently installed plugin decided that a perfectly valid POST or PUT request should be treated like an unwelcome guest.

What follows is a breakdown of every cause I’ve seen in production, plus 11 fixes ordered from “takes thirty seconds” to “restore everything from backup.” If you’re a developer hitting this error in an API context, or a site owner staring at a broken contact form, the fix is almost always in the same handful of places.

What Causes the 405 Error

The 405 error fires when the HTTP request method doesn’t match what the resource accepts. The concept is simple; tracking down which layer introduced the mismatch is the hard part.

Unsupported HTTP Method

Every web resource is wired to accept specific HTTP methods. GET fetches data. POST submits data. PUT updates. DELETE removes. Send a DELETE request to a static HTML page that only handles GET? The server returns a 405. It found the page. It just refuses to process that particular action. This is the most common cause and usually means your code, form action, or API call is targeting the wrong endpoint.

Incorrect Server Configuration

Apache uses .htaccess files. NGINX uses nginx.conf. A single misplaced directive in either one can block an entire HTTP method across a directory tree without any warning. I once tracked a 405 to a Limit directive someone copy-pasted from a security hardening blog without understanding what it did. It blocked POST on every HTML file in the site root. The contact form, the checkout page, the login screen: all broken. The fix was deleting two lines. Finding those two lines took the better part of an afternoon because nobody remembered adding them.

API Restrictions

APIs are strict about which HTTP request methods they accept. An endpoint designed for POST won’t respond to PUT just because your client code sends one. If you’re seeing 405 errors only on API calls, pull up the API documentation and verify you’re using the correct method for each endpoint. This is especially common when working with third-party APIs that version their endpoints and deprecate old methods.

REST APIs are the usual suspect here. A GET request to a resource endpoint that only supports POST will return a 405 every time. Same thing with PATCH versus PUT: some APIs treat them as interchangeable, others don’t. Read the docs, check the Allow header in the 405 response (it’ll list which methods the endpoint actually accepts), and adjust your request accordingly.

Web Application Firewall Rules

A web application firewall can override your server configuration entirely. WAF rules often block HTTP methods like PUT, DELETE, or PATCH on certain paths as a security measure. The trouble starts when those rules are too broad. A rule that blocks DELETE across your entire domain sounds reasonable until your admin dashboard needs DELETE to remove records.

If you recently enabled or updated your WAF and 405 errors started showing up, dial back the method-blocking rules and test again. Check your WAF provider’s dashboard for logs showing which rules triggered. Overzealous security creates its own problems, and a 405 that blocks legitimate functionality is worse than the theoretical attack it’s trying to prevent.

Plugin and Theme Conflicts

WordPress sites are particularly prone to this. You install a new plugin, it registers custom rewrite rules or REST API routes, those routes collide with something in .htaccess, and your site starts throwing 405 errors on form submissions. The plugin works fine in isolation. It’s the interaction with your existing configuration that causes the failure. Same thing with themes that include custom functionality or bundled plugins.

Leftover Database Changes

Some extensions modify database tables during installation and don’t clean up when you uninstall them. Orphaned records in options tables or custom post type registrations can confuse your application’s routing logic. The app might then send requests using the wrong HTTP method because its internal state no longer matches the actual server setup.

How to Fix the 405 Error

Work through these in order. The first few are fast sanity checks that catch the majority of cases. The later ones require digging into server internals and application code.

1. Verify the URL Is Correct

Start with the embarrassingly obvious. Typos in URL configurations cause 405 errors more often than anyone wants to admit.

• Misspelled paths (/usres instead of /users)
• Case sensitivity issues (some servers treat /Page and /page as different URLs)
• Trailing slashes that silently redirect to a different handler
• A route pointing to a handler that doesn’t support the HTTP method being used

Open your browser’s developer tools, go to the Network tab, and look at the failing request. Check the method (GET, POST, etc.) and the exact URL it’s hitting. Then compare that against what your application expects. If there’s a mismatch, fix the URL or the handler. If everything looks right, move on.

2. Roll Back Recent Updates

If the 405 appeared right after an update, don’t sit there debugging it for an hour. Roll it back first. You can investigate later with the site working.

Back up your site before the rollback. Then revert the most recent change. On WordPress, a plugin like WP Rollback handles this for core, themes, and plugins. On other platforms, use your deployment pipeline or version control to restore the previous state. If the error disappears after reverting, you’ve isolated the problem. Either wait for the developer to patch it, submit a bug report, or find an alternative.

One habit that would prevent most of these incidents: test every update in a staging environment before pushing to production.

3. Inspect Database Changes

Extensions sometimes write to your database during installation and don’t clean up after themselves when removed. These orphaned records can disrupt your application’s routing logic, causing it to send HTTP requests with the wrong method.

Open phpMyAdmin or your database tool, select your database, navigate to the SQL tab, and run:

SELECT UNIX_TIMESTAMP(MAX(UPDATE_TIME)) AS last_update

FROM information_schema.tables

WHERE TABLE_SCHEMA = 'your_database_name'

GROUP BY TABLE_SCHEMA;

If the timestamp aligns with when the 405 started, examine the recently modified tables for records that seem out of place. Focus on options tables, routing tables, and anything related to plugins you recently installed or removed. Always back up your database before making changes. Editing production data without a safety net is asking for a worse problem than the one you’re trying to fix.

4. Remove Faulty Plugins or Themes

On CMS-based sites, a recently installed plugin or theme is the single most common trigger for 405 errors. The new code either registers conflicting routes, modifies server-level configuration, or changes how your application processes HTTP requests.

In WordPress, go to the admin panel, open Plugins, and deactivate whatever you installed most recently. Test the site. If the error clears, that plugin was the cause. Repeat for themes under Appearance if the plugin wasn’t responsible.

Can’t reach the admin panel? SSH or FTP into your server and rename the plugin folder inside wp-content/plugins/. WordPress automatically deactivates any plugin it can’t find. Same approach for themes in wp-content/themes/. Try using a different extension that provides similar functionality once you’ve confirmed the old one was causing the conflict.

5. Analyze Server-Side Logs

When quick fixes fail, logs are where you’ll actually find your answer. You need to check two types.

Server Logs

Apache and NGINX maintain access logs and error logs. The access log records every request including the HTTP method, URL, and response status code. The error log explains why the server refused the request. These two together tell the complete story.

Apache logs live in /var/log/apache2/ on Debian/Ubuntu or /var/log/httpd/ on CentOS/RHEL. NGINX keeps them in /var/log/nginx/.

Use tail -f /var/log/apache2/error.log to watch the error log in real time. Trigger the 405 error in your browser, then look at the newest log entry. It’ll tell you exactly which rule or directive caused the rejection.

Application Logs

Your web app keeps its own logs separate from the server. These contain debug output, exception traces, and audit trails showing how the application processed the request internally. If the server-level logs look clean but the 405 keeps happening, the application itself is generating the error through its own routing logic.

Check the logs directory in your application’s root folder. On WordPress, enable WP_DEBUG and WP_DEBUG_LOG in wp-config.php to capture application-level errors to wp-content/debug.log. On Laravel, check storage/logs/laravel.log. On Django, look at whatever logging handler you’ve configured. The application log might reveal that a route mapping was recently changed or that a middleware is rejecting the request before it reaches your controller.

6. Review Web Server Configuration

Most persistent 405 errors live in your web server’s configuration files. This is where careful reading pays off.

Apache (.htaccess)

Two things in .htaccess cause the majority of Apache-related 405 errors:

• mod_rewrite rules that redirect traffic without preserving all HTTP methods. A RewriteRule built for GET that ignores POST will break every form submission on the affected path.
• Limit directives that restrict which methods a resource accepts. These are security measures, but a misconfigured Limit can block legitimate POST or PUT requests across entire directories.

Comment out suspicious directives with # and restart Apache to test. Re-enable them one at a time to isolate the problem.

NGINX (nginx.conf)

In NGINX, check for:

• Location blocks that implicitly exclude certain HTTP methods. If a location block only handles GET, all POST requests to that path will fail.
• error_page directives that redirect 405 errors to a static page that itself doesn’t accept the original request method, creating an endless rejection loop.

After editing, validate your config with nginx -t before reloading. A syntax error in nginx.conf can take your entire site offline.

7. Debug Your Code and Scripts

Sometimes the problem isn’t in the server config. It’s in your application code.

Common culprits:

• A form’s action attribute points to an endpoint that only accepts GET, but the form uses method=”POST”
• A JavaScript fetch() or XMLHttpRequest call sends the wrong HTTP method for the target API endpoint
• Framework middleware silently intercepts and rejects certain methods before your route handler sees them

Clone your site to a local development environment and reproduce the error there. On WordPress, deactivate all plugins and switch to a default theme (like Twenty Twenty-Four) to isolate the issue. If the 405 disappears, re-enable plugins one by one. Use your browser’s Network tab to inspect the exact request: method, URL, headers, and the response status code.

Write unit tests that exercise each endpoint with every HTTP method it should accept. Automated tests catch these mismatches during development instead of in production.

8. Restore Your Website from Backup

If you’ve exhausted every other option, restore the entire site from a backup. This is the nuclear option, and it works because it eliminates every variable at once.

Pick the most recent backup from before the 405 error started. This reverts your files, database, and configuration to a known good state. You’ll lose any changes made after that backup point. That’s the cost. If you don’t have recent backups, this is the lesson that convinces you to start automating them.

Most hosting control panels include a one-click restore feature. If not, manually upload your file backup via FTP and import the database through phpMyAdmin. After the restore, immediately test the pages that were throwing the 405 to confirm the error is gone. Then figure out what caused it before you reapply the changes that broke things. Restoring blindly and then making the same changes again will just put you back in the same broken state.

9. Fix .htaccess Rewrite Rules

Apache’s .htaccess rewrite rules deserve their own section because they cause a disproportionate number of 405 errors.

Open .htaccess through a file manager or FTP client. Search for any line containing R=405. That’s a rewrite rule explicitly returning a 405 status code. Comment it out by adding # at the beginning of the line, save the file, and clear your browser cache.

If the 405 stops, you’ve identified the rule. Before deleting it permanently, investigate why it was added. Someone might have put it there intentionally for security reasons. If it was blocking a method that your application needs, remove it. If it was protecting against an actual attack vector, find a more targeted way to enforce that restriction.

10. Correct File Permissions

Incorrect file permissions can produce 405 errors in unexpected ways. If the web server process doesn’t have proper ownership of your files, it may fail to execute scripts, and the resulting error sometimes shows up as a 405 instead of the 403 Forbidden you’d expect. I’ve seen this happen after server migrations where files were transferred with the wrong owner, or after someone ran a bulk chmod command that changed permissions across the entire document root.

Standard permissions for most web servers:

• Directories: 755
• Files: 644
• Owner: the web server user (www-data on Debian/Ubuntu, apache on CentOS)

Fix ownership recursively: chown -R www-data:www-data /var/www/yoursite

Fix directory permissions: find /var/www/yoursite -type d -exec chmod 755 {} \;

Fix file permissions: find /var/www/yoursite -type f -exec chmod 644 {} \;

11. Verify DNS A Records

This cause is uncommon, but if nothing else has worked, check your DNS. Incorrect A records can route traffic to the wrong server entirely, and that server may not accept the HTTP methods your application relies on.

Log into your domain registrar or DNS management panel and confirm your A records:

• Type: Must be A
• Name: @ for root domain, or the subdomain name
• Points to: The correct IP address of your actual hosting server
• TTL: Typically 14400 seconds (4 hours)

This is most relevant if you recently migrated servers, changed hosting providers, or updated DNS settings. DNS propagation can take up to 48 hours, so even correct changes might not be reflected everywhere yet. Use a tool like dig or an online DNS checker to verify what resolvers are seeing.

Website Maintenance Best Practices

Fixing the 405 error once isn’t enough. Preventing it from coming back is the real job. Most of these errors stem from changes: updates, new plugins, config edits, database modifications. A few habits go a long way toward keeping your site stable.

Check your server logs weekly. Not when something breaks. Weekly. You’ll catch warning signs, unusual 4xx spikes, deprecated method warnings, and failed request patterns before they become user-facing errors that drive visitors away.

Never update production without testing in staging first. This single website troubleshooting practice prevents the majority of 405 errors I’ve encountered in the real world. It takes five minutes to set up a staging site and saves hours of emergency troubleshooting at 2 AM on a Saturday.

Automate your backups and test them by actually restoring one periodically. A backup you’ve never verified is just a file that might work. “Might” doesn’t cut it when your checkout page is returning 405 errors on launch day.

Document your server configuration changes. Keep a changelog for .htaccess, nginx.conf, and any WAF rule modifications. When a 405 shows up three months after someone tweaked a Limit directive, you’ll know exactly what changed and when. Future-you will be grateful.

FAQ: 405 Method Not Allowed Error

What is a 405 Method Not Allowed error?

The 405 status code is an HTTP error response meaning the server recognized the URL and found the resource, but rejected the specific HTTP method used in the request. Sending a DELETE to a page that only accepts GET and POST returns a 405. The resource exists; the method is wrong. The server should include an Allow header in its 405 response listing which methods the resource does accept, which gives you immediate information on how to fix the request.

What is the difference between 404 and 405?

A 404 means the server couldn’t find anything at that URL. The resource doesn’t exist, or the path is wrong. A 405 means the resource is there and the URL is correct, but the server won’t process the HTTP method you sent. A 404 is “there’s nothing here.” A 405 is “this is here, but you can’t do that to it.” The fix for a 404 is correcting the URL or creating the missing resource. The fix for a 405 is using the correct HTTP method or reconfiguring the server to accept the one you’re sending.

Can a plugin cause a 405 error?

Yes, and it’s one of the most common causes on WordPress sites. Plugins can register custom routes, alter .htaccess rewrite rules, modify database records, and change how your server handles incoming requests. If a 405 appeared right after you installed or updated a plugin, deactivate it first. That’s your fastest path to confirming the cause.

How do I fix 405 on NGINX?

Open your nginx.conf file and look for location blocks that restrict HTTP methods. Check for error_page directives that redirect 405 responses to static pages that don’t accept the original method. After any change, run nginx -t to validate the config syntax before reloading with systemctl reload nginx. If you’re on managed hosting without config file access, contact your provider’s support team.

Does a 405 error affect SEO rankings?

It can. If a search engine crawler encounters a 405 on a page it’s trying to index, it can’t crawl that content. Persistent 405 errors signal accessibility problems to search engines, which hurts your crawl budget and can lead to pages being dropped from the index entirely. Users bouncing off error pages also damages engagement metrics like time on site and pages per session, which are indirect ranking signals.

Fix 405 errors fast, especially on pages that receive organic traffic. Use Google Search Console to monitor for crawl errors and set up alerts so you know about them before your rankings take a hit. An error that persists for a few hours probably won’t cause lasting damage. An error that lingers for weeks will.