Schema Markup Implementation
Structured data describing something the page never says is not an optimisation. A machine can detect the contradiction. Ivan Sp audits and corrects structured data on pages that already exist, rather than generating it at build time. The two jobs look similar and solve different problems. This one finds what is missing or broken on a live site.
What the Audit Checks
Every indexable page gets checked against four faults. No schema present at all is the first. A schema type that does not match the actual page content is the second. Required fields missing from a type that is otherwise present is the third. Malformed JSON that breaks parsing entirely is the fourth.
Malformed JSON is the fault most likely to go unnoticed. The markup can sit on the page looking correct while a single syntax error makes it invisible to search engines. Every page’s markup gets validated programmatically rather than reviewed by eye.
Finding Trust Signals With No Markup Attached
Established businesses often carry real trust signals in their content with no schema connecting them to the page. One professional services page displayed 87 awards and 75 genuine reviews in its visible text. None of it was linked to Review or AggregateRating schema, so search engines had to infer the connection from prose rather than read it directly.
The fix adds the missing schema type using values already present on the page. It never adds a number, a rating, or a count that is not already visible to a site visitor.
The Rule That Governs Every Field
I apply one rule above the rest. An unverifiable or invented value never goes into a schema field. Where a required property has no honest answer, the field gets left as a flagged placeholder for the client to supply. A plausible guess never fills the gap.
Fabricated structured data is a known trigger for a manual action. The risk applies to a rating, a price, or a review count the same way it applies to a fabricated credential in body copy.
Matching Type to Actual Page Purpose
I match schema type to what the page genuinely is. A page mismatching its schema type, such as Product markup on a page with no product for sale, gets corrected to the type the content actually supports.
Review markup is checked hardest, because it only qualifies where a genuine, visible review or rating already appears on the page. Markup describing content the page does not show is a guideline violation, independent of intent.
Where This Sits Against Generated Markup
Sites building new pages at volume generate schema at creation time as part of the template, covered under schema markup automation for generated pages. This audit applies to pages that already exist and were never built with that system.
What This Looks Like in a Support Ticket
Consider an in-house marketer who wakes to a Search Console message about a structured data manual action. Nobody on the team wrote any structured data.
She needs this resolved before the weekly review, and she has no idea where the markup came from. Being blamed for something a plugin did unattended is a particular kind of unfair.
I open the Rich Results Test and find an aggregateRating on four thousand product pages. None of those products has a single visible review, and the plugin never checked.
Where the Standard Schema Advice Breaks Down
- The usual advice
- Install a schema plugin, enable every available type, and let it generate markup across the site.
- What holds up in practice
- More markup types make a breach of Google’s structured data policies more likely, rather than a rich result. Every field is a claim, and an unsupported claim is worse than silence.
Picture a clinic whose plugin cheerfully generates an aggregateRating on every page. The rating looks impressive in the markup and appears nowhere on the site.
Google’s policy requires that structured data describe content visible on the page. The plugin was not asked whether the reviews existed, and it never checks.
I remove fields before adding any. The first pass on most sites deletes more markup than it writes, and the eligible rich results go up rather than down.
An unsupported rating field risks a manual action against structured data, which removes rich results across the whole site rather than on one page.
Four Things Commonly Assumed About Structured Data
Does the structured data on your site describe anything a visitor can actually see?
Ivan Sp meets the same four assumptions whenever a plugin has been generating markup unattended.
| Commonly assumed | What actually holds |
|---|---|
| Schema markup is a ranking factor. | Google has stated it is not. Markup governs eligibility for rich results and helps machines describe entities unambiguously. |
| More markup types means more rich results. | Each type is a set of claims to support. Unsupported claims risk a structured data manual action, which affects the whole site. |
| Valid markup guarantees a rich result. | Validity makes a rich result possible. Google decides eligibility, and it declines routinely for reasons outside the markup. |
| A plugin handles it correctly by default. | Plugins generate against templates without checking whether the underlying facts exist. Rating fields with no visible reviews are the common result. |
| Markup can describe things the page does not show. | Google’s structured data policies require markup to represent visible content. A mismatch is a policy breach rather than an optimisation. |
A rating field with no reviews behind it puts every rich result on your site at risk, not just the page carrying it. No other fault here is worth checking sooner.
Structured Data Reference
- Format Google recommends
- JSON-LD, delivered in a script tag with the type application slash ld plus json.
- Vocabulary
- Schema.org types and properties, which Google reads a defined subset of.
- Core identity types
- Organization, LocalBusiness, Person, and Service.
- Common page-level types
- Article, Product, FAQPage, BreadcrumbList, Event, and Review.
- Entity linking properties
- The at-id property to give an entity a stable identifier, and sameAs to point at external profiles.
- Validation surfaces
- Google’s Rich Results Test, and the Schema Markup Validator at validator.schema.org.
- The governing rule
- Markup must describe content visible on the page, and Google treats mismatches as a violation.
- Eligibility caveat
- Valid markup makes a rich result possible. It never makes one certain.
A Worked Example: A LocalBusiness Block That Contradicts the Page
Consider a clinic whose plugin generated a default markup block years ago. The values below are illustrative and show the kind of drift an audit surfaces. They are not drawn from a client engagement.
| Field | What the markup said | What the page said |
|---|---|---|
| name | Smile Clinic Inc. | Smile Dental Clinic |
| aggregateRating | 4.9 from 210 reviews | No reviews shown anywhere on the page |
| openingHours | Mo-Fr 09:00-17:00 | Open Saturdays, per the visible hours table |
| priceRange | $ | No pricing published |
| @type | LocalBusiness | A service page, not the business homepage |
I remove fields before adding any. The rating block is the serious one, since a rating with no visible reviews breaches Google’s own structured data policy.
Structured data works like a label on a filing box. A label listing contents the box does not hold is worse than no label, because someone acts on it and finds nothing.
The type mismatch in the final row is the quiet one. A service page marked as the business itself competes with the homepage for the same entity.
How a Schema Audit Runs
I work through the sequence below on any site with markup already in place.
- Crawl the site with structured data extraction enabled, and export every type found per URL.
- Group URLs by markup type, and check whether the type matches what each page actually is.
- Run the Rich Results Test on one URL per template, and record every error and warning separately.
- Validate the same URLs against the Schema Markup Validator, which reports vocabulary faults Google ignores.
- Compare every property value against the visible page copy, field by field.
- Remove any aggregateRating or Review markup where the reviews are not visible on the page.
- Add a self-referencing at-id to each identity entity, so pages can reference one entity rather than repeating it.
- Add sameAs values pointing at profiles the business genuinely controls.
- Add BreadcrumbList markup matching the visible breadcrumb trail on each template.
- Re-crawl after deployment, then monitor the Enhancements reports in Search Console for new errors.
How This Work Is Scoped
I scope markup work against template count, since one template fix usually corrects thousands of URLs.
- What arrives
- A per-template markup specification, the removal list, and validated JSON-LD ready to deploy.
- Typical duration
- One to three weeks, depending on template count and platform.
- What the client supplies
- CMS or template access, and confirmation of any factual value entering a field.
- Included
- Audit, removal of unsupported claims, corrected markup, validation, and post-deployment monitoring.
- Not included
- Any promise of a rich result, since eligibility is Google’s decision rather than a build outcome.
- What changes the estimate
- Several page types, an existing plugin injecting markup, or a headless front end.
- How it is quoted
- After a short scoping call, once template count and existing markup are known.
Tools and Primary Sources
The references below define the vocabulary and the rules. Each opens in a new tab.
- Google structured data general guidelines states the content, relevance, and completeness rules markup must satisfy.
- Schema.org vocabulary is the vocabulary itself, listing every type and property with its expected values.
- Rich Results Test reports which Google rich result types a page currently qualifies for.
- Schema Markup Validator validates against the full vocabulary rather than only Google’s supported subset.
- Search Central structured data introduction explains how Google consumes JSON-LD and which formats are supported.
Validate One Page Yourself
I suggest a check that takes about five minutes per template.
- Open the Rich Results Test and enter the URL of your most important page.
- Read the detected item types, and confirm each one matches what the page actually is.
- Expand any rating, review, or price field, and confirm the same value appears visibly on the page.
- Run the same URL through the Schema Markup Validator for a stricter vocabulary check.
A rating in the markup with no reviews on the page is the most common fault worth fixing today. A page type that disagrees with the markup type is the most common one that goes unnoticed.
Common Questions
How is a schema audit different from a Rich Results Test?
Google’s Rich Results Test checks one URL at a time for eligibility. A site-wide audit checks every indexable page for presence, type accuracy, required fields, and syntax validity, then prioritizes fixes by page value.
Will adding schema guarantee a rich result?
No. Valid schema makes a page eligible for a rich result, and Google still decides independently whether to display one. Eligibility is the achievable goal, not the guarantee.
What happens if a required field genuinely cannot be filled honestly?
The field stays empty and gets flagged to the client as a gap. The schema type gets reconsidered if the missing field is fundamental to that type. An invented value is never used to complete the markup.
Does adding schema markup improve rankings directly?
No. Google has stated that structured data is not a ranking factor on its own. The value lies in rich result eligibility and in describing entities unambiguously. Clearer machine-readable descriptions also help systems that summarise a page rather than rank it.
Discuss This Work
The first call is a free 30-minute consultation with no pitch attached. You receive an honest assessment of where the site stands and what can realistically be built.