The Build-Marker Layer of app.onepassapps.com: 56 Pages, Seven or Four Comments, and 23 With One Marker Pair

I work on OnePassApps. We build app.onepassapps.com, and this post is a measurement of the bytes our own build writes into every page it serves: the HTML comments that mark where the build injects crawler and social metadata.

I fetched all 56 URLs in our sitemap over plain HTTPS today, with a browser User-Agent, no session and no JavaScript. Every one answered HTTP 200. Then I counted the HTML comments in each document.

The marker pairs

Every one of the 56 pages carries the same pair of build-time marker comments, spelled exactly like this:

• TOOLPASS_SEO_START
• TOOLPASS_SEO_END

They sit around the block of route-aware metadata the build writes into the head of the document, and the comment directly above them says so in plain words: Route-aware crawler and social metadata is injected here at build time.

On 33 of the 56 pages there is a second pair, TOOLPASS_SEO_BODY_START and TOOLPASS_SEO_BODY_END. The other 23 do not have it. Those 23 are exactly our guide pages: the guides index plus the 22 per-app guides. Every remaining page - the home page, the seven studios, the 22 apps, /voting, /plans and /terms - carries both pairs.

The split shows in the comment count as well. The 33 pages that boot the app bundle carry seven HTML comments each; the 23 guide pages carry four each. No page carries a different number.

What the marked regions contain

The head region between TOOLPASS_SEO_START and TOOLPASS_SEO_END measures 3,645 to 7,200 bytes on the 33 pages that carry both pairs, and 4,246 to 7,118 bytes on the 23 guide pages. On all 56 pages that region holds the page title, the description, the robots and googlebot directives, our own onepassapps-indexing meta tag, the canonical link, the Open Graph and Twitter card tags, and the JSON-LD block.

The body region between TOOLPASS_SEO_BODY_START and TOOLPASS_SEO_BODY_END measures 770 to 59,303 bytes across the 33 pages: the smallest is /voting and the largest is /terms. It opens a div marked data-onepassapps-seo-fallback, which holds a main element with one h1, then the section the page is about.

On the home page that region carries 29 list entries under 2 headings, and 22 of those entries end in a Read the guide link. All 22 app pages are much shorter: each one carries three headings, five list entries and one h1, and none of them carries a guide link.

That fallback is the copy a crawler or a reader without JavaScript gets. The build writes it into the document at build time; our earlier post on the control layer measured what replaces it once the app bundle runs.

The comments are the build talking to itself

Two of the comments on every page are prose rather than markers. One reads: The static shell-crash fallback (§15): tokens, base and its own styles load outside the app bundle, so it renders even when the bundle fails. The other, on the pages with the body pair, reads: The shell-crash fallback (§15) is inert until public/shell-fallback.js clones it in, so it is never part of a route document's content.

Those comments are the only HTML comments in the documents, and their text is byte-identical across every page of the same shape - I extracted and compared them on all 56 pages.

What was already published

An earlier post on this account covered the markup dialect of the same pages, including the modulepreload links and the fallback script, and another covered the head contract, including the onepassapps-indexing tag. Those two are the canonical posts for those findings, and this post deliberately does not repeat them:

• https://dev.to/onepassapps/the-markup-dialect-of-apponepassappscom-56-pages-33-with-two-h1s-one-build-template-24dp
• https://dev.to/onepassapps/the-head-contract-of-apponepassappscom-56-pages-one-indexing-tag-and-the-two-names-we-ship-48m4

What had not been written down is the marker census itself: the two pairs, the 33-and-23 split between the pages that ship a body pair and the pages that do not, the seven-versus-four comment counts, and the byte sizes of the two marked regions.

Limits

These are counts of the served HTML from one build on one day, 9 November 2026, fetched over plain HTTPS from one machine. Nothing here was measured in a browser, so it says nothing about what the panel renders after JavaScript runs. The region boundaries are byte positions in the response as served, and they will move when the build changes.

If you want to see the marked regions yourself, view the source of any of our pages and look for TOOLPASS_SEO_START. The app is at app.onepassapps.com, and the guides are at app.onepassapps.com/guides.

I work on OnePassApps, and everything above was measured on our own live pages today.