Schema Frameworks For Google Rich Results

From Manual To Conditional Logic

Most structured data starts as JSON-LD written by hand for one page. That works for a handful of pages and breaks down at scale: every new page is another snippet to write, and every content change is another snippet to update.

Templates solve scale. The CMS fills one JSON-LD template with fields from each content object, so a single template covers every event, product or person. But content objects are rarely complete. When a field is missing, the template still prints the property, now empty, and a variable printed without quotes can break the JSON so that nothing in the block parses.

A conditional-logic framework builds the markup from the data that actually exists. Each property, and each nested object, is added only when the content object has the field that feeds it, and the whole item is skipped when Google's required properties are missing.

A Worked Example

One Person content model, two content objects. Jane Doe has a name only. John Doe has a profile URL and a job with a title and a company.

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "{{ person.name }}",
  "url": "{{ person.url }}",
  "jobTitle": "{{ person.job.title }}",
  "worksFor": {
    "@type": "Organization",
    "name": "{{ person.job.company }}"
  }
}

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Jane Doe",
  "url": "",
  "jobTitle": "",
  "worksFor": {
    "@type": "Organization",
    "name": ""
  }
}

function buildPersonSchema(person) {
  if (!person.name) return null;

  const schema = {
    "@context": "https://schema.org",
    "@type": "Person",
    "name": person.name
  };

  if (person.url) schema.url = person.url;

  if (person.job) {
    const worksFor = { "@type": "Organization" };
    if (person.job.company) worksFor.name = person.job.company;
    if (person.job.companyUrl) worksFor.url = person.job.companyUrl;
    if (person.job.title) schema.jobTitle = person.job.title;
    if (worksFor.name) schema.worksFor = worksFor;
  }

  return schema;
}

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Jane Doe"
}

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "John Doe",
  "url": "https://www.example.com/john-doe",
  "jobTitle": "Head of SEO",
  "worksFor": {
    "@type": "Organization",
    "name": "Example Co",
    "url": "https://www.example.com"
  }
}

The template gives Jane three empty properties (url, jobTitle and the nested company name), which validators flag and search engines ignore at best. The conditional version gives her a clean Person with only her name, and gives John a url, a jobTitle and a nested Organization because his data supports them.

How Every Framework Here Is Built

• Starts from Google's current documentation for that rich result: required properties, recommended properties, either-or rules, value formats and limits.
• Checks the page first: no markup on noindex pages, on pages canonicalized elsewhere, or for content that is not visible.
• Returns nothing when a property Google requires is missing, instead of shipping an item that cannot earn the rich result.
• Adds recommended properties and nested objects only when the data exists, then strips any empty values.
• Enforces the feature's own rules in code, such as breadcrumb positions, prices above zero, and ISO 8601 dates and durations.
• Ships in JavaScript and Python with identical output, and every example output on these pages validates with zero errors.

Features Google has retired, such as HowTo and the sitelinks search box, stay in the library with a dated notice. No rich result appears for them any more, but the markup can still help search engines and AI assistants understand the page.

Page Types

A real page uses several of these frameworks at once. The page types show the whole connected graph for the most common pages, each from one builder, linked by @id and validated. See how the page types fit together.