Ship site-wide Organization schema

What the scan checks: it looks for an Organization JSON-LD node (on the page or the homepage) with at least six populated properties. Missing entirely is a fail. Present but thin (under six populated properties) is a warning, because a threadbare entity record underperforms.

Two details worth knowing:

• Populated means populated. "description": "" is not a description and "sameAs": [] is not a sameAs array. Empty values are not counted, and neither are the JSON-LD plumbing keys (@type, @context, @id). This is not pedantry: in the 2026 citation studies, pages carrying thin generic schema were cited less often than pages carrying no schema at all. A six-key node made of empty strings is worse than nothing.

• A Service node is not an Organization. If your site markets services, you may well have Service schema and no Organization. Service describes something you do; Organization is the entity record for the brand that does it, and an engine cannot resolve a brand from the former. You need both. (Until 30 July 2026 this check accepted a bare Service node as an Organization — that was a bug, and it is fixed. If your score moved on a re-scan, this is why.)

• Identifiers are reported, never required. If your Organization node declares leiCode, duns, vatID, naics or legalName, the scan lists them, and it verifies a declared leiCode against GLEIF, the free public register of Legal Entity Identifiers. A verified LEI turns a self-asserted string into a corroborated fact an engine can cross-check. Declaring none of them costs you nothing: most companies legitimately have none, and there is no evidence that would justify failing a site over it. parentOrganization and subOrganization are recorded the same way, because they are what tells an engine which entity a subsidiary’s facts belong to.

Why it matters for AI search visibility

Organization schema is your brand’s entity record: the machine-readable statement of who you are, which an engine reads to recognize you by name and link you to a knowledge-graph entity. It is the backbone of being cited by name rather than as “a vendor.” Without it, the model has to infer your identity from scattered mentions, and identity fragments (cited as “Acme Blog” in one place and “Acme” in another). One consistent Organization node, present on every page and referenced everywhere by its @id, is what makes the brand resolve to a single, confident entity.

How to fix it

Emit one Organization block server-side in your layout template, so it appears on every page:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#org",
  "name": "Example Inc",
  "url": "https://example.com",
  "logo": {
    "@type": "ImageObject",
    "url": "https://example.com/logo.png",
    "width": 512, "height": 512
  },
  "description": "AEO monitoring for marketing teams.",
  "foundingDate": "2024",
  "sameAs": [
    "https://www.linkedin.com/company/example",
    "https://www.crunchbase.com/organization/example"
  ]
}

• Clear six properties. Name and url are required; add logo, description, foundingDate, sameAs, contactPoint, and knowsAbout to get past “thin.”
• Give it a stable @id of {origin}/#org (see the @id guide) so other nodes can reference it.
• Render it server-side (see T3); a block injected by JavaScript is invisible to non-rendering crawlers.

Then extend sameAs into a real mesh (E5) and add Wikidata (E3).