A broken internal link during a real product launch is what forces someone to actually read the 404 page instead of the homepage
The near miss: a 404 that looked finished on a desktop screen but sent mobile visitors to a dead end with no way back
Three things a 404 page needs to do its actual job, checked against how RAXXO's page now works
The five minute check every new RAXXO page gets before it ships, 404 included
The Page Nobody Designs On Purpose
Every page on a Shopify store gets a design pass except one, and it is the one page a visitor lands on by accident. The homepage gets a hero, a product grid, testimonials, all of it argued over and rebuilt more than once. The 404 page gets whatever the theme shipped with, because nobody plans to send a visitor there. It is the page that exists only when something already went wrong.
That framing is exactly backwards. A visitor who hits a 404 is not a random sample of traffic. They are someone who clicked a link that used to work, typed a URL from memory, or followed a bookmark to a page that got renamed. They already had intent. They already wanted something specific from the store. The 404 page is the one moment where the entire relationship with that visitor depends on what happens in the next five seconds, and it is also the page I spent the least time on for longer than I want to admit.
I only noticed this because a routine link cleanup on the site renamed a handful of pages, and one of the old links was still live in a place I had not checked. The first person to hit the dead link was not a bot or a test account, it was a real visitor coming from an external post. That is the moment a 404 page stops being theoretical and starts being the actual front door for someone who already wanted to buy something.
Related reading: the shared snippet that almost broke three RAXXO tools at once covers a different near miss from the same instinct, checking the boring parts before they become the visible parts.
What Almost Went Out
The version I almost shipped looked fine on a desktop browser. A short headline, a line of text explaining the page was not found, and a button back to the homepage. Clean, on brand, using the same dark background and the same text color as every other page on the store. On a laptop screen, in a quick glance, it passed.
On a phone, it did not. The button back to the homepage sat below the fold on most screen sizes, which meant the only thing visible without scrolling was the headline and the explanation that something had gone wrong. No path forward, no way to keep browsing, just a dead end that required a visitor to scroll down and hope there was an exit somewhere below. I found this by testing the page on my own phone before pushing it live, not because a checklist told me to, but because testing every page on a phone before a desktop is a habit I already had for a different reason, and it happened to catch this one too.
That single layout mistake would have quietly turned every broken link, every renamed page, every old bookmark, into a visitor who saw an error and closed the tab. Not because the copy was wrong. Not because the design was ugly. Because the one actionable element on the page was invisible on the exact device most people carry it on. A 404 page that requires scrolling to find its own exit is not a 404 page, it is a wall with a light switch hidden behind it.
What made the mistake easy to make is that I had built and reviewed the page on the same laptop the whole time. Every pass looked correct because every pass used the same viewport width, the same generous vertical space, the same forgiving conditions. Nothing about the page was wrong in isolation. The headline was accurate, the tone matched the rest of the store, the button worked when clicked. The failure only existed at the intersection of a specific screen height and a layout that assumed more room than a phone actually gives a page above the fold. That kind of bug is the hardest to catch by staring at code or a style sheet, because nothing in either one is technically broken. It only shows up when a real device forces the same page to prove itself under smaller, more common conditions than the one it was built on.
What A Good 404 Page Actually Needs
Fixing it meant being honest about what the page has to do, which turns out to be three things, not one.
First, it has to say clearly and immediately that the page does not exist, without making the visitor guess whether something is broken on their end or on the store's end. Vague language here wastes the only few seconds of attention a visitor gives an error page. State the fact, plainly, and move on.
Second, it has to give an obvious next step above the fold, on every screen size, not just the ones I happened to test it on first. A homepage link is the minimum. A search box or a link into the most relevant collection does more work, because it treats the visitor's original intent as still worth serving instead of discarding it the moment the specific URL fails.
Third, and the part I underweighted the most, it has to look like it belongs to the same store the visitor was trying to reach. The same background, the same type, the same tone of voice a RAXXO page normally uses. A generic, unstyled error page reads as if the whole site might be broken, not just one link. Visual consistency on the error page is doing trust repair work, quietly, in a moment where trust is already lower than it was a page ago.
None of those three things are difficult individually. What is difficult is remembering that a page nobody plans to visit still has to clear the same bar as every page somebody plans to visit, on every device, not just the one open on the desk in front of me.
There is a fourth thing worth naming even though it matters less often: what the page should never do. It should never suggest a random product with no relation to what the visitor was probably looking for, because a mismatched suggestion reads as noise dressed up as help. It should never bury the fact that the page is missing behind vague, cheerful copy that avoids saying what happened. And it should never load slower than the rest of the store, because a slow error page adds a second frustration on top of the first one, right when patience is already lowest. An error page earns almost no goodwill for being clever. It only loses goodwill for being slow, confusing, or off brand, so the honest bar is closer to competent and fast than to memorable.
Related reading: the error message I rewrite until a stranger understands it goes deeper into the wording side of this same problem, getting the sentence right instead of just the layout.
The Check I Run Now Before Any Page Ships
The fix for the immediate bug was simple, move the homepage link above the fold and add a link into the most relevant collection so a visitor with intent has somewhere useful to go. The fix that actually mattered was adding the 404 page to the same pre-ship pass every other page already gets, instead of treating it as a template default that does not need attention.
That pass is short on purpose, because a checklist too long to actually run every time becomes a checklist nobody runs. Load the page on a phone first, not a desktop, because most visitors will see it on a phone first. Confirm the one thing the page wants a visitor to do is visible without scrolling. Confirm the page reads as the same brand and voice as everywhere else on the store, not a stripped down fallback. Confirm the copy says what happened without sounding alarmed or apologetic past the point of usefulness.
Running that same short pass against a 404 page felt unnecessary the first time, mostly because a 404 page has no product to sell and no conversion to optimize, so it is easy to file it under pages that do not need the same care as a product page. But a visitor does not know or care that the page they landed on was never supposed to be seen. They only know they clicked something, ended up somewhere, and are deciding in the next few seconds whether to keep looking or leave. That decision does not care how much design time the page received.
Related reading: the check I run on every tool before I call it shipped is the same instinct applied to RAXXO's actual products, run before anything, including a page nobody planned to visit, gets called finished.
Bottom Line
The 404 page is the one page on a store that only exists because something already went wrong, which is exactly why it deserves the same attention as every page that goes right. I almost shipped one that looked finished on the screen I was looking at and failed the screen most visitors would actually use. The fix was not clever, moving one button above the fold and giving a visitor a real next step instead of a dead end. The habit that matters more than the fix is testing every page, including the ones nobody plans to visit, the same way, on the same devices, before calling it done. A store is judged by its worst page as often as its best one, and the 404 page is usually the one that never gets checked at all. It costs almost nothing to check it properly. It costs a real visitor, and the sale that visitor already wanted to make, when nobody does.
This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)
Top comments (0)