Free tool
Schema markup validator
Convertica's free schema markup validator checks JSON-LD structured data in your browser. Paste the markup, or a page's whole HTML source, and it reports on every item: JSON mistakes with their line and column, names schema.org does not define, values of the wrong kind, and the properties Google's documentation requires or recommends. Each finding is labeled as an error, a Google requirement, a Google recommendation or advice. No sign-up, and nothing you paste leaves the page.
Short answer
A schema markup validator reads the structured data on a page and reports what is wrong with it: JSON that does not parse, names schema.org does not define, values of the wrong kind and missing properties. Convertica's free validator checks pasted JSON-LD in your browser and labels each finding as an error, a Google requirement, a Google recommendation or advice.
- Valid is not the same as eligible. Markup can pass every schema.org check and still lack a property Google requires for a rich result.
- Every finding carries one of four labels. Errors come from the JSON standard and schema.org, requirements and recommendations from Google's documentation, and advice is Convertica's own.
- Three tools answer three questions: this validator checks the markup you paste, schema.org's validator shows what a parser extracts, and Google's Rich Results Test reports the rich result types Google supports.
- Google does not guarantee a rich result for correct markup, and says its generative AI features need no special schema.
- Nothing you paste is sent anywhere. The validator runs in your browser and never fetches a URL.
Schema markup validator: check your JSON-LD
Free to use, no sign-up. The box starts with an example page from a made-up store, with deliberate mistakes. Replace it with your own markup and press Validate. Nothing you paste leaves your browser.
Result
4 errors
2 JSON-LD blocks found in the HTML.
7 items, 3 at the top level: Organisation, BreadcrumbList and Product.
Google requirements not met: 3. Google recommendations: 4. Advice: 5.
An error is invalid markup. A Google requirement or recommendation comes from Google's documentation. Advice is Convertica's own and is never counted as an error.
Report
- Error: invalid JSON, or something schema.org does not define
- Google requirement: required by Google for a rich result
- Google recommendation: recommended by Google
- Advice: Convertica's own check, not a rule
Nothing to list yet. Paste your markup and press Validate.
-
Organisation
Checked against schema.org for names, values and references.
-
"Organisation" is not a schema.org type. Did you mean Organization?
Source: schema.org, full list of types
-
url is "www.example.com", with no https:// in front, so it is not a full address. Write the full URL.
-
logo is a relative URL ("/images/logo.png"). Write the full URL, starting with https://, so that it means the same thing wherever the markup is read.
-
-
BreadcrumbList
Checked against Google's Breadcrumb list, and against schema.org for names and values.
No findings.
-
Product
Checked against Google's Product snippet and Merchant listing lists, and against schema.org for names and values.
For product pages where people cannot buy the product directly, such as reviews and comparison pages.
For pages where customers can buy the product from you. Skip these findings on a page that does not sell the product.
-
image is missing or empty. Google's Merchant listing documentation lists it as required.
Source: Google, Merchant listing
-
Google's Product snippet documentation recommends more properties than this item has. Not present: aggregateRating and review.
Source: Google, Product snippet
-
Google's Merchant listing documentation recommends more properties than this item has. Not present: aggregateRating, brand.name, description, gtin or gtin8 or gtin12 or gtin13 or gtin14 or isbn, mpn, review and sku. Also on its list, for the pages or businesses they apply to: audience, category, color, hasAdultConsideration, hasCertification, inProductGroupWithID, isVariantOf, material, pattern, size and subjectOf.
Source: Google, Merchant listing
-
description is empty. An empty value says nothing: fill it in or remove the property.
-
schema.org does not list price as a property of Product. It lists it for DonateAction, Offer, PriceSpecification and TradeAction. Check that it sits on the item it describes.
Source: schema.org/price
-
brand points to the @id "https://www.example.com/#brand", and no item in what you pasted has that @id. If the item is defined on another page, a parser that reads one page at a time learns nothing from the pointer: define it here, or check the spelling.
-
-
Offer
Checked against Google's Product snippet and Merchant listing lists, and against schema.org for names and values.
-
schema.org has no property named "priceCurency". Did you mean priceCurrency? A parser has nothing to read it as.
-
availability is "In stock", which is not a value of ItemAvailability. Write https://schema.org/InStock.
Source: schema.org/ItemAvailability
-
priceValidUntil is "December 31, 2026", which is not an ISO 8601 date. The form is year, month, day, as in 2026-01-31.
Source: schema.org/Date
-
price is "$649.00". Google reads the price as a number with a dot as the decimal separator and no currency sign, such as 1299.00. The currency goes in priceCurrency.
Source: Google, Product snippet
-
priceCurrency or priceSpecification.priceCurrency is missing or empty. Google's Merchant listing documentation lists it as required.
Source: Google, Merchant listing
-
Google's Product snippet documentation recommends more properties than this item has. Not present: priceCurrency or priceSpecification.priceCurrency.
Source: Google, Product snippet
-
Google's Merchant listing documentation recommends more properties than this item has. Not present: hasMerchantReturnPolicy, itemCondition and shippingDetails. Also on its list, for the pages or businesses they apply to: url, validFrom and validThrough.
Source: Google, Merchant listing
-
3 nested items had no findings and are not listed.
How to use the schema markup validator
To use the schema markup validator, paste your JSON-LD or the page's full HTML source into the box and press Validate. The report lists every item it finds, what each was checked against and what is wrong. Fix the errors first, then decide which Google requirements and recommendations apply to the page.
- Get the markup. For a block you are writing, copy the JSON-LD itself. For a published page, open View page source in your browser, select everything and copy it. The validator picks out each JSON-LD block.
- If your markup is added by JavaScript, it is not in the page source. Open the browser's developer tools, find the script element of type
application/ld+jsonin the Elements panel and copy it from there. - Paste and press Validate. Short pastes are also checked as you type.
- Fix the errors. A syntax error comes with its line and column. A block that does not parse is ignored whole, so fix it and validate again before reading anything else into the result.
- Read the Google findings against the page. A requirement only matters if you want that rich result. A recommendation only matters if the page really has the information.
- Treat advice as advice. It points at things that are usually mistakes. It is never a rule.
- Test the live page with the two official tools described under the three validators compared, and compare the markup with what a visitor sees.
What does the schema markup validator check?
The schema markup validator checks four things: that the JSON parses, that every type and property is one schema.org defines, that each value is the kind the property takes, and that the properties Google's documentation lists for the item's rich result are present. Every finding carries one of four labels.
| Label | What it means | Where the rule comes from | What to do |
|---|---|---|---|
| Error | The JSON does not parse, or the markup uses something schema.org does not define: no schema.org @context, no @type, a type or property name that is not in the vocabulary, or a value that cannot be the kind the property takes. | The JSON standard and schema.org's vocabulary | Fix it. A parser drops the block, the item or the property. |
| Google requirement | A property Google's documentation lists as required for a rich result is missing or empty, or a price, currency or position is not in the format Google's page gives. | Google Search Central, the page named in the finding | Fix it if you want that rich result. If the page is not meant to earn it, leave it. |
| Google recommendation | Properties Google's documentation lists as recommended are not present. | Google Search Central, the page named in the finding | Add the ones your page really has. Skip the rest. |
| Advice | Something schema.org allows and Google does not forbid, which is usually a mistake or a missed chance: a property on a type it is not listed for, text where an item is expected, a relative URL, an empty value, an @id that points nowhere. | Convertica's own checks | Read it and decide. It is not a rule. |
The line between an error and advice is not ours to draw freely. schema.org's data model says that it expects its properties to be used on types they are not listed for, that it expects text where an item such as a Person or an Organization is called for, and that validators are not obliged to treat unexpected structures as errors. So those are advice here. A name that is not in the vocabulary at all, or a date that is not a date, is an error.
Every check, and the basis for it
| Area | The validator checks that | If not | Basis |
|---|---|---|---|
| JSON | The JSON parses | Error | A JSON-LD block is JSON. One stray comma, quote or bracket makes a parser drop the whole block. The report gives the line and the column. |
| JSON | No property name is written twice in one object | Advice | RFC 8259: names within an object should be unique, and many parsers keep only the last one. |
| JSON-LD | The script element's type is exactly application/ld+json | Error | A block typed application/json+ld, or anything else, is not read as structured data. |
| JSON-LD | @context is the schema.org context | Error | schema.org's FAQ: https://schema.org and http://schema.org are both fine. Without the context the names are not schema.org terms. |
| JSON-LD | Every top-level item has an @type | Error | An item with no type cannot be told apart from any other. A nested object with no @type is advice. |
| JSON-LD | @graph is a list of items, and @id and @type are text | Error | The JSON-LD keywords have fixed shapes. |
| Names | Every type is a schema.org type | Error | The 939 types in schema.org's vocabulary file, release 30.1. Names are case-sensitive. A close name is suggested. |
| Names | Every property is a schema.org property | Error | The 1,538 properties in the same file. A parser has nothing to read an unknown name as. |
| Names | Each property is one schema.org lists for the item's type | Advice | schema.org's data model expects properties to be used on other types, so this is advice. It often means a property sits one level too high, such as price on a Product. |
| Names | No type or property has been replaced | Advice | schema.org marks retired terms with the term that supersedes them. |
| Values | Dates, times and durations are ISO 8601 | Error | schema.org defines Date, DateTime, Time and Duration as ISO 8601 values: 2026-01-31, 2026-01-31T09:30:00+00:00, 09:30, PT30M. |
| Values | Numbers, true or false values and URLs are what they claim to be | Error | A property that takes only a number, only true or false or only a URL cannot hold other text. |
| Values | An enumeration holds one of its values | Error | A property such as availability takes one of schema.org's listed values, such as https://schema.org/InStock. |
| Values | A property that takes text, a number or a date does not hold an object | Error | The value has to be written directly. |
| Values | A property that expects an item holds an item, of an expected type | Advice | schema.org accepts text where it expects a Person, a Place or an Organization, so this is advice. An item with its own properties says more. |
| Values | URLs are absolute | Advice | A relative URL, or a host name with no https://, is not a full address. Google's pages ask for fully qualified URLs for several properties. |
| Values | No value is empty or a placeholder | Advice | An empty text, null, an empty list, or a value such as undefined or {{ name }}, usually comes from a template that printed nothing. |
| References | Every @id that is pointed to is defined in what you pasted | Advice | A pointer to an item on another page tells a parser that reads one page nothing. |
| References | No two items of different types share an @id | Advice | A JSON-LD parser treats items with the same @id as one item. Two descriptions of the same thing may share one; a WebSite and an Article may not. |
| The properties Google lists as required for the item's rich result are present | Google requirement | Google's general guidelines: items that are missing required properties are not eligible for rich results. | |
| The properties Google lists as recommended are present | Google recommendation | Google: it is more important to supply fewer but complete and accurate recommended properties than every possible one. | |
| Prices, currencies and breadcrumb positions are in the format Google's pages give | Google requirement | A price as a number with a dot, a three-letter ISO 4217 currency, a whole-number position. A video duration that is not ISO 8601 is reported as a recommendation. |
Names and value kinds come from schema.org's own vocabulary file, release 30.1, read on : 939 types, counting enumerations and data types, 1,538 properties and 546 enumeration values. A type that is new or pending in a later release may be reported as unknown until the file is refreshed.
What it does not check: your live page. The validator reads only what you paste. It cannot see whether the markup matches the visible page, whether an image address works, or whether Google can crawl the page. It reads up to 3,000,000 characters and lists the first 150 items.
Which schema types does the validator check against Google's requirements?
The validator checks 16 schema types against 15 lists of required and recommended properties from Google's structured data documentation. Every list below was copied from the Google Search Central page it links to, read on . Subtypes are checked with their parent's list, so a Restaurant is checked as a local business.
| Google feature | Types | Required | Recommended |
|---|---|---|---|
| Organization | Organization | None | address, address.addressCountry, address.addressLocality, address.addressRegion, address.postalCode, address.streetAddress, alternateName, contactPoint, contactPoint.email, contactPoint.telephone, description, duns, email, foundingDate, globalLocationNumber, hasMerchantReturnPolicy, hasMemberProgram, hasShippingService, iso6523Code, legalName, leiCode, logo, naics, name, numberOfEmployees, sameAs, taxID, telephone, url, vatID |
| Local business | LocalBusiness | address, name | aggregateRating, department, geo, geo.latitude, geo.longitude, menu, openingHoursSpecification, openingHoursSpecification.closes, openingHoursSpecification.dayOfWeek, openingHoursSpecification.opens, openingHoursSpecification.validFrom, openingHoursSpecification.validThrough, priceRange, review, servesCuisine, telephone, url |
| Site name | WebSite | name, url | alternateName |
| Article | Article, NewsArticle, BlogPosting | None | author, author.name, author.url or author.sameAs, dateModified, datePublished, headline, image |
| Product snippet | Product | name, review or aggregateRating or offers | aggregateRating, offers, review |
| Product snippet: each offers item | Offer | price or priceSpecification.price | availability, priceCurrency or priceSpecification.priceCurrency, priceValidUntil |
| Product snippet: each offers item | AggregateOffer | lowPrice, priceCurrency | highPrice, offerCount |
| Merchant listing | Product | name, image, offers | aggregateRating, audience, brand.name, category, color, description, gtin or gtin8 or gtin12 or gtin13 or gtin14 or isbn, hasAdultConsideration, hasCertification, inProductGroupWithID, isVariantOf, material, mpn, pattern, review, size, sku, subjectOf |
| Merchant listing: each offers item | Offer | price or priceSpecification.price, priceCurrency or priceSpecification.priceCurrency | availability, hasMerchantReturnPolicy, itemCondition, priceValidUntil, shippingDetails, url, validFrom, validThrough |
| Breadcrumb | BreadcrumbList | itemListElement | None |
| Breadcrumb: each itemListElement item | ListItem | item, name, position | None |
| Review snippet | Review | author, reviewRating, reviewRating.ratingValue, itemReviewed (unless nested in the item it reviews), itemReviewed.name (unless nested in the item it reviews) | datePublished, reviewRating.bestRating, reviewRating.worstRating |
| Review snippet (aggregate rating) | AggregateRating | ratingCount or reviewCount, ratingValue, itemReviewed (unless nested in the item it reviews), itemReviewed.name (unless nested in the item it reviews) | bestRating, worstRating |
| Profile page | ProfilePage | mainEntity | dateCreated, dateModified |
| Profile page: each mainEntity item | Person | name or alternateName | agentInteractionStatistic, alternateName, description, identifier, image, interactionStatistic, sameAs |
| Profile page: each mainEntity item | Organization | name or alternateName | agentInteractionStatistic, alternateName, description, identifier, image, interactionStatistic, sameAs |
| Event | Event | location, location.address, name, startDate | description, endDate, eventStatus, image, location.name, offers, offers.availability, offers.price, offers.priceCurrency, offers.validFrom, offers.url, organizer, organizer.name, organizer.url, performer, performer.name, previousStartDate |
| Video | VideoObject | name, thumbnailUrl, uploadDate | contentUrl, creator or author, creator.name or author.name, creator.url or author.url, description, duration, embedUrl, expires, hasPart, ineligibleRegion, interactionStatistic, interactionStatistic.interactionType, interactionStatistic.userInteractionCount, publication, regionsAllowed |
| Software app | SoftwareApplication | name, offers.price, aggregateRating or review | applicationCategory, operatingSystem |
| Recipe | Recipe | image, name | aggregateRating, author, cookTime, datePublished, description, keywords, nutrition.calories, prepTime, recipeCategory, recipeCuisine, recipeIngredient, recipeInstructions, recipeYield, totalTime, video |
| Job posting | JobPosting | datePosted, description, hiringOrganization, jobLocation, title | applicantLocationRequirements, baseSalary, directApply, employmentType, identifier, jobLocationType, validThrough |
A dotted name such as author.name means the name of each author item. "Or" is Google's own: either property meets the entry. Where Google ties a recommended property to a kind of page or business, such as a menu for a food business or a DUNS number for a company that has one, the report lists it apart from the rest. That grouping is ours, not Google's.
Product has two lists because Google has two product features. Product snippets are for pages where people cannot buy the product directly. Merchant listings are for pages where customers can buy from you, and they need an image, an Offer and a currency. Read only the findings for the kind of page you have.
Types with no Google list
For every other type the validator checks names, values and references against schema.org, and says so in the report. Three common ones deserve a note:
- FAQPage. Google stopped showing FAQ rich results on May 7, 2026 and has removed its FAQ documentation, so nothing here is a Google requirement. The item is checked against the shape schema.org gives a FAQPage.
- WebPage. Google documents no rich result for a plain WebPage, and schema.org requires no property. Names, values and references are checked.
- Person. Google documents Person only inside other features: as the author of an article or the main entity of a profile page. Names, values and references are checked.
To build FAQPage markup from a list of questions, use the FAQ schema generator, which also sets out what Google has published about FAQ rich results.
Schema markup examples, checked by the validator
The five schema markup examples below are checked by the same code as the tool above. Example Bike Shop, its products and its prices are made up. They show how markup is checked, not what a store should publish.
1. A product page with common mistakes
The tool starts with a page of 46 lines that holds 2 JSON-LD blocks and 7 items. The validator reports 4 errors, 3 Google requirements, 5 pieces of advice and 4 lists of Google recommendations. Each finding except the recommendations, with its fix:
| Item | Label | What the validator says | Fix |
|---|---|---|---|
| Organisation | Error | "Organisation" is not a schema.org type. Did you mean Organization? | Write Organization, the spelling schema.org uses. |
| Organisation | Advice | url is "www.example.com", with no https:// in front, so it is not a full address. Write the full URL. | Write https://www.example.com/. |
| Organisation | Advice | logo is a relative URL ("/images/logo.png"). Write the full URL, starting with https://, so that it means the same thing wherever the markup is read. | Write the full address of the image. |
| Product | Google requirement | image is missing or empty. Google's Merchant listing documentation lists it as required. | Add the address of a product photo, if this page sells the product. |
| Product | Advice | description is empty. An empty value says nothing: fill it in or remove the property. | Write the description the page shows, or remove the property. |
| Product | Advice | schema.org does not list price as a property of Product. It lists it for DonateAction, Offer, PriceSpecification and TradeAction. Check that it sits on the item it describes. | Remove price from the Product. It belongs on the Offer, where it already is. |
| Product | Advice | brand points to the @id "https://www.example.com/#brand", and no item in what you pasted has that @id. If the item is defined on another page, a parser that reads one page at a time learns nothing from the pointer: define it here, or check the spelling. | Write the brand as a nested Brand item with a name, or add an item that has this @id. |
| Offer | Error | schema.org has no property named "priceCurency". Did you mean priceCurrency? A parser has nothing to read it as. | Correct the spelling: priceCurrency. |
| Offer | Error | availability is "In stock", which is not a value of ItemAvailability. Write https://schema.org/InStock. | Write https://schema.org/InStock. |
| Offer | Error | priceValidUntil is "December 31, 2026", which is not an ISO 8601 date. The form is year, month, day, as in 2026-01-31. | Write 2026-12-31. |
| Offer | Google requirement | price is "$649.00". Google reads the price as a number with a dot as the decimal separator and no currency sign, such as 1299.00. The currency goes in priceCurrency. | Write 649.00, with the currency in priceCurrency. |
| Offer | Google requirement | priceCurrency or priceSpecification.priceCurrency is missing or empty. Google's Merchant listing documentation lists it as required. | Nothing more to do: correcting the misspelled property supplies it. |
Two things in that table are worth a second look. The misspelled priceCurency produces two findings: an error for the unknown name, and a Google requirement because the real property is now missing. And price on the Product is only advice, although it does nothing there: schema.org lists price for an Offer, and the data model does not make a misplaced property an error.
2. The same page, corrected
Press "Load the corrected example" in the tool to see the page with every finding dealt with. The product block becomes:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Commuter 8 city bike",
"description": "An eight-speed city bike with mudguards, a rear rack and hub dynamo lights.",
"image": "https://www.example.com/images/commuter-8.jpg",
"brand": { "@type": "Brand", "name": "Example Bike Shop" },
"offers": {
"@type": "Offer",
"price": "649.00",
"priceCurrency": "USD",
"availability": "https://schema.org/InStock",
"priceValidUntil": "2026-12-31"
}
}
</script>The validator now reports no errors, no missed Google requirement and no advice. It still lists 4 sets of Google recommendations, among them ratings, reviews, a GTIN and a return policy. A made-up store has none of those, and a real page should add only the ones it can state truthfully. Recommendations left open are not a fault.
3. One trailing comma
The most common reason a block is ignored is a JSON mistake, and the most common JSON mistake is a comma after the last property:
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "How to choose a city bike",
"datePublished": "2026-03-02",
}The validator stops at line 5, column 32, which is the comma itself, and says: "There is a comma after the last property of this object. JSON does not allow a trailing comma: remove it." Nothing else in the block is checked until it parses, because a JSON-LD parser would read none of it.
4. Valid markup that is not eligible
A free web app, marked up correctly:
{
"@context": "https://schema.org",
"@type": "WebApplication",
"name": "Frame size calculator",
"url": "https://www.example.com/frame-size-calculator/",
"applicationCategory": "UtilitiesApplication",
"operatingSystem": "Any",
"offers": { "@type": "Offer", "price": "0", "priceCurrency": "USD" }
}The validator reports no errors and one Google requirement: "aggregateRating or review is missing or empty. Google's Software app documentation lists it as required." The markup is valid schema.org and says true things. It is not eligible for Google's software app result, because Google's page asks for a rating or a review. The honest fix is none: a tool with no real ratings should not invent one. This page's own markup describes the validator the same way, without a rating.
5. A graph whose items point at each other
Larger sites describe the organization, the site and the page as separate items in one @graph, joined by @id. Two things go wrong with that pattern, and neither is a syntax error:
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "WebSite",
"@id": "https://www.example.com/#website",
"name": "Example Bike Shop",
"url": "https://www.example.com/",
"publisher": { "@id": "https://www.example.com/#organisation" }
},
{
"@type": "Organization",
"@id": "https://www.example.com/#organization",
"name": "Example Bike Shop",
"url": "https://www.example.com/"
},
{
"@type": "Article",
"@id": "https://www.example.com/#website",
"headline": "How to choose a city bike",
"datePublished": "2026-03-02T09:00:00",
"author": "Sam Rider",
"publisher": { "@id": "https://www.example.com/#organization" }
}
]
}The validator finds no errors, and 3 pieces of advice plus one Google recommendation about a date:
| Item | Label | What the validator says |
|---|---|---|
| WebSite | Advice | publisher points to the @id "https://www.example.com/#organisation", and no item in what you pasted has that @id. If the item is defined on another page, a parser that reads one page at a time learns nothing from the pointer: define it here, or check the spelling. |
| Article | Google recommendation | datePublished has a time and no timezone. Google recommends adding one, such as +00:00 or Z; without it Google assumes the timezone Googlebot uses. |
| Article | Advice | author is text ("Sam Rider"). schema.org expects an item (Organization or Person) here. Parsers accept text, but a nested item with its own @type and properties says more. |
| Article | Advice | 2 items share the @id "https://www.example.com/#website" and give different types (WebSite and Article). A JSON-LD parser treats items with the same @id as one item and merges their types and properties. If they are different things, give each its own @id. |
The website's publisher points to #organisation, spelled with an s, and the organization is defined as #organization. The article reuses the website's @id, so a parser merges the two into one item that is both a WebSite and an Article. Both are a single character away from correct, and both are invisible until something reads the graph as a whole.
Schema markup validator, Rich Results Test or validator.schema.org: which to use?
Use all three, in that order: this schema markup validator while you write the markup, the Schema Markup Validator at validator.schema.org to see what a parser extracts, and Google's Rich Results Test on the live page. This tool is not either of the official ones and does not reproduce their results.
| This validator | Schema Markup Validator (validator.schema.org) | Rich Results Test (Google) | |
|---|---|---|---|
| Who provides it | Convertica | Google, as a service for the schema.org community. It is based on the former Structured Data Testing Tool | |
| What it reads | Pasted JSON-LD, or the JSON-LD blocks in pasted HTML | JSON-LD, RDFa and Microdata, from a URL or from pasted markup | JSON-LD, RDFa and Microdata, from a URL or from a pasted code snippet |
| Fetches the live page | No | Yes. It also extracts structured data injected by JavaScript | Yes, as a smartphone or a desktop crawler. Its code explorer uses the rendered source |
| What it reports | Findings for each item, labeled as an error, a Google requirement, a Google recommendation or advice, each with its source | A summary of the extracted structured data graph, and syntax mistakes in the markup | Which rich result types were found on the page, with errors and suggestions for each, and a preview for some types |
| Limits | Fetch a page, render JavaScript, read Microdata or RDFa, or decide what Google will show | Its documentation describes syntax checks and a summary of the graph, and names no check of Google's rich result requirements. It is focused on schema.org and does not interpret other @context addresses | Its help page lists the rich result types the test supports. FAQ is not on that list |
Sources: the Schema Markup Validator's documentation at schema.org and Google's Rich Results Test help page, which lists the rich result types the test supports. One detail from that help page explains a common surprise: the Rich Results Test ignores comments inside JSON-LD, although the JSON-LD standard does not allow them. A block with a comment can pass there and still fail in a parser that follows the standard. This validator reports the comment as an error.
Results can differ between the three. A parser is free to be more forgiving than a definition, so a date written as words may be accepted by one tool and reported by another. This validator reports anything that is not ISO 8601, because that is how schema.org defines its date types and what Google's pages ask for by name.
Does valid schema markup guarantee rich results?
No. Valid schema markup makes a page eligible for a rich result, and Google decides whether to show one. Google's general structured data guidelines say it does not guarantee that structured data will show up in search results, even if the page is marked up correctly according to the Rich Results Test.
The same page gives the reasons markup that passes can still show nothing:
- Structured data enables a feature. It does not guarantee the feature, and Google may decide that a plain text result serves the search better.
- The structured data is not representative of the main content of the page, or is potentially misleading.
- The structured data is wrong in a way the test could not catch.
- The content the markup refers to is hidden from the user.
- The page does not meet Google's structured data guidelines or its other policies.
So there are three separate states, and a validator can speak to the first two only:
- Valid: the JSON parses, and the names and values fit schema.org. This validator's errors cover that.
- Eligible: the item has every property Google lists as required for a feature. This validator's Google requirements cover that, for the types in the table above. Google's guidelines put it plainly: items that are missing required properties are not eligible for rich results.
- Shown: Google chose to display the rich result for a search. No tool can tell you that in advance.
How many recommended properties should you add?
Add the recommended properties your page really has, and stop there. Google's introduction to structured data says it is more important to supply fewer but complete and accurate recommended properties than to try to provide every possible one with less complete, badly formed or inaccurate data. That is why this validator reports recommendations as one list per feature and never counts them as errors.
Rich results Google has retired
Markup can be valid for a feature that no longer exists. Google's documentation changelog records that FAQ rich results stopped appearing in Google Search on May 7, 2026, and that the documentation for them, and for the sitelinks search box, has been removed. The types themselves are still schema.org types and still parse. They just earn nothing visible in Google.
How to fix common schema markup errors
Most schema markup errors come from a short list of causes: JSON punctuation, a misspelled or misplaced name, and a value in a format a machine cannot read. Each row below is something the schema markup validator reports, with its usual cause and the fix.
| What the report says | Usual cause | Fix |
|---|---|---|
| A comma after the last property | A property was removed from the end of an object, or a template loop prints a comma after every item | Remove the comma. In a template, print the comma only between items |
| A curly quote where a straight quote belongs | The markup passed through a word processor or a rich text field | Retype the quotes, and paste markup only into a code or HTML field |
| A line break inside a text | A description was pasted with its paragraphs, or a closing quote is missing | Keep the text on one line, or write each break as \n |
| An HTML character reference in a value | The CMS escaped the value for HTML, turning & into &. Inside a script element that is not decoded | Output the value as JSON, not as HTML text |
| No @context, or one that is not schema.org | The block was cut from a larger one, or the address is misspelled | Add "@context": "https://schema.org" at the top of the block |
| A type or property schema.org does not define | A spelling or capital letter: Organisation, LocalBusines, datepublished | Use the name the report suggests. Types start with a capital letter, properties do not |
| A property schema.org does not list for the type | The property sits one level too high or too low, such as price on a Product in place of its Offer | Move it to the item it describes |
| A date that is not ISO 8601 | The date was written the way the page shows it | Write year, month and day with hyphens, such as 2026-01-31, and add the time and timezone where the property takes them |
| A price Google cannot read | The currency sign or a thousands separator is inside the price | Write the number alone with a dot for decimals, and put the three-letter currency code in priceCurrency |
| A value that is not in the enumeration | Availability or condition written as words | Use schema.org's value, such as https://schema.org/InStock |
| A relative URL | The template printed the site's internal path | Print the full address, starting with https:// |
| An @id that points nowhere | The item it names is defined on another page, or the two spellings differ | Define the item on this page too, or correct the @id |
| An empty value or a placeholder | A template field had nothing to print | Leave the property out when there is no value |
What correct JSON-LD looks like
A JSON-LD block is a script element of type application/ld+json that holds one JSON value: an object, or a list of objects. Each item names its vocabulary and its type, then states its properties.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "The type, such as Product",
"name": "A property that takes text",
"url": "https://www.example.com/a-full-address/",
"offers": {
"@type": "A nested item has a type of its own",
"price": "649.00"
}
}
</script>Google's guidelines accept JSON-LD, Microdata and RDFa, and recommend JSON-LD. One page can hold several blocks, or one block with several items in @graph.
Can wrong schema markup hurt a website?
Wrong schema markup can cost a page its rich results, and Google says it does not cost rankings. Its structured data guidelines state that a structured data issue can result in a manual action, that a manual action means the page loses eligibility for appearance as a rich result, and that it does not affect how the page ranks in Google web search.
What draws a manual action is not a missing comma. It is markup that breaks the quality guidelines on the same page, which no validator can test for you:
- Markup for content readers cannot see. Google's example: if the markup describes a performer, the page itself must describe that performer.
- Irrelevant or misleading content, such as fake reviews or content unrelated to the focus of the page.
- The wrong type for the content. Google's examples are a streaming site labeling broadcasts as local events and a woodworking site labeling instructions as recipes.
- Out-of-date information. Google says it will not show a rich result for time-sensitive content that is no longer relevant.
A plain technical mistake has a smaller cost: the block, the item or the property is not read, and the page is simply not eligible for the feature until it is fixed.
Does schema markup help with AI Overviews and ChatGPT?
Google says schema markup is not required for its generative AI features. Its guide to optimizing for generative AI search lists overfocusing on structured data among the things you do not need to do, and says there is no special schema.org markup to add. It still recommends structured data, because it helps pages become eligible for rich results.
Google's page on AI features and your website asks one thing of markup: that structured data matches the visible text on the page. So this validator makes no promise about AI answers. It tells you whether the markup is correct. Whether an AI assistant cites a page is a different question, and whether a crawler can read the page at all is a third:
- The crawlability test shows what a crawler that does not run JavaScript receives from a page, including which JSON-LD types are in the HTML before any script runs.
- The AI visibility checker reads a live page and its site files: robots.txt rules for AI crawlers, llms.txt and structured data.
- The AI agent readiness checklist covers access, readable facts, structured data and checkout.
- The share of voice calculator takes a set of AI answers you checked yourself and works out how often each brand is mentioned. It queries no assistant.
What a schema markup validator cannot tell you
A schema markup validator cannot tell you whether the markup is true. It reads structure, not the page. A Product block with a perfect price passes every check even when the page shows a different price, and that mismatch is the one that matters: to Google's guidelines, and to the person about to buy.
Structured data is a second copy of the facts a buyer decides on: the name, the price, the currency, what is in stock, the return policy, who sells it. Every copy is a chance to disagree with the page. Three habits keep them in step:
- Print the markup from the same data as the page. This site builds each page's JSON-LD from the same data that prints the visible content, and an automated check fails when the FAQ markup and the visible FAQ differ. Markup pasted in by hand is the kind that drifts.
- Check the markup when the page changes, not once at launch. A price change, a discontinued product or a new return window all have to reach the markup too.
- Mark up only what the page states. If a rating, a review count or an availability is not visible to a visitor, it does not belong in the markup.
Whether the visible page then persuades anyone is a separate job. Convertica's free CRO audit runs eight checks on a page, among them how clearly it states the offer and whether an AI agent can read what it sells. For one page, the landing page analyzer runs the same checks under its own name.
Related tools and guides
Checking the markup is one step in making a page readable by machines. These cover the others.
See all free tools and how they fit together.
Schema markup validator FAQ
What is a schema markup validator?
A schema markup validator is a tool that reads the structured data on a page and reports what is wrong with it. Convertica's validator reads JSON-LD, pasted alone or inside a page's HTML source. It reports JSON that does not parse, names that schema.org does not define, values of the wrong kind, and properties that Google's documentation requires or recommends.
How can I check if my schema markup is correct?
Check it in three steps. Paste the markup or the page's HTML source into this validator and fix every error. Then run the live page through Google's Rich Results Test, which reports the rich result types Google supports. Last, compare the markup with the visible page by eye: no validator can tell you that a price or a name in the markup matches what a visitor reads.
What is the difference between this validator, validator.schema.org and Google's Rich Results Test?
They answer different questions. This validator checks pasted JSON-LD against schema.org's vocabulary and Google's published property lists, and labels each finding. The Schema Markup Validator at validator.schema.org is schema.org's own tool: it also reads Microdata and RDFa, and can fetch a URL. Google's Rich Results Test fetches and renders a live page and reports the rich result types Google supports.
Does valid schema markup guarantee a rich result?
No. Google's structured data guidelines say Google does not guarantee that structured data will show up in search results, even when the page is marked up correctly according to the Rich Results Test. Valid markup makes a page eligible for a feature. Google decides whether to show it.
Can schema markup hurt my website?
Markup that breaks Google's structured data guidelines can lead to a manual action, which removes a page's eligibility for rich results. Google says a structured data manual action does not affect how the page ranks in web search. Markup that is only incomplete is not penalized: the item is simply not eligible for the feature.
Should @context be http://schema.org or https://schema.org?
Either works. schema.org's own FAQ says both https://schema.org and http://schema.org are fine, and that https is its preferred form in examples. This validator accepts both. It reports a context that is neither, such as a misspelled address or a missing one, as an error.
Does this validator read Microdata or RDFa?
No. It reads JSON-LD only: every script element in the pasted HTML whose type is application/ld+json. It counts the Microdata and RDFa it sees and tells you they were not checked. The Schema Markup Validator at validator.schema.org and Google's Rich Results Test read all three formats.
Can I validate a URL?
Not with this tool. It runs in your browser and never fetches a page, so you paste the markup or the page's HTML source. To test a live address, use the Schema Markup Validator at validator.schema.org or Google's Rich Results Test, which both fetch pages.
Why does the validator list properties that Google only recommends?
Because Google's documentation lists them, and the report labels them as recommendations so that they cannot be mistaken for errors. Google's own advice is to supply fewer recommended properties that are complete and accurate, not every possible one. Add the ones your page really has.
Does the validator check FAQ schema?
Yes, as markup. It checks a FAQPage for a list of questions, each with a name and an answer with text, and labels anything missing as advice. Nothing about FAQPage is a Google requirement any more: Google stopped showing FAQ rich results on May 7, 2026 and has removed its FAQ documentation.
Does schema markup get a page cited in AI answers?
Google says it is not needed for that. Its guidance on generative AI search says structured data is not required and that there is no special schema.org markup to add, while still recommending structured data for rich results. This validator checks that markup is correct. It does not measure AI citations.
Is the schema markup validator free, and where does my markup go?
It is free and needs no sign-up. The check is done by a script in your browser. Nothing you paste is sent to a server and nothing is stored, so you can check a page that is not live yet.