A WordPress site can fail with a bare 403 Forbidden, 500 Internal Server Error, or 502 Bad Gateway instead of a normal page or the familiar critical-error screen. The number is a status code from the web server or a proxy in front of it. It is not a WordPress setting you flip in Admin.
Work this checklist in order. Capture the exact status, URL, and time before you rename plugins or edit .htaccess. Once the page loads again, restore any settings or files changed only for testing and check important site features. If one covered WordPress issue is clearly to blame and you want help, use the $99 one-time fix after you can authorize access.
What 403, 500, and 502 mean on WordPress
- 403 Forbidden — the server understood the request but refused to serve it. Common on WordPress when file or directory permissions are too open or too locked down, when
.htaccess or a host security rule blocks the path, when a firewall or WAF denies the IP or user agent, or when a plugin denies Admin or a REST/AJAX route.
- 500 Internal Server Error — the origin server hit an unexpected failure while building the response. On WordPress this often traces to a PHP fatal error, a broken
.htaccess rewrite rule, an exhausted PHP memory or execution limit, or a misconfigured server directive. Visitors may see a host-branded 500 page rather than WordPress’s critical-error message.
- 502 Bad Gateway: a proxy or CDN received an invalid response from the server running WordPress. A crashed PHP worker, an unreachable origin, or a connection or protocol problem can be involved. A gateway that waits too long for a response normally returns 504 Gateway Timeout; hosts can report failures differently, so check the matching logs. The site files may still be intact.
These codes are different from a full DNS or certificate failure (the browser never reaches your host) and from the in-WordPress critical error screen. If nothing on the host responds at all, start with the site down checklist.
Capture facts before you change anything
- Note the exact URL, whether it is the homepage, a single post, checkout, or
/wp-admin, and the status code shown (browser Network tab or a simple curl -I from another network).
- Check whether every URL fails or only some paths. A 403 on one Admin or plugin path with a working homepage points to a rule or permission on that path, not a dead server.
- Ask whether other sites on the same hosting account work. If every site fails the same way, treat it as hosting or account-level until the host says otherwise.
- Write down the last change: plugin/theme/core update, PHP version change, new security rule, CDN cutover, migration, or
.htaccess edit.
- Open the host’s error log (web server and PHP) for the same minute. Keep errors hidden from visitors. Do not share logs publicly; they may contain sensitive information.
Safe triage order
Prefer staging when you have it. Take a backup before renaming folders or rewriting .htaccess on production. Disabling plugins or security rules can stop checkout, forms, and login protection—restore them after the test.
- Confirm the code still matches. Hard-refresh or bypass CDN cache for one request so you are not debugging a cached error page.
- Read the matching log line. A path under
wp-content/plugins or wp-content/themes is the first suspect for many 500s. A permission or “client denied” line often explains a 403. An “upstream prematurely closed” line can explain a 502; a gateway timeout normally produces a 504. Ask the host to match the log entry to the status you saw.
- Test a static file. Request a known static asset (for example a CSS or image file under
wp-content or a simple ping.txt your host allows). If static files return 200 while PHP URLs return 502 or 500, focus on PHP-FPM, the app pool, or PHP limits rather than DNS.
- Check server rules with your host. On Apache, back up
.htaccess and test changes on staging first. Ask the host to identify the failing rule. If you temporarily move the file aside, restore it immediately after the test: it may contain security restrictions, redirects, and host or plugin rules as well as WordPress rewrites. Default WordPress rules alone may not restore those functions. On nginx, ask the host to check the relevant server configuration. After a fix, test page URLs, redirects, login, forms, and checkout where used.
- Check file and directory permissions. Typical WordPress defaults are directories that are not world-writable and directories that are executable by the web user. A blanket
777 “fix” can trigger host security 403s. Ask the host for their recommended ownership and modes before mass chmod.
- Test plugins and the theme on staging. If logs name a plugin, test that plugin first and change one thing at a time. Keep required login, security, and site dependencies active. If Admin is unavailable, rename only the suspected plugin folder on staging, retest, then restore its original name and reactivate it if needed. If the error remains, restore that plugin before the next test. For a theme test, switch staging to an installed default WordPress theme, retest, then restore the original theme. Check login, forms, and checkout where used after restoring the setup. If you cannot recover access safely, ask the host for help; the critical error checklist also covers recovery and must-use plugins.
- Ask the host about upstream and WAF. For persistent 502s, ask whether PHP-FPM or the app pool is running, whether recent deploys or restarts occurred, and whether the CDN or WAF is failing health checks to the origin. For 403s with no local file clue, ask whether a firewall, ModSecurity, or bot rule blocked the request.
Common causes by status
403 Forbidden
- Directory indexing disabled plus a missing index file on a path you expected to serve content.
- Over-restrictive or host-enforced permissions; security plugins or
.htaccess deny rules for wp-admin, xmlrpc.php, or plugin endpoints.
- IP, country, or user-agent blocks at the WAF, CDN, or limit-login / firewall plugin.
- Hotlink or referrer rules blocking assets; hotlink protection misfiring on your own pages.
500 Internal Server Error
- PHP fatal from a plugin or theme (also see the critical error article when WordPress can still render its own screen).
- Corrupt or hand-edited
.htaccess rewrite or php_value directives the host rejects.
- Memory_limit or max_execution_time exhausted on a heavy Admin or checkout request.
- Partial updates that left plugin files half-written after a timeout.
502 Bad Gateway
- PHP-FPM, LiteSpeed worker, or application container stopped, crashed, or restarting.
- The connection to the WordPress server closed before it sent a valid response. If the proxy timed out waiting, check for a 504 and ask the host to confirm the logged cause.
- CDN or reverse proxy pointing at the wrong origin port or an unhealthy origin.
- An overloaded server that drops connections or crashes workers. Slow responses can also produce a 504 timeout; the status alone does not identify the cause.
Hosting versus the WordPress site
- Likely hosting / edge: every site on the account fails; static files also fail; only 502 with healthy local files; host status page shows an incident; errors began at a platform maintenance window; WAF dashboard shows a block you did not configure in WordPress.
- Likely the WordPress site / config: only one site or one path fails; logs name a plugin or theme file;
.htaccess was edited; a plugin update preceded the 500; permissions were bulk-changed; Admin or a single plugin endpoint returns 403 while the public homepage is fine.
When both could fit, send the host the status code, URL, timestamp, and the matching log lines, then keep site-side isolation on staging so you do not thrash production while they check the pool.
When a $99 one-time fix fits
Request the $99 one-time WordPress fix if you want help with one clearly defined issue on one WordPress site. Name the status code, the URL that fails, when it started, and the last change you made. We confirm the scope before work begins. Send credentials only through the private access link provided after your request is accepted.
Full rebuilds, new custom features, full migrations, account-wide host outages, and multiple unrelated issues are outside this offer. If you suspect malware or a sustained attack, say so in the request so we can confirm what work is covered.
Related checks
If the checks do not identify the cause, send your host the status code, failing URL, start time, and any matching log lines. Suspected compromise needs a security investigation as well as restoring normal HTTP responses.