A broken link usually lands on a blank page or the host's own error screen.
That page does nothing for the visitor or the business. It should do three things: say what happened, point back to something real, and tell Google and AI tools like ChatGPT that the page is actually gone.
Most sites get none of that right.
The Default Error Page
A default 404 page comes from the hosting platform, not the business. It carries the platform's own look, or no look at all. A visitor who clicks a dead link from an old email or a search result lands there with one choice. Hit back.
That is a lost visit for no good reason. The link was already broken. The page did not have to lose the visitor too.
What A Good Page Includes
A working error page carries the same header, footer, and voice as the rest of the site. It says plainly that the page could not be found, not a code to decipher. It gives the visitor somewhere real to go.
- A link back to the homepage
- A search box or a short list of the pages people land on most
- A phone number or a contact link, for the visitor who wants an actual person
Three things. Not a maze.
Where The Hits Actually Come From
Most hits on a 404 page are not random. They come from an old link somewhere else, a bookmark from before a redesign, or a typo in something that got shared around. I check the server logs for the paths getting hit the most, then fix those first.
Fixing the ten most common paths usually clears most of the lost traffic. The long tail of one-off typos matters far less.
What Crawlers Do With It
A crawler, Google's or an AI tool's, treats a real 404 as a normal signal. The page is gone. It gets noted. The crawler moves on, and that costs the site nothing.
The actual problem is a soft 404, a page that looks empty but still returns a normal, found status instead of an error status. Google and AI tools can index that page as if it were real, then hand a visitor or an answer a dead end. A true 404, or a 410 for a page gone for good, keeps that from happening.
Redirects Instead Of Dead Ends
When a page moves, the fix is not a clever error page. It is a redirect straight to the page that replaced it. A buyer who bookmarked a pricing page should land on the current pricing page.
A 404 page is for the links that are actually gone. A retired product. An old campaign. A page that never should have been shared in the first place. Everything else gets a redirect.
I see the same mistake on sites that went through a rebuild without anyone mapping the old pages to the new ones. Every old product page, every retired service, every blog post that got folded into a bigger guide needs a destination. Skipping that step is the single most common cause of broken links on a site that otherwise looks finished.
Testing It After Launch
A 404 page gets built once and then forgotten, including by the people who built the site. I check that it renders correctly on a phone screen, since that is where most visitors land on it first. I also click every link on the page itself to confirm it actually goes somewhere.
Analytics should track 404 hits the same way it tracks any other page. A spike right after a launch usually means a page moved and nobody set up the redirect for it. A steady trickle of the same few paths means an old link is still circulating somewhere, in an email, a directory listing, or a page on another site entirely.
Keeping It On Brand
I build the error page as part of the site, not as an afterthought bolted on after launch. The voice matches the rest of the pages. The layout matches too. A visitor who lands there should not feel like they left the business and ended up somewhere else.
I covered a related piece of this, what makes a page worth keeping versus retiring, in our post on how to tell when a website needs rebuilding. The same judgment applies to one broken link as it does to a whole site.
A 404 page is small. It is also a page almost every visitor hits without planning to, so it is worth building on purpose instead of leaving it to the host's default. If the site itself needs a closer look, that is where a Web Experiences build starts.