403 Forbidden Error: How to Identify What’s Blocking Your Site
Updated 2 months ago
The 403 Forbidden error means access to an address on your site was denied. To resolve it, check whether it affects all visitors or just one connection, and whether the block comes from Cloudflare, the application, or a server rule.
If you’re just visiting someone else’s website, check 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, whether you’re signed in, or the action you’re trying to perform. Save the complete error message before changing any settings.
Copy the exact URL and note the date, time, and time zone when the error occurred.
Try the homepage and another address that normally works.
Try the affected URL in a private window. If you need to sign in, use an authorized account.
Try from another connection, such as mobile data, to compare the result.
Note whether the error appears when you open the page or perform an action, such as saving a change or submitting a form.
A test that works from another network is a clue that the block may be related to the connection or IP address, not definitive proof of the cause. Use it to investigate the event; don’t use it to keep attempting an operation the system is blocking.
What you see
Where to start
A Cloudflare block page, sometimes with a Ray ID
Cloudflare security events.
The site opens, but saving or submitting a form returns a 403
Security rules and application logs.
Only your connection or one visitor gets the error
Restrictions by IP, session, country, or request frequency.
Everyone gets a 403 after the site is uploaded or moved
Domain folder, index 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 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 you search for the request in the domain’s security events.
A response passing through Cloudflare doesn’t prove that Cloudflare caused the 403. A page without its logo doesn’t rule it out completely either: if you can’t find the event, we also need to check the origin server.
The site opens, but I get a 403 when saving or submitting a form
A security rule may reject the contents of a request while allowing the rest of the site to open. WordPress or the application may also have its own restriction.
Note the page and the exact action that triggers the error.
If you’re editing content, keep a private copy before trying again.
Try once with test content that contains no sensitive data, provided this won’t trigger orders or other real transactions.
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 doesn’t identify ModSecurity, Imunify, or any specific plugin.
Don’t permanently remove valid content just to “make it go through.” If a false positive is confirmed, the rule should be adjusted for the required operation.
Only one IP, user, or connection gets a 403
Access rules can restrict an IP or a group of requests. In a private area, it may also be correct for an account without permissions to be denied access.
If the result changes depending on the network, save the affected connection’s public IP and share it privately with support.
If the result changes depending on the user, check their permissions in the application.
If you use a security plugin, review its events and any recently configured restrictions.
If you use Cloudflare, compare the time of the error with its events before changing a rule.
If an authorized person has been blocked, the fix 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 gets a 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 addon domain may use a different folder from public_html.
Check that the application’s expected index file, 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 index file is missing and directory listing is disabled, the server may deny access to the folder. Restore the correct file from your site; enabling file listing is not a substitute for a homepage.
If the message says the server can’t read .htaccess, send us the error. Both the permissions and the owner and folders in the path need to be checked, not just the named file.
The error started after changing .htaccess or access rules
A .htaccess rule can deny access to a path or IP. If you know which change caused the problem, restore the previous version of that rule after saving a copy of the current file.
Don’t delete the entire file 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 for common WordPress rules can help you compare, but it shouldn’t blindly replace a custom or multisite configuration.
Only one folder or private file returns a 403
The denial may be intentional. A backups folder, configuration file, or restricted area doesn’t necessarily need to be accessible from a browser.
Confirm whether that address should be public before changing permissions. If you only need to download your own backup, do so through the backup tool or file manager without making the directory public.
I get the Imunify360 bot-protection message
The notice Access denied by Imunify360 bot-protection. IPs used for automation should be whitelisted indicates that bot protection blocked the connection, usually because an automation is sending too many requests in a short time.
Send us the IP and time of the block so we can review and unblock it, and adjust the automation to spread requests out over time.
The site opens in a browser, but an API or crawler gets a 403
Security rules evaluate request frequency, IP address, and client characteristics, not just credentials: an integration or crawler may be blocked even when browser access works.
Provide the endpoint, method, time, integration IP, and complete error message, and send us those details so we can locate the block at the relevant layer.
Don’t apply 777 permissions or recursive changes to the entire account to resolve a 403. Don’t disable the entire firewall either: a targeted fix preserves protections and makes it easier to verify what resolved the problem. On shared hosting, we apply IP allowlists and global firewall settings: request them in your support ticket, including the IP and time of the block.
How to check that the issue is resolved
The check should repeat the same request from the connection or user that was failing, as well as verify 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 areas remain protected.
Remove temporary exceptions that are no longer needed and record the change that resolved the error.
If the problem persists, don’t make a series of permission, DNS, and security changes all at once. Return to the last known working state and gather the event details.
