Schema Markup Consulting

What schema markup does, and what it does not

Schema markup is structured data, usually written in JSON-LD, that describes the content of a page using the shared vocabulary at schema.org. It helps search engines understand that a page is about a specific product with a price and availability, an article written by a named person, or a business location with opening hours. Some types make pages eligible for rich results in Google, such as product details or breadcrumbs.

It is worth being clear about the limits. Markup does not make a weak page rank, and eligibility for a rich result does not mean it will be shown. Search engines also change which rich results they display; some features have been restricted to certain kinds of sites or retired over time. I therefore do not recommend markup purely to chase a visual feature. The lasting value is clarity: consistent, accurate descriptions of your entities that search engines and AI tools can rely on.

Markup must also describe what is actually on the page. Marking up reviews that visitors cannot see, or prices that differ from the visible price, conflicts with Google's structured data guidelines and can lead to manual actions. Accuracy comes first. This page is a focused schema engagement; structured data is also covered at a high level in my technical SEO service.

Audit method: by template, not by URL

Schema problems almost always come from templates, plugins or data feeds, so I audit by page type. I crawl the site, extract structured data from each template, and compare it with the rendered page. Then I review Search Console enhancement reports and run representative URLs through validation tools.

For each template I check:

• Which types are present, and whether they describe the main content of the page
• Whether several plugins output overlapping or conflicting blocks
• Whether the organization is defined once with a stable identifier, or redefined differently on every page
• Whether values such as price, availability, author, address and dates match the visible page
• Whether required and recommended properties for relevant rich results are present
• Whether markup is present in the initial HTML or injected by JavaScript, which affects reliability

I also look at where values come from. On ecommerce and catalog sites, the key question is whether price and stock in markup are generated from the same feed as the page. If markup reads a cached value while the page reads live inventory from the ERP, they will disagree sooner or later. That is a systems problem as much as an SEO one, and it is where my ERP integration background helps.

Deliverables and diagnostic examples

The audit report summarizes problems by template and severity. The schema model and JSON-LD specifications give developers exactly what to build: types, properties, data sources, example output and rules for missing values.

Typical findings, described generally:

• Three organizations. The theme, an SEO plugin and a reviews widget each output their own Organization block with different names and logos.
• Stale offers. Product markup shows an item as in stock when the page says it is unavailable, because the markup reads from a cached field.
• Invisible reviews. Aggregate ratings are marked up but the reviews are not shown on the page.
• Generic articles. Blog posts are marked up without an author or with the company as author, missing a chance to connect content to real experts.
• Wrong type. Service pages are marked up as products, or category pages as single products.
• Orphaned identifiers. Entities are defined on each page without consistent identifiers, so nothing links together.

The model ties into entity SEO: the same canonical facts about your company and people drive both your about page and your markup.

Implementation checklist

1. Remove or disable duplicate markup sources, so each entity is output by one system only.
2. Define the Organization once, with a stable identifier, logo, contact points and sameAs links to verified profiles.
3. Add WebSite and BreadcrumbList markup consistent with the visible navigation.
4. Implement template-specific types: Service, Product with Offer, Article with Person author, LocalBusiness for real locations, and others the model calls for.
5. Connect each value to its data source: CMS field, product catalog, ERP or inventory feed, location master or review platform.
6. Define rules for missing data, so markup omits a property rather than outputting an empty or wrong value.
7. Prefer server-rendered JSON-LD where possible, especially on JavaScript-heavy sites.
8. Validate on staging, then spot check production after release.
9. Add schema checks to the release QA checklist and monitor Search Console enhancement reports.

I review pull requests or staging output and confirm each template against the specification. For catalog sites, this work often runs alongside ecommerce SEO, and for location data alongside multi-location local SEO.

Measuring schema markup work

Because markup supports understanding rather than directly driving rankings, I measure it on quality first and outcomes second.

Quality indicators:

• Valid items and error counts per enhancement report in Search Console
• Template coverage: the share of priority templates matching the schema model, tracked as a checklist
• Data consistency: spot checks showing markup values match the visible page and source system
• Regression incidents: releases that broke markup, which should fall as the QA process matures

Outcome indicators:

• Rich result appearance and click-through rate for eligible page types, compared before and after
• Merchant listing and product snippet performance in Search Console for catalog sites
• Brand and entity accuracy in search results and AI answers

On catalog and multi-location sites, I also track how often markup disagrees with the source system. When that number is consistently zero, the integration is working, and the same data discipline benefits your feeds, marketplaces and internal reporting.