Schema Markup Services Built on Valid, Maintained JSON-LD
Markup is the only part of SEO that ships as code and fails silently. We write it per template, validate it against the fields Google actually requires, and keep it from drifting out of sync every time your product data changes.
- Scope
- Templates, not pages — home, category, detail, article, FAQ
- Output
- JSON-LD blocks merged by @id, no microdata leftovers
- Gate
- Zero errors in the Rich Results Test before deploy
- Handover
- Fixture files plus a regression checklist for CI
Send one product URL and we will return its current parsed type set, free.
Markup that validates can still earn nothing
Most schema work fails in one of two directions. Either the block is copied from a generator, passes a validator, and describes a business that is not on the page — so Google ignores it. Or it is correct on launch and then slowly rots: prices change format, a new template ships without markup, a developer duplicates the entity, and six months later the enhancement report is a wall of warnings nobody reads.
Both failures share a cause. Markup was treated as a one-off file rather than a template contract with required fields, ownership and a test. Our schema markup services are built around that contract, which is why every engagement starts with the data model rather than with a snippet library.
- Wrong type for the page — Product markup on a category page, Article markup on a service page
- Invisible content — reviews, FAQs or prices in the JSON-LD that a visitor cannot see anywhere
- Orphan entities — nested objects with no @id, so the same company exists four times on four URLs
- Format drift — "1.299,00 €" where the parser expects 1299.00 and an ISO currency code
- Client-side injection — markup added after interaction, arriving late or not at all
- Duplicate blocks — two plugins both emitting Organization, with different names
Which types actually change what a buyer sees
Structured data is not decoration. Four types carry most of the practical value for a B2B or storefront site, and each one does a different job. The table is the honest version: what it can change, and what it will never do.
| Type | What it can change | Non-negotiable fields | Use it when |
|---|---|---|---|
| Service | No dedicated visual feature. Clarifies the entity for knowledge panels, brand queries and AI answer surfaces. | name, serviceType, provider, areaServed | Every service or capability page on a B2B site |
| FAQ | Accordion treatment is now limited to government and health sites. Value sits in entity clarity, not in the fold-out. | mainEntity, Question, acceptedAnswer | Only where the same questions are visible on the page |
| Product | Price, availability, rating and shipping annotations in shopping surfaces. | name, offers.price, priceCurrency, availability | One product per detail page, never on listings |
| Organization | Brand entity signals: logo, sameAs profiles, contact points, address. | name, url, logo, sameAs | Once per site, referenced everywhere by @id |
The nesting rule that saves months
Give every entity a stable @id and reference it instead of repeating it. The Organization lives once, at the site root, and every Service, Product and Article points back to that identifier. Nested objects keep the graph connected, duplicated objects split it. When the same company appears as four unrelated blobs, Google has to guess which one is true — and it usually guesses by ignoring all of them.
The second rule is that required fields are only the entry ticket. A Product without offers.price will not produce a merchant annotation, a Service without provider is a name with no owner, and an Organization without sameAs has no way to connect your site to the profiles that already describe your brand.
The errors we keep finding on live sites
"price": "€1,299.00"
"priceCurrency": "EURO"
"availability": "In stock"
"datePublished": "12/03/2025"
"price": 1299.00
"priceCurrency": "EUR"
"availability": "https://schema.org/InStock"
"datePublished": "2025-03-12"
Every field above looks reasonable to a human and fails a parser. Prices must be bare numbers with the currency in a separate ISO 4217 field. Availability must be a schema.org enum URL, not a translated label. Dates follow ISO 8601. Ratings must come from real, visible reviews, and self-serving reviews about your own organisation are not eligible at all.
Two more that break whole templates: a canonical that disagrees with the markup @id, and a product variant matrix where colour and size variants all claim to be the same product with different prices. Both produce valid syntax and contradictory meaning, and contradictions are how you lose an enhancement rather than win one.
Rich results and the CTR question
A result that shows price, availability and a rating takes more vertical space and answers a question before the click. That is the whole commercial argument: markup does not raise your position, it changes how much of the decision happens on the results page.
We measure it rather than assert it. Search Console gives CTR by page group and by query, so a template that gained annotations can be compared against its own 28-day baseline. Where CTR moves without a ranking change, the markup is doing its job. Where it does not move, the annotation may be too generic to notice — which is a copy and offer problem, not a markup problem.
This is also why markup work belongs next to on-page work. The title, the description and the annotated fields are read as one unit by a searcher, so a technically perfect Product block under a weak title still loses the click. Where those two workstreams run together, we usually fold the markup into Technical SEO Services so the snippet is tuned as a single surface.
FAQ and HowTo markup: what is still worth shipping
The landscape changed and a lot of advice did not. FAQ rich results were narrowed in 2023 to a small set of authoritative government and health sites, so a supplier adding twenty Q&A blocks should expect no accordion in the results. HowTo rich results were retired from most surfaces altogether.
That does not make the markup worthless. A visible, well-structured FAQ still clarifies the page for retrieval systems, supports long-tail question matching, and gives sales-ready answers on the page itself. We ship FAQ markup where the questions are genuinely visible and useful to a buyer, and we say plainly that the SERP feature is not the reason to do it.
What we do not do is inflate a page with machine-only questions to chase a feature that no longer renders. That is the kind of shortcut that gets a whole domain's structured data discounted.
Validation is a pipeline, not a checkbox
Syntax validation is table stakes. The real work is keeping the graph true after the fifth release, the third currency and the second developer. Our loop has five gates, and a template does not go live until it clears all of them.
Gate two is the one people skip. Markup generated by a theme filter can vanish on a cached page or a variant URL, so we always inspect what the browser and the crawler actually receive. Gate five is what turns a project into an asset: a stored snapshot of every template's JSON-LD, compared on a schedule, surfaces a broken field before a client notices a drop in annotations.
How an engagement runs
- 01 · Inventory. Crawl the site, extract every JSON-LD block, and classify it by type, template and validity. You get a spreadsheet of what exists today.
- 02 · Model. Decide one entity per template, one Organization for the site, and the minimum field set that will survive your data feeds.
- 03 · Implement. Write the blocks into the template layer, keyed off the same data your storefront already uses, so price and availability cannot drift.
- 04 · Validate. Parse rendered HTML, run both validators, and fix warnings that indicate a missing or mistyped field rather than ignoring them.
- 05 · Monitor. Snapshot monthly, watch the enhancement reports, and roll a fix into the next release when a template changes.
Markup sits inside the broader technical layer — crawl, rendering, canonicalisation — which is why we usually deliver it as part of On-Page SEO Services rather than as a file drop.
Where it has moved the numbers
"An industrial fastener supplier, 5 months: 1,240 product templates marked up properly, annotation coverage 12% to 94%, organic inquiries 7 to 26 per month."
Fasteners · US & DE"A lab equipment brand, 3 months: duplicate Organization blocks merged into one @id graph, brand-query CTR up 21% with no position change."
Lab supplies · UK"A furniture exporter, 4 months: variant matrix rebuilt as one product with proper offers, merchant annotations recovered on 380 SKUs."
Furniture · NLNumbers like these come from fixing a graph, not from adding a snippet. In each case the first two weeks were spent on the data model and only the last week on writing JSON.
Scope, not a price list
A quote depends on how many templates exist, whether product data is already structured in one place, and which platform renders the page. A fifty-SKU catalogue with a clean schema is a short build; a marketplace with variants, currencies, regional pricing and five sellers per product is a project with a data contract.
We scope by template, by type and by the monitoring window you want afterwards. No per-page pricing, no surprise line items for validation — a block that fails the gate is our problem to fix before it ships.
Send one URL. Get its parsed type set.
We will return the types currently emitted, the required fields that are missing, and the one change that would earn an annotation.
Spec-sheet FAQ
How quickly does markup change anything?
Re-crawling can take days to a few weeks depending on your crawl rate. Annotations typically appear after the template is recrawled and reprocessed; we check the enhancement reports at 14 and 30 days and adjust the fields if a type is still unprocessed.
Do we need to rewrite the whole site?
No. We work template by template. A product detail template plus an Organization block covers most of the value on a storefront, and the rest can follow release by release.
Which platform does this work on?
Any platform that lets us control the rendered head: custom stacks, headless front ends, Shopify, WooCommerce, Magento and most enterprise CMS builds. If the only option is a plugin, we audit its output rather than trusting its template.
Can markup hurt rankings?
Valid markup describing visible content does not hurt. The risk is in violations — marking up hidden reviews, inventing ratings, or emitting contradictory entities — which can cost you rich results and, in repeat cases, manual action on structured data.
Who maintains it after launch?
Either your developer, using the fixture files and checklist we hand over, or us on a monitoring retainer that includes the monthly snapshot diff and fixes for new templates.
How do we measure success?
Three readings: valid items per template, annotation coverage across the catalogue, and CTR for the affected page group against its own baseline. We report all three, including the ones that did not move.
Is this a one-off build or a retainer?
Usually both phases. A build to get every template clean, then a light retainer because catalogues, currencies and templates change and markup does not update itself.
Who reads the spec
A structured-data team that has modelled catalogues for industrial suppliers, lab equipment brands and multi-currency storefronts — the environments where variant logic and translated labels break naive markup fastest. We read rendered HTML, not source files, and we write the field model before we write a single line of JSON.
If a type cannot earn an annotation for your business, we will tell you before you pay for it. A short honest list beats a long decorated one.