A Working Organization Schema Example You Can Copy and Verify

Most pages ranking for this query hand you a code block and stop. The code block matters, and ours is below, complete and valid. But the markup itself is the easy half. The hard half is the architecture around it: where the node lives, how every other page references it, why the type you choose changes what Google can do with it, and what happens when a plugin quietly publishes a second, contradicting copy. This page covers all of it, and the worked example is not hypothetical. It is the exact pattern running on this site right now. View source on this page and you will find the same node the example describes, which means every claim here is inspectable rather than theoretical.

What organization schema actually does

Organization schema is a JSON-LD block that tells search engines and AI systems, in machine-readable terms, which legal and commercial entity stands behind a website. Google's own documentation is plain about the purpose: the markup helps Google understand administrative details and disambiguate your organization from others with similar names, and it influences visual elements such as which logo appears in search results and in your knowledge panel.

Disambiguation is the word to hold onto. Google does not need schema to know your site exists. It needs schema to be certain that the "Formative Digital" mentioned on LinkedIn, the one in a Brantford business directory, and the one publishing this page are the same entity and not three. Every property in the markup either identifies the entity, locates it, or connects it to an external confirmation. That certainty is what feeds a knowledge panel, and increasingly it is what lets an AI engine attribute a fact to your brand instead of hedging or hallucinating. We map this work to Vector 2 (Anchor) and Vector 6 (Structure) in the 12 Vectors framework: the entity gets anchored first, then the markup expresses the anchor in a form machines read with confidence.

The complete example, ready to adapt

Here is a full Organization node using this agency's real details. Swap in your own values and it is production-ready. It parses as valid JSON, which you should verify after editing, because a single trailing comma silently kills the whole block.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://formativedigital.com/#organization",
  "name": "Formative Digital",
  "url": "https://formativedigital.com",
  "logo": {
    "@type": "ImageObject",
    "url": "https://formativedigital.com/assets/logo.png",
    "width": 600,
    "height": 600
  },
  "description": "AI-search visibility agency in Brantford, Ontario. GEO, SEO, and web engineering under the 12 Vectors methodology.",
  "telephone": "+12264502065",
  "email": "support@formativedigital.com",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Brantford",
    "addressRegion": "Ontario",
    "addressCountry": "CA"
  },
  "areaServed": {
    "@type": "AdministrativeArea",
    "name": "Ontario, Canada"
  },
  "founder": {
    "@type": "Person",
    "@id": "https://formativedigital.com/#matt-griffin",
    "name": "Matt Griffin",
    "jobTitle": "Founder"
  },
  "sameAs": [
    "https://www.linkedin.com/company/formative-digital"
  ]
}

Wrap it in a <script type="application/ld+json"> tag in the page head, server-rendered, never injected by JavaScript after load. Static HTML sites like this one have an advantage here: what the crawler fetches is exactly what the browser gets, with no hydration step that can drop or duplicate the block.

Property by property: what each line earns you

None of these properties is decorative. Each one answers a specific question a machine asks about your entity.

• @id establishes a permanent name for this node inside your schema graph. More on this below, because it is the property almost everyone gets wrong.
• name must match your Google Business Profile, your legal registrations, and your social profiles character for character. NAP inconsistency is still the most common entity-confidence leak we find in audits.
• url is the canonical home of the entity. Use the bare domain with your preferred protocol and no tracking parameters.
• logo feeds the image Google shows in search results and knowledge panels. Google has supported logo markup since 2013 and folded it into the wider Organization type in its November 2023 documentation expansion. Square, at least 112x112 pixels, on a crawlable URL.
• telephone and email are administrative signals. They should match the contact details published visibly on your site; markup that contradicts the page is worse than no markup.
• address uses the nested PostalAddress type. A service business that hides its street address can legitimately supply only locality, region, and country, as the example does.
• areaServed tells engines the geography you actually cover, which matters when your service area is wider than your address. A Brantford agency serving all of Ontario should say so here rather than hoping Google infers it.
• founder connects the organization to a Person entity. This is the join point for author E-E-A-T: when your articles carry Person markup for the same @id, the byline, the founder, and the organization resolve into one connected graph.
• sameAs is the disambiguation workhorse, covered in its own section below.

Google also supports deeper administrative properties on Organization, including vatID, iso6523Code, and for merchants a return policy nested via hasMerchantReturnPolicy. Add them when they apply; skip them when they do not. Empty or guessed values damage trust rather than padding it.

The @id strategy: one node, referenced everywhere

The @id property is where a schema block stops being a page decoration and becomes a graph. An @id is a stable identifier, conventionally your domain plus a fragment such as https://formativedigital.com/#organization. It does not need to resolve to a page. It needs to never change.

Once the identifier exists, every other node on the site references it instead of repeating the details. The Article markup on this page does not restate the agency's phone number and address; its publisher property is simply {"@id": "https://formativedigital.com/#organization"}. The WebSite node points its publisher at the same fragment. Person markup for Matt uses #matt-griffin the same way, and the Organization's founder property points back at it. Parsers stitch the fragments into one connected entity description, which is exactly how Google reads structured data: as a graph, not as isolated islands.

The payoff is maintenance and consistency at once. Change the phone number in one node and the whole site is correct. Repeat full organization details on 400 pages instead, and the day one template lags an update you are publishing two versions of the truth. Machines notice contradictions faster than humans do.

