Shadcn error pages that recover the visit#
A 404 is not a dead end unless you design it as one. Somebody arrived from a search result, an old link or a typo, and they still want the thing they came for. These pages are built to offer that next step rather than to apologise politely and stop.
The four error pages in this collection#
- Error Page 1 (centred 404): an illustration, a home link and a contact action. Free, and the right default for a small site.
- Error Page 2 (split 404): the brand mark beside the illustration with a single home action, for a site where the error page should still look like the brand. Free.
- Error Page 3 (interactive 404): the message paired with search and help options, which is the version that actually recovers traffic.
- Error Page 4 (maintenance): a countdown and progress, so a visitor gets an expected return time instead of an unbounded wait.
What a 404 page should offer#
A link to the home page is the least useful option, because somebody who wanted the home page would have gone there. Better, in order: a search box, the section they were probably heading for, and a way to report the broken link. Error Page 3 carries the first two.
Keep the response code correct as well. A page that looks like a 404 but returns 200 is a soft 404, and search engines treat a site full of them as a site that cannot be trusted about what exists.
404, 403, 500 and maintenance#
The layouts take the code and the message as content, so one page serves every status. The wording should not be shared, though, because the next step differs: a missing page wants search, a permission error wants a sign-in or an account switch, a server fault wants a status page and a time to try again, and planned maintenance wants a countdown.
Error Page 4 covers the last of those. Set its end time from your own deploy window and be generous with it, since a countdown that expires while the site is still down is worse than no countdown.
Not found pages and search visibility#
An error page is one of the few pages you hope nobody sees, which is exactly why it gets forgotten. Two things are worth checking once: that the page returns the right status code, and that it is excluded from your sitemap. Both are easy to get wrong when the error page is a route like any other.
Where these sit alongside the rest of the product#
An error page should wear the same clothes as the pages around it, so it takes its navigation from the navbar and footer on a marketing site, or sits inside the app shell in a signed-in product. For an unauthorised state, the login form is usually the better destination than a generic message, and an empty state inside the screen itself handles the case where the page is fine and the data simply is not there yet.
