# The Organization node: the one JSON-LD block every page's schema hangs off

One nested publisher object turns the Mega Analyzer Organization schema row green. The row tests presence of a type, not an entity home. Here is how to build one.

Author: J.A. Watte
Published: September 21, 2026
Source: https://jwatte.com/blog/blog-mega-analyzer-organization-schema-node/

---

Two rows in the Mega Analyzer read one flag. The Schema tab shows **Organization (or subtype) schema**, and the E-E-A-T tab repeats it as **Organization schema on the page**. Both go green the moment any JSON-LD object on the page carries an Organization type or one of its subtypes. What the row is really asking is whether your site has an entity home: one node, with a stable `@id`, that every other block (WebSite, Article, Person, BreadcrumbList) can point at instead of describing the publisher again from scratch. The row can only test presence.

## What the check actually tests

The analyzer parses every `<script type="application/ld+json">` block on the page, then walks every object value inside each block, not only the `@graph` array, and collects every `@type` it finds into one deduplicated list. That list is the strip of type chips above the check ("Types detected"). The flag behind both rows, `hasOrg`, is true when any string in that list is on an explicit list of 54 type names (Organization, LocalBusiness, Corporation, NewsMediaOrganization, OnlineBusiness, GeneralContractor, Plumber, Electrician, HVACBusiness, RoofingContractor, Store, FinancialService, LegalService, LawFirm, MedicalBusiness, Dentist, Restaurant, LodgingBusiness, Hotel, Motel, SelfStorage, RealEstateAgent, InsuranceAgency, NGO, EducationalOrganization, GovernmentOrganization and so on), or when the type name ends in Business, Organization, Service, Agency, Contractor or Store. The suffix rule exists because the schema.org Organization tree is large (the analyzer's own source comment counts LocalBusiness alone at about seventy subtypes) and an earlier literal list false-failed a real contractor site that emitted `HomeAndConstructionBusiness` and `GeneralContractor`.

Pass wording: **Organization (or subtype) schema** with no detail line. Fail wording: the same title with one line under it, "Required for Knowledge Panel eligibility." On the E-E-A-T tab the row is **Organization schema on the page** and carries no detail in either state.

Three things follow from how the flag is computed.

First, nesting counts. A `BlogPosting` whose `publisher` is an inline `{"@type": "Organization", "name": "..."}` turns the row green. So does a `Person` whose `worksFor` is an inline Organization, or whose `alumniOf` is an `EducationalOrganization`. The E-E-A-T Generator's own Person block emits that `alumniOf` node when you fill in the education field, which means a page carrying only a Person block can pass this row without saying a word about the business. The row tests that an Organization-shaped type exists somewhere in the JSON-LD, not that your site's own entity is modeled.

Second, the suffix rule is generous but not blind. Any type ending in Business, Organization, Service, Agency, Contractor or Store passes, which is how `HVACBusiness` or `LegalService` (a LocalBusiness subtype) count without being listed. The schema.org Service family is excluded on purpose: a bare `Service` node, `TaxiService` or `GovernmentService` describes the thing you sell, not the company selling it, and does not turn the row green. Even so, green is proof that an organization type exists somewhere on the page, not that you have a real entity home.

Third, what does not trip it. Microdata `itemtype="https://schema.org/Organization"` is invisible to this row; only JSON-LD is read. A block with a trailing comma or curly quotes around a key fails to parse, gets counted under "Parse errors" in the same card, and contributes no types. And a reference-only object, `{"@id": "https://example.com/#organization"}` with no `@type`, contributes nothing either. That last one matters for inner pages, and the fix section deals with it.

The row does not check `name`, `url`, `logo`, `sameAs` or `address`. Property completeness is the Schema Validator's job. This row stops at the type.

Person-only sites fail. A solo author with `Person` plus `ProfilePage` and no business gets a red row on both tabs, even though the E-E-A-T tab already treats that combination as a personal brand elsewhere (the team-page row drops to info-only for it). This row carries no such exemption.

## Why it matters

Google's own description of Organization structured data is modest, and worth quoting rather than inflating: adding it to your home page "can help Google better understand your organization's administrative details and disambiguate your organization in search results," and the markup can influence which logo appears and what shows in a knowledge panel. There are no required properties on that type; Google recommends adding as many relevant ones as apply, and recommends putting the block on the home page or on a single page that describes the organization, such as the about page. So the analyzer's fail line, "Required for Knowledge Panel eligibility," is stronger than Google's wording. The markup is one input to the knowledge panel. It is not a switch.

What makes the node structurally important is not the panel. It is that everything else in your schema wants to point at it. `WebSite.publisher`, `Article.publisher`, `Person.worksFor`, `Service.provider`, `JobPosting.hiringOrganization`, the location nodes on a multi-property operator's pages: each is a slot that expects an Organization. If there is no canonical node with an `@id`, every template fills that slot with a fresh anonymous copy, and the entity graph fragments into one Organization per page, none connected to each other or to your Google Business Profile, LinkedIn page or Wikidata item. That fragmentation is what two rows further down the same Schema tab catch: "Anonymous author/publisher Organization inside Article/NewsArticle" (an Organization-typed object with no `@id` sitting inline in the `author` or `publisher` of an Article, BlogPosting, NewsArticle, Recipe or Review node) and "Entity node has no @id" (no `@id` on any Person or Organization node on the page).

The reconciliation problem is real on Google's side. The Knowledge Graph Search API describes itself as using "standard schema.org types" and being "compliant with the JSON-LD specification," and each entity it returns carries an `@id` machine identifier. Your `sameAs` array and your stable `@id` are the page's half of that handshake: they are how you tell the graph that this URL, that Business Profile, that LinkedIn page and that Wikidata item are one thing.

For a local business the subtype is the point, not a nicety. On schema.org, `LocalBusiness` sits under both Organization and Place, which is why it inherits `geo` and `openingHoursSpecification` from Place and defines `priceRange` itself. A plain `Organization` has none of those. Google's Local Business guide asks for the most specific LocalBusiness subtype possible ("for example, Restaurant, DaySpa, HealthClub"), lists `name` and `address` as its two required properties, and recommends `geo`, `openingHoursSpecification`, `priceRange`, `telephone`, `url`, `aggregateRating` and `review`. The same guide ties that markup to the business knowledge panel and to the carousel shown for a "type of business" search, hedged as "may display" in both cases.

## How to fix it

**Step 1: pick the type**. Start at schema.org/Organization and walk down. A place people visit is a `LocalBusiness` subtype: `Motel`, `Plumber`, `Dentist`, `SelfStorage`, `AutoRepair`. A company without a customer-facing location is `Organization` or `Corporation`. A nonprofit is `NGO`. One trap: `ProfessionalService` looks like the safe catch-all and the analyzer accepts it, but schema.org's own definition says the general type "was deprecated due to confusion with Service." If nothing narrower fits, use `LocalBusiness` for a place or `Organization` for a company and put the specialty in `description` and `knowsAbout`.

**Step 2: emit one canonical block on the homepage**. Give it an `@id` at the site root with a fragment and fill the recommended properties. This is the shape the Schema Fix Bundle produces (Organization and WebSite linked by `@id`), extended with the local fields and a linked owner:

```json
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Plumber",
      "@id": "https://example.com/#organization",
      "name": "Example Plumbing",
      "url": "https://example.com/",
      "logo": {
        "@type": "ImageObject",
        "url": "https://example.com/images/logo.png",
        "width": 512,
        "height": 512
      },
      "image": "https://example.com/images/shop-front.jpg",
      "telephone": "+1-208-555-0100",
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "100 Main St",
        "addressLocality": "Boise",
        "addressRegion": "ID",
        "postalCode": "83702",
        "addressCountry": "US"
      },
      "geo": {
        "@type": "GeoCoordinates",
        "latitude": 43.615,
        "longitude": -116.2023
      },
      "openingHoursSpecification": [
        {
          "@type": "OpeningHoursSpecification",
          "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
          "opens": "08:00",
          "closes": "17:00"
        }
      ],
      "priceRange": "$$",
      "areaServed": { "@type": "City", "name": "Boise" },
      "sameAs": [
        "https://maps.google.com/?cid=1234567890123456789",
        "https://www.facebook.com/exampleplumbing",
        "https://www.linkedin.com/company/example-plumbing"
      ],
      "founder": { "@id": "https://example.com/#owner" }
    },
    {
      "@type": "Person",
      "@id": "https://example.com/#owner",
      "name": "Pat Example",
      "jobTitle": "Owner and master plumber",
      "worksFor": { "@id": "https://example.com/#organization" }
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "name": "Example Plumbing",
      "publisher": { "@id": "https://example.com/#organization" }
    }
  ]
}
```

Two details from Google's guide: the logo needs to be at least 112 by 112 pixels, on a crawlable and indexable URL, and it has to look right on a plain white background. And add a Wikidata URL to `sameAs` only if the item already exists; the analyzer's Wikidata row is info-only for that reason.

**Step 3: reference it everywhere else, with a typed reference**. On article pages, service pages and the about page, do not paste the block again. Point at it. Two analyzer rows shape the exact form: the duplicate-inline row goes red when two full blocks share one `@id`, and this row ignores a bare `{"@id": "..."}` because it has no `@type`. A typed reference satisfies both. The duplicate detector treats `@type`, `name` and `url` (plus a `worksFor` or `parentOrganization` delta) as reference-grade keys, and the `@type` keeps the Organization row green on the inner page.

```json
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://example.com/blog/fix-a-running-toilet/#blogpost",
  "headline": "How to fix a running toilet in ten minutes",
  "datePublished": "2026-09-21T09:00:00-06:00",
  "author": {
    "@type": "Person",
    "@id": "https://example.com/#owner",
    "name": "Pat Example"
  },
  "publisher": {
    "@type": "Plumber",
    "@id": "https://example.com/#organization",
    "name": "Example Plumbing"
  },
  "mainEntityOfPage": "https://example.com/blog/fix-a-running-toilet/"
}
```

Inside one document, JSON-LD flattening collects everything said about an `@id` into one node. Across pages, the identical `@id` is the only thing telling a consumer that the references describe the entity declared on the homepage. Spell the fragment `#org` in one template and `#organization` in another and you have two entities again. This is the part most sites get wrong, usually because the article template and the homepage template were written months apart.

**Step 4: never type a person as an Organization**. A solo practitioner is `Person`, plus `ProfilePage` on the bio page. A registered company with a named owner is the company subtype plus a linked founder Person, as above.

**Step 5: generate, validate, re-run**. [E-E-A-T Generator](/tools/eeat-generator/) builds one business block typed from the industry you pick (a LocalBusiness subtype for most industries, `NGO` for a nonprofit, `EducationalOrganization` for education), a Person block and the `sameAs` list from one profile form; it emits the blocks without `@id` fields, so add those by hand using the pattern above. [Schema Fix Bundle](/tools/schema-fix-bundle/) emits four identity nodes with every preset (Organization at `/#organization`, WebSite with `publisher` pointing at it, BreadcrumbList and an author Person), plus the page-type node for the preset you pick. One caution: its LocalBusiness preset adds the local node at a separate `/#localbusiness` beside the generic Organization. For a single-location business, merge those into one node with the subtype as `@type`, as in the sample above. Run the output through [Schema Validator](/tools/schema-validator/) and Google's Rich Results Test, then re-run the Mega Analyzer and check that "Organization (or subtype) schema" and "No anonymous author/publisher Organizations" are green and that the @id row no longer reads "Entity node has no @id".

## When to leave it alone

A personal-brand site whose root entity is `Person` plus `ProfilePage` should leave this row red. There is no honest Organization to declare. Inventing "Jane Doe LLC" as a `Corporation` when no such entity exists in a state registry, on Google Business Profile or on LinkedIn hands the Knowledge Graph a name it has never seen, and the `sameAs` handshake has nothing to reconcile against; the row goes green and your entity picture gets worse. If you form a real company later, add the node then and link yourself as `founder`.

Second exception: the row is already green because of a nested node and you are about to "fix" it. Check the type chips first. If `Organization` appears only because an Article's publisher is inline, the right move is to build the canonical node and convert the inline copies to typed references, not to add another inline block. A second full block that shares the inline copy's `@id` flips the duplicate-inline row red; a second block while the inline copy stays anonymous leaves the anonymous-publisher row red. Either way the report gets worse.

Third: a location site owned by a multi-property operator. Give the location its own `Motel` node with its own `@id`, and add a `parentOrganization` reference to the operator's node on the operator's domain. One entity per real thing, each with its own identifier, linked. That is the same shape The $100 Network is built around: several small sites, one owner, one entity graph.

## Fact-check notes and sources

- **Source**: https://developers.google.com/search/docs/appearance/structured-data/organization establishes that Organization markup "can help Google better understand your organization's administrative details and disambiguate your organization in search results," that it influences the logo and knowledge panel treatment, that there are no required properties (only recommended ones), that Google recommends placing it on the home page or a single about page, that the logo image "must be 112x112px, at minimum" on a crawlable and indexable URL, and that Google recommends the most specific Organization subtype that matches (its example: OnlineStore rather than OnlineBusiness for an ecommerce site).
- **Source**: https://developers.google.com/search/docs/appearance/structured-data/local-business establishes the two required LocalBusiness properties (`name`, `address`), the recommended ones (`geo`, `openingHoursSpecification`, `priceRange`, `telephone`, `url`, `aggregateRating`, `review`, `department`, `menu`, `servesCuisine`), the "use the most specific LocalBusiness sub-type possible" guidance, and that Search "may display" a business knowledge panel or a carousel of businesses from it.
- **Source**: https://schema.org/Organization is the type tree the analyzer's allow list and suffix rule approximate; its direct subtypes include LocalBusiness, Corporation, NGO, EducationalOrganization, GovernmentOrganization, MedicalOrganization, NewsMediaOrganization and OnlineBusiness.
- **Source**: https://schema.org/LocalBusiness establishes that LocalBusiness is a subtype of both Organization and Place, which is where `geo` and `openingHoursSpecification` come from, and that `priceRange` is defined on LocalBusiness itself. https://schema.org/ProfessionalService carries the note that the general type "was deprecated due to confusion with Service."
- **Source**: https://developers.google.com/knowledge-graph establishes that the Knowledge Graph Search API "uses standard schema.org types and is compliant with the JSON-LD specification" and returns each entity with an `@id` machine identifier.
- **Source**: https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data is Google's general statement of how it reads structured data and lists JSON-LD as the recommended format; the analyzer's row reads JSON-LD only, in line with that recommendation.
- **Source**: https://www.w3.org/TR/json-ld11/#node-identifiers establishes that "in JSON-LD, a node is identified using the `@id` keyword", and https://www.w3.org/TR/json-ld11/#flattened-document-form establishes that flattening "collects all properties of a node in a single map", which is the merge-by-`@id` behavior the typed-reference pattern relies on inside one document.

## Related reading

- [Your schema validates. Google AI Mode still can't find you. Here's the missing piece.](/blog/blog-ai-mode-entity-anchors-knowledge-graph/)
- [Why five inline Person blocks broke my AI Search visibility (and the fix)](/blog/blog-entity-duplication-ai-search/)
- [E-E-A-T Schema Markup: The JSON-LD That Makes Google Understand Your Brand](/blog/blog-eeat-schema-structured-data/)
- [How to Trigger a Google Knowledge Panel: The E-E-A-T Endgame](/blog/blog-eeat-author-authority-knowledge-panel/)
- [Why E-E-A-T Generator Exists](/blog/blog-tool-eeat-generator/)

*This post is informational, not legal advice. Mentions of third parties are nominative fair use. No affiliation is implied.*


---

Canonical HTML: https://jwatte.com/blog/blog-mega-analyzer-organization-schema-node/
RSS: https://jwatte.com/feed.xml
JSON Feed: https://jwatte.com/feed.json
Hero image: https://jwatte.com/images/blog-mega-analyzer-organization-schema-node.webp