A default JSON-LD bundle beats a taxonomy research project on every new site

Richard Lemon has published on dev.to a walkthrough of the default JSON-LD bundle he ships on almost every marketing or SaaS site, plus variants for blogs and local businesses ^[1][4]. The markup itself is ordinary; the operating decision behind it is the part worth copying, because he says he stopped treating Schema.org as a research project after noticing where the research led ^[2].

The failure mode he describes is familiar: new client, new niche, too many candidate schema types, and then you add nothing at all because the job feels endless ^[3]. A fixed default closes the scope. His bundle is governed by four constraints ^{[5][6][7][8][25]}. Two are about vocabulary: JSON-LD only, inside `script type="application/ld+json"`, with no microdata and no RDFa ^[5], and one primary entity per page, on the grounds that Google can handle more but simplicity wins unless a composite is genuinely needed ^[6]. The other two are about provenance, and they are the ones that change outcomes. The markup is generated from a build step or CMS fields rather than hand-written per page ^[7], and the data must exist visually: if the user cannot see it, it does not go in the schema, which he frames as staying out of spam territory ^[8].

Those two rules together mean the page is the source of truth, not a separate document that drifts. The contactPoint block shows the discipline working: he includes a phone number in the Organization markup only if the site displays one, and deletes the block otherwise ^[21]. Same logic on the site-wide WebSite entity, which he puts only on the root URL, not every page ^[13], and only with a `potentialAction` if a real search endpoint exists, with no fake endpoints ^[14]. He matches the `url` value to the canonical link tag every time ^[15]. According to Lemon, Google uses this block for sitelinks search boxes ^[12]. The implementation is a `buildWebsiteSchema(config)` helper fed a site name, a URL and an optional search URL, which the page component calls and stringifies ^[16].

The main entity is a generic Organization for SaaS, agencies without public shops and online-only services, carrying name, url, logo, sameAs and contactPoint ^[17][18]. Logo is the same file as the header, absolute and crawlable ^[19]; sameAs holds only real social profiles, not directory listings ^[20]. It sits on the homepage next to the WebSite block as a second, separate script ^[22]. Brick-and-mortar clients get a LocalBusiness subtype instead, such as Restaurant, Physiotherapy or HealthClub ^[23], and the gym example adds an `@id` anchored to a `#business` fragment, a PostalAddress, GeoCoordinates and openingHoursSpecification ^[24]. Injection is in the head wherever possible, via a Head component in Next.js or written directly in Astro, Svelte and plain HTML ^[9], with dynamic data rendered on the server and dropped in as stringified content ^[10]. No CDNs, no external scripts ^[11].

Two things to watch if you adopt this. First, the visibility rule creates a coupling that has to be enforced somewhere: remove the phone number from the footer and the contactPoint block has to go with it ^[21][8], which is a template problem, not an editorial one. Second, the walkthrough as supplied breaks off inside the local-business section, so the blog and local-business variants he references are not fully in evidence ^[26][4].