What Do 502 and 503 Website Errors Mean?
Distinguish 502 Bad Gateway from 503 Service Unavailable and gather a useful incident report without assuming the host or plugin is at fault.
Part of our guide: What Is Technical SEO and Why Does It Matter?
A 502 or 503 error means the request did not produce the expected working page. The number is a clue about the failure, not a complete explanation of its cause.
MDN describes 502 Bad Gateway as a gateway or proxy receiving an invalid response from an upstream server. 503 Service Unavailable indicates that the server is currently unable to handle the request, for example during overload or maintenance.
Do not assume either code proves that a particular plugin is defective.
Establish what is affected
Check the public homepage, one important service page and the relevant customer function. If only a booking tool fails, record that boundary rather than reporting that the whole website is offline.
Write down the exact URL, time and timezone, response code and any request identifier shown. Avoid publishing screenshots that expose server details or customer information.
A screenshot of a branded error screen is useful, but the actual response code matters too. A custom page can look reassuring while the service is still unavailable.
Compare the likely investigation paths
| Error | Useful first question |
|---|---|
| 502 | Which upstream service failed to respond correctly? |
| 503 | Was the service intentionally unavailable or unable to cope? |
| Intermittent failure | What changed between successful and failed requests? |
| One feature only | Which separate application or integration serves it? |
These questions guide support; they do not authorise random production changes. Ask the host or maintainer to correlate the recorded time with relevant logs.
The technical SEO overview gives context for reliable responses, but restoring customer access comes before trying to interpret search consequences.
Avoid repeated submissions
If an error appears after a payment, booking or enquiry submission, do not assume the action failed completely. It may have reached a backend before the response broke.
Check the relevant confirmation or business system before trying again. Repeated clicking can create duplicate work or duplicate transactions.
Provide an alternative contact route through an available, trusted channel if the interruption affects customers. Keep messages factual and avoid promising a restoration time the technical team has not confirmed.
Give support a useful incident note
An illustrative report might say: “At 10:15 UK time, the contact page returned 502 on two networks. The homepage loaded. No form was resubmitted. The last known change was yesterday’s hosting update.”
That is much more actionable than “The internet is broken”. Include only observed facts and clearly separate a suspected cause.
If the website works elsewhere, the local connection checklist can help distinguish a broad service incident from one browser or network.
Restore deliberately
The support team may need to recover an application process, undo a configuration change or resolve a provider incident. The correct action depends on evidence.
Do not restart services repeatedly without understanding what they are doing. Do not restore an old database without considering bookings or orders created since that backup.
The backup and recovery guide explains why recovery is a business-data decision as well as a technical one.
Confirm sustained recovery
Retest the failing route and the important customer task, not just a cached homepage. Record whether the error returns under ordinary use.
Ask for a short note explaining what failed, what changed, how it was checked and who will watch for the error returning. Keep monitoring after the first successful refresh.
Thinking about your own rebuild?
Tell us about your business, your current website and what you would like to improve. We will help you work out the next step.
