Getting locked out of your own dashboard doesn’t mean your site is gone. A WordPress 403 error means a request was refused, usually because of an access rule, security block, or file-permission problem.
Your safest fix starts with isolating the blocked request, then changing one thing at a time. Before touching files or settings, back up your site and note what changed before the error appeared.
1. Identify Where the WordPress 403 Error Happens
A 403 Forbidden is an HTTP status code, not a WordPress-specific error. It can mean a file is intentionally restricted or that the server can’t access it.
Start by opening your homepage, /wp-admin/, and the exact failing URL. Then try another browser and a different connection, such as mobile data.
Use the symptom to choose your next check.
| Where the 403 appears | Start investigating |
|---|---|
| Every page, but only on your connection | IP blocks or firewall rules |
| Only wp-admin or wp-login.php | Security plugins and login restrictions |
| One image, file, or directory | Permissions, ownership, and index files |
| Saving pages or using Elementor | Blocked REST API or AJAX requests |
| Immediately after migration | Server configuration and database prefixes |
If only an editor action fails, open your browser’s developer tools and select Network. Repeat the action, then inspect the request showing status 403.
A request to /wp-json/ involves the REST API; /wp-admin/admin-ajax.php involves AJAX. Record its URL and response before changing anything.
2. Back Up Before Changing Files or Settings
Create a backup containing both your database and site files. If your dashboard works, All-in-One WP Migration provides an export under All-in-One WP Migration > Export > Export To > File. Confirm you can access the exported files before making changes.
If wp-admin is blocked, use your hosting panel’s backup function. Otherwise, download the files through SFTP and export the database through phpMyAdmin.
Also download separate copies of .htaccess and wp-config.php. Record current file permissions before editing them.
This protects you if a plugin loses settings or a configuration edit makes things worse. However, restoring an older copy can remove newer posts, orders, or comments.
For every test below, repeat the same failing action. A working homepage doesn’t prove that saving an Elementor page works.
3. Test Plugins, Then Your Theme
Start here if the error followed an update, plugin installation, or security-setting change. Otherwise, follow the symptom table before disabling working components.
Deactivate plugins one at a time, starting with likely suspects
Open Plugins > Installed Plugins. Deactivate the security plugin or most recently changed plugin first, then retry the failing request.
If you can’t access wp-admin, connect through SFTP or your host’s file manager. Inside wp-content/plugins/, rename the suspect folder by adding -disabled.
When the error disappears, that plugin is involved. Restore its folder name, adjust or update it, and retest before leaving it active.
If you have no clear suspect, temporarily rename the whole plugins folder. If access returns, restore its name and reactivate plugins individually until the error returns. Our instructions for disabling plugins without dashboard access cover this recovery method.
Also inspect wp-content/mu-plugins/. Must-use plugins aren’t listed among ordinary plugins and remain active. Don’t move host-managed files without hosting support.
Switch to an installed default theme
If plugins aren’t responsible, open Appearance > Themes and activate a default theme such as Twenty Twenty-One.
Then repeat the blocked action. If it works, investigate your original theme’s custom functions and plugin integrations.
Without dashboard access, rename the active theme’s folder inside wp-content/themes/, but only when a working default theme is installed.
Although deactivation usually preserves settings, some themes and plugins reset options. Keep your backup and record theme settings before testing.
4. Inspect File Permissions and Missing Index Files
Correct only the affected permissions
Using SFTP or your hosting file manager, right-click the affected file or directory and open Permissions or File permissions.
Community guidance commonly recommends 755 for directories and 644 for files. These aren’t universal hosting defaults. One community report described a site breaking after directories were changed to 750.
WP Engine’s permission requirements are different: directories use 0775, and files use 0664. A plugin can’t force higher permissions on its hosting.
Change only the affected path, then reload its URL. Avoid recursive changes across your entire account, and never use 777 as a shortcut.
If file permissions look right but access still fails, ownership may be wrong. Ask hosting support to repair ownership rather than making files broadly writable.
Restore an index file only where required
A directory without an index file can return 403 because the server refuses directory listings.
For a WordPress installation directory, look for index.php. If it’s missing, restore the correct file through the core-repair step below.
For theme or plugin directories, get the expected file from the developer if you’re unsure.
Don’t add index files merely to expose private folders. A 403 on a directory listing may be the correct security behavior.
5. Temporarily Rename and Regenerate .htaccess
On Apache and compatible servers, .htaccess controls rewrite rules and access restrictions. Nginx doesn’t read it, so skip this test on an Nginx-only setup.
Follow this sequence:
- Enable Show hidden files in your file manager and find
.htaccessbesidewp-config.php. - Download a backup, then temporarily rename the file to
.htaccess-disabled. - Reload the exact URL that returned 403.
- If access returns, open Settings > Permalinks and click Save Changes twice without changing the permalink structure. Saving Permalinks regenerates WordPress rewrite rules.
- Test your homepage, an individual post, wp-admin, and the previously blocked action.
If renaming fixes the error, a rule in the original file is responsible. Keep its backup so required redirects and security settings aren’t lost.
If nothing changes, restore its original name. Continue with security-rule checks rather than repeatedly rewriting the file.
Temporarily removing the file also removes its access restrictions. Keep this test brief and restore required protections afterward.
6. Check Firewall Rules and IP Lockouts
Security plugins, Sucuri, Cloudflare, and host-level security controls can reject requests before WordPress runs.
If access works over mobile data but fails on your usual connection, investigate an IP block. Repeated failed logins can trigger a security-plugin lockout, even for the site owner. Use its unlock email if available.
In Cloudflare, open Security > Events and match the blocked request by time, path, and IP address. Cloudflare’s security-event troubleshooting points to this check for WordPress API failures.
For editor saves or header-code submissions, a security rule may mistake a REST API request for an attack. Request a narrow exception for the identified rule and REST API endpoint.
Don’t disable the firewall permanently. Retest the save after the exception and confirm normal protection remains active.
WP Engine says a site-wide 403 can mean your IP was denied and needs allowlisting by support. Your host may also need to adjust a server-level security rule that plugins can’t control.
7. Repair Core Files or Migration Settings
Replace missing or damaged WordPress core files
If the error followed an interrupted update, reupload clean core files from the same WordPress version. If you use WP Engine, confirm its repair process before replacing core files.
Through SFTP, replace wp-admin, wp-includes, and the WordPress core files in the installation’s root directory. Preserve wp-content and your existing wp-config.php; don’t overwrite them.
This also restores a missing root index.php. After uploading, test the homepage, dashboard, and original failing URL.
If uploads produce permission errors, stop and have your host repair access first. Repeated uploads won’t fix incorrect ownership.
Compare database prefixes after migration
A reported migration case traced wp-admin 403 errors to a mismatch between the configuration file and the imported database’s table prefix.
Compare $table_prefix in the configuration file with the imported table names in phpMyAdmin to confirm the database prefix. Keep the matching prefix rather than choosing a new one.
Our guide to editing the wp-config.php file explains its configuration settings.
If table names match but admin permissions disappeared, old prefix-dependent role entries may need repair. Use database support rather than bulk search-and-replace, which can damage serialized settings.
8. Read Logs and Escalate With Evidence
Enable private debugging temporarily
Use WordPress’s debugging guidance to collect errors without showing them to visitors.
In wp-config.php, above the “That’s all, stop editing!” comment, set define( 'WP_DEBUG', true );, define( 'WP_DEBUG_LOG', true );, and define( 'WP_DEBUG_DISPLAY', false );.
Edit existing definitions instead of adding duplicates. Repeat the failing action, then check wp-content/debug.log. Our WordPress debug-mode guide covers safe logging.
Messages such as failed to open stream: Permission denied and Could not copy file point to filesystem access problems.
By contrast, Failed to load resource: the server responded with a status of 403 (Forbidden) confirms the rejection but doesn’t identify its cause.
If the log reports memory exhaustion, try define( 'WP_MEMORY_LIMIT', '256M' );. This requests more memory within your hosting limits. It doesn’t bypass a firewall or permission denial.
Turn debugging off after testing, then remove or secure the log.
Give hosting support a reproducible failure
Contact your hosting provider if the error persists, ownership needs repair, or a server rule blocks access.
Send the failing URL, exact error, timestamp with timezone, recent changes, and tests you’ve completed. Include your public IP if access differs between connections.
Ask support to inspect access logs, security-rule matches, ownership, and server restrictions. WP Engine’s log guidance explains common server errors.
If a request never reaches PHP, WordPress’s debug log may stay empty. Hosting logs are more useful in that case.
Frequently Asked Questions
Does 403 Forbidden mean you’re blocked?
Sometimes. An IP block can deny your connection, but incorrect permissions or a restricted file can affect everyone. Compare the same URL over another connection to narrow the cause.
Why does wp-admin fail after you’ve logged in?
Logging in doesn’t remove firewall restrictions or grant every capability. If the public site works, focus on login security, the blocked admin request, and post-migration role data.
Key Takeaways
Your fastest route to fixing a WordPress 403 error is a targeted, reversible test based on where access fails.
Back up first, change one thing, and repeat the original request after each fix. Keep permissions appropriate for your host and restore security protections after testing.
When server rules or ownership are responsible, give hosting support the evidence needed to repair the block without weakening your site.
