Your Schema Can Pass Validation and Still Misrepresent the Business

Structured data can pass every syntax test and still describe the wrong business, product, person or page. Validation proves that a machine can parse the code. It does not prove that the claim is true, visible, current or eligible for a particular search feature.

That puts the visible page, evidence and accountable fact owner ahead of the plugin. The markup comes later.

Begin with the page job, not the type menu

A plugin can offer dozens of schema types before anyone has decided what the page is principally about. That is how an organisation, person, service, product, review, FAQ and several unrelated concepts end up injected into every template because a bigger graph looks more sophisticated. Start with five questions:

1. What is the main thing this page is about?
2. Which visible facts define that subject?
3. Which reader decision does the page support?
4. Is there a documented search feature relevant to this page type?
5. Which system and person maintain each changing fact?

If the first two answers are unclear, schema will encode the confusion rather than fix it. Google describes structured data as a standardised format for classifying page content and providing explicit clues about meaning. It also says not to mark up information that is not visible to users (Google: introduction to structured data).

I call this the Page-before-Graph Rule: establish the visible subject, claim and relationship first. Only then decide whether structured data can represent them usefully.

Build a visible fact inventory

For a product page, the inventory might include name, description, images, price, currency, availability, SKU, brand and review information. For a physical location, it might include business identity, address, telephone, opening hours and the actual nature of the location. Classify every candidate field:

Google’s general structured-data policies require markup to represent the main content and avoid hidden, irrelevant or misleading information (Google: structured-data policies). The inventory is deliberately boring. That is its strength. It stops a developer encoding “nationwide”, “award-winning” or “available” because those words appeared in a marketing field nobody was responsible for maintaining.

Choose a type for truth, not ambition

A service-area business should not invent a staffed branch. A category is not automatically a Product. A testimonial does not automatically qualify for review markup. A list of objections is not necessarily an FAQ. Schema.org provides a broad vocabulary. Google supports particular search features with additional technical and content requirements. The existence of a type or property does not promise that Google will display it.

This distinction protects against two sales tricks: “Schema.org has a type for it, so Google will show it,” and “Google did not show a rich result, so the implementation failed.” Google explicitly says valid structured data creates eligibility rather than guaranteeing a rich result. Search appearance may vary by query, user, device and other factors (Google: structured-data policies).

One source should feed visible and structured facts

Prices, stock, opening hours, event dates, author records and product variants change. Markup becomes dangerous when the visible page, plugin and custom script each maintain a different copy. Where practical, generate the visible value and structured value from the same authoritative field. A stock update should not depend on someone remembering hidden JSON. A change in branch hours should not leave last year’s timetable in a sitewide template. For every changing fact, record:

An omitted optional field is often safer than a stale field nobody owns. Completeness is not the goal when the extra properties increase contradiction. My preference is single-source, dual-surface publishing: one maintained fact, expressed visibly for people and structurally for machines.

Keep the graph explainable

Several related objects can describe a page appropriately. An Article can identify a Person author and an Organization publisher. A Product can carry an Offer. A WebPage can contain a BreadcrumbList. Every node and relationship should answer an ordinary question: what is this page; what is its primary subject; who created or published it; what offer or object is actually visible; and how does this relationship follow from the page?

Stable identifiers can keep repeated entities consistent. They cannot resolve uncertain identity, contradictory facts or invented relationships. I would rather maintain three well-supported nodes than thirty decorative ones nobody can explain after the developer leaves. Complexity is justified when it preserves a real distinction used across the site. It is theatre when the graph grows because a tool can emit more code. Vocabulary is permission to describe a fact. It is not permission to create one.

Validation has three different jobs

Teams often use “validated” as though one green result settled everything. I separate three validation layers.

The first two can reveal technical faults. They cannot verify that a qualification belongs to the named person, that an address is a staffed customer-facing branch or that a commercial promise is current. Use Google’s Rich Results Test for documented Google features and an appropriate Schema.org validator for broader vocabulary. Then inspect a live production URL rather than stopping with a copied code fragment. The green test result is the beginning of reality validation, not the end.

Compare the live page with the code

For each representative URL, check:

1. Does the rendered page contain the expected markup?
2. Does the primary type match the visible subject?
3. Are required properties present for the intended feature?
4. Do URLs and images resolve?
5. Do visible and structured values agree?
6. Has another plugin or theme emitted a duplicate or conflicting object?
7. Can Google crawl and index the page?
8. Can the accountable owner explain each consequential claim?
9. Does an absent field fail safely?

This is the Same Story Test: a visitor reading the page and a crawler reading the structured data should receive the same material account of the business. If the code makes the company appear more qualified, available, reviewed or locally present than the page can prove, the implementation is not an optimisation. It is a hidden contradiction.

Release by template, then sample reality

Template changes can affect thousands of URLs. A demonstration page with complete data rarely reveals what happens to sparse, expired or unusual records. Test representative conditions before full release:

• A complete record
• A sparse record
• An unavailable product
• A page with no reviews
• Unusual opening hours
• An expired event
• A missing image
• A translated or regional variation
• Any condition likely to expose faulty logic

After deployment, sample live URLs from every affected template. Caching, minification, client-side injection, translation, plugin priority and theme updates can change the final output. Keep rollback straightforward. A search enhancement is rarely worth leaving contradictory production code live while teams debate ownership.

Measure the feature, not “schema installed”

“Schema installed” is a release note, not a business outcome. Record which page type changed, which feature the work intended to support, when the live pages were processed and which eligible search-appearance data became available. Where sufficient data exists, compare a stable page group while accounting for other releases, seasonality and selection bias. Google recommends using Search Console and, where possible, before-and-after testing across pages with enough data, while recognising that performance changes for many reasons (Google: measuring structured-data effects).

Keep four states separate: technical eligibility; observed appearance; visits or Search performance; and commercial outcome. One does not automatically prove the next. An absent rich result does not prove the implementation is wrong. A richer result does not prove that every click change came from the markup.

Give every type an owner and an exit

Every markup type should have:

• an accountable owner;
• an authoritative source;
• a representative validation sample;
• an update trigger;
• a failure behaviour;
• a retirement rule.

Recheck after theme changes, plugin replacements, feed updates, business-detail changes and material guideline revisions. Remove markup when the page no longer supports it, when duplicate systems cannot be reconciled or when the intended feature no longer justifies maintenance. Code does not become valuable merely by surviving in the template.

My final approval question is simple: if the visible page disappeared and only the structured data remained, would the code tell a more flattering story than the business can prove? If yes, stop. Fix the page, the fact or the markup source. Passing validation is not permission to publish a machine-readable exaggeration.