Technical SEO

Structured Data That Earns You Something Back

Schema markup only pays off when it changes how your result appears or how machines read you. Here are the types worth implementing & how to get them right.

A Big Shout Out6 min read
Start reading

Structured data has a reputation problem. Half the industry treats it as a magic ranking lever, & the other half dismisses it as pointless because it is not a ranking factor. Both are wrong in a way that costs money.

Schema markup does not raise your position. What it does is remove ambiguity. It tells a machine, in a format designed for machines, that this string is a price, this one is an opening time, & this entity is the organisation that published the page. That clarity buys you two things: enhanced appearance in search results, & reliable extraction by the language models increasingly answering questions on your behalf. The second is becoming the more valuable of the two.

Start with the types that change the result

Most sites should implement a small, well-maintained set rather than a sprawling one. In rough priority order:

  • Organization. Your identity anchor. Name, logo, URL, contact points, & the sameAs links to your verified social & directory profiles. This is what helps search engines & language models connect your brand to a single, coherent entity.
  • LocalBusiness. Essential for anyone with a physical presence. Address, geo coordinates, opening hours, price range, phone. If you serve customers in Kathmandu from a real office, this is not optional.
  • BreadcrumbList. Cheap to implement, changes the URL display in results, & reinforces your site hierarchy.
  • Article. For editorial content. Headline, author, publication & modification dates. The author field matters more than it used to, because it links content to a named person with a reputation.
  • Product & Offer. For ecommerce. Price, currency, availability & condition. This is where rich results are most visually valuable.
  • FAQPage. Still useful for machine extraction even where visual rich results have been reduced, because it presents question & answer pairs in an unambiguous structure.
  • Service. Underused. It lets you state precisely what you offer & where you offer it, which is exactly what an answer engine needs when someone asks for a provider.

A small set of accurate, validated schema types beats a large set that half validates & nobody maintains.

Use JSON-LD & put it in the head

There are three syntaxes. Use JSON-LD. Microdata & RDFa require you to weave attributes through your HTML, which means every template change risks breaking the markup. JSON-LD sits in a single script block, is generated independently of your presentation layer, & is trivially testable.

Generate it server-side wherever possible. Schema injected by client-side JavaScript is usually read eventually, but it depends on the render pass completing, which introduces exactly the fragility discussed in our guide to rendering. If it is important enough to add, it is important enough to ship in the initial HTML.

The rules that keep you out of trouble

Structured data is one of the few areas where getting it wrong attracts an actual manual penalty. The guidelines are not complicated, but they are enforced.

  1. Mark up only what is visible. If a price, rating or FAQ answer is in your markup but not on the page, that is a violation. Not a grey area, a violation.
  2. Never mark up reviews you collected about yourself on your own site as aggregate ratings on your homepage. Self-serving review markup is explicitly disallowed for organisation & product entities in this configuration.
  3. Keep it accurate & current. Opening hours that changed six months ago, or availability that says in stock when it is not, damages trust in a way that is hard to recover.
  4. Validate at template level. Test one URL from every template, not one URL from the site. An error in a template repeats across every page using it.
  5. Do not stuff. Adding every property the specification allows does not help. Fill the properties you can answer truthfully & leave the rest out.

Connecting entities so the graph makes sense

This is where most implementations stop short, & where the remaining value sits. Rather than publishing isolated blocks on each page, link them using @id references. Your Organization node gets a stable identifier. Your Article node references that identifier as its publisher. Your LocalBusiness node references the same organisation. Your author references a Person node that exists in one place.

The result is a connected graph rather than a pile of disconnected assertions. Machines resolving "who is this company, what do they do, & where" get a single consistent answer instead of having to reconcile several partial ones. That consistency is precisely what determines whether a generative system cites you confidently or hedges.

Structured data & answer engines

The traditional payoff for schema was the rich result: stars, prices, breadcrumbs, FAQ dropdowns. That payoff still exists but has been trimmed over time as search results were simplified.

The newer payoff is extraction reliability. When a language model assembles an answer, it needs facts it can state without qualification. Clean structured data provides exactly that. A model that can read your service area, your pricing model & your opening hours as typed data is far more likely to represent you accurately than one parsing it out of a paragraph. This overlaps heavily with our work on generative engine optimisation & answer engine optimisation, where structured data is a foundational layer rather than a finishing touch.

Implementation checklist

  • Decide which types apply to each template & document the mapping.
  • Generate JSON-LD server-side from your actual content fields, never hand-written per page.
  • Give the Organization node a stable @id & reference it everywhere.
  • Validate every template with the Rich Results Test & the Schema Markup Validator. They check different things.
  • Monitor the enhancement reports in Search Console monthly for new errors introduced by content changes.
  • Re-audit after any redesign, since presentation changes frequently break field mapping.

What to skip

Do not implement HowTo markup expecting rich results that no longer render broadly. Do not add Event markup unless you actually run events. Do not add speakable markup on the assumption it will do something. & do not install a plugin that adds fourteen schema types by default without checking what it is asserting on your behalf, because plugins routinely claim things that are not true of your business.

Structured data is a small, high-discipline task. Done once & maintained, it quietly improves how every other channel reads you. Done carelessly, it is a liability. If you want it built properly alongside the rest of your foundation, look at our technical SEO work or talk to us about an implementation review.

Next step

Have a goal in mind? Let’s talk.

A quick conversation is all it takes to see what’s possible & where we can start.

Typical first reply: under 24 hoursNo obligation