Link check returns 405: compare HEAD and GET

Do not label a link broken from the number alone

Your browser opens a page, but a check returns 405. The discrepancy calls for investigation rather than immediately deleting the link. The code means the requested method is unsupported for that resource according to the response received. It does not confirm that the content exists, is public, or is available to every visitor. Keep the exact address and note which tool produced the result.

In a Stack Overflow question, switching a check from GET to HEAD caused 405 errors. Another question on Reddit describes false positives when checking links with a program. These are reported problems, not evidence of the cause in your case. This guide compares requests and checks content before deciding whether the link, checker, or site configuration needs correcting.

What changes between HEAD and GET

GET requests a representation of the resource; HEAD requests the metadata corresponding to GET without that response body. MDN documents the distinction. Requesting headers alone can reduce transfer, but cannot read the page or confirm that it contains the expected document. Nor does it guarantee that an application or intermediary handles both methods correctly. When a method is rejected, record which method was used.

RFC 9110 requires a 405 response to include Allow listing the methods currently supported for the resource. Inspect that header if your tool displays it. If absent, record its absence; do not invent its contents or assume that allowing every method would solve the problem. The sample response is illustrative, not a capture from a real website. Allow does not replace testing the method you need.

HTTP/1.1 405 Method Not Allowed
Allow: GET

Compare requests you can interpret

If you administer the site and understand a terminal, compare HEAD and GET against the same public read-only address. The commands show headers; the second discards the body after receiving it, so it may download data. Replace example.invalid with your authorized page; this is a fictional domain, not an available service to check. Do not test purchasing, deletion, or sign-out actions.

Keep the URL and controllable conditions identical. Record time, method, status, and any redirect. The commands do not follow redirects: inspect a redirect destination before deciding whether to repeat there. Do not add credentials or copy private cookies into public tools. A signed-in browser and an anonymous request from another machine are not equivalent comparisons; record that difference before blaming the method.

curl --head --max-time 20 "https://example.invalid/guide"
curl --silent --show-error --max-time 20 --dump-header - --output /dev/null "https://example.invalid/guide"

Interpret results without jumping to conclusions

If HEAD returns 405 and GET returns 200 under comparable conditions, you can say those two requests received different responses. You must still open the page and check its content. If GET also returns 405, you have not demonstrated a HEAD-only problem. If GET returns 404, the earlier HEAD check did not establish that the requested page existed. Separate each observation from your hypothesis.

Do not change a form from POST to GET to remove an error message. This may alter its operation and expose data in the address. Do not disable security controls or enable write methods for convenience. On your own site, give the results to the person reviewing routing and server rules. For someone else's site, request a suitable public link or report the issue without sensitive data.

Add a WikiURL check

Paste the complete public address into WikiURL's URL checker and save the HTTP status and detected final address. This is an additional observation from the service's server. Do not assume it reproduces your browser, session, or earlier commands. The interface does not provide a manual HEAD/GET selector; do not attribute a comparison to it that it does not display.

Then open the real destination in a browser and confirm it is the intended page for its audience. If checker and browser disagree, preserve both results and their conditions. A 200 certifies neither content nor safety; an isolated 405 does not by itself decide whether to remove the link. Gather evidence to correct the specific component rather than turning a label into a complete diagnosis.

Record a verifiable decision before sharing

Keep a brief record: URL, date, tool, known method or not observed, status, final destination, and checked content. Mark missing tests as pending. Save necessary headers without tokens, cookies, or personal information. Give another reviewer that summary and the expected behavior, rather than a conclusion the observations do not yet support.

After a concrete correction, run a proportionate check and confirm the content before shortening the address or generating a QR with WikiURL. These formats help sharing but neither change the server's supported method nor repair the resource. Keep the reference link alongside the published file. This distinguishes client differences, a rejected method, and an incorrect destination without destroying a valid address on the basis of one response.