Schema Markup: A Practical Google-Aligned JSON-LD Guide

Schema markup is structured data added to a web page to describe the page and its entities in a machine-readable form. Google says structured data can provide explicit clues about page meaning and can make a page eligible for documented Search features.

The boundary is equally important: valid markup does not guarantee that Google will show a rich result, improve a ranking, or include the page in an AI Overview. Google also says its AI Search features do not require special schema or new AI-specific markup.

This guide keeps the practical JSON-LD examples while removing unsupported claims about citation rates or “AI ranking impact.”

What Google documents

Google's introduction to structured data explains that markup can help Google understand page content and can enable supported rich results.

Google's structured data general guidelines require accurate, relevant markup that represents the main visible content. The policies state that enabling a feature does not guarantee that it will appear.

For AI Overviews and AI Mode, Google's AI features guidance says:

• ordinary SEO best practices remain relevant;
• a page must be indexed and eligible to appear with a snippet;
• there are no additional technical requirements;
• no special schema or AI text file is required; and
• meeting requirements does not guarantee crawling, indexing, serving, or inclusion.

Use structured data for its documented purpose, not as a promise of AI citations.

Why use JSON-LD?

Google supports JSON-LD, Microdata, and RDFa for documented structured data features and generally recommends JSON-LD because it is easier to implement and maintain.

JSON-LD is placed in a script element:

<script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "Organization",
    "name": "Example Company",
    "url": "https://example.com"
  }
</script>

The script describes the visible page. It is not a place to hide claims, prices, ratings, or features that users cannot see.

Choose markup by page purpose

Do not choose a type because a marketing list labels it more powerful. Choose it because it accurately describes the page and because your team can keep the values current.

Feature support and eligibility rules can change. Check the current Google Search documentation for the type before implementation.

Organization JSON-LD example

Use Organization on a page that provides the official public facts about the organization.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Company",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "description": "Example Company publishes inventory software for independent retailers.",
  "sameAs": ["https://www.linkedin.com/company/example-company"],
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "customer support",
    "url": "https://example.com/support"
  }
}

Check before publishing

• The organization name matches the visible brand name.
• The logo URL is public and represents the organization.
• The description is factual and visible on the page.
• sameAs contains only official public profiles.
• Contact information is current.

Do not add awards, credentials, locations, or social profiles that cannot be verified.

Article JSON-LD example

Use Article or the appropriate documented subtype for editorial content.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to Reconcile Retail Inventory",
  "description": "A practical guide to reviewing stock records and resolving discrepancies.",
  "image": "https://example.com/images/inventory-guide.png",
  "author": {
    "@type": "Person",
    "name": "Jordan Lee",
    "url": "https://example.com/authors/jordan-lee"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example Company",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "datePublished": "2026-06-01",
  "dateModified": "2026-07-16",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/guides/reconcile-inventory"
  }
}

Check before publishing

• The headline and description match the article.
• The author is the person or organization actually responsible.
• Dates reflect real publication and material updates.
• The image and canonical page URLs resolve publicly.
• The publisher identity is consistent with the site.

Changing dateModified without reviewing the content creates misleading markup.

SoftwareApplication JSON-LD example

Use SoftwareApplication when the page visibly describes a software product.

{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "Example Inventory",
  "url": "https://example.com/inventory",
  "applicationCategory": "BusinessApplication",
  "operatingSystem": "Web",
  "description": "Inventory reconciliation software for independent retail teams.",
  "offers": {
    "@type": "Offer",
    "price": "29",
    "priceCurrency": "USD",
    "url": "https://example.com/pricing",
    "availability": "https://schema.org/InStock"
  }
}

Check before publishing

• The product name, category, and operating system are visible.
• The offer matches the current public price and currency.
• Availability uses an appropriate Schema.org value.
• The pricing URL contains the same offer details.

Do not add an aggregateRating unless genuine ratings are visible and the page meets the current feature rules.

FAQPage JSON-LD example

Use FAQ markup only when the questions and answers are visible on the page and the current Google eligibility guidance applies to the site and content.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Does the product support CSV imports?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes. The import page accepts CSV files that use the documented inventory template."
      }
    },
    {
      "@type": "Question",
      "name": "Where can I download the template?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "The current CSV template is available from the public import documentation."
      }
    }
  ]
}

Check before publishing

