The Page Opens, but Your Link Checker Returns 403: What to Check
A working browser page and a failed automated check can both be real. Separate missing pages, denied requests, rate limits and login walls before changing links.
Like it ? share it
Keep the URL for review. A 403 means the server refused the request. It does not tell you that the page has disappeared.
Your browser may already be signed in. A server-side checker uses another network address and different headers, and may start with a different HTTP method. Those differences can explain why the same URL works in one place and fails in another.
A TechSEO user reported 200 in one crawler and 403 in other checks. Another asked how to check the response from a CDN, beyond reading robots.txt. Both describe a mismatch worth investigating, without establishing a common cause.
Check the status before changing the link
| Result | What this request established | Next step |
|---|---|---|
| 404 or 410 | The server reports the resource as unavailable or gone | Check the exact URL and whether an appropriate replacement exists |
| 403 | The request was understood but refused | Investigate access rules and differences between the browser and checker |
| 429 | The requester hit a rate limit | Stop the batch, respect any Retry-After instruction, and retry later |
| 500 or 503 | The request encountered a server-side failure | Retry after a reasonable interval; inspect logs for a site you manage |
| Timeout or no response | The check did not obtain an HTTP response | Check availability, DNS, TLS and access conditions before deciding the page is gone |
| 200 | The server returned a successful HTTP response | Inspect the content: a sign-in screen or challenge page can still answer 200 |
Repeatedly sending the same request usually will not resolve a 403 permission refusal. A 429 rate limit calls for waiting, with Retry-After specifying an interval when the server provides it.
Compare one URL in the browser and checker
Start with one failing address before rerunning the spreadsheet.
Open the exact URL in your normal browser, then in a private window. Note any login screen, challenge or change of address. Keep session cookies and private access tokens out of public checking tools.
A private window still uses your computer's network, so it cannot reproduce a remote checker's request.
Check which response each tool reports. One may follow redirects and show the final status; another may stop at the first response. A 301 followed by a 200 is a different result from a direct 200.
Use the Redirect Checker to inspect a public URL's HTTP redirects. Enfect's server requests the URL, so the trace cannot reproduce your signed-in browser or every client-side navigation.
Check whether the methods differ
HEAD requests headers without the response body, which makes it useful for lightweight checks. A site's implementation or access rules may treat it differently from GET. See the HTTP HEAD reference for how the methods are intended to relate.
For an address you are authorized to inspect, these commands compare the two methods without following redirects:
curl --max-time 20 -I "https://example.com/page"
curl --max-time 20 -sS -D headers.txt -o page.html "https://example.com/page"Replace the example address. The second command saves the GET headers and body for inspection. In Windows PowerShell, use curl.exe if curl resolves to a PowerShell alias. On another organization's site, stay within its permitted access.
We configured a local demonstration server and verified these responses on October 12, 2026:
| Demonstration path | Request | Observed response |
|---|---|---|
| /method-check | HEAD | 403 |
| /method-check | GET | 200 |
| /temporary-limit | GET | 429 with Retry-After: 60 |
| /gone | GET | 404 |
| /login-wall | GET | 200, with a body saying “Sign in” |
These controlled examples are not measurements of a public website. The same demonstration URL answers HEAD with 403 and GET with 200; another returns 200 but only a sign-in message.
The Enfect implementation reviewed for this article tries HEAD first, then GET if the HEAD request raises an error or returns 405 or 501. It returns a received 403 without automatically retrying with GET. Keep that result for manual review.
For your own site, find the request in the logs
Record the test time, path, HTTP method and status, then find the matching request in your origin or CDN logs.
Look for an access rule, challenge, missing permission or rate limit. Identify why it matched before changing the responsible rule. Disabling the entire security service is a poor diagnostic shortcut.
There are two separate questions:
- Do the site's robots.txt rules permit the crawler to request this path?
- Does the server actually deliver an accessible response to that crawler?
A robots.txt permission cannot override a server denial. Nor does a Googlebot User-Agent string establish who sent the request. Follow Google's request-verification instructions, using its published IP ranges or reverse DNS followed by a matching forward lookup.
For an indexing problem, check Search Console's inspection and crawl evidence alongside the logs. A checker's 200 does not prove indexing. A simulated Googlebot request's 403 does not prove Google's verified crawler received it too.
You may not be able to diagnose a site you do not manage. Mark the result as access-restricted or inconclusive, and contact the owner if the link matters.
Turn the batch into a review list
Run the list through the Bulk URL Checker and export the CSV. Keep each input URL beside its result and retain the final URL if the report includes it.
Add a few review columns:
| Column | Why keep it |
|---|---|
| Checked at | Separate an old failure from the current state |
| Browser result | Record content, sign-in requirements or challenges, not just “opens” |
| Expected destination | Catch redirects that succeed but land on the wrong page |
| Decision | Keep, replace, remove, access-restricted, or retry later |
| Next check | Avoid repeatedly probing an unresolved restriction |
Group failures by domain before reviewing them. Fifty 403s from one host may share one access rule. A single 404 on an otherwise healthy host points you toward that URL first.
After changing a permission or configuration, retest one representative URL before expanding the batch. If you hit a rate limit, wait for the requested interval and follow the site's permitted request rate.
A VPN-only work link, a temporary failure and a permanently removed article need different decisions. Record which one you have before removing the link.