Schema Markup Validator
Paste your structured data or enter a URL. We check every item against schema.org and Google's requirements, show the exact line of each problem and tell you how to fix it.
- JSON-LD, Microdata and RDFa
- Every schema.org type
- Nothing you paste is stored
Need to create markup first? Use the Schema Markup Generator.
Items found
Open an item to see its issues, Google's requirements and the parsed data.
Your code
Lines with problems are highlighted. Select a line number in an issue to jump here.
Want structured data done right on your whole site?
A validator finds the errors; deciding which schema each page needs and rolling it out cleanly takes experience. I handle technical SEO and structured data for businesses in Nepal and worldwide.
Four layers of checks on every item
Most validators stop at "is this JSON valid". This one keeps going until it has compared your markup with schema.org and with what Google asks for.
1. Find the markup
Reads JSON-LD (including @graph and several script tags), Microdata and RDFa from pasted code or a fetched page.
2. Check the syntax
A strict parser reports the exact line and column of a mistake and repairs trailing commas, curly quotes and comments.
3. Compare with schema.org
Every type, property and value is checked against the full vocabulary: spelling, expected value types, URLs, dates, numbers and enumerations.
4. Apply Google's rules
Matches each item to a Google feature, then lists the required and recommended properties that are present or missing.
The most common schema markup errors and how to fix them
These nine problems account for most of what the validator finds on real sites.
| Message | What causes it | How to fix it |
|---|---|---|
| Unknown property | The name isn't in schema.org, usually a typo or wrong capitalization (datepublished, reveiw). | Use the exact schema.org name. The validator suggests the closest match. |
| Unknown type | The @type isn't a schema.org type, or it is in the wrong case (product, Offerr). | Check the spelling and capitalization, and use a more specific type where one exists. |
| Missing @context | The block doesn't say which vocabulary it uses, so search engines can't read it. | Add "@context": "https://schema.org" at the top of the object. |
| Invalid object type | A nested object has a type that the property doesn't accept, such as a Person for offers. | Use the type schema.org expects for that property, such as an Offer inside offers. |
| Missing required field | A property Google needs for the rich result is missing, such as offers.price or startDate. | Add the field, or accept that the page won't qualify for that rich result. |
| Not a valid URL | A URL is relative (/image.jpg), has spaces or has no https:// at the start. | Use full absolute URLs for url, image, logo and sameAs. |
| Not a valid date | A date is not in ISO 8601, for example 14/10/2026 or Oct 14. | Use 2026-10-14, or 2026-10-14T09:30:00+05:45 when you include the time. |
| Price must be a number | The price has a currency symbol or thousands separator, such as $1,299.00. | Write 1299.00 and put the currency in priceCurrency as a code like USD. |
| Syntax error | The JSON can't be read: a trailing comma, curly quotes, a comment or a line break inside a string. | Use Apply suggested fixes, or fix the line the validator points to. |
Error
Wrong or missing required data. Fix before publishing.
Warning
Valid but risky, or a recommended field is missing.
Note
Good to know, such as a retired feature. No action needed.
This validator, Google's Rich Results Test and validator.schema.org
They answer different questions. A good workflow uses more than one.
| Question | This validator | Google Rich Results Test | validator.schema.org |
|---|---|---|---|
| Is my page eligible for a Google rich result? | Checks Google's documented requirements | Yes, the final word | No |
| Is every property valid schema.org? | Yes, with suggestions | Only for Google's features | Yes |
| Exact line for each problem and how to fix it | Yes | Partly | Partly |
| Repairs broken JSON | Yes | No | No |
| Renders JavaScript before checking | No, reads server HTML | Yes | Yes, for URLs |
| Best used for | Building and debugging markup | Final eligibility check | Broad vocabulary check |
Run the live page through Google's Rich Results Test before you call it done, and watch the Enhancements reports in Search Console afterwards.
What a schema validator can't tell you
A clean result means the markup is well formed and complete, not that Google will reward it.
Eligibility isn't a promise
Google decides whether to show a rich result. Valid markup only makes you eligible.
Server HTML only
The URL tab reads the HTML your server sends. Markup injected by JavaScript afterwards isn't visible; paste the rendered HTML instead.
It can't see your page content
Whether a price or rating matches what visitors see on the page is something only you can verify.
Rules change
It uses schema.org 30.1 and Google's documentation as of 2026. Both are updated over time, so re-test important pages.
What a schema markup validator checks and what a pass means
A schema markup validator reads the structured data on a page and checks it at three levels. First is syntax: can the JSON-LD be parsed at all, or does a trailing comma or a curly quote break it? Second is vocabulary: are the types, properties and values real schema.org terms used in the right place? Third is the requirements of a specific feature, such as the fields Google lists for a Product or an Event.
Those levels answer different questions, which is why more than one test exists. Schema.org runs its own validator for the vocabulary, and Google's Rich Results Test checks whether a page can qualify for Google's features. Google's structured data guidelines add rules that no tool can test, such as marking up only what visitors can see. A page can pass every automated check and still break one of those rules.
So read a pass as a statement about form, not value. It means the markup is well formed and complete, not that Google will show a rich result or that the facts are right. Use the validator to find the line of each problem and fix it, then confirm the live page in Google's test and in Search Console. Errors are for fixing before you publish, and warnings are optional improvements.
When to validate structured data
Validate whenever markup is created, changed or inherited from something you did not write.
After generating new markup
Paste the code you just built before it goes on the page. It is quicker to fix a missing field or a misspelled property here than after a crawl has reported it.
After installing a plugin or theme
Check the markup it outputs with the Check a URL tab. Plugins often add several types at once, and some add duplicates or fields that do not match your page.
On staging or behind a login
Paste the page source on the Paste code tab to test a build before launch, since the URL tab can only reach public pages.
When Search Console reports errors
Take a flagged URL, run it here and read the exact line and message. The explanation and suggested fix often point to the template that needs changing.
After a redesign or migration
Templates are rebuilt and markup is easily lost or duplicated. Compare a few key pages before and after, such as a product, an article and the home page.
For markup added through a tag manager
Markup injected by script is not in the server HTML. Copy the rendered HTML from your browser's developer tools and paste it in to test what visitors and Google may see.
Validation mistakes and how to fix them
The tool finds the errors. These are the habits that create them, or that make a pass misleading.
Copying code through a word processor
What goes wrong: Curly quotes, hidden characters or stray line breaks from a document or chat app turn valid-looking JSON into a syntax error.
The fix: Paste from a plain text editor. Use the suggested fixes for trailing commas, curly quotes and comments, then read the code once to confirm nothing important changed.
A missing @context or wrong @type
What goes wrong: Without "@context": "https://schema.org" the vocabulary is unknown, and a type spelled in the wrong case, such as product, is not a real schema.org type.
The fix: Put @context at the top of every block and match type names exactly. Use the more specific type when one exists.
Relative URLs and dates in the wrong format
What goes wrong: A path such as /images/logo.png or a date such as 14/10/2026 is clear to a person but not to a parser. Google's documents ask for ISO 8601 dates, and a full URL is the safe choice for images and logos.
The fix: Write full https URLs and ISO 8601 dates, for example 2026-10-14 or 2026-10-14T09:30:00+05:45. Add a time zone when you include a time.
Testing only the raw HTML
What goes wrong: Markup added by JavaScript or a tag manager does not appear in the server's HTML, so a URL check can say there is none even though visitors' browsers build it.
The fix: Paste the rendered HTML from developer tools. Then run the live page through Google's Rich Results Test or the URL Inspection tool to see what Google reads.
Ignoring errors, or fixing every warning
What goes wrong: Errors mean required data is wrong or missing, while warnings usually flag optional fields. Treating them alike wastes time or leaves real faults in place.
The fix: Clear every error first. For warnings, add a property only when you have real, visible data for it. A page with warnings but no errors is valid.
Treating a pass as proof of a rich result
What goes wrong: Validators check form. They cannot tell whether a price matches the page, whether a review is genuine or whether Google will show anything.
The fix: Compare each value with what visitors see, and keep markup honest. Then watch the rich result reports in Search Console after Google recrawls the page.
Structured data validation terms explained
@context- The JSON-LD key that names the vocabulary a block uses. For schema.org it is
https://schema.org. Without it, search engines cannot tell what the other keys mean. @type- The key that says what kind of thing the block describes, such as
ProductorEvent. Type names are case sensitive and must exist in schema.org. - Expected type
- The kind of value a property accepts, such as text, a number, a date, a URL or another type. An
offersproperty expects an Offer, not a Person. - ISO 8601 date
- The date and time format used in structured data, for example
2026-10-14or2026-10-14T09:30:00+05:45, where the last part is the time zone offset. - Error, warning and note
- An error is wrong or missing required data. A warning is valid but risky, or a recommended field is absent. A note is good to know, such as a retired feature.
- Microdata
- A way to add schema.org terms as attributes, such as
itemscopeanditemprop, directly inside the visible HTML. Google supports it, though it recommends JSON-LD. - RDFa
- Another attribute-based format that embeds structured data in HTML. Google supports it, and this tool reads it along with JSON-LD and Microdata.
- Rich Results Test
- Google's own test for whether a page's markup can qualify for Google's rich result features. It is the final check before you rely on a feature, and it can also preview how some of them look.
Related tools, guides and services
Validation is the middle step. These help you build the markup and fix what the pages around it need.
Schema Markup Generator
Build new JSON-LD for 28 guided types or any schema.org type, with required-field checks.
ToolMeta Tag Checker
Check the head tags that sit beside your structured data, which this validator does not read.
ToolLocal SEO Landing Page Audit
Audit a location page, including its local business markup and other local signals.
GuideSEO audit errors that matter
See how structured data issues rank against crawling and indexing problems.
GuideSEO for Nepali ecommerce
Read a worked Product markup example, with prices in NPR.
ServiceTechnical SEO service
Get markup planned, rolled out cleanly and monitored across your whole site.
Built by
Madhav Kushwaha
SEO, AEO, GEO & Digital Marketing Consultant in Kathmandu, Nepal, and trainer at ODcrU Academy and TechAxis Institute. I built this validator because structured data errors are some of the easiest wins in a technical SEO audit, and the messages in most testing tools don't say what to change. Every rule here follows the schema.org vocabulary and Google's documentation, and the checks are exactly what the code does.
Schema Markup Validator: Frequently Asked Questions
More free SEO tools and ways to learn
Explore the full toolkit, or go deeper with a service or course built from the same client work.