Error states and empty states in web design

Every website, eventually, shows a visitor a page with nothing on it, or a message telling them something has gone wrong. A search with no results, a form that failed to submit, a page that no longer exists, a blog with no posts yet. Whether that moment has been deliberately designed, or is simply whatever the underlying software shows by default, is a genuine design decision. It’s the one most consistently missing from a design brief, because it’s easy to plan for the site working and easy to forget to plan for the moments it doesn’t.

Why empty states and error states matter more than their frequency suggests

An error or empty state is, by definition, a moment where something hasn’t gone as the visitor expected. That means it’s already a slightly tense moment, before any design choice is made about it. A generic, unhelpful message at exactly that point — a plain “404 error” with no further guidance, a blank white page where search results should be — compounds the tension rather than resolving it. It’s often the last thing a frustrated visitor sees before leaving the site entirely, rather than trying again.

A well-designed error or empty state can recover the moment almost completely. A 404 page that clearly explains the page moved, and offers a search box or a link back to the homepage, turns a dead end into a redirected visit rather than a lost one.

The empty state, empty screen and error screens most business sites actually need (not placeholder starter content)

The 404, page-not-found state. Happens whenever a link is mistyped, an old bookmark is followed, or a page is removed during a site update. A good version explains plainly that the page wasn’t found, offers a link to the homepage or a search box, and matches the rest of the site’s design rather than showing a generic server message.

Empty search or filter results. A visitor searching a product catalogue or filtering a service list who gets zero results deserves more than a blank space. A message suggesting a broader search, or a link to browse everything, keeps them on the site rather than assuming it’s broken.

The empty blog, gallery or portfolio. A brand-new site frequently launches with sections that are structurally ready but have no content in them yet. This empty state matters: a “Coming soon” message, or a graceful hidden state, is the difference between a site that looks intentionally new and one that looks abandoned mid-build. A visibly empty grid with placeholder Lorem Ipsum starter content still in it does not achieve that.

Form submission failure. What a visitor sees when a form fails to submit, and whether it’s clear what to do next, is one specific and high-stakes version of this same general problem. It’s covered in more detail on forms that get filled in.

Loading and “nothing has happened yet” states. A button clicked with no visible response — no loading indicator, no confirmation — leaves a visitor unsure whether to click again, wait, or assume it failed. A brief, simple loading indicator resolves that ambiguity cheaply.

A short checklist for designers, and the action a brief usually omits

State	Question to ask a supplier
404 / page not found	Does it match the site design, or is it the framework’s generic default?
Empty search results	Does it suggest a next step, or just show nothing?
Empty content sections	Is there a plan for launch day, when several sections may genuinely have no content yet?
Form errors	Is the message specific to what went wrong, and where the visitor needs to look?
Slow-loading actions	Is there any visible indicator something is happening?

Why this gets skipped, and whose job it actually is to protect users

These states are easy to omit from a design brief. A design concept, by its nature, shows the site working — a homepage full of content, a form ready to be filled in, a gallery full of images. Designers rarely mock up what the site looks like when a visitor searches for something that doesn’t exist, because an empty state isn’t the exciting part of the project to present. That’s exactly why error states and empty states need to be asked about directly rather than assumed to be covered.

Some of these states sit closer to development than to visual design — what happens technically when a form fails, for instance, involves both the visible message and the underlying handling of the failure. Web development services covers the engineering side of a build, including this kind of edge-case handling. A genuinely well-scoped project treats error states and empty states as a shared responsibility between the designers and the build team, rather than either side assuming the other has it covered.

What to ask before a build is signed off, including loading and onboarding states

Ask specifically to see the 404 page. Ask what a brand-new section of the site looks like with no content in it yet — not hypothetically, but as an actual screen to look at. If a supplier hasn’t thought about either, raise it before launch. The alternative is discovering it the first time a customer mistypes a web address and lands on a page that looks like the site is broken.

Redirects: the difference between a planned error state and a broken one

A 404 encountered because an old page was deliberately removed or renamed during a redesign is a different situation from one encountered because a link was simply mistyped. It deserves a different fix: a proper redirect from the old address to its new equivalent, rather than a generic not-found message standing in for what should have been an automatic handover. A site migrating from an old structure to a new one, without mapping its old addresses to new ones, is manufacturing hundreds of avoidable error states. Those are pages that used to work perfectly well. That redirect mapping is squarely a development responsibility rather than a design one — worth raising directly during any redesign or platform move.

Why a launch date makes these states more likely, not less

The pressure around a launch date is exactly when empty and error states are most likely to be visible to real visitors. Content population is often still catching up when a site goes live, and early visitors are disproportionately likely to hit a section that isn’t fully populated yet. Plan for that in advance. Decide which sections will be hidden until they’re ready, rather than shown half-finished. That small amount of extra design thinking prevents a site’s first real visitors forming an impression based on its least complete moment.

A note on tone: error state and empty state copy, not just function

An error or empty state is also a small brand moment, whether or not a business thinks of it that way. A blunt, cold “Error 404: Not Found” reads very differently from a message written in the business’s own voice, briefly acknowledging the dead end and pointing somewhere useful. It costs nothing extra to write the second version instead of accepting the first as an unavoidable default. And it’s one of the smallest, cheapest pieces of genuine care a website can show a visitor at exactly the moment something has gone slightly wrong for them.