Why does it say GET and HEAD are supported when I only defined GET?

Laravel registers HEAD alongside every GET route, because HTTP requires a HEAD response to match the GET response without a body. Seeing both is normal and tells you nothing is wrong with that route.

The form posts to the right URL. What else could it be?

A redirect in between. If something sent the browser from the posted URL to another one - a trailing-slash rule, a locale prefix, an auth middleware - the redirected request arrives as a GET, and then the URL in the message is not the URL your form submitted to.

Why does it work locally and fail on the server?

Usually a stale route cache. `php artisan route:cache` writes the routes to a file and a deploy that adds a route without clearing it serves the old table. The message then describes a route table that no longer matches your code.

Does this apply to PUT and DELETE in forms?

Yes, and it is the most common version of it. An HTML form can only issue GET or POST, so a route defined as PUT needs `@method("PUT")` in the form to be spoofed. Without it the request really is a POST and the route really does not accept one.

Laravel error

Laravel: The POST method is not supported for this route

The error

The POST method is not supported for this route. Supported methods: GET, HEAD.

A MethodNotAllowedHttpException means the URL matched a route but the verb did not. The supported methods in the message tell you which mistake you made.

Updated October 27, 2026

Symfony\Component\HttpKernel\Exception\MethodNotAllowedHttpException
The POST method is not supported for this route. Supported methods: GET, HEAD.

The URL matched. The verb did not. That distinction is the whole diagnosis: this is never a missing route, it is a route that exists for a different method.

Read the supported list in the message first. It is the route table's own answer, and it narrows the cause to one of four.

The route is defined for the wrong verb

Route::get('/orders', [OrderController::class, 'store']);   // posts here fail
Route::post('/orders', [OrderController::class, 'store']);  // what you meant

Obvious once seen, and worth eliminating before anything else:

php artisan route:list --path=orders

The form cannot send the verb it claims

HTML forms issue GET or POST and nothing else. A route defined as PUT, PATCH or DELETE needs the method spoofed:

<form method="POST" action="{{ route('orders.update', $order) }}">
    @csrf
    @method('PUT')
</form>

Without @method, the request is a genuine POST, the route accepts only PUT, and the message is accurate.

For a JSON client there is no spoofing involved - send the real verb and make sure nothing between you and the application rewrites it.

Something redirected the request first

This is the one that wastes an afternoon, because the URL in the message is not the URL you posted to.

A POST that is redirected arrives at the destination as a GET. Every redirect does this: a trailing-slash normalisation, a locale prefix added by middleware, an https upgrade, an auth middleware bouncing a guest to the login page and back. The destination route has no POST handler, and the error names the destination.

Check the network panel rather than the code. Two requests where you expected one, with a 301 or 302 in between, is the answer.

The route cache is stale

php artisan route:clear
php artisan route:cache

A cached route table is a file. If a deploy added a route and did not rebuild it, the application is serving the previous table, and route:list will agree with the error rather than with your code - which is what makes this one confusing to diagnose from the source.

Rebuilding the cache belongs in the deploy, not in a developer's memory.

The one that is not a bug

A crawler, a scanner, or somebody's old bookmark will POST to a GET route, and the exception is the correct response. These belong in the log and nowhere else.

If they are filling your error reporting, the fix is to stop reporting them rather than to accept the method: a 405 for a request nobody legitimate made is the framework doing its job. What is worth watching is the rate - a sudden burst of them against form endpoints is usually somebody probing, not a regression.