Skip to content
Search visibility6 min read

Structured data that earns its place

Structured data is worth implementing when it describes something the page genuinely shows and a consuming system genuinely uses. Generate it from the same data that renders the page, keep it to types the content supports, and treat any mismatch between markup and visible content as a defect.

Part ofTechnical SEO Engineering

Structured data has an unusual failure mode: it is invisible to the people who own the page, so it drifts from reality without anybody noticing. A price changes in the database and the JSON-LD keeps the old one. A review block is removed from the design and the aggregateRating stays behind. Both are worse than having no markup at all, because both describe a page that no longer exists.

Rule one: generate it, never hand-write it

The single most effective structural decision is to derive JSON-LD from the same objects that render the page. If the heading, the description and the markup all read from one content record, they cannot disagree. Hand-maintained script blocks in page templates always eventually disagree.

ts
// One content record feeds both the rendered page and its markup.
export function serviceSchema(service: Service) {
  return {
    "@context": "https://schema.org",
    "@type": "Service",
    name: service.title,
    // Same string the page renders as its opening definition.
    description: service.definition,
    provider: { "@id": absoluteUrl("/#organization") },
    areaServed: ["India", "Worldwide"],
    url: absoluteUrl(`/services/${service.slug}`),
  };
}

A test that asserts the markup's description equals the rendered description costs three lines and catches the entire class of drift permanently.

What is actually worth implementing

For most business sites the useful set is small. The types below do work: they either produce a documented search feature or they establish machine-readable facts that ranking and generative systems both consume.

TypeWhereWhy it earns its place
OrganizationOnce, site-wide, with a stable @idThe entity anchor. Every other node references it, and it is the primary factual record about the company.
WebSiteOnce, site-wideNames the site and, where a site search exists, declares it.
WebPage / ArticlePer page or postEstablishes page identity, dates and authorship — the signals generative systems use to judge freshness.
BreadcrumbListAny page below the rootDocumented search feature, and it makes hierarchy explicit rather than implied by URL shape.
ServiceService pagesDescribes what is offered and who provides it, linked back to the Organization node.
FAQPagePages with genuine Q&ARich results are now rare, but it remains clear machine-readable structure for answer systems.
SoftwareApplicationProduct pages for softwareDescribes the application category and platform where a product genuinely exists.

Connect the nodes with stable identifiers

Isolated snippets describe fragments. Linking them with stable @id values describes a graph, which is what lets a consuming system understand that the organisation publishing this article is the same organisation providing that service.

json
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example",
      "url": "https://example.com",
      "sameAs": ["https://www.linkedin.com/company/example"]
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com",
      "publisher": { "@id": "https://example.com/#organization" }
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/services/#webpage",
      "isPartOf": { "@id": "https://example.com/#website" },
      "about": { "@id": "https://example.com/#organization" }
    }
  ]
}

Use a fragment identifier on a canonical URL, keep it stable forever, and reference it from everywhere. Regenerating identifiers on each deploy defeats the purpose.

sameAs is how you disambiguate an entity

Company names are rarely unique. sameAs links to authoritative profiles are the cheapest available signal that the organisation on this page is the one on those profiles. Only include properties you actually control and keep current — a link to an abandoned profile with a contradictory description is worse than omitting it, because it gives a generative system two conflicting sources to reconcile.

Validation in the pipeline, not in a browser tab

  1. Assert in unit tests that generated markup carries the required properties for each type you emit.
  2. Assert that the description and name in markup equal the strings the page renders.
  3. Check the Rich Results Test and Schema Markup Validator before launch and after any content-model change.
  4. Watch the Enhancements reports in Search Console for errors that appear only at scale.
  5. Re-check whenever the content model changes, because that is when drift is introduced.

What changes when the consumer is a language model

Structured data was designed for search features, and it is now also parsed by systems generating prose. That shifts the emphasis in two ways. First, factual properties matter more than feature-triggering ones: name, description, areaServed, sameAs, dates and authorship are the fields that shape how an assistant describes you. Second, consistency across pages matters more than completeness on any single page — a generative system reconciling three different descriptions of your company will produce a fourth.

It does not, however, change the fundamental rule. Markup asserts facts about the page. If the assertion and the page disagree, you have published something untrue in a format designed to be trusted. That is the one outcome worth engineering against.

Questions

Does structured data improve rankings?

Not directly, and Google has said as much. It makes eligibility for specific search features possible and makes page facts machine-readable, which matters increasingly for answer and generative surfaces. Treat it as a comprehension and eligibility mechanism rather than a ranking lever.

Should structured data include content the page does not display?

No. Markup is meant to describe visible content, and mismatches are a documented cause of manual action. It is also simply misleading. If information is worth asserting to a machine, display it to the reader.

JSON-LD, Microdata or RDFa?

JSON-LD. Google recommends it, it keeps markup separate from presentational HTML, and it can be generated from the same data objects that render the page — which is what prevents drift.

Want this applied to your systems?

Most of what is described here begins as an assessment: a fixed-scope review producing a prioritised written report you can act on with any supplier.

Prefer email? hello@kornspire.com