Skip to content

7 November 2026 · Sirajia Sol

Schema Markup for SEO: A Practical Guide

Cover image with the title Schema Markup for SEO: A Practical Guide on a dark Sirajia Sol background

Schema markup for SEO is how you describe a page in a format search engines can parse without guessing. Instead of leaving Google to infer that a block of text is an address, a product price or a frequently asked question, you label those facts with structured data, most often as JSON-LD. Done well, that markup can make pages eligible for rich results. Done badly, it creates errors, mismatches and, in the worst cases, spam issues.

This guide covers what schema is and is not, how to choose the right types, how to add JSON-LD, how to validate and monitor it, and the mistakes that waste the most time. It is written for business and marketing sites that need clear, maintainable markup, not for inventing ranking claims or stuffing every possible type onto every page.

What schema markup is (and is not)

Schema.org is a shared vocabulary of types and properties that describe things on the web: organisations, products, articles, events, places and more. Search engines including Google use that vocabulary as structured data. Google's introduction to structured data explains that you add markup to a page so Google can understand the content and, when eligible, show it with enhanced features in search.

Important limits:

  • Eligibility is not a guarantee. Valid, matching markup can make a page eligible for a rich result. Google still decides whether to show one.
  • Schema is not a ranking factor you can buy. Google does not promise higher positions because you added JSON-LD. Markup supports understanding and appearance; content quality, relevance and technical health still do the heavy lifting.
  • Markup must match the visible page. Google's structured data general guidelines and spam policies forbid marking up content users cannot see, misleading types or deceptive rich-result tactics.
  • Not every Schema.org type is a Google rich result. Schema.org is broad. Google documents a smaller set of features it supports. Prefer Google's feature docs when your goal is Search appearance.

Schema sits alongside the rest of on-page and technical work. Our on-page SEO checklist covers structured data as one page-level item; a technical SEO audit is where you validate templates site-wide.

JSON-LD: the format to prefer

Google supports three formats: JSON-LD, Microdata and RDFa. For almost every business site, JSON-LD is the right choice:

  • It lives in a <script type="application/ld+json"> block, usually in the page head or near the end of the body.
  • It stays separate from the HTML you style and edit day to day.
  • Templates can generate it from the same data that powers the visible page, which reduces drift.
  • Google's documentation examples are written in JSON-LD, which makes copying and adapting safer.

A minimal Organisation example looks like this in structure (properties must still match your real site):

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Company",
  "url": "https://www.example.com/",
  "logo": "https://www.example.com/logo.png"
}

Keep one clear graph per page when you can. Multiple blocks are allowed, but overlapping or contradictory descriptions of the same entity cause more support tickets than they solve.

How to choose the right schema types

Start from the page's job, not from a wishlist of rich results.

  1. What is this page primarily about? A blog guide, a location page, a product, a service overview or the company homepage each map to different types.
  2. What does the visitor see? Only mark up facts that appear on the page or that are standard site-wide identity details (name, logo, sameAs profiles) maintained consistently.
  3. Does Google document a feature for that type? Check the specific Search Gallery entry before you invest in a type for rich-result reasons.
  4. Can you maintain it? Markup that goes stale after a redesign or a price change is worse than no markup.
Page type Schema types that usually fit Google feature docs to read
Homepage / About Organization (and WebSite where useful) Organization
Blog or guide Article or BlogPosting, often with BreadcrumbList Article
Location / store LocalBusiness (or a more specific subtype) Local business
Product detail Product with offer, availability and review rules followed carefully Product
FAQ section that users can read FAQPage FAQ
How-to content with clear steps HowTo when the format truly matches HowTo
Any deep page in a hierarchy BreadcrumbList Breadcrumb
Service landing page Service and/or Organization / LocalBusiness as appropriate Use Schema.org Service thoughtfully; pair with Google-supported types where you need rich results
SaaS product page Software application markup where it fits Software app

For multi-location brands, each location page should describe that location only. That pattern is covered in more depth in local SEO for multi-location businesses. For SaaS sites, software application schema is one option among several; see our SaaS SEO strategy for the wider plan.

Core schema types for business sites

Organization

Use Organization on the homepage or about page to define the brand: name, URL, logo, contact points and sameAs links to official profiles. Keep those details identical to what appears in the footer, contact page and business listings. Organisation markup is foundational identity data, not a substitute for a thin about page.

LocalBusiness

LocalBusiness (or subtypes such as Restaurant, Dentist or Store) belongs on pages that represent a real place customers can visit or a genuine service-area business. Include name, address, geo coordinates, telephone, opening hours and the location page URL. Generate it from the same master location record you use for Google Business Profile and directories so the three never disagree.

Article and BlogPosting

Guides and news-style posts should use Article or BlogPosting with headline, image, datePublished, dateModified and author. Author should be a real person or organisation that matches what readers see on the page. Dates must stay in sync with the visible publish and update labels.

FAQPage

FAQPage is only for pages that present a visible Q&A. Each question and answer in the markup must appear on the page. Do not use FAQ schema for advertising copy disguised as questions, or for accordion content that is not actually FAQ content. When Google restricts FAQ rich results for certain site types, eligibility rules still matter even if your markup validates.

Product

Product markup can power rich product results, but it has strict expectations around name, image, price, currency, availability and review policies. Mark up only products users can see and buy (or inquire about) on that URL. Fake reviews, hidden prices or offer details that do not match the page violate Google's guidelines.

Breadcrumbs help searchers and search engines understand hierarchy. Mark up the same trail users see in the breadcrumb UI. Each item needs a name and an item URL that resolves to a real page.

Service

