A comprehensive schema markup auditor that extracts JSON-LD, Microdata, and RDFa from any URL, validates against schema.org vocabulary, checks Google rich result eligibility, and surfaces the specific property gaps blocking your structured data from working. Get a scored report with exact fix instructions for every issue found.
A focused audit built around the signals that actually move rankings for Technical SEO.
Most SEOs treat schema as a checkbox — add it, move on, done. That's missing what's actually changed. Google's AI systems (Gemini, AI Overviews, the Knowledge Graph) consume structured data differently than the old crawl-and-index model. When a page has clean, accurate schema, it becomes a machine-readable source that AI systems can confidently cite and include in generated responses. When it's broken or absent, the AI has to guess from raw HTML — and guessing means your content gets deprioritized in favor of sites that give unambiguous signals.
Rich results are the tangible win most site owners think about. Pages with schema get roughly 40% more clicks on average compared to the same ranking position without them. The mechanism here is CTR, not rankings — schema doesn't directly move you up. What it does is make your result take up more visual space (star ratings, FAQ dropdowns, recipe cards, breadcrumbs) and signal to users that your page contains exactly what they're looking for. Lower position with rich results often outperforms higher position without them.
There's a second, increasingly important dynamic: Google's trust scoring. Bad schema isn't just ineffective — it actively signals low quality. If you mark up fake reviews, use fabricated aggregate ratings, or apply a Product schema to a blog post, Google's systems flag that as a trust violation. It's the structured data equivalent of hidden keyword stuffing. The algorithms are increasingly sophisticated about detecting mismatches between what you claim in schema and what's actually visible on the page.
That disconnect between schema claims and page reality is the most common penalty-triggering mistake I see in technical audits. A product page with a 4.8-star rating in schema but no visible reviews. An article claiming to be published yesterday with content that hasn't changed in two years and no date visible to users. These mismatches erode trust — and in 2026, trust is harder to rebuild than rankings.
These aren't hypothetical — these show up in real audits, on real sites, causing real lost traffic.
The most common version: an ecommerce category page (/products/running-shoes/) with Product schema applied. Category pages list multiple products — they're not products themselves. Product schema on a category page tells Google this single page is a product with a specific price. The result: Google gets confused, Product rich results don't appear, and the schema may be ignored entirely. Product schema belongs on individual product detail pages only.
This appears constantly on newer sites that want to look established. They add aggregateRating with a 4.7 rating and "234 reviews" — but there are no reviews visible on the page, or the reviews live on a different page entirely. Google's requirement is explicit: rating data in schema must be visible to the user on that same page. This isn't theoretical risk. It's an active violation that can trigger manual review and loss of rich result eligibility sitewide.
A blog's index page (/blog/) is not an article. A category archive (/category/news/) is not an article. Paginated views (/page/2/) are not articles. Article schema should only appear on the individual, full-content post URL — and only if the page content actually is the article, not a list of articles. Applying it to dynamic, auto-generated archive content confuses Google about what the article actually is and when it was published.
Google's rules are explicit: FAQPage schema must reflect Q&A content that is visible to users in Q&A format on the page. A common abuse pattern: marking up FAQ schema with questions that exist only in the JSON-LD, not in the HTML. Or questions taken from a different page applied to a product page to game FAQ snippets. Google detects this. You won't get a manual action necessarily, but you'll lose eligibility and flag the site for lower quality trust scoring.
Not the full schema.org vocabulary — the types that generate real results for real websites.
Blog posts, long-form content, and news pieces should use Article or its subtypes. Google uses Article schema to surface content in Featured Snippets and AI Overviews — when someone asks a question your article answers, clean Article schema increases the probability Google attributes the answer to you. The things that typically break it: missing datePublished (Google needs freshness signals), a plain-text author string instead of a structured Person object, and applying it to paginated archives instead of the individual article page.
Required for rich results: headline, image, datePublished, author (Person object)
If you sell anything, Product schema is non-negotiable. The critical properties are name, price, priceCurrency, and availability — and that last one catches people off guard. It's not just the word "InStock," it needs to be the full schema.org URI. What Google actually checks: they compare the price in your schema to the price visible on the page. If those don't match — and they get out of sync constantly with sale prices and dynamic pricing — you get flagged for potentially misleading users. Any time your pricing logic changes, audit your Product schema.
Required: name + offers.price, offers.priceCurrency, offers.availability
If you have a physical location or serve a specific area, this feeds Google Maps, the local pack, and voice search results. The mistake I see on corporate sites: they add LocalBusiness schema to their HQ homepage as a "brand" signal. The problem: LocalBusiness implies customers can visit or be served at that address. If someone in a different city sees your site in local results based on that schema, you've misled them — and Google knows it. LocalBusiness schema is for pages representing real locations, not brand-level homepages.
Required: name, address (PostalAddress with streetAddress, addressLocality)
This is the homepage schema most sites need and most sites get wrong. Organization tells Google who you are: official name, website URL, logo, and social profiles (via sameAs). Getting this right makes you eligible for a Knowledge Panel. The most common gap: missing sameAs links. Google uses sameAs to cross-validate that the entity in the schema matches the entity they know about across the web — LinkedIn, Twitter/X, YouTube, Facebook, Wikipedia. List them all.
For Knowledge Panel: name, url, logo + sameAs array (all major social profiles)
Google restricted FAQ rich results in August 2023 — they're now only shown for government and health sites in most cases. But FAQPage schema still matters because LLMs and AI systems use it to understand your content's Q&A structure. Keep it if your questions actually appear on the page in Q&A format visible to users. Remove it if you're marking up questions that exist only in the JSON-LD. The schema without the visible content is a trust signal violation, not an opportunity.
Required: mainEntity array of Questions, each with name + acceptedAnswer.text
Underrated and under-implemented. BreadcrumbList schema replaces URLs in your search result snippet with navigation breadcrumbs — cleaner and more useful for users. It also helps Google understand site hierarchy. Implementation is straightforward: a list of ListItem objects with position, name, and item (URL). Most CMS platforms support it natively or via plugin. If you're on a custom build, this is the easiest rich result to add with the highest implementation-to-impact ratio. Don't skip it.
Required: itemListElement array with ListItem objects (position + name + item URL)
If you're implementing schema in 2026, JSON-LD is the only format worth your time. It lives in a <script type="application/ld+json"> block in your HTML — usually in the head, though the body works too. It doesn't touch your visible content structure at all. You can update schema markup without touching page layout. With Microdata or RDFa, schema data is woven directly into your HTML attributes, making maintenance harder and conditional rendering messy. Google reads all three formats equally — choose JSON-LD for development practicality.
The typical implementation workflow: identify what schema type belongs on each content template (homepage → Organization, blog posts → Article, product pages → Product, location pages → LocalBusiness), draft the JSON-LD for one example, then validate it with Google's Rich Results Test before deploying across templates. Important: validate, then check eligibility separately. Google's Rich Results Test will tell you a schema block is syntactically valid without confirming it qualifies for rich results. Validity means the JSON parses and the @type is recognized. Eligibility means you have the exact required properties for that specific result type.
Deploy through templates so one change updates all pages of that type. Monitor in Google Search Console → Enhancements — errors appear within days of deployment. If rich results disappear from Search Console, something in your schema changed, and this tool is the fastest way to find what.
The vocabulary standard is schema.org. Don't invent property names or use markup from outdated tutorials that reference data-vocabulary.org. schema.org is maintained collaboratively by Google, Microsoft, Yahoo, and Yandex. If a property you want doesn't exist in the vocabulary, use the closest available one or leave it out — inventing properties wastes the signal.
A 30-minute technical SEO strategy call covers your audit results, a prioritized roadmap, and what implementation actually looks like.