The Guide Pages app.onepassapps.com Ships: Two Guides, Ten Anchor IDs and One Missing FAQPage

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

Our guides live at /guides, /guides/newsflow and /guides/movie-tracker. An earlier post here compared what the guides say against what the apps say. This one is about how a guide page is built - the section skeleton, the anchor ids, the on-page nav, the step markers and the structured data - because that layer had not been read by any channel.

The guide pages are worth reading closely for anyone writing their own docs, and they are also where we are thinnest: two guides for nine apps, with the seven browser studios documented only by their own tool pages.

How this was measured

• Three GETs per URL over plain HTTPS with a desktop Chrome user agent, no JavaScript, no cookies, no session - signed out.
• Byte counts are from the decompressed response body; character counts are from the decoded text. The two differ because the pages contain em dashes and curly apostrophes.
• The HTML was parsed for element ids, heading levels, section elements, anchors, list items and the JSON-LD graph.
• No browser was opened for this post, so nothing here says how the pages look, only what they contain.

Page	HTTP	Bytes	Characters	Main text	Words
/guides	200	19,824	19,809	1,015	163
/guides/newsflow	200	22,480	22,462	2,442	393
/guides/movie-tracker	200	23,889	23,871	2,680	422

All three guides together are 978 words of main text. Three consecutive fetches of each URL agreed on length exactly. Two back-to-back fetches of the same URL were not byte-identical, though: they differed only inside one long hex-encoded segment of the page, with the rendered text identical. The served HTML is not identical between requests.

The same ten ids on both guide pages

Each guide page carries exactly ten element ids, and the list is the same on both pages, in the same order:

onepassapps-structured-data, guide-content, features, features-heading, steps, steps-heading, limits, limits-heading, questions, questions-heading.

The pattern is: four <section> elements with the ids features, steps, limits and questions, and each section's <h2> carries a second id formed from the section name plus -heading. So one guide section contributes two ids, and the extra -heading id is what a link to the heading text itself would use.

guide-content is the main content region, and onepassapps-structured-data is the JSON-LD block. The index page carries only the first two of those - it has no sections and no on-page nav.

The on-page nav is labelled from the section, not from the heading

Both guide pages print an "On this page" list whose four entries point at #features, #steps, #limits and #questions. The labels it shows are:

Nav label	Anchor	The heading it lands on
Features	#features	What you can do
Steps	#steps	How to use this app
Limits and privacy	#limits	Limits and privacy
Questions	#questions	Common questions

Three of the four labels differ from the heading they point at. "Limits and privacy" is the one that matches exactly. All four anchors do resolve - each target element exists in the page - so the navigation works; it is the wording that does not line up. A reader who clicks "Features" lands on a heading that says "What you can do", and a reader who clicks "Steps" lands on "How to use this app".

The headings themselves are identical on both pages: What you can do, How to use this app, Limits and privacy, Common questions. The section ids are identical too. Whatever is happening here, it is happening in the template rather than in one guide.

Three steps, numbered 01/02/03

Both guides number their how-to steps 01, 02, 03. The NewsFlow guide reads:

• 01 Open Inbox and select a story. Check its source and any stale-data or availability notice before relying on the brief.
• 02 Read the brief and open the original for context. Choose Listen to prepare or reuse the selected story's audio.
• 03 Queue another item or adjust your followed sources after signing in. Leaving the active story pauses playback.

The MovieMatcherAI guide uses the same three-step shape with its own content: open Browse and search, sign in to add to Unwatched or mark Watched, then add a rating, note or reaction.

Seven questions, none of them marked up as questions

The questions live in <h3> headings. NewsFlow has three:

• Can I listen without an account?
• Does NewsFlow include every story from a source?
• Does NewsFlow cost anything or use credits?

MovieMatcherAI has four:

• Can I browse without signing in?
• What happens when I rate a title?
• Does a provider listing prove local streaming availability?
• Is MovieMatcherAI free, and does it use credits?

That is seven questions across the two guides. The answers are open prose in the HTML - there is no <details> and no <summary> anywhere on either page, so nothing is hidden behind a click and the answer text is in the response body.

Here is the part worth flagging: the structured data does not describe any of it. The JSON-LD graph on both guide pages is Organization, WebSite, WebPage, BreadcrumbList. There is no FAQPage node - not on the guide pages, not on the index, not anywhere in the site. FAQPage is the schema.org type for exactly this shape of content, and our own pages do not use it. A crawler looking for our answers has to read the prose.

What the graph does say

The WebPage node on the NewsFlow guide carries "@id": "https://app.onepassapps.com/guides/newsflow#guide" and an about pointer to a WebApplication node for the app it documents - "name": "NewsFlow", "url": "https://app.onepassapps.com/apps/newsflow". The MovieMatcherAI guide points at https://app.onepassapps.com/apps/movie-tracker the same way. Both carry a three-step BreadcrumbList: Home, App guides, then the guide itself.

The index is a different shape entirely: a CollectionPage, a two-step BreadcrumbList, and an ItemList naming the two guides with their positions and URLs. Its two <h2> elements are the guide titles themselves rather than section headings, its only in-page anchor is the skip link's target, and its list header reads "All guides" with a meta line of "2 apps". Each card carries a category line and a call to action - "News / Briefs / Audio" with "Open NewsFlow", and "Personal / Media / Discovery" with "Open MovieMatcherAI". A guide page repeats its own app's card twice, once at the top and once at the foot.

All three pages carry a skip link reading "Skip to content" that points at #guide-content. The index has five list items; each guide page has thirteen.

One more comparison, because it is the kind of thing that only shows up when you read the bytes: in llms.txt, the two guide pages are summarised with a line that is byte-identical to that page's own meta description. The index is not - llms.txt summarises it as "Supported tasks, steps, formats, and limitations." while the page's meta description reads "Explore practical OnePassApps app guides, supported formats, step-by-step instructions, and tool limitations."

The edges

• /guides/does-not-exist answers 404 with a 3,942-byte body rather than falling back to the index, so a wrong guide slug fails loudly.
• Two guides cover the two hosted apps. None of the seven browser studios has one - the index makes a general statement about browser-local tools and then documents none of them, and the sitemap agrees.

You can read the guides themselves at app.onepassapps.com/guides, and the NewsFlow guide - the shorter of the two - at app.onepassapps.com/guides/newsflow.

Limits of this measurement

• One build, one day, 5 November 2026, signed out, server-rendered HTML only. Anything the pages add after JavaScript runs is outside these counts.
• The ids, headings, anchors and JSON-LD are what the served markup says. I did not read the component library behind them, so I am not claiming why the nav labels differ from the headings - only that they differ, and that they differ on both guides.
• Anchors were checked for the presence of their target elements, not by scrolling a rendered page.
• No styling, layout or visual behaviour was measured. The word counts are main-text counts with tags stripped.
• The absence of a FAQPage node is a statement about the markup we serve. I am not claiming how any search engine treats it.
• The byte counts are one build's response sizes; the pages are server-rendered and their lengths have been stable across every fetch this run.

If you build docs like this, the two things worth copying are the section-and-heading id pair and the about pointer from a doc page to the app it documents. The two things worth fixing on ours are the nav labels and the unmarked questions.

I work on OnePassApps - we build these tools and these guides.