Our own helper put a second WebSite node in the homepage JSON-LD
Peter Benes ·
On August 31 a deploy to aibubblequestion.com, our editorial research site, took its production score from 96% to 92%. One check that had been passing now failed: jsonld.single_website. The homepage was declaring two WebSite nodes in its structured data.
Why one WebSite node matters
JSON-LD is the structured data a page hands to search engines and AI systems so they don’t have to guess what the page is. On a well-built site there is one WebSite entity, one Organization, one Person, and every page refers back to them.
Two WebSite nodes on one page make that ambiguous. Which one is the site? Is the second one a different website? A parser has to choose, and you don’t control how it chooses. We can’t point to a ranking we lost over it. But entity data is what AI answers lean on when they decide who to cite, and ambiguous entity data is a bad trade for no benefit.
A probe that counts node types is cheap. Ours runs daily against the live site, and that is how this one surfaced.
What caused it
The previous build, eeef9cb, had a single failing check: sec.csp, a known gap. The new deploy, 8d28a3a, included commit 4829bdf, which added an articleSchema() helper and wired it into the homepage for the first time.
The helper wrote its isPartOf and author properties as inline objects: a full WebSite and a full Person, declared on the spot. Meanwhile the site’s base layout was already emitting a keyed WebSite and Person in the page graph. The result was one WebSite with an @id, and a second one without.
What it was not
In July we had fixed an earlier WebSite problem on this same site, tied to EmDash’s siteName handling. The first instinct was that it had come back. We checked and ruled it out. This one was our own code, repeating a pattern that a comment a few lines away warned against.
The fix
Commit 7e89b09 changed three things. The helper now references the WebSite and Person by @id instead of redeclaring them. The Person’s ID comes from one exported constant that every file shares, so it is defined in exactly one place. And each per-page node gets its own @id, so nothing on the page is anonymous.
Verified locally afterward: one WebSite, one Organization, one Person and one WebPage on the homepage, and one canonical on each sampled page.
The latent copy
The same mistake was sitting in the case study template, /case-studies/[slug]. The daily probe samples the homepage, so it never saw those pages. We logged it for the next time that template is touched, and wrote down that the probe’s coverage stops at the homepage, so nobody mistakes a pass there for a pass everywhere.
Where it ended up
By September 2 the homepage emitted exactly one WebSite node, and the site was back at 96%, with sec.csp the only failing check.
The rule
Declare each entity once. Everywhere else, point to it by @id. It is a small discipline, and it is the difference between a site that describes itself clearly and one that contradicts itself in its own markup.
If you maintain structured data by hand or through helpers, a quick way to check yourself is to paste your homepage into any JSON-LD viewer and count the WebSite and Organization nodes. If either number is more than one, something is redeclaring what it should be referencing.
What this means if you hire us
Atomic Wax sites are built for AI answers as well as Google, which means structured data that is checked on the live site every day, not validated once at launch and forgotten. If a change introduces a regression, the probe tells us before you have to. The free assessment includes a look at what your current structured data says about you.