Technical SEO
Structured data implementation
This is the narrowest useful unit of Technical SEO: describe your pages in the vocabulary machines read, correctly and in sync with what is visible.
Structured data implementation: what it is and what it is not
Describe your pages in the vocabulary machines read, correctly and in sync with what is visible. In practice that means choosing the right types per template rather than applying one everywhere, and then the harder half: implementing valid JSON-LD with the required and recommended properties populated.
Why this work exists
It is the first thing a competent competitor will have done, and the last thing most briefs mention.
Technical SEO holds the whole discipline. This page is one defined piece of it.
The nearest piece of work to it is making the mobile markup carry the same content as the desktop markup. Where that is already handled, this moves faster than the estimate; where it is not, the two get done together or neither of them holds.
What good looks like
The sign it is working is that nothing surprising happens. Changes are noticed on the day they are made rather than in the next quarterly review.
The gap between that and where most accounts start is why this is scoped as structured data implementation rather than as a line inside something larger. Finding the images that are five times larger than the box they render in is the usual second step once it is in place.
When this is the right work
What makes this the next piece of work:
- Markup validates but describes a type the page is not
- Marked-up content does not appear on the page
- Each page carries three unrelated schema blocks that contradict each other
If none of those is true, something else is probably the constraint, and the Technical SEO overview maps the alternatives. The usual neighbours are sorting which 404s deserve a redirect and which deserve to stay gone and reading the server log rather than guessing what the crawler did.
What the work covers
In order, the work is:
- Choosing the right types per template rather than applying one everywhere, scoped against what the business can actually act on rather than what is possible.
- Implementing valid JSON-LD with the required and recommended properties populated. Slow, unglamorous, and the reason the rest holds up.
- Connecting entities with identifier references so the graph is coherent rather than a pile of fragments. Worth doing badly rather than not at all, if time is short.
- Adding validation to the build so invalid markup cannot be published. Slow, unglamorous, and the reason the rest holds up.
How it runs
How an engagement on this actually proceeds.
The second look
A fortnight after the first pass, the same ground gets covered again with fresh eyes. The second pass finds a different class of problem from the first.
Bringing in whoever owns the system
Developers, agency partners or whoever actually controls the platform get involved before recommendations are written, not after they are rejected.
Proving it in one place first
Changes get made to a small, representative slice and measured there before being applied everywhere. It is slower for three weeks and faster for the rest of the year.
What each part runs into
Where each part tends to meet resistance:
- Choosing the right types per template rather than applying one everywhere, and in Noida the constraint on it is a market where buyers qualify by area rather than by city
- Implementing valid JSON-LD with the required and recommended properties populated, harder in Chennai because of a competitive set that changes street by street
- Connecting entities with identifier references so the graph is coherent rather than a pile of fragments – in Chandigarh, complicated by the fact that a decision made by somebody who never visits the site
- Adding validation to the build so invalid markup cannot be published, which in Manchester runs into a procurement step nobody accounted for
The mistake most often made here
Treating schema as a ranking lever. It makes meaning explicit; it does not make a weak page strong.
The reason it matters is that the failure is invisible from the report: the activity happened, the number did not move, and the conclusion drawn is usually the wrong one.
How it is measured
Valid markup coverage by template, and eligible rich result types earning impressions. That measure is agreed before the work starts, so there is no argument about the result afterwards.
The point of the number is to settle an argument, so it is chosen for being hard to dispute rather than for being flattering.
What you end up with
You are left with a schema specification per template, implemented and validated, with validation enforced in the publishing process.
Structured so one section can be lifted out and sent on without the rest.
How it differs by sector
This work is not sector-neutral, and the differences are specific:
- For Marketplaces and platforms, two sides to acquire, and a programmatic page set that can sink the whole domain. and that shapes how far this can go.
- Finance and fintech brings its own limit: regulated claims, compliance review in the publishing path, and trust signals that have to be real.
- Real estate and property, constrained by the fact that portals own the generic demand, so the win is locality authority and the specific listing.
The industry pages carry the rest of that detail. Marketplaces and platforms and Finance and fintech are the two where this piece of work most often decides the outcome.
Common questions
Does structured data improve rankings?
Not directly, and anyone claiming otherwise is overselling it. What it does is make eligibility for specific result features possible and make the page’s meaning explicit to systems that parse rather than read. Both are worth having; neither substitutes for the page being good.
What happens if markup does not match the visible page?
It is a structured-data policy violation, and the consequence can be loss of all rich-result eligibility across the domain rather than just on that page. Markup has to describe what a user actually sees, which means it needs to update when the content does.
What if we disagree with the diagnosis?
Then we look at the data together. Valid markup coverage by template, and eligible rich result types earning impressions is the test, and a finding that cannot survive being questioned is not a finding worth acting on.
Does anything need doing before structured data implementation?
Sometimes. The signals above are the honest test, and where something upstream is the real constraint we will name it even though it is not the work on this page. If a number has to be defended at the end of the quarter, Do we need a blog? and Does Google penalise AI-written content? are where that starts.
Is there a minimum worth doing?
There is a point below which the measurement cannot detect a change, and we would rather say so than take the work. Valid markup coverage by template, and eligible rich result types earning impressions has to be able to move for the engagement to mean anything. Two of these come up often enough to be worth reading first: Hallucination and HTML sitemap.
Ask about structured data implementation
No brief needed. One paragraph about where you are stuck gets a specific answer back.
Find out what is actually holding this back
Send us your site and your goals. You will get an honest read on the gaps worth fixing first, whether or not you work with us.