Many B2B sites describe services rather than products. Schema.org Service can describe what you offer and who provides it. Pair it with strong Organisation or LocalBusiness identity, and do not invent rich-result expectations Google has not documented for that type.

How to add schema markup to a page

A practical rollout looks like this:

  1. Inventory templates, not individual URLs. Homepage, blog post, location, product, service and contact templates cover most sites.
  2. Decide the primary type per template using the table above. Add secondary types only when they describe something distinct on the same page (for example Article plus BreadcrumbList).
  3. Bind JSON-LD to the same fields the CMS renders. Title, dates, price, address and FAQ answers should come from one source.
  4. Output one JSON-LD script per logical graph in the template. Escape user-generated text so broken quotes cannot invalidate the JSON.
  5. Ship to staging first. Validate there before production.
  6. Document owners. Someone must update markup when the template or content model changes.

For teams that ship with developers, this work sits cleanly next to web development template work and SEO QA. Avoid pasting one-off JSON into a page builder on every URL unless you have no template option; one-off markup is the first thing that drifts.

Validate before you celebrate

Validation is not optional.

  • Use Google's Rich Results Test on the final URL or a public HTML sample. It shows which Google features the page is eligible for and which errors block them.
  • Use the Schema Markup Validator when you need broader Schema.org checking beyond Google's feature set.
  • Fix errors before launch. Treat warnings as a backlog, but do not ignore warnings that mean missing recommended properties on commercial templates.
  • Re-test after A/B tests, tag managers or consent banners that might alter the DOM or inject conflicting markup.

A green Rich Results Test means the tested URL is eligible based on that snapshot. It does not mean every similar URL in production is healthy, and it does not mean a rich result will appear tomorrow.

Monitor structured data in Search Console

After launch, watch Google Search Console:

  • Open the Enhancements (or equivalent rich-result) reports for the types you implemented.
  • Separate valid, valid with warnings and error URL counts.
  • When errors spike after a release, compare the failing template to the last good version and re-validate a sample of URLs.
  • Use URL Inspection on priority pages when a feature disappears or never appears despite valid markup.

Structured data monitoring belongs in the same rhythm as the rest of your technical SEO checks: after major releases, after migrations and on a monthly glance for active sites. Our technical SEO audit checklist includes structured data as a standard audit item for that reason.

Common schema markup mistakes

  • Marking up content users cannot see. Hidden FAQs, fake star ratings and prices that only exist in JSON-LD break Google's guidelines.
  • Using the wrong type to chase a rich result. Calling a marketing page a Product or HowTo when it is neither helps nobody.
  • Contradicting the visible page. Different phone numbers, dates, prices or business names in HTML and JSON-LD undermine trust and create errors.
  • Copy-pasting examples without adapting them. Placeholder names, example.com URLs and leftover fields from tutorials show up in production more often than teams expect.
  • Stacking every type on every page. More markup is not more SEO. Irrelevant types add noise and maintenance cost.
  • Ignoring author and date fields on articles. Thin or anonymous Article markup is a missed clarity opportunity and can fail feature requirements.
  • Never re-validating after a redesign. New themes and headless setups frequently drop or duplicate JSON-LD.
  • Treating schema as a substitute for content. Rich-result eligibility does not fix thin pages, weak titles or unclear intent. Fix the page first, then describe it accurately.

A simple rollout checklist

Use this when you add or rebuild markup on a site:

Step Done when
Template map Every important template has a primary schema type
Field mapping JSON-LD fields come from the same source as visible content
Guidelines review Types match Google's feature docs and general structured data policies
Staging validation Rich Results Test passes on representative URLs
Production sample Priority URLs inspected after deploy
Search Console Enhancement reports watched for two weeks after launch
Ownership A named owner updates markup when templates change

How schema fits with the rest of SEO

Schema markup is one clarity layer. It works best when:

Think of JSON-LD as labelling what you already built, not as a shortcut around building it.

How Sirajia Sol helps with schema markup

At Sirajia Sol, we work with businesses in the USA and worldwide that need structured data that is accurate, maintainable and aligned with Google's guidelines. Our SEO team maps the right types to your templates, writes the field rules and validates eligibility. When markup has to ship inside your codebase, our web development team implements JSON-LD in the templates your CMS or framework already uses, so marketing and engineering stay on one source of truth.

If you want a practical schema plan for your site, contact us with your main page types and any Search Console enhancement errors you are already seeing.

Frequently asked questions

Does schema markup improve rankings?

Google does not treat schema markup as a guaranteed ranking boost. Structured data helps Google understand what a page is about and can make it eligible for rich results when the markup and content match. Better understanding and richer appearances can affect visibility and clicks, but adding schema alone does not push a page up the rankings.

What is the difference between schema markup and rich results?

Schema markup is the structured data you add to a page, usually as JSON-LD. Rich results are the enhanced search appearances that can follow when Google understands that markup and decides the page qualifies. Valid markup makes a page eligible; it does not guarantee a rich result will show.

Which schema format should I use?

Google recommends JSON-LD for structured data on web pages. You can also use Microdata or RDFa, but JSON-LD is easier to maintain in templates, keeps markup separate from the visible HTML and is the format most modern CMS and frameworks support well.

Do I need FAQ schema on every page?

No. Use FAQPage markup only when the page contains a clear list of questions and answers that users can see. Do not mark up advertising FAQs, or invent Q&A blocks only to chase rich results. Google's FAQ structured data guidelines and spam policies expect the content to match what people read on the page.

How often should I check structured data?

Validate every new template before it goes live, then re-test after redesigns, CMS updates or content changes that touch marked-up fields. In Search Console, watch the Enhancement reports for the types you use so you catch errors before they spread across hundreds of URLs.