The 404 Page app.onepassapps.com Serves: 13,953 Bytes for Every Missing URL

I work on OnePassApps, the team behind app.onepassapps.com. Every URL on our site that does not exist returns one fixed HTML document - and it is not the page a visitor actually sees. Here is what is inside it, byte for byte.

Every number below was measured on 5 November 2026 with plain HTTPS from outside the browser - no session, no cookies, signed out. Where it says "in the browser", it was measured in the visible Chrome on our own desktop.

One document for every missing URL

Ask the app host for a page that is not there and you get the same 13,953-byte document every time:

GET https://app.onepassapps.com/no-such-page-404-probe
404  content-type: text/html; charset=utf-8   13,953 bytes
cache-control: no-store

I tried /no-such-page-404-probe, /nope2, /deep/missing/path, /x.png, /x.json and /not-found. All six answered 404 with 13,953 bytes. Two of those fetches differ from each other in exactly one place - Cloudflare's per-request email-obfuscation token - and nowhere else.

The pages that do exist are different documents: the home page is 18,624 bytes and our app guides page (https://app.onepassapps.com/guides?utm_source=devto&utm_medium=community&utm_campaign=404-route-document&utm_content=guides-link) is 19,457.

What the document says to a crawler

The 404 carries the same 28 meta tags as a real page, with different values:

<title>Page not found — OnePassApps</title>
<meta name="description" content="Return to OnePassApps to browse the available apps and workspace features." />
<meta name="robots" content="noindex, nofollow" />
<meta name="googlebot" content="noindex, nofollow" />
<meta name="onepassapps-indexing" content="allowed" />
<meta property="og:url" content="https://app.onepassapps.com/__not-found__" />

Three things are worth stopping on.

The crawler directives are right: both robots and googlebot say noindex, nofollow.

Our own indexing-policy tag, which the build writes onto every route, says "allowed" on this document too.

And og:url is a placeholder rather than the address you asked for: every missing path advertises https://app.onepassapps.com/__not-found__ as its own URL. That page is itself a 404, so the card a crawler would build for a broken link points at another 404.

Two things the 404 does not have, and both real pages do: a canonical link (the home page and /guides each have one, the 404 has none) and any JSON-LD (both real pages carry one ld+json block, the 404 carries none).

The fallback React throws away

Inside the body there is a static block, marked with the attribute data-onepassapps-seo-fallback. It holds an h1 reading "Page not found — OnePassApps", the same sentence as the meta description, and a single link - "Return to OnePassApps" - pointing at our home page (https://app.onepassapps.com/?utm_source=devto&utm_medium=community&utm_campaign=404-route-document&utm_content=home-link).

That block exists for a crawler, or for a reader whose JavaScript never runs. As soon as the app boots, React removes it: in the browser, that container is gone once the page has hydrated.

What replaces it is the real 404:

That page doesn’t exist
Nothing is published at this address. Pick an app below, or search every app.

with two buttons, Browse all apps and Go to Home, then an OPEN INSTEAD block listing the two live apps - MovieMatcherAI, marked LIVE APP · FILMS, and NewsFlow, marked LIVE APP · NEWS - and after that the standard-price panel: $0 / month, 100,000 credits every 30 days, no card required.

So the search-engine fallback and the visitor-facing page do not say the same thing. The first says "Page not found"; the second says "That page doesn’t exist" and then offers you somewhere else to go.

The crash card that ships but never shows

The document also carries a template element holding the shell-crash fallback: the title "OnePassApps stopped working in this tab", the line "Files and data saved on this device are unaffected. Reloading usually fixes it.", a Reload link and a support address. It ships with the hidden attribute and stays inert - in the browser it never became visible - because the fallback script only clones it in if the app itself fails to start.

The support address inside it is protected by Cloudflare's email obfuscation, so the HTML holds a token rather than the address itself. Decoding that token gives [email protected].

The document also inlines our startup mark as SVG - three linear gradients, one radial gradient - plus a nine-bar pulse and a prefers-reduced-motion branch that switches the animation off. And a small script locks the theme to dark and the Graphite preset before first paint.

And it still downloads the whole app

A 404 is not a light page. Loading one in a cold browser produced 110 requests and 870,253 bytes of encoded response bodies in the measured run:

Script       792,726
Font          49,942
Fetch         11,601
Other          8,145
Stylesheet     4,333
Image          1,912
Manifest       1,594

The three largest single responses were Clerk's UI bundle (134,369 bytes), clerk.browser.js (84,596 bytes) and the Inter Latin variable font (49,942 bytes). The document's own script references are the normal app bundle - the entry chunk, the shared app shell, the React vendor chunk and the runtime - so a missing URL costs what a real page costs before the app decides what to show.

Two CORS preflight requests in that run went to the API host and were answered 204 with no body.

If you are linking here

• A missing URL is a real 404 with a real body. It is not a soft redirect to the home page.
• The crawler directives on it are noindex, nofollow, so nothing on that page is meant to be indexed.
• If you want a reader on the right page, link the canonical URL of the page you mean, and if you want them on a guide, the guides list is the one that holds them.