• Every question and answer is visible to users.
• The marked-up answer does not add hidden marketing claims.
• The content is written or reviewed by the site, rather than copied from users.
• The page follows the current Google documentation and content policies.

Valid FAQ markup does not guarantee an expanded result or an AI citation.

BreadcrumbList JSON-LD example

Use breadcrumb markup to describe the visible navigation hierarchy.

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Guides",
      "item": "https://example.com/guides"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Inventory",
      "item": "https://example.com/guides/inventory"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Reconciliation",
      "item": "https://example.com/guides/reconcile-inventory"
    }
  ]
}

The order, labels, and URLs should match the page's real hierarchy.

Combining multiple types with @graph

A page can describe more than one related entity. Use @graph when it makes the relationships easier to maintain.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Company",
      "url": "https://example.com"
    },
    {
      "@type": "Article",
      "@id": "https://example.com/guides/reconcile-inventory#article",
      "headline": "How to Reconcile Retail Inventory",
      "publisher": {
        "@id": "https://example.com/#organization"
      },
      "mainEntityOfPage": "https://example.com/guides/reconcile-inventory"
    }
  ]
}

Use stable @id values and avoid defining the same organization with conflicting facts in separate blocks.

Common implementation mistakes

Markup does not match visible content

The most important quality rule is that structured data represents the main visible content. Hidden prices, invented reviews, and unsupported claims can make a page ineligible for a feature and can lead to a manual action.

The wrong type is used

Do not mark a product page as an article or add FAQ markup to a page without visible questions and answers. Start from the page purpose, then consult the current feature documentation.

Required properties are missing

Google's feature documentation identifies required and recommended properties. A Schema.org-valid object may still be ineligible for a Google feature if feature-specific requirements are missing.

Duplicate blocks conflict

Plugins, themes, and custom code can each emit markup. Inspect the rendered page and reconcile duplicate names, URLs, authors, prices, and identifiers.

Dates or offers are stale

Structured data can remain cached in templates after visible content changes. Update markup and page content together.

JSON is invalid

Unescaped quotation marks, trailing commas, and broken nesting can invalidate a JSON-LD block. Validate the rendered page, not only the source template.

Validation workflow

1. Open the rendered page and compare every structured value with visible content.
2. Run Google's Rich Results Test for documented Google features.
3. Run the Schema.org Validator for vocabulary and syntax checks.
4. Inspect the page in Search Console after deployment.
5. Monitor enhancement reports when the feature provides one.
6. Recheck after template, plugin, price, author, or navigation changes.

Passing a validator confirms syntax or feature eligibility checks. It does not guarantee display or ranking.

Deployment checklist

• The type accurately describes the page.
• Marked-up facts are visible.
• Required properties follow current Google documentation.
• URLs resolve and use the canonical domain.
• Dates, prices, availability, and authors are current.
• Reviews and ratings are genuine and eligible.
• Duplicate blocks do not conflict.
• The rendered page passes the relevant validator.
• An owner is responsible for future updates.

Frequently Asked Questions

Does Schema markup guarantee AI citations?

No. Google documents structured data as a way to help it understand page content and establish eligibility for supported Search features. Google does not require special schema for AI Overviews or AI Mode, and valid markup does not guarantee display, ranking, or AI citations.

Which format should I use?

Google supports JSON-LD, Microdata, and RDFa for documented structured data features and generally recommends JSON-LD because it is easier to implement and maintain.

Can I use multiple Schema types on one page?

Yes, when each type accurately represents visible content and the entities do not conflict. Separate script blocks or an @graph can both work.

Can markup contain details that are not shown to users?

No. Google's guidelines require the structured data to represent the page and prohibit markup for hidden or misleading content.

Will a valid Rich Results Test guarantee a rich result?

No. Validation can confirm required properties and syntax, but Google's policies state that eligibility does not guarantee display.

How should I prioritize implementation?

Start with pages where a documented type clearly matches the visible content and where your team can maintain the data. Fix incorrect or conflicting markup before adding more types.

References

• Google Search Central — AI features and your website
• Google Search Central — Introduction to structured data
• Google Search Central — Structured data general guidelines
• Schema.org — vocabulary reference

Check the rendered page

Use the Skillaeo anonymous audit as one limited Perplexity observation, not proof that markup caused a citation. For structured data, compare the rendered page with Google's documentation and validation tools.