Replace the Press Release Boilerplate With schema.org Organization Markup

The traditional three-paragraph press release boilerplate is invisible to AI search engines. Replace it with a schema.org Organization JSON-LD block — a structured entity record that engines like Google AI Overviews, Perplexity, and ChatGPT actually parse and cite. Keep the marketing prose as a short two-sentence human summary, and let the structured data carry the entity facts AI search needs.

Why the legacy boilerplate fails in AI search

Boilerplates were designed for a 1990s wire-service workflow. A human editor at the AP or Reuters desk would skim three paragraphs of marketing prose, extract the relevant facts, and rewrite them into the story. Retrieval systems do the opposite — they build entity graphs. They ingest structured facts (foundingDate, HQ, founders, products, funding stage) and discard puffery.

Phrases like "leading provider of AI-powered solutions" or "industry-leading platform trusted by Fortune 500 enterprises" carry zero entity-level signal. An AI engine reading that sentence cannot extract a single citable fact.

Worse: every release ends with the same three paragraphs. That creates duplicate content across your wire output without giving the engine any new entity differentiation. The boilerplate is dead real estate that the engine treats as dead real estate.

What a 2026 boilerplate must actually contain

A modern boilerplate carries an entity spine — verifiable facts an AI engine can cite — alongside a short human summary.

The spine:

• Legal name, foundingDate, founders, HQ location. These resolve "who are you" at the entity level.
• Verifiable identifiers. Domain, plus sameAs links to LinkedIn, Crunchbase, Wikipedia, and Wikidata. These are how AI engines disambiguate your company from another company with a similar name.
• Product and service taxonomy. Use knowsAbout or makesOffer with concrete product names — not adjective soup.
• Funding stage and last announcement date when relevant. These are the facts journalists and AI engines re-cite across stories.
• Press contact as a structured ContactPoint. Gives engines a routable path back to your newsroom.

The human summary stays short — two or three sentences a journalist can drop into a story. The structured data does the entity work.

The schema.org Organization fields that move the needle

schema.org Organization is the canonical vocabulary for company entity data and is jointly supported by Google, Microsoft, Yahoo, and Yandex. Google explicitly uses the logo, sameAs, contactPoint, and address fields to populate knowledge panels and resolve brand entities in search.

Field-to-use-case map:

Field	What it unlocks
@type, name, url, logo	Mandatory baseline — without these the record is invalid
description, foundingDate, address	Knowledge panel population
sameAs (array)	Entity disambiguation across LinkedIn, Crunchbase, Wikipedia, Wikidata
founder, numberOfEmployees, knowsAbout	High-leverage entity context for AI citations
parentOrganization, subOrganization, brand	Corporate graph stitching across releases
contactPoint (with contactType: "press")	Structured route to your newsroom

sameAs is the single most important field. It is the connective tissue an AI engine uses to merge your release with your LinkedIn page, your Crunchbase profile, and your Wikipedia entry. Without it the engine sees a name and a URL — not an entity.

A copy-pasteable snippet, built from Stripe's public-facing facts:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Stripe, Inc.",
  "url": "https://stripe.com",
  "logo": "https://stripe.com/img/v3/home/twitter.png",
  "description": "Financial infrastructure for the internet.",
  "foundingDate": "2010",
  "founder": [
    {"@type": "Person", "name": "Patrick Collison"},
    {"@type": "Person", "name": "John Collison"}
  ],
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "354 Oyster Point Boulevard",
    "addressLocality": "South San Francisco",
    "addressRegion": "CA",
    "postalCode": "94080",
    "addressCountry": "US"
  },
  "sameAs": [
    "https://www.linkedin.com/company/stripe",
    "https://www.crunchbase.com/organization/stripe",
    "https://en.wikipedia.org/wiki/Stripe,_Inc.",
    "https://www.wikidata.org/wiki/Q24255410"
  ],
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "press",
    "email": "[email protected]"
  }
}

The same shape works for any company.

Before and after

Before — the legacy three-paragraph boilerplate:

About Acme Corp: Acme Corp is a leading provider of innovative cloud-native solutions trusted by Fortune 500 enterprises across the globe. Our industry-leading platform combines best-in-class AI with seamless integration to deliver unparalleled customer outcomes.

Founded by visionary entrepreneurs, Acme Corp is committed to redefining the future of enterprise software. Our world-class team operates across multiple continents to bring digital transformation to every customer we serve.

For more information, visit www.acme.example.

Three paragraphs. Zero structured facts. An AI engine reads this and extracts nothing.

After — the same company, expressed as Organization JSON-LD plus a two-sentence human summary:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Acme Corp",
  "url": "https://www.acme.example",
  "foundingDate": "2018",
  "founder": [{"@type": "Person", "name": "Jane Doe"}],
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Austin",
    "addressRegion": "TX",
    "addressCountry": "US"
  },
  "numberOfEmployees": {"@type": "QuantitativeValue", "value": 240},
  "knowsAbout": ["cloud-native infrastructure", "Kubernetes operators", "observability"],
  "sameAs": [
    "https://www.linkedin.com/company/acme-corp",
    "https://www.crunchbase.com/organization/acme-corp"
  ]
}

Acme Corp builds cloud-native infrastructure tools for Kubernetes operators. Founded in 2018, the company is headquartered in Austin, TX with a team of 240.

Two sentences for the human reader. A complete entity record for the machine reader.

Validating before you ship: the two tools that matter

Run every release through two validators:

• Google Rich Results Test — the official validator for whether your structured data qualifies for Google's enhanced search appearances. Narrower than the full schema.org spec; determines knowledge panel eligibility.
• schema.org Markup Validator — operated by schema.org itself, checks JSON-LD against the full vocabulary and catches type errors Google's narrower validator does not flag.

Common failure modes:

• Missing @context — breaks the whole record.
• Wrong @type casing (organization instead of Organization).
• address provided as a plain string instead of a PostalAddress object.
• sameAs provided as a single string instead of an array.

A worked example. This fails:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Acme Corp",
  "address": "Austin, TX",
  "sameAs": "https://linkedin.com/company/acme"
}

The validator flags address (must be a PostalAddress object) and sameAs (must be an array). Corrected:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Acme Corp",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Austin",
    "addressRegion": "TX",
    "addressCountry": "US"
  },
  "sameAs": ["https://www.linkedin.com/company/acme"]
}

Generative-engine retrieval research from Princeton finds that content with structured data and explicit entity citations is preferentially surfaced and quoted by AI search engines. Treat structured-data errors as ship-blockers — same severity as a broken link.

Boilerplate-as-API: one source, every release

Run the boilerplate as an API. Maintain one canonical Organization JSON-LD record at a stable URL — /press/about.jsonld is a clean convention — and reference it from every release. Embed the JSON-LD inline in each release HTML and link to the canonical record. Both, for redundancy.

When the entity record changes — a funding round closes, the HQ moves, a new exec joins — update the canonical file once. Every future release inherits the corrected entity data automatically. Your release composer should attach the current canonical record at publish time, not at draft time.

Pair this with a short two-or-three-sentence human boilerplate for journalists who still skim. The human summary lives in the prose; the entity record lives in the JSON-LD. Two channels, one source of truth.

This is the release composer pattern: the boilerplate stops being three paragraphs of dead prose and becomes a structured entity record that AI engines can cite, that knowledge panels can populate, and that updates in one place. For more on newsroom architecture see related posts on the blog.