The Identity Layer of Our JSON-LD: 54 Distinct IDs, 91 Nodes Without One, and 22 Guide Pages That Point Elsewhere

I work on OnePassApps, so this is our own site and our own build. Every number below was measured today on app.onepassapps.com with plain HTTPS requests from one server - no browser session, no cookies, no JavaScript.

Our sitemap lists 56 URLs. Every one of them ships exactly one application/ld+json block. Earlier posts here have looked at what sits inside those graphs. This one is about the identity layer: which nodes carry an @id, which ones carry none, and what the identifiers actually point at.

What I measured

• The 56 URLs in https://app.onepassapps.com/sitemap.xml
• One plain GET each
• The one application/ld+json block on each page, parsed as JSON, then every node in its @graph

56 blocks, 0 parse errors, 255 nodes in total.

Every block has the same two keys

All 56 blocks carry exactly two top-level keys: @context and @graph. Nothing else - no top-level @type on any of them. The context is https://schema.org on all 56.

The types live inside the graph instead, and the census of node types across the site is:

255 nodes, seven types. Two of them - Organization and WebSite - are on every page.

Two of those nodes never change

The Organization node and the WebSite node are byte-identical on all 56 pages. Not merely similar: one variant of each, once you serialise them. So 112 of the 255 nodes are the same two objects copied 56 times - the brand name, the URL, the logo at /icon-512.png, the description, the customer-support contactPoint at [email protected], and inLanguage: en-GB.

54 identifiers for 255 nodes

164 of the 255 nodes carry an @id. The other 91 carry none at all. And the 164 collapse to 54 distinct values:

The 29 #app identifiers are the 22 app pages and the 7 studio pages. The 22 #guide identifiers are one per guide page.

The guide pages point at a node in another document

Here is the part worth reading.

Every one of the 22 guide pages has a WebPage node whose about pointer names an application:

"about": { "@id": "https://app.onepassapps.com/apps/newsflow#app" }

That identifier is not defined in the guide page's own graph. The guide page defines three identifiers - the shared #organization, the shared #website and its own #guide. The #app one it points at is defined on the app page, /apps/newsflow, as that app's WebApplication node.

Our 56 graphs contain 218 identifier references in total, and 22 of them - one on each guide page - point at a node that lives in a different document. They do resolve, but only by following the pointer to another page of the same site. The other 196 resolve inside their own document.

The 29 app and studio pages point their WebPage at an #app identifier defined in the same document, so those references are local.

32 pages describe a page that has no identifier

54 of our pages carry a WebPage node. Only 22 of them give it an @id - the guide pages, as https://app.onepassapps.com/guides/newsflow#guide.

The 22 app pages, the 7 studio pages and the three plain routes - /voting, /plans and /terms - have a WebPage node with no identifier at all. Their page identity is only in the url field.

The application nodes, and their categories

30 WebApplication nodes: the home page, the 22 app pages, the 7 studio pages. The 23 guide pages, /voting, /plans and /terms carry none - a guide page describes an app without claiming to be one.

Eight category values across the 30:

Each of the 22 app pages lists exactly 3 items in its featureList; the studios list between 4 and 11; the home page's own WebApplication node lists none, and it is the only one of the 30 with no applicationSubCategory.

The breadcrumbs, and the one page without them

55 of the 56 pages carry a BreadcrumbList: 33 with two steps, 22 with three. The three-step ones are exactly the guide pages - Home, App guides, then the guide itself. The home page is the only page with no breadcrumb at all.

What I did not measure

Everything above comes from the HTML the server returns. I did not open the 56 pages in a browser to confirm the rendered DOM carries the same block, so if a script rewrites the structured data client-side, I have not measured that. I did not run a schema validator, I did not see how any search engine renders these graphs, and I have no evidence about whether the cross-page #app reference helps or hurts a crawler. I did not check whether the identifier scheme changes for a different user agent.

If you want to look for yourself, start with the home page and the guides index, then read the application/ld+json block in the page source.

We will keep measuring and keep publishing the numbers.