403 Forbidden: Is the Website Down or Is Access Blocked?

1. Read the result as a response to one request

A 403 is an HTTP response, so the check reached a server capable of answering. That response may come from the website, a hosting access rule, a security service or another component in front of the application. The status code alone does not identify which component made the decision.

NetLuma groups 401, 403 and 429 under restricted access and displays the actual code. These codes have different meanings. In particular, a 403 is not an instruction to keep trying the same login; valid credentials do not necessarily grant permission to that resource.

When HTTPS is shown as Verified beside a 403, the connection passed certificate verification. The application can still deny the request over that trusted connection. Neither result proves that every page or feature works.

2. Compare the same URL in both places

Copy the exact public address, including http or https, the hostname and the page path. A working homepage and a restricted account page are different resources. Do not put a password, private invitation link or access token into a public checker.

Your browser and NetLuma make different requests. A browser can have an existing session, cookies and JavaScript support. NetLuma sends an HTTP request from its hosting server without your browser session and does not run page scripts. The target may apply different rules to those requests or their source networks.

For example, a public page might open in your browser while NetLuma receives 403 with HTTPS verified. Record both observations and their times. That combination suggests a difference in access or serving conditions; it does not prove a particular firewall or plugin caused it.

3. Use the pattern to choose the next check

Start with the result you can reproduce. The examples below are investigation paths, not automatic diagnoses.

On a small screen, scroll the table sideways to see both columns.

4. If you are visiting someone else’s website

Use the site’s normal navigation to confirm the address. If the resource requires an account, follow the owner’s access instructions in your browser. A public website checker cannot sign in as you or establish your account permissions.

If a page you expect to be public remains restricted, contact the owner with the public URL, displayed error and approximate time. Avoid repeatedly submitting the same check: additional requests do not resolve a permission rule and may run into a request limit.

5. If you own the affected website

Look for the failed request in your hosting, application or security-service logs using its time and path. Where available, compare the recorded status, request source and matched rule with a successful browser request. If the request never appears at the application, inspect the service handling traffic before it.

Check whether that path is intentionally private, whether the hostname reaches the expected installation, and whether a hosting rule or application setting excludes the request. Ask your provider to help identify the denying component when the available logs do not show it.

After finding the cause, make the smallest change that matches your intended public access. Keep a copy of the previous configuration and test the same page again. A blocked checker alone is not a reason to remove security protection from the entire site.

6. Keep the conclusion within the evidence

A successful browser visit establishes that the page worked for that visit. A 403 check establishes that this request was refused. Keep the status visible instead of treating a refusal as a successful page response.

NetLuma performs a single check from its hosting server. Compare another network or the provider’s service status when necessary. For a redirect or certificate issue, use the dedicated tool for that part of the connection; none of these checks measures historical uptime or availability everywhere.