I work on OnePassApps, the team behind app.onepassapps.com, so this is our own site. Every status code, byte count and header below was measured on 7 November 2026 with plain HTTPS - one GET per URL, no browser, no session, no cookie, no JavaScript.

A site has to answer three kinds of path: the ones that exist, the ones that are nearly right, and the ones that do not exist at all. The lazy answer is 200 with an empty shell for all three. Ours answers each one differently.

We have written about parts of this before: the route map, the redirects and browser storage covers the 301s and the trailing-slash rule, and the miss page itself looks inside the document a missing URL returns. This post is about the parts that are still unwritten - the layer under the 44 real routes, the rule about case, and how fixed the miss page really is.

The three answers

The path The answer
A route that exists 200, with a server-rendered title and heading, and Cache-Control: public, max-age=0, must-revalidate
A route that is nearly right 308, to the canonical path, with a relative Location
A route that does not exist 404, with one fixed page that says so, and Cache-Control: no-store

The 44 routes that exist

I fetched every app page and every guide page in turn:

  • 22 of 22 /apps/<slug> pages answer 200.
  • 22 of 22 /guides/<slug> pages answer 200.
  • Each app page carries a server-rendered <title> and an <h1> that are the same string, for example QR Code Maker — Static QR codes for links, Wi-Fi and contacts — OnePassApps. That held on all 22 app pages.
  • The app pages run from 19,132 to 19,576 bytes.
  • All 44 of them send Cache-Control: public, max-age=0, must-revalidate, so the browser revalidates instead of quietly serving a stale copy.

Try it on the QR Code Maker, or read the guides.

The rule about case

Two requests, one rule:

  • /apps/QR-Code-Maker -> 404
  • /Apps/qr-code-maker -> 404

Neither is a redirect. The server does not fold the case and point the request at the lower-cased path - it simply says the route is not there. The slugs are lowercase, and that is the whole rule. The same page answers 200 when the case is right and 404 when it is not, with no redirect in between, which is why a link with a stray capital letter lands on the miss page rather than on the tool.

The misses

9 unknown paths answered 404 in total. Here are the 6 that are simply missing, all fetched the same way:

  • /apps/not-a-real-app -> 404, the same 14,320-byte page.
  • /apps/qr-code-maker-2 -> 404, the same 14,320-byte page.
  • /guides/not-a-real-guide -> 404, the same 14,320-byte page.
  • /nope -> 404, the same 14,320-byte page.
  • /random-page -> 404, the same 14,320-byte page.
  • /nonexistent-guide-page -> 404, the same 14,320-byte page.

Every one of them answers a real 404, not a 200 with an empty body, and every one of them serves the identical 14,320-byte page whose <title> and <h1> both read Page not found — OnePassApps. The two case variants and one deep path answer with that same page too, so all 9 misses share one document.

Two details make that page behave like a proper miss:

  • Cache-Control: no-store. The real pages send public, max-age=0, must-revalidate; the 404 sends no-store, so neither a browser nor a crawler is meant to hold on to the miss.
  • No X-Robots-Tag header on the 404 responses. The miss is handled by the status code and the no-store header rather than by a header-level robots directive, and the page says the same thing in its own meta tag: robots reads noindex, nofollow. The 404 page carries no canonical link and no JSON-LD block, while the real pages carry both.

One path under a real slug does not fall through to the app. /apps/movie-tracker/extra/path is a 404, so a stray suffix under a live app slug does not quietly render the app.

How fixed the miss page is

The size does not depend on the path. I asked for missing paths of 1, 5, 20, 80 and 140 characters, and every one of them answered 404 with the same 14,320-byte document. The requested URL is not echoed into the page either: the og:url on the miss page is always the placeholder https://app.onepassapps.com/__not-found__, whatever you asked for.

The document is not quite byte-for-byte identical between requests, and the difference is worth naming so nobody calls the page static when it is not: two fetches of the same missing path differ in 84 byte positions inside a 127-byte span, and that span is Cloudflare's per-request email-obfuscation token. Everything outside that token is the same bytes on every fetch.

The paths that are nearly right

Our earlier route-map post covered this, so it is one line of context: a trailing slash is a permanent redirect, not a second URL. Four of them, all 308, each with a relative Location:

  • /apps/ -> 308 with Location: /apps
  • /apps/qr-code-maker/ -> 308 with Location: /apps/qr-code-maker
  • /guides/ -> 308 with Location: /guides
  • /guides/qr-code-maker/ -> 308 with Location: /guides/qr-code-maker

The two index routes resolve the same way: /apps/ -> /apps and /guides/ -> /guides, and both of those answer 200.

A query string changes nothing. /apps/qr-code-maker?utm_source=devto answers 200 with 19,386 bytes - the same size as the bare path, which was also 19,386 bytes.

The rest of the top level

  • /voting -> 200, 16,380 bytes
  • /studios/image -> 200, 17,379 bytes
  • /studios/colour -> 200, 17,372 bytes
  • /og-image.png -> 200, 42,818 bytes
  • /robots.txt -> 200, 160 bytes
  • /llms.txt -> 200, 17,965 bytes
  • /sitemap.xml -> 200, 4,046 bytes

What the contract comes to

One rule per answer, and no clever handling hiding behind it:

  • A route that exists answers 200 with a server-rendered title and heading, and asks the browser to revalidate.
  • A route that is nearly right answers 308 to the canonical form.
  • A route that does not exist answers 404 with one fixed page that says Page not found - OnePassApps, and asks the browser not to cache it.
  • Case is part of the route. There is no folding and no redirect to fix it.

For a site that runs nine apps and seven studios, with a guide page behind every one of them, that is 44 real pages plus a handful of files, and the answer for anything else is a 404 that says exactly that.

Limits

  • One build, one GET per URL, 7 November 2026, plain HTTPS from one network, no browser and no cookies.
  • I did not test other HTTP methods, and I did not follow the 308s from a separate request - the canonical targets were fetched directly and answer 200.
  • The byte counts are a snapshot of this build, not a promise about the next one, and the miss page is not byte-identical between requests because of the token above.
  • No JavaScript ran, so this says nothing about what the client-side router does after a link is clicked inside the app.
  • I checked the unknown paths listed here, not every path that could be wrong.