The Short Answer
Most structured data errors in Search Console come from four causes: the wrong type in a field that only accepts certain types, a schema type that does not fit the page, addresses inside the markup that are not the final canonical address, and markup that claims something the visible page does not show. Fix each at the template that produced it, test the rendered page, deploy, and only then ask Search Console to validate. And fix the build, not just the page, because every one of the errors below came back at least once on our sites before we made the build refuse it.
The one sentence version
Find the template that wrote the error, fix it there, test the rendered page, and add a check so the same error cannot ship again.
Errors, Warnings and Statuses Are Not the Same
Search Console mixes three kinds of message, and treating them alike wastes time. An error makes a page ineligible for a rich result. A warning means a recommended field is missing and the page may still be eligible. A status in the page indexing report, such as page with redirect or alternate page with proper canonical, often describes your site working as intended. Validate Fix is for errors you have actually fixed; pressing it on an intentional status always fails, because nothing was wrong.
| Message type | Example | What to do |
|---|---|---|
| Error | Invalid object type for field isPartOf | Fix the template, then validate |
| Warning | Missing field license | Add the field if you have a true value |
| Status | Page with redirect for an address you redirect on purpose | Leave it; do not validate |
| Status caused by your markup | Page with redirect for addresses printed inside your schema | Fix the addresses in the markup |
Dataset: Invalid Object Type for isPartOf
Google's Dataset documentation allows isPartOf and hasPart to hold either a plain address or another Dataset, and a nested Dataset must carry every required Dataset property itself. A study page that says its Dataset is part of a WebPage breaks that rule, and Search Console reports an invalid object type. We hit this on a CV product's study pages in August, fixed it, and hit it again on 30 October when a new page type reused the old pattern. The same day Search Console warned that the license field was missing.
Remove the WebPage parent
Delete isPartOf when it points at a WebPage, or replace it with the plain address of the parent page.
Add a license
Give license as an address that identifies a specific version of the license, for example a Creative Commons licence page.
Check the description length
Dataset descriptions must be between 50 and 5,000 characters.
Add a creator
Name the person or organization that produced the data.
Fix every page type that prints it
Search for the pattern in every template, not only the page in the report.
Merchant Listings Errors on Software Pages
Product markup tells Google you sell a physical item, so Google checks it against merchant listing requirements: an image, shipping details, a return policy. Put Product on the pricing page of a software subscription and Search Console reports critical errors for fields that make no sense for software. We did exactly this on software pricing pages in August, and the same markup gave the brand as a bare reference to another object, which Google also rejected.
| What was there | Error | What to use instead |
|---|---|---|
| Product on a software pricing page | Missing image, shipping details and return policy | Software application markup, with offers |
| brand given as a reference with no type | Invalid object type for field brand | An inline Organization or Brand with a name |
| WebApplication with no rating | Invalid item | Leave it out, or use software application markup only with real reviews |
SoftwareApplication needs real ratings
Google's rich result for software requires a name, a price in offers, and either an aggregate rating or a review. If you have no genuine reviews, accept that the rich result is unavailable. Never invent a rating to satisfy a required field; fabricated ratings are a spam policy violation that can cost a site far more than a missing star.
Page With Redirect Caused by Your Own Markup
Every address inside structured data is an address search engines may crawl. If the markup prints a version that redirects, for example without the trailing slash your site adds, each page points crawlers at a redirect and the page indexing report fills with redirect statuses you did not create on purpose. We fixed this on our agency site in the summer, then articles written in September reintroduced the slashless form in ten places, because the article generator still printed it.
List every address in the markup
Extract url, id, sameAs, author, publisher, image and breadcrumb item values from the rendered page.
Request each one
Any address that answers with a redirect is a problem, even when the redirect is correct.
Print the final form
Use the exact canonical address, with the same protocol, host and trailing slash as the canonical tag.
Fix the generator
Change the function that builds the addresses, not the pages it already produced.
Breadcrumbs are the most common source. On a directory site we run, every listing's breadcrumb pointed at a section address with a trailing slash that the site removes, so it redirected. One line in the listing template fixed every page on 2 November 2026.
Markup That Does Not Match the Page
Structured data is a statement about the visible page, and Google treats a mismatch as a reason to ignore the markup. Three patterns cause most mismatches.
FAQ markup without the visible FAQ
Every question and answer in FAQPage must appear on the page, word for word. Render both from one source.
Reviews nobody can see
Ratings in markup must be backed by real reviews shown on the page.
Dates that disagree
datePublished and dateModified must match the visible published and updated dates.
Our own reviews page showed a related warning in October: reviews nested inside the organization they review also pointed at it again, a directional conflict Search Console reports as a nested object that cannot contain itemReviewed. Our guide to fixing review snippet errors covers that one in full.
Indexing Problems That Start in the Sitemap
Some structured data and indexing problems are really sitemap problems. A page marked noindex but still listed in the sitemap appears as excluded by noindex, because the sitemap asked for a page the page itself refuses. A sitemap that stamps every address with today's date on every deploy tells search engines that everything changed, so nothing stands out. Keep the sitemap a list of pages you want indexed, with honest last modified dates.
| Sitemap problem | What Search Console shows | Fix |
|---|---|---|
| A noindex page in the sitemap | Excluded by noindex | Remove it from the sitemap |
| Redirecting addresses in the sitemap | Page with redirect | List only final addresses |
| Every lastmod set to the deploy time | No direct error; new pages stand out less | Real dates per page |
How to Find the Template Behind an Error
Search Console lists affected pages, not the code that produced them. Finding the source takes four steps, and it is worth doing before touching any page, because the page you fix by hand will be overwritten the next time the template runs.
Export the affected examples
Download the list of affected addresses from the report, not just the first few shown.
Group them by page type
If every affected address shares a path pattern, one template is responsible.
Search the code for the field name
The property named in the error, such as isPartOf or brand, appears in very few places in a codebase.
Compare with a clean page type
A similar page type without the error shows what the broken template does differently.
Keep a Table of Every Error You Have Met
When we swept our own project notes at the end of October, three of the five structured data and metadata errors we found had already happened twice. Each fix had been correct; none had been written anywhere the next template could see it. The cure was a single shared table with four columns: the message as Search Console states it, where we met it, the cause, and the rule that prevents it. It is short, it lists only errors we actually caused, and it is read before any schema change on any site. Every rule in it that a script can check became a build check.
Structured Data and AI Assistants
Assistants mostly read the visible page, but structured data still shapes how machines understand who you are, what you sell and how pages relate. Markup that calls a subscription a physical product, or names a parent page that does not exist as a dataset, gives every system that reads it a wrong fact about you. Correct, minimal markup that matches the page is the safest choice. Our guide to entity SEO and the knowledge graph covers the markup that defines an organization and its people.
A Check That Runs on Every Build
The reason these errors kept returning on our sites is that each fix lived in someone's memory instead of in the build. Now every site runs the same check on the rendered page before and after deploy, and fails on the known causes.
Parse every structured data block
Fail on anything that does not parse.
Check Dataset rules
Name present, description 50 to 5,000 characters, license and creator present, isPartOf only a Dataset or plain address.
Block the wrong types
No Product on software pages, no WebApplication, no brand as a bare reference.
Check ratings and FAQ
No rating without stored reviews; FAQ markup must match the visible FAQ.
Check every address
Every address in the markup must be the final canonical form and answer without a redirect.
Check titles and descriptions
Titles 60 characters or fewer, descriptions 50 to 160, one self canonical.
Run it against the origin as well as the public address, because a cached copy at the edge can hide a broken page underneath. The technical SEO checklist has the rest of the deploy checks, and our guide to schema for AI search explains which types are worth having at all.
Validating the Fix
Validate only after every template that produced the error is fixed and deployed. Search Console rechecks the affected pages over the following days and reports started, passed or failed. If it fails, open a failing example, test the live rendered page, and look for a second template printing the same pattern. Do not press validate on statuses that describe your site working as intended. And keep a note of the date you validated, so that if the same error reappears months later you can see whether a new template caused it or the old fix never fully landed.
Common Mistakes
Fixing the page in the report
The template that made it will make the next one. Fix the source.
Choosing a type for the rich result
Pick the type that describes the page truthfully, not the one with the best snippet.
Filling required fields with guesses
A guessed rating or date is worse than a missing field.
Validating statuses
Intentional redirects and canonicals are not errors and never pass.
The Bottom Line
Structured data errors are rarely mysterious. They come from a field holding the wrong type, a type that does not fit the page, an address that redirects, or a claim the page does not back up. Fix them where they are generated, verify the rendered page, validate only real errors, and turn each fix into a build check. The errors that cost us the most time were not the hard ones. They were the easy ones we fixed twice.