Two rules keep the strategy stable. First, pick the fragment once and treat it as permanent; changing #organization to #org later orphans every reference that pointed at the old name. Second, keep the full property set in exactly one place, normally the home page node, and keep every other appearance a bare @id reference. One authoritative node, many pointers.

Organization or LocalBusiness: how to pick

LocalBusiness is a subtype of Organization, so this is not an either-or between two rival types. It is a question of specificity. The decision comes down to how customers reach you:

• Choose LocalBusiness (or a more specific subtype such as Dentist, Plumber, or Store) when customers visit a physical premises or you serve a defined local area. The subtype unlocks properties Organization lacks: openingHoursSpecification, geo coordinates, priceRange, and eligibility for local rich results.
• Choose Organization when the entity is not location-bound: online businesses, publishers, SaaS companies, brands with many locations (where each location gets its own LocalBusiness node and the parent stays Organization), and agencies whose work is delivered remotely.

Formative Digital runs plain Organization markup even though the agency sits in Brantford, because clients hire us from anywhere in Ontario and beyond, and there is no storefront to walk into. A dental clinic three blocks away should make the opposite call. If your situation is genuinely local, our local business schema guide walks the subtype selection and the local-specific properties in the same copy-and-verify format as this page.

The one wrong answer is publishing both as separate nodes. That creates two entities where one exists, which is the exact failure mode the whole exercise is meant to prevent.

sameAs: how machines confirm you are you

The sameAs array is a list of external URLs that refer to the same entity: your LinkedIn company page, your Wikidata item if you have one, your Google Business Profile, active social accounts. Each link is a testable claim. A parser can fetch the LinkedIn page, compare the name, location, and description against your markup, and raise or lower its confidence that both describe one organization.

That checking behaviour dictates the strategy. Curate rather than accumulate. A Wikidata item is the strongest target where one legitimately exists, because Wikidata feeds Google's Knowledge Graph directly and propagates into the training and retrieval layers of the major AI engines over time. LinkedIn and a verified Google Business Profile are solid second-tier confirmations. A pile of abandoned directory profiles with outdated addresses actively works against you: every mismatch is a contradiction on the record. In Matt's audits of Ontario service businesses, stale sameAs targets pointing at renamed or dead social accounts turn up more often than missing sameAs arrays altogether, and the fix is deletion, not addition.

sameAs also carries the entity-disambiguation load when your name collides with someone else's. If three companies share your name, the array of profiles is how an engine resolves which one published the page it is reading. That resolution is upstream of everything we cover in the Knowledge Graph guide for businesses: no panel, no brand card, and no confident AI citation happens while the engine is still unsure who you are.

The breakage we see most: conflicting Organization nodes

Here is the failure pattern that shows up in a majority of the WordPress site audits we run, described qualitatively because the mix varies by stack. An SEO plugin outputs an Organization node from its settings screen. The theme outputs another from its own branding options. A page builder widget adds a third. None of the three shares an @id, two disagree on the phone number, and one still carries the business's previous name from a rebrand two years back.

Google's response to contradiction is not to average the versions. It is to trust none of them very much. The result is a site that technically "has schema" while its entity confidence sits lower than a competitor running one modest but consistent node. Matt has watched a knowledge panel display a client's pre-rebrand logo for months, sourced from a forgotten theme setting nobody knew was emitting markup, while the plugin's correct version sat ignored on the same pages.

The diagnostic is quick. Open any page's source, search for every occurrence of "Organization" inside ld+json blocks, and list what you find. The target state is a single node, or multiple appearances that all reference one @id. The fix usually means turning off schema output in every tool except one, then confirming with a fresh crawl. Static builds like ours sidestep the problem structurally, since no plugin exists to disagree with the markup we wrote, but the single-node discipline applies to any stack.

How to validate the markup after you paste it

Three checks, in order, before you call the job done:

• Syntax. Run the JSON through any strict parser or validator. Trailing commas, curly quotes pasted from a word processor, and unescaped line breaks inside strings are the three killers. A malformed block fails silently; browsers do not warn you.
• Schema validity. Google's Rich Results Test shows what Google extracts, and the Schema.org validator at validator.schema.org checks the vocabulary itself. Run both, because they answer different questions.
• Live consistency. Fetch the deployed page, not your local copy, and confirm the block survived the build. Then compare name, phone, and address against your Google Business Profile and your visible footer. Markup, profile, and page should read as one voice.

Recheck after any platform migration, theme change, or plugin update. Schema regressions are quiet; nothing visibly breaks when a deploy drops your JSON-LD, and you find out weeks later when the knowledge panel drifts.

Where organization schema fits in the wider entity work

One Organization node is the foundation course, not the finished building. The connected pieces, in the order we implement them for clients:

• Person markup for the people behind the brand. Founders and named authors get their own stable @id nodes with knowsAbout arrays, joined to the Organization through founder and author properties. Worked example in our person schema example.
• LocalBusiness depth where geography matters, per the decision above.
• Article, WebSite, and BreadcrumbList markup on every content page, each referencing the Organization @id so publishing activity accrues to the entity.
• External confirmation: aligning the profiles your sameAs array points at, and earning the mentions that give engines independent evidence.

That last layer is where markup ends and entity strategy begins, and it is the core of our entity optimization service. The blunt sequencing advice: get the single clean Organization node live this week, because every later layer references it, and none of the later layers can compensate for a contradicted foundation.

If you would rather talk it through than fill in a form, reach out directly and tell us what your current markup looks like. Bring the messiest version you have; contradictory schema is the problem we untangle most often, and the conversation costs nothing.