Website 404 (Error) Page Design and Development

Why a 404 page design loses traffic and leads

A link from an old newsletter, someone else's blog, or search results leads to a moved section — and the visitor sees a gray default placeholder: "404 Not Found" centered on a line, without a header, menu, or search.

What happened — a typo in the address, the page was deleted, or the site broke — they do not understand and do not try to find out.

Hence the loss of visitors, which is noticed last of all. In analytics, such a visit passes as ordinary: the person leaves the funnel at a step where they have not bought anything yet, and in the report it looks like a single session with a high bounce rate. No inquiry, no repeat visit, no chance to explain what to do next.

The cost of a 404 error on a site is higher than it seems: the visitor came via a link with intent — to compare, order, return to an interrupted purchase — but did not find a way forward.

Such transitions accumulate from old materials, third-party sites, newsletters, and addresses typed by hand with a typo.

On projects with history, a noticeable share of transitions lands on a 404 error — it can be seen in server logs by response code.

A careful 404 page design brings back some of these people: it suggests related sections, redirects from the erroneous address to a working one, and searches by a fragment of the name. The difference from a technical placeholder is in the retained contact, not in the picture.

We explain how this is addressed: what exactly should be on the error page, which redirects and response code rules solve the problem at its root, and how to check that traffic has stopped leaking.

What a well-designed error screen delivers: effect in metrics

A broken link is a point where the visitor has already arrived but has not yet decided anything: whether to leave or continue is determined within seconds.

If the error screen is empty, the session ends, and the traffic that already took effort to attract does not reach the main scenario. After rework, the screen becomes a fork with a clear next step.

The main measurable effect is the share of returns to the catalog or to the main scenario directly from the error screen.

We mark transitions with a separate event, so what is visible is not "it became neater" but the specific share of sessions that did not break off at 404. This is one of the cheapest growth points: the audience is already there, and one template changes.

The second consequence is a reduction in the number of support requests for "page not found".

Catalog search, links to popular sections, and an explanation of the cause resolve typical questions before they are asked to an operator: the first line is unloaded, and complex requests reach the right specialist faster.

Third — predictable behavior on a broken link and clean engagement metrics. Previously, some visitors left silently, some wandered through irrelevant pages, and in reports this looked like natural bounce. Now the route is set, and sessions return to the funnel instead of being lost.

Error screen implementation options and their limitations

The error screen is part of routing, not a separate image.

At the moment a non-existent address is requested, what matters is what the server returns and how the application intercepts the route: both the correct response code and whether a search engine can distinguish a missing page from a live one depend on this. The implementation option is chosen by applicability, and each approach has its own limitations.

Comparison of options

The choice of solution is dictated by the address structure and the cost of a lost transition. Where the visitor came from search for a specific product or piece of content, a scenario-based screen is justified: it returns the person to the catalog and preserves the transition.

For static pages, a neat template with navigation and a link to the home page is enough — it is important that the server returns a correct response code, not a redirect.

Work stages: from request audit to handoff of mockups

Before drawing, we analyze what actually lands in 404. An export from web server logs and web analytics shows real addresses, transition sources, and the share of bots: some requests are closed with a redirect to the current section, some with an honest error page. That is why implementation stages begin with data, not with a sketch.

1. Request audit. We export addresses, response codes, and sources for a period, separating live transitions from bots and broken external links. The output is a decision for each address: redirect or error page.
2. Prototype. A framework without graphics: block hierarchy, user exits — search, categories, popular materials, behavior on narrow screens. We agree on the logic before drawing.
3. Mockup approval. Visual language, states (empty search, incorrect address), texts, and tone. The mockup is accepted together with behavior, not as a picture.
4. Coding and connection. The page returns an error code, not a successful response — otherwise search engines consider it ordinary and keep empty addresses in the index. Static content is served without unnecessary server requests.
5. Testing on staging. Test environment: crawling broken links, redirect scenarios, behavior on a slow connection and with a cleared cache.
6. Mockup handoff. Source files and components, redirect rules, and a brief memo in case the site structure changes.

What we hand over: mockups, texts, states, and regulations

Handoff is not a folder with pictures, but a set from which coding is assembled without clarifying questions. Each part covers its own area: rendering, behavior, texts, and the rules by which the page lives after launch.

• Mockup source files: layers with grid, components, and text styles. Paddings, colors, and sizes are taken from the mockup, not selected by eye from a picture.
• Screen states: request to a non-existent address, deleted section, access-restricted material, server-side failure. For each — its own rendering, heading, and action.
• Responsive layouts: behavior on narrow and wide screens, heading length, line breaks in buttons and captions.
• Error texts: heading, short explanation, and a hint on what to do next. Ready-made variants for each state, without apologies and jargon in the interface.
• Link substitution rules: transition priority — home page, nearest section from the broken address, search, popular materials — and the logic for choosing a variant.
• Response status map: where we return a page with a "not found" code, where a redirect to the new structure, and where the address is better marked as permanently removed.
• Analytics specification: which events and parameters we pass — original address, transition source, state type. From them it is clear where broken links come from.
• Update regulations: who edits texts, how a new state is added, at what moment the page is reviewed together with changes to the section structure.

