403 Forbidden Error: How to Identify What Is Blocking Your Site
Updated 3 days ago
The 403 Forbidden error indicates that access to an address on your site was denied. To resolve it, check whether it affects all visitors or only one connection, and whether the block comes from Cloudflare, the application, or a server rule.
If you are only visiting someone else’s website, verify the address and notify its administrator. The file, permission, and security rule changes in this guide require access to the site or hosting account.
First, narrow down the problem
The same URL can provide different clues depending on the connection, the logged-in session, or the action you are trying to perform. Save the complete message before changing any settings.
Copy the exact URL and note the date, time, and time zone of the error.
Try the home page and another address that normally works.
Try the affected URL in a private window. If it requires you to log in, use an authorized account.
Try from another connection, such as mobile data, to compare the result.
Record whether the error appears when opening the page or when performing an action, such as saving a change or submitting a form.
A test that works from another network is a clue pointing to a connection- or IP-based block, not definitive proof of the cause. Use it to investigate the event, not to keep attempting an operation that the system is blocking.
What you observe
Where to start
A Cloudflare block page, sometimes with a Ray ID
Cloudflare security events.
The website opens, but saving or submitting a form returns 403
Application security rules and logs.
Only your connection or one visitor receives the error
Restrictions based on IP, session, country, or request frequency.
Everyone receives 403 after uploading or moving the site
Domain folder, start file, permissions, and access rules.
Only one folder or private area fails
Whether that address should allow public access.
Review the case that matches your error
A 403 is the result of a restriction. The event log helps distinguish legitimate protection from a rule that is blocking a valid action.
I see a Cloudflare block page
If a Ray ID appears, copy it along with the time of the error. This identifier lets us search for the request in the domain’s security events.
The fact that a response passed through Cloudflare does not prove that Cloudflare originated the 403. Likewise, a page without its logo does not completely rule it out: if you cannot find the event, we also need to review the origin server.
The site opens, but I receive 403 when saving or submitting a form
A security rule can reject the content of a request even when it allows the rest of the website to open. There may also be a restriction specific to WordPress or the application.
Note the page and the exact action that triggers the error.
If you are editing content, keep a private copy before repeating the test.
Try once with test content that contains no sensitive data, provided this does not create orders or perform other real operations.
Send us the time and result so we can search for the request in the server logs.
If you use our Imunify Security plugin, its events may also provide information. The 403 code alone does not identify ModSecurity, Imunify, or a specific plugin.
Do not permanently delete valid content to “make it pass.” If a false positive is confirmed, the rule should be adjusted for the required operation.
Only one IP, user, or connection receives 403
Access rules can limit an IP or a group of requests. In a private section, it may also be correct for an account without permission to be unable to enter.
If the result changes depending on the network, save the public IP of the affected connection and share it privately with support.
If it changes depending on the user, review their permissions within the application.
If you use a security plugin, review its events and the restrictions configured recently.
If you use Cloudflare, compare the time of the error with its events before modifying a rule.
If an authorized person was blocked, the correction should be limited to the access they need. Disabling all site protections makes it harder to find the cause and broadens the scope of the change.
Everyone receives 403 after uploading or migrating files
The domain must point to the correct folder, and the server must be able to read the files needed to display the page.
Check the root folder of the affected domain; an additional domain may use a folder other than public_html.
Verify that the start file expected by the application, such as index.php or index.html, is in that folder and that the upload has finished.
Compare the permissions and access rules with those the site had before the migration.
If the start file is missing and directory listing is disabled, the server may reject opening the folder. Restore the correct file from your site; enabling file listing does not replace a home page.
If the message indicates that the server cannot read .htaccess, send us the error. Both the permissions and the owner and folders along the path need to be reviewed, not just the named file.
The error started after changing .htaccess or access rules
A .htaccess rule can prohibit a path or an IP. If you know which change caused the problem, restore the previous version of that rule after saving a copy of the current file.
Do not delete the entire file just to test: it may contain security restrictions, redirects, and application settings. The file may also be hidden in the file manager.
If the site is WordPress, our reference on common WordPress rules can help you compare them, but it should not blindly replace a customized or multisite configuration.
Only one folder or private file returns 403
The denial may be intentional. A backup folder, configuration file, or reserved section does not necessarily need to be available from a browser.
Confirm whether that address should be public before changing permissions. If you only need to download your own backup, do so from the backup tool or file manager without making the directory public.
I receive the Imunify360 bot-protection message
The message Access denied by Imunify360 bot-protection. IPs used for automation should be whitelisted indicates that bot protection blocked the connection, usually because an automated process is sending many requests in a short period.
Send us the IP and time of the block so we can review and release it, and adjust the automation so that it spreads requests over time.
The website opens in a browser, but an API or crawler receives 403
Security rules evaluate request frequency, IP, and client characteristics, not just credentials: an integration or crawler may be blocked even when browser access works.
Gather the endpoint, method, time, integration IP, and complete error message, and send us this information so we can locate the block at the appropriate layer.
Do not apply 777 permissions or recursive changes to the entire account to resolve a 403. Do not disable the entire firewall either: a targeted correction preserves protections and makes it easier to verify what resolved the problem. In shared hosting, we apply IP allowlists and global firewall settings: request this in your inquiry with the IP and time of the block.
How to verify that the issue is resolved
The check should repeat the same request from the connection or user that was failing, in addition to verifying public access.
Try the original URL and action after the adjustment.
Check another page on the site and, if applicable, access to the dashboard.
Verify that private sections remain protected.
Remove temporary exceptions that are no longer necessary and record the change that resolved the error.
If the issue persists, do not accumulate permission, DNS, and security changes at the same time. Return to the last known state and gather the event information.
