HTTP Error Fixes: Diagnosing Every Status Code
Every time a browser or search engine asks your server for a page, the server answers with a three-digit status code before anything else. A 200 means all is well. Anything else means the visitor was sent elsewhere, refused, or let down by the server.
The HTTP Error Audit requests every URL in your crawl scope, records the status code and response time, follows redirects, and flags anything outside the 200 range. This page explains what each code tells you, where to look for the cause, and which guide walks through the fix.
What the status code is telling you
The first digit of a status code tells you who is likely at fault, which is the most useful thing to know before you start.
| Code | Meaning | Usually caused by | Where to look |
|---|---|---|---|
| 301, 302, 307, 308 | The content is somewhere else | Redirect rules, often several layered on top of each other | Server config, CMS redirect plugin, CDN rules |
| 403 | The server refuses to serve it | File permissions, access rules, a firewall or bot protection | Permissions, .htaccess, firewall and security plugin logs |
| 404 | Nothing exists at this URL | Deleted or moved pages, typos in links, changed URL structures | The link that pointed there, and your redirect map |
| 410 | Gone on purpose | A page deliberately removed with no replacement | Usually intended; confirm it was meant |
| 500 | The application failed | A code error, a failed database connection, running out of memory | Application and PHP error logs |
| 502 | The proxy got a bad answer from the app | The application process crashed or is not running | Web server error log, process manager |
| 503 | Temporarily unavailable | Maintenance mode, overload, rate limiting | Maintenance settings, server load |
| 504 | The proxy gave up waiting | Slow queries, slow external services, long-running scripts | Slow query logs, timeout settings |
A 4xx code generally means the request cannot be served as asked; the fix is in your links, redirects or access rules. A 5xx code means the server itself failed; the fix is in your code, hosting or configuration. Two further failures sit outside the status code system altogether: an SSL handshake that fails before any code is sent, and a request that times out with no answer at all.
The fix guides
Each guide focuses on one failure, with the diagnosis steps first, because the right fix depends on the cause.
Client errors (4xx)
Fixing 404 Not Found errors covers
finding every missing URL in bulk, deciding whether to redirect, restore or let it go, tidying up after
a migration, and soft 404s, where a page returns 200 but shows an error message. Fixing
403 Forbidden errors covers wrong file permissions, .htaccess deny rules, firewall rules
and IP blocks, including the permission fix in Plesk and cPanel.
Server errors (5xx)
Fixing 500 Internal Server errors starts
with the error log, where the real message is recorded, and covers PHP fatal errors, database connection
failures and memory limits. Fixing 502 Bad
Gateway errors covers a crashed PHP-FPM pool or Node process, proxy buffer settings and automatic
restarts. Fixing 504 Gateway Timeout errors
covers slow database queries, slow external APIs, timeout settings such as fastcgi_read_timeout,
and moving long jobs out of the request.
Failures around the request
Fixing redirect chains and loops covers multi-hop redirects, loops and conflicts between Cloudflare and the origin. Fixing SSL handshake failures covers expired certificates, missing intermediate certificates, hostname mismatches and outdated protocol settings. Fixing request timeout errors covers the case where no response arrives at all, including slow first bytes, DNS problems and keep-alive settings.
By platform
The WordPress guide covers
plugin and theme fatal errors, .htaccess corruption, wp-cron and using debug.log.
The Plesk and cPanel guide covers
where the logs really are, restarting PHP handlers and fixing permissions. The Node.js
and Next.js guide covers process crashes under PM2, the 502s that follow, hosting platform timeouts
and build failures that surface as 500s.
Which errors to fix first
Not all error codes are equally urgent. Rank them by how many people they affect and whether they are getting worse.
- Anything failing on the homepage or main landing pages. A 5xx or SSL error there affects every visitor who arrives.
- SSL failures. Browsers show a full-page warning and most people leave. Certificate problems also tend to affect the whole domain at once.
- Recurring 5xx errors. Occasional server errors are common; a pattern on one template or at certain times of day points to a real fault that will get worse under load. Search engines also slow down their crawling of a site that keeps returning server errors.
- 403s on pages you want public. These often come from a security rule that is too broad and may be blocking search engine crawlers as well as people.
- 404s that receive links or traffic. A missing page that other sites link to, or that people still visit, deserves a redirect to its closest replacement.
- Redirect chains and loops. Loops first, because they make pages unreachable; then chains, which only slow things down.
- 404s with no links and no traffic. These are usually harmless. A 404 for a page that genuinely no longer exists is the correct answer.
Start with the logs, not guesses
The status code tells you something failed; the server log tells you why. For 5xx errors especially, the message in the log usually names the exact file, line or service at fault, which saves hours of trial and error.
- Web server error log: on many Linux servers running nginx this is at
/var/log/nginx/error.log, and Apache has its own equivalent. Look here for 502 and 504 errors, which the proxy records. - Application or PHP log: PHP fatal errors, database connection failures and memory
limit messages usually appear here. WordPress can write its own
debug.logwhen debugging is enabled. - Hosting control panel logs: Plesk and cPanel keep logs per domain, and the panel's log viewer may show a filtered view. The Plesk and cPanel guide explains where to find the raw files.
- Access log: records every request with its status code. Searching it for a failing URL shows how often it fails, when, and whether search engine crawlers are affected.
Match the time of an error in the audit with the time in the logs. If the audit shows a 500 at a particular minute, the log entry from that minute is almost always the cause.
If you are not comfortable reading server logs, the guide to finding 400 and 500 errors gives a gentler introduction, and your hosting provider's support team can usually read them for you if you give them the URL and the time.
Errors that come and go
Some errors in the audit will not reproduce when you open the page yourself. That does not mean they are false. Intermittent errors are often the most informative, because they show where the site is close to its limits.
- 502s and 504s under load: the site works for one visitor but fails when several requests arrive together, as they do during a crawl or a busy period. Look at the number of PHP or Node workers, memory, and slow database queries.
- Errors at the same time every day: often backups, scheduled tasks or cron jobs competing for resources. Move heavy jobs to quiet hours or run them outside the web server.
- 403s for some visitors only: firewall and bot protection rules can block by country, IP range or behaviour. A crawler making many requests quickly can trigger rules that a person would not.
- Timeouts on the first request: sites on platforms that pause idle applications, or that build pages on first request, can be slow to answer the first visitor after a quiet spell.
- Errors from one server only: sites behind a load balancer or CDN may have one unhealthy server among several, so failures appear random.
Run the audit again at a different time of day. If the same URLs fail, the problem is in the page; if different URLs fail each time, the problem is in the server's capacity or configuration. The Site Crawler Guide explains how crawl speed and scope affect what the audit sees.
Order of work
- Run the HTTP Error Audit and group the results by status code.
- Check the certificate and any SSL failures first, since they affect every page on the host.
- For 5xx errors, read the server and application logs at the times shown, fix the underlying fault, and confirm the page now returns 200.
- For 403s, check whether the page should be public; if so, correct permissions or loosen the rule that blocks it.
- For 404s, decide per URL: redirect with a 301 to a true equivalent, restore the page, or leave it as a 404 or 410.
- Correct internal links that point at errors or redirects so they point straight at the final live URL.
- Collapse any redirect chains and remove loops, using the Redirect Checker Guide for the detail.
- Re-run the audit, ideally at a busier time of day, to confirm the fixes hold under load.
For a broader view of on-page issues once the server is answering correctly, see the Site Audit Guide.
1. Do 404 errors hurt my SEO?
Not in themselves. Google has said that 404s for pages that genuinely no longer exist are normal and do not harm the rest of the site. They matter in two situations: when your own internal links point at them, which wastes visitors' clicks and crawl requests, and when the missing page used to receive links or traffic, because that value is lost unless you redirect it to a relevant replacement. Fix those cases and leave truly dead URLs as 404s.
2. What is the difference between a 404 and a 410?
Both tell browsers and search engines that nothing is available at the URL. A 404 says the page was not found, without saying whether it might come back. A 410 says it has been removed deliberately and is gone for good. In practice search engines treat them very similarly, with a 410 sometimes leading to slightly faster removal from the index. Use a 410 when you have intentionally removed content with no replacement, and a 404 otherwise.
3. What is a soft 404?
A soft 404 is a page that tells visitors it does not exist, or shows little or no real content, but returns a 200 success code to browsers and search engines. Common examples are empty search result pages, out-of-stock product pages with nothing else on them, and custom error pages that forget to send a 404 code. Search engines usually detect these and exclude them. Fix them by returning a proper 404 or 410, or by giving the page real content.
4. Why does my site show a 502 Bad Gateway error?
A 502 means a server acting as a go-between, such as nginx, a CDN or a load balancer, asked your application for the page and got an invalid answer or no usable answer. The most common causes are a crashed PHP-FPM pool, a Node process that has stopped, or an application that ran out of memory. Check the web server error log first, then restart the application process and look for the reason it stopped.
5. How do I fix a 403 Forbidden error on my own website?
Start by checking file and folder permissions, which on many Linux hosts should typically be 644 for files and 755 for folders. Then look for deny rules in .htaccess or the server configuration, and check any firewall, security plugin or CDN bot protection that might block the request. If the 403 only affects some visitors or crawlers, a security rule is the likely cause. Your host can also check their server-level firewall logs for you.
6. Will a short outage damage my Google rankings?
A brief outage of a few hours is unlikely to have a lasting effect. If you need to take the site down for planned maintenance, returning a 503 status with a Retry-After header tells search engines it is temporary. Longer or repeated server errors are more serious: search engines slow down crawling when they keep meeting errors, and pages that fail for an extended period may eventually be dropped from the index until they recover.
7. Why does the audit report errors I cannot reproduce in my browser?
The audit requests many pages in a short time, much as a search engine crawler does, and records what happened at that moment. Errors that appear only then are often caused by load, scheduled jobs, rate limiting or bot protection rules that treat automated requests differently from a single person browsing. Match the times in the report with your server logs, and run the audit again at another time to see whether the same URLs fail.
The HTTP Error Audit requests every URL in your crawl scope, records the status code and response time, follows redirects and flags anything outside the 200 range, so you can fix errors before search engines and visitors meet them.
Run the HTTP Error Audit →