What Happens to 12 Ways to Misspell a URL on app.onepassapps.com: The Status Codes and Where They Point

I work on OnePassApps, the team behind app.onepassapps.com. This post is about the redirect and error layer of our own site, and every status code in it was measured on 10 November 2026 over plain HTTPS from outside the browser - one build, one network, signed out, no cookies, no JavaScript, one request per URL.

A visitor does not type our URLs from memory. They follow a link, copy a line out of a chat, or fat-finger a domain. So the interesting question about a site is not only which URLs work - it is what the site does with the ones that do not.

Our sitemap lists 56 URLs. Asked for one at a time without following redirects, every one of them answers 200. There is no redirect layer on the happy path - nothing on our site bounces you somewhere else.

One correct URL, 12 ways to misspell it

I took three real routes - an app, a guide and a studio - and broke each of them 12 ways. The three routes were asked the same 12 questions, so every row below is a measurement repeated three times, not one guess.

  • the URL as published - 200 on all three routes.
  • the http scheme instead of https - 301 on all three routes. The Location header points at https://app.onepassapps.com/apps/movie-tracker.
  • a www prefix in front of the host - there is no answer at all on all three routes. www.app.onepassapps.com has no DNS record, so the request never reaches a server: this is a failed lookup, not a status code.
  • a trailing slash - 308 on all three routes. The Location header points at /apps/movie-tracker.
  • an upper-case path - 404 on all three routes.
  • a doubled slash - 200 on all three routes.
  • an .html suffix - 308 on all three routes. The Location header points at /apps/movie-tracker.
  • an index.html at the end - 404 on all three routes.
  • a query string on the end - 200 on all three routes.
  • a fragment on the end - 200 on all three routes.
  • a dot segment in the path - 200 on all three routes.
  • a typo in the last segment - 404 on all three routes.

Two of those rows are worth spelling out, because they are the ones a reader hits by accident. The query string row answers 200 on every route: a tracking tag, a campaign name or a UTM parameter appended to a path does not change which page you get, and does not send you somewhere else. The fragment row also answers 200, and it has to be that way - a fragment is never sent to a server, so it cannot change the answer.

What a crawler sees

For a search engine or a link preview bot, only the status code and the Location header matter. The body of a not-found page is for people, not for crawlers.

So the rows that carry a Location header are the ones that move a reader or a bot somewhere else, and the rows that do not are the ones that end the request at the address that was asked for.

The API host is the same product on a different hostname, and it behaves differently: https://api.onepassapps.com/apps/movie-tracker answers 404 on the path a browser would use on the app host. That host's robots.txt is 1248 bytes of commentary, so it is not a redirector either.

Limits

One build, one network, one day, plain HTTPS from outside the browser, one request per URL, no cookies and no JavaScript. These are the answers our host gave today. A different edge, a cached answer or a different host could answer differently, and I did not test the browser-facing routes with a session.

If you want the apps themselves rather than the addresses that lead to them, the guides page lists all of them, and the home page is where they live.