Organization schema, field by field

A working guide to the JSON-LD block that tells a crawler what your company is called, where it lives, and which profiles belong to it.

Organization schema is a block of JSON in your HTML that states, unambiguously, what your company is called and where its official presence lives. It is the closest thing the web has to an ID card, and roughly half the sites we scan do not have one.

This is what to put in it, what to leave out, and where it goes.

The block itself

Drop this in the <head> or anywhere in the <body> of your homepage. JSON-LD does not have to be near the content it describes.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://northstar.example/#organization",
  "name": "Northstar Analytics",
  "legalName": "Northstar Analytics, Inc.",
  "url": "https://northstar.example",
  "logo": "https://northstar.example/logo.png",
  "description": "Product analytics for B2B SaaS teams, built around activation and retention.",
  "foundingDate": "2021",
  "sameAs": [
    "https://www.linkedin.com/company/northstar-analytics",
    "https://x.com/northstarhq",
    "https://github.com/northstar",
    "https://www.crunchbase.com/organization/northstar-analytics"
  ],
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "customer support",
    "email": "support@northstar.example"
  }
}
</script>

That is a complete, valid, useful block. Everything below is commentary on the fields.

Field by field

name — the brand name people use, not the legal entity. "Northstar Analytics", not "Northstar Analytics, Inc." This is the string that has to match your title tag, your H1 and your profiles. Get this one wrong and nothing else in the block saves you.

legalName — the incorporated name, if it differs. Having a separate field for it is exactly why you should not stuff ", Inc." into name.

url — the canonical homepage, in the form you actually redirect to. If you serve https://www. then write https://www.. A mismatch here against your real canonical is a small but real inconsistency.

logo — an absolute URL to a real image file, not a CSS background or an inline SVG. Square or near-square, at least 112×112, on a background that survives being placed on white. Google's guidance is stricter than schema.org's, and it is the stricter one worth meeting.

description — one or two sentences. This is the highest-value string in the whole block, because it is the sentence a machine is most likely to reuse verbatim when asked what you do. Write it as a definition, not a pitch. "Product analytics for B2B SaaS teams" beats "the leading platform empowering modern teams."

sameAs — an array of URLs to profiles you control. This is the connective tissue of your entity and it gets its own post.

@id — a stable identifier for this node. Useful once you have more than one schema block on the site, because other blocks can reference {"@id": "...#organization"} instead of redefining the company. Optional, cheap, worth adding.

contactPoint — useful, low-effort, and a signal of a real operating business. Use email or a telephone you actually answer.

Fields to add if they are true

foundingDate, numberOfEmployees, address (a full PostalAddress), areaServed, parentOrganization and brand are all worth adding when they are accurate. Two rules: never invent a value to fill a field, and never add aggregateRating for your own organisation from testimonials you collected yourself — that is a policy violation that can cost you rich results entirely.

Where it goes, and how many

One Organization block, on the homepage, is the baseline. Putting the same block site-wide in a shared layout is fine and common — just make sure it is genuinely identical everywhere rather than drifting per template.

If you have a physical location, you may want LocalBusiness instead. That is a real decision with a real wrong answer, and it is covered separately.

The mistakes we actually see

• Rendered by JavaScript. The block exists in the DOM and not in the served HTML. AI crawlers generally do not run JS, so to them it does not exist. More on that here.
• Invalid JSON. A trailing comma, a smart quote pasted from a doc, an unescaped quote inside a description. One character and the whole block is discarded silently. Validate it.
• @type as a bare string when it should be an array, or the reverse. Both "Organization" and ["Organization", "LocalBusiness"] are legal; a typo like "organisation" is not.
• logo pointing at a 404, usually after a redesign moved the asset.
• Copied from another site and half-updated, so sameAs still lists someone else's LinkedIn. We have seen this more than once.

Checking your work

View source — real source, curl or Ctrl+U, not the DevTools inspector, which shows you the post-JavaScript DOM. Search for application/ld+json. Paste what you find into a JSON validator first, and only then into a schema validator. Most "my schema isn't working" problems are a JSON syntax error, not a schema one.