Schema Markup Automation
Hand-written markup on a large site decays because nobody updates it when the page changes. Ivan Sp generates structured data from the same source that builds the page, so markup and visible content cannot drift apart. Hand-written schema across a large site decays quickly, because every content edit creates a chance for the markup to stop matching.
The Rule That Never Bends
Schema claims must match what a visitor can actually see on the page. Review markup does not go on a page without visible reviews, and a price in Product markup must match the price displayed.
Mismatched structured data is a known trigger for rich-result removal and manual action. Automation makes the rule enforceable, because markup generated from the same data that rendered the content cannot describe something the page does not show.
Required Properties by Type
Each schema type carries properties that must be present for the markup to qualify:
| Type | Required properties |
|---|---|
| Article | headline, author, datePublished, image |
| Product | name, description, image, offers including price |
| FAQPage | mainEntity, acceptedAnswer |
| HowTo | name, step |
| LocalBusiness | name, address, telephone |
Generated markup gets checked against this list before publication. Incomplete markup is not a partial win, because a type missing a required property is usually ignored entirely.
Choosing the Type Per Page
Schema type follows page purpose rather than preference. Service, LocalBusiness, and Organization markup covers business pages. Article and author markup covers editorial content. Product and Review markup covers catalogue pages. FAQPage markup covers genuine question and answer blocks.
FAQPage markup has one additional constraint. Markup only gets added where a real question and answer accordion already exists in the page, with question and answer text pulled verbatim from it. Writing new FAQ content purely to justify the markup inverts the purpose.
Rich Result Enhancements
Beyond the core types, additional markup can earn enhanced search listings. Store rating markup, coupon code markup, and delivery and return policy markup each produce visible additions to a listing.
Enhanced listings raise click-through rate at an unchanged ranking position, which makes them among the cheaper wins available on a catalogue. Each one still requires the underlying fact to be genuinely true and visible.
Validation at Scale
Generated markup gets validated three ways. Syntax gets checked programmatically for malformed JSON. Required properties get checked against the type. Values get compared against the rendered page rather than against the database alone.
Structured data reports in Google Search Console then get monitored after publication, since Google reports parsing failures the generator cannot predict. Structured data audits on existing sites are covered under schema markup implementation and audits.
What Generated Markup Solves
- The drift problem
- Markup written by hand stops matching the page as content changes.
- The generation rule
- Markup is built from the same source that renders the visible page.
- Why drift becomes impossible
- One source feeds both, so a change updates the markup automatically.
- The governing policy
- Markup must describe content visible on the page, without exception.
- Format
- JSON-LD, which Google recommends and which generates cleanly from a template.
- Type selection
- Chosen per page from what the page genuinely is, rather than one type site-wide.
- Required properties
- Vary by type, and a missing required property makes the item ineligible.
- Validation at scale
- Sampled per template rather than per page, since a template fault repeats.
Where the Standard Schema Advice Breaks Down
Does every property in your markup appear somewhere on the visible page?
- The usual advice
- Add every property the vocabulary supports, since richer markup gives search engines more to work with.
- What holds up in practice
- Every property is a claim that must appear on the visible page. Adding properties the page does not support turns richer markup into a policy breach. A structured data manual action affects the whole site rather than one page.
Picture a template generating aggregateRating on every product page, because the vocabulary supports it and the field was available.
Most of those products have no reviews. The markup now claims a rating on thousands of pages where nothing visible supports it.
Ivan Sp generates a property only where the source holds a real value for that row. Conditional generation is what keeps a template inside the policy at scale.
A template fault repeats across every page it renders. One unsupported property becomes thousands of policy breaches in a single deployment.
A structured data manual action removes rich results across your whole site. One template-level mistake is all it takes.
Four Things Commonly Assumed About Generated Schema
Which of these describes your current markup?
I meet these four assumptions on most schema automation work.
| Commonly assumed | What actually holds |
|---|---|
| More properties means better markup. | Every property is a claim requiring visible support. Unsupported properties are a policy breach rather than an enhancement. |
| One schema type can cover a whole site. | Type follows what each page actually is. A service page marked as the organisation competes with the homepage for the same entity. |
| Markup can be added after the pages are built. | Markup added separately drifts as content changes. Generating both from one source is what prevents drift entirely. |
| Validation means checking every page. | A template fault repeats identically. Sampling per template catches the same faults for a fraction of the effort. |
| Valid markup produces a rich result. | Validity makes eligibility possible. Google decides whether to show a rich result, and declines routinely. |
One conditional rule in a template prevents thousands of unsupported claims. Writing it costs an hour and it protects every rich result on the site.
A Worked Example: Conditional Generation
Consider one product template generating markup two ways. The comparison below is illustrative, written to show what a conditional rule changes. No client engagement is described here.
| Property | Unconditional template | Conditional template |
|---|---|---|
| name | Always generated | Always generated |
| offers price | Always generated | Generated where a price exists |
| availability | Always generated as InStock | Generated from the real stock field |
| aggregateRating | Always generated | Generated only where reviews are visible |
| Pages claiming a rating with no reviews | About 4,000 | 0 |
| Structured data policy exposure | Site-wide | None |
I write the conditional into the template rather than auditing afterwards. The fourth row is where site-wide exposure comes from.
An unconditional template is a form letter that fills every field whether or not the data exists. Every blank becomes a confident wrong answer.
The availability row matters commercially. Marking everything as in stock produces disapprovals and disappointed buyers at the same time.
How Schema Generation Gets Built
I generate markup from the same source that renders the page, so the two cannot diverge.
- Map each page type to the schema type that describes what the page genuinely is.
- List the required properties for each type, since a missing one makes the item ineligible.
- Map every property to a field in the data source rather than to a template constant.
- Write a conditional rule for every property that is not present on every row.
- Prohibit generating any property the visible page does not display.
- Render markup and visible content from the same fields, so a change updates both.
- Add a self-referencing identifier per entity, so pages reference one entity rather than repeating it.
- Validate one URL per template against the Rich Results Test before deployment.
- Validate the same URLs against the Schema Markup Validator for vocabulary faults.
- Monitor the Enhancements reports in Search Console after each batch deployment.
How This Engagement Is Scoped
I scope schema automation by template count, since one template fix corrects every page it renders.
- What arrives
- A type mapping per template, conditional generation rules, and validated sample output.
- Typical duration
- Two to four weeks, depending on template count and platform.
- What the client supplies
- Template access, the data source, and confirmation of any factual value.
- Included
- Type mapping, property mapping, conditional rules, validation, and post-deployment monitoring.
- Not included
- Any promise of a rich result, since eligibility is Google’s decision.
- What changes the estimate
- Several page types, existing plugin markup to reconcile, or a headless front end.
- How it is quoted
- After a short scoping call, once template count is known.
Tools and Primary Sources
The references below define the vocabulary, the format, and the policy. Each opens in a new tab.
- Google structured data policies states the requirement that markup describe visible page content.
- Schema.org vocabulary lists every type and property with the values each expects.
- Rich Results Test reports which rich result types a generated page qualifies for.
- Schema Markup Validator validates against the full vocabulary rather than Google’s supported subset.
- Product structured data documents the required and recommended properties for catalogue pages.
Check One Template Yourself
I suggest a check that finds the most common template fault.
- Open the Rich Results Test and enter one URL per template on your site.
- Expand any rating, review, price, or availability property in the results.
- Open the same URL and search the visible page for that exact value.
- Note every property that appears in markup and nowhere on the page.
A rating in the markup with no reviews on the page is a template fault, not a page fault. Whatever you find repeats on every page that template renders.
Common Questions
Does more schema improve rankings?
Structured data is not a ranking factor on its own. The markup makes entity relationships explicit rather than inferred, and it enables rich results that raise click-through rate at the same position.
What happens if a product price changes?
Markup regenerates from the same data that renders the price, so the two update together. Hand-written markup is where price drift usually starts.
Can schema be added without touching page templates?
Sometimes, through a tag manager. Rendering markup that way works, though it is more fragile than template-level output and gets used only where template access is unavailable.
Should markup be generated or written by hand?
Generated, wherever a data source exists. Hand-written markup drifts as content changes, and generating both from one source removes the possibility of drift entirely.
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.