I work on OnePassApps, so this is our own product, and everything below is a read of our own public pages - fetched and measured, not a guess.

Search engines get a narrow view of a site like ours: a sitemap, a robots file, and a handful of HTML pages. Here is exactly what app.onepassapps.com hands them, measured by fetching every URL it names.

How this was measured: GET https://app.onepassapps.com/sitemap.xml, GET https://app.onepassapps.com/robots.txt, then one request per URL in the sitemap. For each page I recorded the HTTP status, the <title>, the meta description, the <link rel="canonical">, og:title, and the JSON-LD graph.

The sitemap: 16 URLs, and nothing else

https://app.onepassapps.com/sitemap.xml answers 200 with a plain <urlset> (not a sitemap index) containing 16 <url> entries. Each entry carries a <loc> and nothing else: no <lastmod>, no <priority>, no <changefreq>.

The 16 URLs, in the order the file lists them:

Group URLs
Site /, /voting, /plans, /terms
Studios /studios/image, /studios/audio, /studios/files, /studios/text, /studios/data, /studios/icons, /studios/colour
Apps /apps/newsflow, /apps/movie-tracker
Guides /guides, /guides/newsflow, /guides/movie-tracker

That is the whole indexable map: four site-level pages, the seven browser studios, the two live apps, and three guide pages.

robots.txt: five rules and one sitemap pointer

User-agent: * Allow: / Disallow: /api Disallow: /api/ Disallow: /account Disallow: /sign-in Disallow: /sign-up Sitemap: https://app.onepassapps.com/sitemap.xml 

/api and /api/ are both listed, so the API stays closed however you write it. The account surfaces are /account, /sign-in and /sign-up - note those three names, because they are not the same as the names you would guess (see below). There is no Crawl-delay, no per-bot block and no second sitemap declaration.

Every URL in the sitemap has a canonical that points at itself

All 16 URLs returned 200. Each one carries a <link rel="canonical"> whose value is exactly its own URL - no trailing-slash variant, no www host, no query string, no session id. There is no canonical on the site that disagrees with the URL it sits on, so there is nothing for a crawler to reconcile.

Titles: one pattern, one exception

Fifteen of the sixteen titles end with an em dash and OnePassApps:

  • /voting - "Vote on future apps — OnePassApps"
  • /plans - "Plans — OnePassApps"
  • /studios/text - "Text Studio — OnePassApps"
  • /guides/newsflow - "How to read briefs and listen with NewsFlow — OnePassApps"
  • /guides/movie-tracker — "How to track movies and TV in a private watchlist — OnePassApps"

The exception is the home page, whose title is "OnePassApps — PDF, writing, data and design tools" - the brand first, and a description of the tool categories instead.

Descriptions: sixteen of them, all different

Every page in the sitemap carries its own meta description, all 16 distinct, and og:title matches the <title> on all sixteen. Two of them, verbatim:

  • Home: "Organise PDFs, build a résumé, chart CSV data and create designs in your browser. Use local tools without an account and explore OnePassApps membership."
  • Text Studio: "Clean, compare, convert and inspect text in your browser."

The JSON-LD: one shared identity, then a per-page graph

Each of the 16 pages ships exactly one application/ld+json block, and each one is a @graph that starts the same way. The Organization and WebSite nodes are identical on all sixteen pages: the brand name, the URL, the logo at /icon-512.png, the description "A growing collection of practical apps for everyday work, creativity, and life, with one account and one membership.", a customer-support contactPoint at info@onepassapps.com, and the WebSite node marked inLanguage: en-GB.

After those two, the graph changes per page, and the shape tells you what the page is:

  • The home page adds a WebApplication node (applicationCategory: UtilitiesApplication) plus two ItemList nodes: "OnePassApps apps" (NewsFlow, MovieMatcherAI) and "OnePassApps browser-local Studios" (the seven studios, Image first, Colour last).
  • The seven studios and the two apps add a WebPage node, a second WebApplication node for that app, and a BreadcrumbList of two steps: Home, then the studio or app.
  • The guides index is a CollectionPage, with a BreadcrumbList and an ItemList naming its two guides.
  • The two guide pages are WebPage nodes with a three-step BreadcrumbList: Home, App guides, then the guide.
  • /voting, /plans and /terms are plain WebPage nodes with a two-step BreadcrumbList.

So the site describes its identity once and then tells a crawler what each individual page is, rather than stamping one generic block on everything.

Three routes that are not in the sitemap

  • /pricing returns 200 with the same <title> as /plans, and its canonical points at https://app.onepassapps.com/plans. It is a second name for the plans page, resolved by canonical rather than by a redirect.
  • /support returns 200 ("Support and feedback — OnePassApps") but has no canonical tag at all, and it is not in the sitemap.
  • /login and /signup both return 404 with the title "Page not found — OnePassApps". The account routes that robots.txt keeps out are /sign-in and /sign-up; the more obvious guesses are simply not routed.

If you are linking here

  • Link the canonical URL of the page you mean. For plans that is /plans, not /pricing.
  • https://app.onepassapps.com/support works even though it is not in the sitemap.
  • Do not link /login or /signup - they 404. The account pages are /sign-in and /sign-up.
  • Every studio URL answers with the tool page itself, no sign-in redirect in front of it.

Check it yourself

curl -s https://app.onepassapps.com/robots.txt curl -s https://app.onepassapps.com/sitemap.xml | grep -c '<loc>' curl -s https://app.onepassapps.com/studios/text | grep -o '<link rel="canonical"[^>]*>' 

No login, no uploads, nothing to install - the same browser tools the guides walk through, described in one page each. Start with the Text Studio, or browse the app guides.