My App Shows an Ugly Crash When Someone Hits a Page That Doesn't Exist
5 min read
When someone visits a URL in your app that doesn't exist, they should see a friendly "page not found" screen with a way back, not a raw framework error. The fix is to add a custom 404 (not-found) page, which most frameworks let you do by dropping in a single file. Below is how to check what your app does today and how to replace the ugly screen in a few minutes.
Why this happens
Your AI agent built the pages you asked for. It did not build the page for a request that matches nothing, because you never asked for one, and you never see it yourself. In the demo you only ever click real links, so you never hit a dead URL. Real users are messier. They mistype an address, follow an old link from a chat, open a bookmark from last week that now points nowhere, or a share link loses its last character.
When that happens, the framework falls back to its own default: a blank page, a stack trace, or a stark "404" with no styling and no way out. It looks broken because, from the user's side, it is. Nothing tells them where they are or how to get back to your app.
How to check
You do not need any tools for this. Open your live app and, in the address bar,
type your domain followed by something that cannot exist, for example
your-app.com/this-page-does-not-exist, and press enter.
- If you see a styled page that clearly belongs to your app with a link back home, you already have a custom 404. You are done.
- If you see a white screen, a stack trace, a generic host error, or an unstyled "404 Not Found", you are affected.
Try it twice: once on a made-up top-level path, and once on a made-up sub-path
like your-app.com/dashboard/nope. Some setups handle one and not the other.
The fix
- Add the not-found file your framework expects. In Next.js (app router),
create
app/not-found.tsx. In React Router, add a route withpath="*"that renders your not-found component. In plain static hosting on Netlify or Vercel, add a404.html. Check the docs for the framework your agent used and use its exact filename, because the framework only wires it up automatically when it is named correctly. - Make the page feel like your app. Use your normal header, colours, and logo. Say plainly "We couldn't find that page." Avoid jargon like "404" as the only message.
- Give one clear way out. A single button or link back to your home page or dashboard is enough. If you have search, offer that too.
- Redeploy and re-test. Visit the same made-up URLs from the check above on the live site and confirm you now see your page. Test on your phone as well, since that is where a lot of mistyped and shared links land.
The trap to avoid
Do not redirect every unknown URL straight to your home page. It feels tidy, but it hides the problem: a user who followed a broken link is silently dumped somewhere else with no idea why, and you lose the signal that a link was broken in the first place. Show a real not-found page that says what happened, then offer the way home. Save redirects for URLs you deliberately moved.
Also resist "fixing" this by turning off error display. Hiding the stack trace on a crashing route is not the same as handling a missing one. A missing page and a broken page are different problems, and this fix is only for the missing one.
Where this fits
A dead URL is one of the first rough edges a real user hits, and it never shows up while you are clicking through your own app. Getting beta-ready is largely about covering these off-path moments before a stranger finds them. The free Readiness Report crawls your app the way a lost visitor would and flags where a missing page throws an ugly error instead of a friendly one. From there, the Finishing Pass hands you the fixes in order. It pairs naturally with what your app should show when a request fails and with finding buttons and links that go nowhere, since the same broken links that strand users are what send them to a page that does not exist.