Home › Website SEO › Schema Markup
WEBSITE SEO / SCHEMA MARKUP
Schema Markup: Complete Guide to Structured Data & JSON-LD
Schema Markup is structured information added to a webpage to help search engines understand its content, entities, relationships and context. Learn how Schema.org, JSON-LD, validation and Google Search features actually fit together.
With working examples, honest limits and no promises about rich results.
- Schema.org vocabulary versus Google's supported features
- JSON-LD anatomy, common types and entity relationships
- Validation, duplicate markup and troubleshooting
Eligibility is not display. Valid markup qualifies a page; it does not oblige any search engine to show anything.
THE BASICS
What Is Schema Markup?
Schema Markup is structured data that describes the content and entities on a webpage using a standardised vocabulary such as Schema.org.
A page of HTML tells a browser how to display things. It doesn’t say that this string is a price, that one is an author’s name, or that the block underneath is a set of opening hours. Structured data adds that layer of meaning in a form machines can read reliably rather than infer.
Three terms get used interchangeably and shouldn’t be. Structured data is the general concept of describing content in a machine-readable format. Schema.org is a specific vocabulary — a shared set of types and properties maintained collaboratively, including by major search engines. Schema Markup is what you actually add to a page using that vocabulary.
And the claim worth correcting immediately: schema does not make Google rank your website higher. It helps search engines understand a page, which can make it eligible for certain enhanced search appearances. Eligibility is not appearance, and appearance is not ranking. Those are three separate things, and conflating them is the source of most disappointment with structured data.
Schema Markup
What you add to a page — the actual markup describing your content.
Structured Data
The broader concept of machine-readable content description, in any vocabulary or format.
Schema.org
The vocabulary: a shared set of types and properties for describing things.
THE KEY DISTINCTION
Schema.org Vocabulary vs Google Search Features
This is the single most useful thing to understand about structured data, and the thing most guides skip.
Schema.org has hundreds of types. Google supports a much smaller list of structured data features — specific search appearances with their own required and recommended properties. Marking up a page with a valid Schema.org type that Google doesn’t support as a search feature produces perfectly valid structured data and no change whatsoever in search.
That’s not a reason to avoid unsupported types. Describing your content accurately has value for any system reading it. But it does mean you should know which category you’re in before expecting a visible result — and Google’s own documentation is where to check, since the supported list changes over time.
Worth stating plainly: valid structured data can make a page eligible for certain supported search features, but Google does not guarantee that those features will appear in search results. Eligibility depends on the markup; display depends on the query, the page and the search engine’s own judgement.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"@id": "https://example.com/guides/structured-data/#article",
"headline": "A Practical Guide to Structured Data",
"description": "How structured data describes page content for search engines.",
"image": "https://example.com/images/guide-cover.jpg",
"datePublished": "2026-02-14T09:00:00+05:30",
"dateModified": "2026-03-02T11:30:00+05:30",
"author": {
"@type": "Person",
"name": "Example Author",
"url": "https://example.com/authors/example-author/"
},
"publisher": {
"@type": "Organization",
"name": "Example Publisher",
"logo": {
"@type": "ImageObject",
"url": "https://example.com/images/logo.png"
}
},
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://example.com/guides/structured-data/"
}
}
</script>
<!-- All values above are illustrative examples. -->
<!-- Replace them with information genuinely on your page. -->JSON-LD
What Is JSON-LD?
JSON-LD stands for JavaScript Object Notation for Linked Data. It’s JSON with conventions for describing how data relates to a shared vocabulary — which is exactly what structured data needs.
It sits in a <script type="application/ld+json"> block, usually in the head or at the end of the body. The practical advantage over the alternatives is separation: the markup is one self-contained block rather than attributes scattered through your HTML. That makes it easier to write, easier to read, easier to generate programmatically and far easier to change without touching your templates.
JSON-LD is widely used and widely supported for structured data. It’s the format most SEO plugins produce and the one most documentation examples use. The other formats remain valid — this isn’t a rule, it’s a practical default.
One caution: because JSON-LD is separate from the visible HTML, it’s easy for it to drift out of sync with the page. Markup describing a price that changed last month, or an author who no longer wrote the piece, is a real problem. The separation that makes JSON-LD convenient also makes it easy to forget.
STRUCTURE
Understanding JSON-LD Structure
Nearly all structured data is built from the same handful of building blocks. Learn these and most examples become readable.
@context says which vocabulary you’re using. @type says what kind of thing you’re describing. Everything else is a property — a name and a value. Values can be plain text, numbers, URLs, or nested objects with their own @type, which is how an Article carries an author who is a Person who has their own properties.
@id is the one people skip and shouldn’t. It gives an entity a stable identifier so separate blocks of markup can reference the same thing rather than describing it twice. Without it, an Organization mentioned in three places is three unrelated organisations as far as a parser is concerned. With it, they’re one entity described once and referenced elsewhere.
sameAs points at authoritative URLs for the same entity elsewhere — official profiles, reference entries. It’s a disambiguation signal, not a link-building technique.
An important constraint: properties belong to types. Not every property works on every type, and inventing combinations produces markup that validates as JSON but means nothing. Check what a type actually accepts.
@contextDeclares the vocabulary being used, almost always https://schema.org@typeWhat kind of thing this is — Article, Product, Organization, LocalBusiness@idA unique identifier, letting other markup reference this same entitynameThe name of the thing being describedheadlineThe title of an article or similar contentdescriptionA short summary of the itemurlThe canonical address of the itemimageAn image representing the item, as a URL or ImageObjectauthorWho created the content — typically a Person or OrganizationpublisherThe organisation publishing it, usually with a logodatePublishedWhen it was first published, in ISO 8601 formatdateModifiedWhen it was last meaningfully updatedmainEntityThe primary thing a page is aboutmainEntityOfPageThe page this item is the main subject ofaboutA subject the item concerns, without being the item itselfsameAsAuthoritative URLs referring to the same entity elsewhereisPartOf / hasPartStructural relationships between itemsoffersPricing and availability, as an Offer objectreviewAn individual review of the itemaggregateRatingA summary of multiple ratings, where genuine ones existSCHEMA TYPES
Common Schema Types
These are Schema.org types. Which of them correspond to a Google Search feature — and what each feature requires — is a separate question worth checking in Google’s current documentation, since the supported list changes.
Article
For articles, blog posts and news content. Variants include NewsArticle and BlogPosting. Key properties: headline, image, author, publisher, datePublished, dateModified.
BreadcrumbList
Describes the position of a page within a site hierarchy. One of the more reliably useful types, and straightforward to implement correctly.
Organization
Describes a company or organisation: name, logo, URL, contact points and sameAs references. Helps search engines identify who publishes a site.
LocalBusiness
A subtype of Organization for businesses with a physical presence. Adds address, telephone, opening hours and geo coordinates.
Product
Describes a product: name, image, description, brand, SKU, and an offers object carrying price, currency and availability.
Review & AggregateRating
Describes reviews and rating summaries. Subject to the strictest guidelines of any structured data, for obvious reasons.
Event
Describes events with dates, locations and ticketing information. Requires accurate, current details to be useful.
Recipe
Describes recipes with ingredients, instructions, cooking times and nutrition where available.
SoftwareApplication
Describes software: name, operating system, application category, and offers where the software is sold.
VideoObject
Describes video content: name, description, thumbnail, upload date, duration and content or embed URL.
ProfilePage
Describes a page about a person or organisation, with mainEntity identifying whose profile it is.
QAPage
For pages where users ask and answer questions. Not the same as a page with an FAQ section.
Course
Describes educational courses, with provider and course details.
Dataset
Describes datasets, used mainly in research and open data contexts.
WebPage & WebSite
General types describing a page and a site, often used as the structural backbone that other entities attach to.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Home",
"item": "https://example.com/"
},
{
"@type": "ListItem",
"position": 2,
"name": "Website SEO",
"item": "https://example.com/website-seo/"
},
{
"@type": "ListItem",
"position": 3,
"name": "Schema Markup"
}
]
}
</script>
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example Organisation",
"url": "https://example.com/",
"logo": {
"@type": "ImageObject",
"url": "https://example.com/images/logo.png",
"width": 512,
"height": 512
},
"sameAs": [
"https://example.com/profiles/official",
"https://example.com/profiles/directory"
]
}
</script>
<!-- Illustrative values. Use real details from your own site. -->CONTENT & IDENTITY
Article, Breadcrumb and Organization Schema
Article schema describes editorial content. NewsArticle and BlogPosting are more specific variants. The properties that matter are headline, image, author, publisher, datePublished and dateModified.
Two honest points. dateModified should reflect a genuine content update — changing it without changing anything is the kind of markup-content mismatch guidelines exist to prevent. And Article schema does not produce a Top Stories placement; that depends on entirely separate factors.
BreadcrumbList describes where a page sits in the site hierarchy. It’s one of the more consistently useful types: simple to implement, hard to get wrong, and it helps search engines understand structure. The final item conventionally omits item, since it’s the current page. It should match your visible breadcrumb — describing a hierarchy that doesn’t exist on the page is exactly the mismatch to avoid. See our technical SEO guide on site architecture.
Organization schema identifies who publishes a site: name, logo, URL, and sameAs pointing at authoritative profiles. It helps search engines connect a site to an entity they may know about elsewhere. It does not produce a Knowledge Panel — those depend on what search engines independently know about an organisation, not on what you tell them about yourself.
BUSINESS & COMMERCE
LocalBusiness, Product and Review Markup
LocalBusiness is a subtype of Organization for businesses with a physical presence. It carries name, address, telephone, URL, opening hours and geo coordinates, and has many subtypes — use the most specific one that genuinely fits.
The requirement here is accuracy. The details must match what’s on the page and what’s true of the business. Inconsistent business information across your site, your markup and your business listings undermines exactly the confidence structured data is meant to build. More in our local SEO guide.
Product schema describes items for sale: name, image, description, brand, SKU, and an offers object with price, currency and availability. Price and availability must reflect the current page — stale pricing in markup is a real problem, not a cosmetic one. Google distinguishes product snippets from merchant listing experiences, which have different requirements; check current documentation for which applies.
Review and AggregateRating carry the strictest guidelines of any structured data, and deserve a direct warning. Never fabricate reviews or ratings. Never copy ratings from another site. Never mark up reviews that aren’t visible on the page. Never use review markup for content that doesn’t genuinely contain reviews. And be careful with self-serving review markup — reviews you write about your own business, in markup on your own site, fall outside what Google permits.
These aren’t arbitrary restrictions. Rating stars in search results are a trust signal, which makes fabricating them straightforwardly deceptive — and it’s the category of structured data abuse most likely to attract a manual action.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"@id": "https://example.com/products/example-item/#product",
"name": "Example Product Name",
"description": "A short description matching the visible page copy.",
"image": [
"https://example.com/images/product-1.jpg",
"https://example.com/images/product-2.jpg"
],
"sku": "EXAMPLE-SKU-001",
"brand": {
"@type": "Brand",
"name": "Example Brand"
},
"offers": {
"@type": "Offer",
"url": "https://example.com/products/example-item/",
"price": "499.00",
"priceCurrency": "INR",
"availability": "https://schema.org/InStock",
"priceValidUntil": "2026-12-31"
}
}
</script>
<!-- aggregateRating and review are deliberately omitted here. -->
<!-- Add them ONLY when genuine reviews are visible on the page. -->
<!-- Fabricated ratings are a guidelines violation, not a shortcut. -->
<!-- All values are illustrative examples. -->MORE TYPES
Q&A, Software, Video and Profile Markup
FAQ Content and QAPage
These are not interchangeable. QAPage describes a page where users ask questions and others answer — a forum thread, a community Q&A. A page with an FAQ section written by the site owner is a different thing. Which structured data features Google supports for either, and for which sites, has changed over time, so check current documentation rather than older guides.
SoftwareApplication
Describes software: name, operatingSystem, applicationCategory, and offers where it's sold. Ratings only where genuine reviews exist on the page. Useful for app listing and software product pages.
VideoObject
Describes video content with name, description, thumbnailUrl, uploadDate, duration in ISO 8601 format, and contentUrl or embedUrl. Useful when video is a meaningful part of a page rather than decoration.
ProfilePage
Describes a page about a person or organisation, with mainEntity identifying whose profile it is. Helps search engines understand author and creator pages, and connects them to content those people produced.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "VideoObject",
"name": "Example Tutorial Video",
"description": "A description matching the video content on the page.",
"thumbnailUrl": "https://example.com/images/video-thumb.jpg",
"uploadDate": "2026-01-20T10:00:00+05:30",
"duration": "PT8M42S",
"contentUrl": "https://example.com/videos/example.mp4",
"embedUrl": "https://example.com/embed/example"
}
</script>
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "ProfilePage",
"mainEntity": {
"@type": "Person",
"@id": "https://example.com/authors/example-author/#person",
"name": "Example Author",
"jobTitle": "Example Job Title",
"url": "https://example.com/authors/example-author/",
"sameAs": [
"https://example.com/profiles/author-profile"
]
}
}
</script>
<!-- duration uses ISO 8601: PT8M42S is 8 minutes 42 seconds. -->
<!-- All values are illustrative examples. -->└── WebSite
└── WebPage
└── Article
├── author → Person
├── publisher → Organization
└── image → ImageObject
Product
├── brand → Brand
├── offers → Offer
│ ├── price
│ ├── priceCurrency
│ └── availability
├── review → Review
└── aggregateRating → AggregateRating
Entities nest and reference each other. An Article has an author who is a Person; a Product has offers which are Offer objects. Using @id consistently means the same Organization referenced from several places is understood as one entity rather than several.
FORMATS & SEO
Markup Formats and What Schema Actually Does for SEO
Three formats carry structured data. JSON-LD puts it in a separate script block. Microdata and RDFa annotate your existing HTML with attributes. All three are valid; JSON-LD is the most widely used and the easiest to maintain, which is why most tooling produces it. No format is mandatory.
On the SEO question, the honest answer has four steps. Structured data improves machine-readable understanding of your page. That can create eligibility for supported search features. Whether a feature appears is Google’s decision, based on the query and the page. And whether any of that produces SEO impact depends on relevance, content quality, competition and everything else.
Schema is not a ranking factor you can turn up. Adding it to a page that shouldn’t rank will not make it rank. What it can do is help a page that already deserves to rank present itself more usefully, and help search engines understand entities and relationships they’d otherwise have to guess at. That’s worth doing — it’s just not the lever people are often sold.
See our on-page SEO guide for the content side of this, and Core Web Vitals for performance.
VALIDATION
Rich Results, Testing and Search Console
Rich results are enhanced search appearances showing more than a standard title, URL and description — breadcrumb trails, review stars, product details, video thumbnails. Structured data can make a page eligible for supported ones.
Never assume the equation is “add schema, get rich snippets”. Valid markup creates eligibility. Display remains Google’s decision, varies by query and device, and can change without your markup changing at all.
Two validators exist and they answer different questions. The Schema.org Validator checks whether your markup uses the vocabulary correctly. The Rich Results Test checks whether Google can use it for a supported search feature. Markup can pass the first and report nothing in the second — which usually means it’s valid structured data for a type Google doesn’t support as a feature, not that something is broken.
Search Console reports on supported structured data types across your site: which items are valid, which have errors or warnings, which URLs are affected, and how that changes over time. It works from pages Google has actually crawled, so newly added markup takes time to appear. Which reports exist depends on what’s on your site and what Google currently supports.
Errors and warnings are not the same. Errors usually mean a required property is missing or invalid, which can prevent eligibility. Warnings usually flag recommended properties that would improve the markup. Not every warning needs fixing before you ship — read what each one actually says.
Illustrative only. Whether any enhanced appearance is shown is decided by the search engine, not by your markup.
# In the browser, on the live page:
# View source, then search for: application/ld+json
# Every match is a separate block of structured data.
# In the browser console — list every JSON-LD block:
Array.from(
document.querySelectorAll('script[type="application/ld+json"]')
).map(s => JSON.parse(s.textContent));
# Count them. More than you expected means something
# else is generating markup too.
# Then check for conflicts:
# Two Organization blocks with different names?
# Two Product blocks with different prices?
# An @id reused for different entities?
# Fix by disabling one source, not by adding a third.IMPLEMENTATION
WordPress, Elementor and WooCommerce
On WordPress, schema usually comes from an SEO plugin, and often from more than one place at once. Themes generate markup. WooCommerce adds Product data. Dedicated schema plugins add their own. Custom code adds more.
This makes checking what already exists the first step, before adding anything. The most common structured data problem on WordPress sites isn’t missing markup — it’s three systems each outputting their own Organization block with slightly different details, or two Product blocks disagreeing about price.
Duplicate and conflicting markup creates genuine ambiguity. A parser encountering two different answers to the same question has no reliable way to choose. The fix is almost always disabling one source rather than adding a fourth to override the others.
For Elementor specifically: Elementor builds the page content and layout; it isn’t generally where structured data comes from. Your SEO plugin usually produces it, drawing on the post data rather than the builder’s output. Two practical consequences — dynamic content built in Elementor may not automatically appear in markup, and you should always validate the rendered page rather than reasoning about what you think should be there.
For WooCommerce, Product markup is usually generated already. Adding a second Product block manually is the classic way to create a conflict. Check first, then extend what exists if something is genuinely missing.
TROUBLESHOOTING
Common Errors, Mistakes and Myths
Invalid JSON
A trailing comma, unescaped quote or missing brace. Nothing parses. Check syntax before anything else.
Missing Required Property
A supported feature requires specific properties. Without them, no eligibility.
Wrong Schema Type
Article markup on a product page, or a type that doesn't match what the page is.
Wrong Property Type
A string where an object is expected, or a number where a URL belongs.
Incorrect Nesting
Properties placed at the wrong level, so relationships don't hold.
Invalid URLs
Relative URLs, broken links or placeholder addresses left in production.
Bad Date Format
Dates that aren't valid ISO 8601, or times without offsets.
Missing or Inaccessible Image
An image property pointing at something that doesn't load.
Incorrect @id
The same identifier reused for different entities, or inconsistent across blocks.
Markup Not Matching Content
Describing things not present on the page — the most consequential error.
Fabricated Reviews
Ratings that don't exist. A guidelines violation, not a technique.
Duplicate Schema
Several systems each outputting their own version.
Conflicting Schema
Two blocks giving different answers about the same entity.
Outdated Markup
Prices, dates or details that changed on the page but not in the markup.
Copying Another Site's Markup
Someone else's URLs and details left in your JSON-LD.
Schema myths worth retiring
“Schema improves rankings”
It helps search engines understand content and can create eligibility for features. It is not a ranking lever.
“Every type gives a rich result”
Google supports a specific list of features. Valid markup for an unsupported type changes nothing visible.
“Warnings mean it's broken”
Warnings usually flag recommended properties. Errors are the ones that block eligibility.
“More schema is better”
Accurate, relevant markup beats volume. Irrelevant types add risk without benefit.
“Adding it twice helps”
Duplicate markup creates ambiguity and conflicts, not emphasis.
“Valid markup guarantees display”
Eligibility and appearance are separate. Google decides what to show.
GUIDELINES
Structured Data Guidelines and Page Types
The guidelines come down to one principle: markup must accurately describe content that is actually on the page. Almost every rule follows from it.
Mark up what’s visible and genuine. Don’t describe content that isn’t there. Don’t fabricate reviews or ratings. Don’t use markup to mislead about what a page contains. Don’t apply types that don’t fit. Keep markup synchronised when the page changes. Validate before deploying and monitor afterwards.
These aren’t suggestions. Structured data that violates guidelines can result in a manual action against the affected markup, removing rich result eligibility until it’s fixed and reviewed. Fabricated reviews are the most common cause — and the least defensible.
Choosing the right type matters more than choosing many. A page should be described by what it actually is. Forcing Product markup onto a category page or Article markup onto a service page produces markup that is either invalid or misleading, and neither helps.
Homepage
Usually Organization or LocalBusiness, plus WebSite. It is not the place for Article or Product markup.
About Page
Organization details, or AboutPage with the organisation as mainEntity.
Service Page
Service or Organization markup. Not Product unless something is genuinely being sold there.
Blog Article
Article, BlogPosting or NewsArticle with author, publisher and accurate dates.
Product Page
Product with offers. Ratings only where genuine reviews are visible on the page.
Category Page
Often CollectionPage or ItemList. Not Product — a category is not a product.
Local Business Page
LocalBusiness with accurate address, hours and contact details matching the visible page.
Author or Profile Page
ProfilePage with a Person as mainEntity, linked to their content.
Video Page
VideoObject alongside whatever describes the page itself.
Event Page
Event with accurate dates, location and ticketing details, kept current.
AUDIT
Schema Markup Audit Checklist
A working checklist for implementing or reviewing structured data on a page. The order matters: checking what already exists comes before adding anything.
Before you start
- Identify what the page is actually about
- Identify the primary entity
- Choose the type that genuinely fits
- Check what schema the page already outputs
- Confirm no duplicate or conflicting markup exists
Building the markup
- Include the properties the type requires
- Add recommended properties where they apply
- Confirm every value matches visible content
- Use absolute URLs throughout
- Use valid ISO 8601 dates
- Check images load and are accessible
- Confirm author and publisher details are accurate
- Confirm offers, price and availability are current
Reviews specifically
- Confirm reviews genuinely exist on the page
- Confirm ratings are real and not copied
- Confirm review markup is permitted for this content
- Never add ratings that are not visible
Validation
- Validate the JSON syntax
- Run the Schema.org Validator for vocabulary
- Run the Rich Results Test for eligibility
- Fix errors first, then read the warnings
- Test the rendered page, not a draft
After publishing
- Confirm markup appears in the live page source
- Monitor Search Console structured data reports
- Recheck after any content change
- Recheck after plugin or theme updates
- Remove markup for content no longer on the page
BEFORE YOU START [ ] Identify what the page is actually about [ ] Identify the primary entity [ ] Choose the type that genuinely fits [ ] Check what schema the page already outputs [ ] Confirm no duplicate or conflicting markup exists BUILDING THE MARKUP [ ] Include the properties the type requires [ ] Add recommended properties where they apply [ ] Confirm every value matches visible content [ ] Use absolute URLs throughout [ ] Use valid ISO 8601 dates [ ] Check images load and are accessible [ ] Confirm author and publisher details are accurate [ ] Confirm offers, price and availability are current REVIEWS SPECIFICALLY [ ] Confirm reviews genuinely exist on the page [ ] Confirm ratings are real and not copied [ ] Confirm review markup is permitted for this content [ ] Never add ratings that are not visible VALIDATION [ ] Validate the JSON syntax [ ] Run the Schema.org Validator for vocabulary [ ] Run the Rich Results Test for eligibility [ ] Fix errors first, then read the warnings [ ] Test the rendered page, not a draft AFTER PUBLISHING [ ] Confirm markup appears in the live page source [ ] Monitor Search Console structured data reports [ ] Recheck after any content change [ ] Recheck after plugin or theme updates [ ] Remove markup for content no longer on the page
FAQ
Schema Markup: Frequently Asked Questions
Short answers to the questions people ask most about structured data, JSON-LD and rich results.
NEXT TOPICS
Related Website SEO Topics
Technical SEO
Structured data sits alongside crawling, indexing and site architecture.
On-Page SEO
Markup describes content — the content itself still has to be worth describing.
Core Web Vitals
Performance affects whether people stay long enough for any of this to matter.
Image SEO
Image properties appear across many schema types and need to resolve correctly.
Local SEO
LocalBusiness markup works alongside consistent business information elsewhere.
SEO Tools
Validators, Search Console and testing tools for structured data work.
CMS
How WordPress and other platforms generate structured data by default.
Website Speed
Broader performance work across the site.
Build a Stronger Technical SEO Foundation
Explore related SEO topics including Technical SEO, On-Page SEO, Core Web Vitals, Image SEO, Local SEO and SEO Tools.