I work on OnePassApps, so this is our own site, measured twice on 10 November 2026: once as the HTML our server sends, and once as the page a browser actually renders.
The finding is short and slightly uncomfortable: on several of our pages those are two different documents, describing the same products in different words.
How I measured it
- Served side: a plain HTTPS GET of each URL with a browser User-Agent. No cookies, no session, no JavaScript.
- Rendered side: the same URL opened in the visible Chrome on our own machine, with the visible text captured once the app had finished booting. A fresh tab per page, closed after the capture.
- Comparison: sentences from the served document and lines from the rendered page, whitespace normalised, each side checked against the other as a substring. A line counts as a sentence if it ends in a full stop and carries at least five words, which keeps the navigation out of the counts.
Eight pages, one build, one region, one day.
One sentence that changes on /plans
Our plans page ends its payment paragraph with a sentence about what still works for paying customers. The served document and the rendered page do not use the same words for it.
Served: "Existing billing records, management and support remain available."
Rendered: "Existing purchases and billing support remain available."
Everything before it is identical: "New payments are disabled during the free promotional period."
The numbers agree in both documents and in the API: 100,000 credits every 30 days, no card, $0 during the promotion. The line "New payments paused" appears on the rendered page and nowhere in the served HTML, which is the kind of difference that makes a quote look stale when you check it against the wrong copy of the page.
The home page: 29 products, two sets of words
The served home page carries an SEO fallback list of 29 products: 22 apps and 7 Studios. Every entry has a name, a description and, for the apps, a guide link.
The rendered home page shows the same 29 products as cards. The names match - 29 of the 29 names appear on both sides - but the descriptions do not:
| Product | Served document | Rendered page |
|---|---|---|
| NewsFlow | Follow news and research, read original headlines and source-based briefs, and listen to your brief queue. | Trusted-source news briefs to read or listen to. |
| MovieMatcherAI | Browse movies, track what you want to watch, and rate what you’ve seen. | Find films, keep a watchlist and rate what you’ve seen. |
Counted across the whole list: 0 of the 29 descriptions in the served document appear anywhere in the rendered page, and 0 of the 29 rendered card blurbs appear in the served HTML. The guide links are the other way round: the served document carries 22 "Read the guide" links, the rendered page carries 0.
The rest of the eight
| Page | Served bytes | Served text | Rendered text | Sentences only served | Lines only rendered |
|---|---|---|---|---|---|
| / | 24,644 | 3,648 chars | 5,763 chars | 33 | 46 |
| /plans | 20,234 | 3,544 chars | 2,603 chars | 40 | 9 |
| /terms | 74,495 | 30,334 chars | 30,900 chars | 38 | 28 |
| /guides | 61,393 | 6,348 chars | 6,319 chars | 3 | 2 |
| /apps/movie-tracker | 18,944 | 2,088 chars | 2,083 chars | 19 | 1 |
| /apps/qr-code-maker | 18,872 | 1,893 chars | 1,491 chars | 18 | 6 |
| /voting | 15,866 | 454 chars | 2,115 chars | 3 | 8 |
| /studios/data | 17,024 | 870 chars | 1,393 chars | 8 | 4 |
Our terms page is the extreme case: 74,495 served bytes and 30,900 characters of visible text, with 38 served sentences and 28 rendered lines that have no counterpart in the other document.
Why I am publishing this
A crawler, a reader and our own API can each be right about the same page and still disagree about its wording. If you build against our pages, read the rendered DOM. If you read our HTML, know that you are reading a fallback document: the same names, mostly the same numbers, and sentences that are not the ones on screen.
What I did not do
I did not change the site, and I am not calling the difference a bug: the fallback document exists on purpose, so a crawler and a reader without JavaScript both get something useful. I read eight pages, one build, one region, in one browser, in one day. I did not test another browser, another viewport, another language or a signed-in session, and I did not compare the fallback text against the API field by field.
Where to look
The plans page this was measured on:
The app guides, if you would rather read what each tool does:
I work on OnePassApps, so this is our own site, measured today rather than described from memory.
Top comments (0)