Case study: how visitor return grew after rework

Before: one template for all broken addresses

A service catalog with several thousand addresses, and after a structure change, some old links and external transitions remained broken. Any such request received one screen: the heading "Page not found", a line of text, and a button to the home page.

According to reports from Yandex Metrica, the share of exits from it stayed above 80%, while less than 12% of sessions moved to the home page — a visitor from a bookmark or a third-party site was lost for good.

After: address-based hints and a 404 log

From the address, we extracted the meaningful remainder of the path and matched it with current sections: if a service name or transliteration could be read in it, 3-4 related sections appeared at the top, below — search with suggestions and a link back through browser history.

Separately, we enabled logging of all 404 responses together with the transition source: once a week the stream was reviewed, broken internal links and outdated addresses were closed with redirects.

Three weeks after launch, the share of transitions further through the site grew from 12% to 38%, exits from the screen dropped from 81% to 44%, and repeat visits to the catalog added 9 percentage points.

From the log, more than sixty broken internal links were found and closed — 404s themselves became a third less frequent. The result was measured using the same entry reports by which the "before" was calculated, so the comparison is correct.

How 404 differs from 410 and what to do with redirects

Both codes say "the page is not there", but the difference is in meaning: 404 is a neutral "not found", 410 is "deleted forever and will not return".

For a search engine, these are different signals: after receiving 410, it removes the address from indexing on the next crawl, while with 404 it continues to visit it for months, periodically rechecking.

The practical rule is simple. Content has been moved or merged with another page — 301 to the nearest relevant address. A product has been discontinued, a section is closed, a publication is revoked — 410.

Temporary unavailability (database maintenance, hosting migration) — not 404 and not 410, but 503 with an indication of the return time: the robot will not throw the page out of search results and will come back on its own.

The main mistake is redirecting everything broken to the home page. The user expected a specific product but got a general menu; the search engine sees dozens of addresses with identical content and marks them as soft 404 — indexing is blurred, weight is not passed. A mass 301 to the home page does not cure the problem but masks it.

The second most frequent miss is a "404" page with a 200 response code. It looks neat, but for a robot it is an ordinary page, and it gets into the index.

To check that the server returns exactly 404, crawling the site with a robot helps — Google Search Central describes such a scenario as typical.

Design here is secondary to code: first the correct status and redirect logic, then the visual design — site search, links to popular sections, recognizable visuals. Then removed addresses leave the index predictably, while live ones do not lose positions.

Common technical doubts and answers about the error screen

The client's engineering teams most often ask the same questions: will the error screen integrate into the current template, what about the mobile version and languages, and will it conflict with already configured redirects. We answer briefly and to the point — these things are checked before release, not after.

Below are four technical doubts and how we address them.

How is the mobile version tested?

We test at real checkpoints, not at a single window size: a narrow phone, a tablet, landscape orientation, a large system font. Separately, we look at behavior on a slow connection and the clickability of return buttons — a finger should not hit neighboring elements. There should be no horizontal scrolling or clipped text in any position.

Will you support multilingualism?

Yes, texts are moved into translation files rather than hardcoded into the markup. The error screen determines the language from the page address or from the user's saved choice, so on a bilingual site a person receives the message in the language they were reading. Adding a new language is a dictionary edit, not a re-layout.

Will automatic redirects break?

We separate two scenarios: a moved address goes away with a permanent redirect to a live page, and the error screen is shown only to those who came via a truly non-existent path.

The rules are configured so that the chain of transitions is no longer than one step — otherwise search positions are lost and response time grows. The rules themselves are collected into one list, which is visible and can be maintained.

Let's discuss the task: how we will start work

So that discussion of the task turns into a concrete work plan rather than a correspondence about wishes, a few inputs are enough for us.

Then the timeline estimate is calculated from the real scope — the number of templates, return scenarios, and page states — and the team composition is selected for them without extra reserve.

What will be useful at the input:

• access to error statistics: which addresses produce 404 most often and from which sources they come — this determines the link structure on the page.
• a list of brand requirements: palette, logo, font, and rules for their use, so the page does not look foreign to the site.
• examples of unsuccessful addresses — typos, old addresses, links with parameters: the behavior of hints and search depends on them.
• output limitations: whether the page is served as a static file or through a content management system template, and whether there is a separate environment for testing edits.
• scenarios that need to be covered: return to the home page, transition to a section, site search, contact support.
• contact of a technical specialist on the client side — for access to server settings and verification of response codes.

Based on the discussion, we will return with a work plan, stage-by-stage timeline estimates, team composition, and a list of what is needed from you at the start of the project. Describe the task — and we will return with an estimate and a plan.