My website shows an error page

An error page means the server is answering. That is already useful: a site that is genuinely down does not answer at all, and the distinction is on a website that will not load.

The number on the page is free diagnostic information, and it narrows the cause before anyone technical is involved. Read it, write it down, and quote it when you call.

What each number means

Code	Plain meaning	Usual cause	Who fixes it
404	The page is not there	Deleted page, mistyped address, missing redirect	Whoever manages the site
403	Permission refused	File permissions, a security rule, a directory with no index	Host or developer
500	Something inside failed	A fault in the site or its software	Developer
502 / 504	A service behind the server did not answer	Overload, or a component that has stopped	Host
503	Temporarily unavailable	Maintenance mode, overload, a stopped service	Host, or whoever left maintenance mode on
429	Too many requests	Rate limiting, sometimes triggered by a bot	Host

Two of these are frequently self-inflicted and worth checking before calling anyone. A 503 that persists is often a maintenance mode left switched on after an update. A 403 across the whole site is often a security rule that a plugin or a host applied.

404, and the case where it is serious

A single 404 on a mistyped address is normal, correct behaviour, and not a fault.

A 404 on a page that used to exist is a missing redirect. Every link, bookmark, printed reference and search result pointing at that address now goes nowhere.

A large number of them at once, after a rebuild, is the most damaging launch failure there is, and it is invisible from the new home page. That is the whole subject of what happens to your old addresses, and if you have recently relaunched, this is the first thing to check.

Two things make ordinary 404s much less costly. A genuinely helpful error page — what happened, and links to where the person probably wanted to go. And somebody reading the error report in a search console monthly, which is where the addresses being requested and failing actually surface.

500, and why the recent change matters

A 500 means the request reached the site and something inside it failed while producing the page. It is not a missing page and it is not usually a hosting failure.

The cause is almost always the most recent change: an update, a new plugin, an edit to a configuration file, or a component that exceeded a limit. The diagnostic sequence is the same as for any post-update fault and it is on reversing a bad update.

Two practical points. A 500 with no detail on screen is normal — servers deliberately hide the specifics from visitors, and the actual message is in a log file the host or developer can read. And a 500 that appears only sometimes usually indicates a resource limit rather than a broken file, which points at the host rather than the site.

Errors that only some visitors see

The confusing category, and worth naming because it wastes time.

A page that errors for some people and works for others usually means either a caching layer serving a stored copy of a failure, or a rule that treats some visitors differently — a security rule, a rate limit, or geography.

Test in a private browsing window and on a different network before concluding it is intermittent. Intermittent faults are much harder to diagnose than consistent ones, and most reported intermittent faults are actually caching.

The error page itself is a design decision: default versus a custom one

The number tells a machine what happened. The page tells a person, and on most small business sites it tells them nothing.

A default error page is a dead end: it states a code, offers no route onward, and frequently does not look like the rest of the site, which makes a visitor wonder whether they are still on it. A visitor who reaches one after clicking a link from a search result usually leaves.

A useful one says what happened in plain language, keeps the site’s navigation, and offers the three or four destinations most people were probably looking for — aiming for reassurance rather than confusion. Some larger sites go further with an animation or a small hidden game on their 404 page — a Space Invaders easter egg is the best-known example — but for most small-business sites that effort is better spent making the useful version above than on the delight of a game most visitors will never notice. It costs an hour once and it applies to every future error.

What to have ready when you call

Four things, and having them converts a billed investigation into a fix.

• The exact address that produces it, copied rather than described
• The number on the page
• When it started, and what changed in the fortnight before
• Whether it happens on every page or on one

The fourth is the most useful single fact. One page erroring is a content or component problem. Every page erroring is a platform, server or configuration problem. They are different people’s jobs.

Do not do these: mistakes that turn a small problem into a broken site

Do not delete the page that errors. If it is a 500, the file is the evidence. If it is a 404 on a page that used to exist, deleting the record of it removes the information needed to build the redirect.

Do not reinstall the platform. It rarely fixes a 500 and it frequently destroys the configuration that made the site work.

Do not leave a maintenance page up longer than the work. Visitors and search engines both treat a prolonged unavailability differently from a brief one.

What to do next

Write down the address and the number, then check whether it is every page or one page. Between those two facts you can route the call correctly, which is the entire purpose of this section. Where the fault is genuinely in the site’s code, that scope is on web development services, and keeping error reports monitored is a standing item in the maintenance page.