Structured data is a block of JSON in your page's <head> that states, in a shared vocabulary, what the page is. For an article it says: this is an Article, its headline is X, it was published on date Y, this organisation published it. The vocabulary is schema.org and the encoding almost everyone uses now is JSON-LD, which sits in a script tag and does not touch your visible markup.

What it does

It removes guesswork. Without it, every consumer of your page has to infer what it is from headings, class names and dates scattered through the HTML — and they infer differently. With it, the page states its own type and its own publication date, once, unambiguously. That is genuinely valuable to anything reading at scale: search crawlers, aggregators, and increasingly models building a summary of a page they will only fetch once.

It also makes you eligible. Search engines have said for years, plainly and repeatedly, that valid structured data is a precondition for certain result features — the ones that render as something other than a blue link. No markup, no eligibility. That is the mechanism, and it is the only mechanism anybody has documented.

What it doesn't do

It does not rank you. Eligibility is not a ranking factor, and the distinction is not a technicality: adding correct markup to a page that nobody wants to read produces a correctly-described page that nobody wants to read. The search engines' own guidance says this. It is the single most common misunderstanding we see, usually in the form of a site that has marked up four hundred pages and is puzzled that nothing moved.

It does not guarantee the feature either. Eligibility means you are in the pool. Whether a rich result actually renders is the engine's decision, it varies by query and device, and it can be withdrawn. Markup buys you a ticket, not a seat.

It does not make claims true. Marking a page as an Article with a datePublished of last week does not make it fresh. Markup that disagrees with the visible page is not a clever optimisation; it is the one category of structured data mistake that carries an actual penalty, because it is indistinguishable from lying.

The fields, and the discipline of leaving them out

For an article, the useful core is small — six fields:

  • the type;
  • the headline;
  • a description;
  • the publication date;
  • the canonical URL of the page itself;
  • the publisher.

Everything else is optional and most of it should stay optional.

The temptation is to fill every field the vocabulary offers, because a validator will happily accept more. Resist it. Two examples of why:

  • dateModified should appear only when the article was actually revised. A dateModified set equal to datePublished on every page is a field asserting that a revision happened. It is noise at best, and if you ever automate it to "today", it is a freshness claim you are making about pages you have not touched in a year.
  • author as a Person requires a person. If the piece was written by a team and published under the company's name, the honest markup is an Organization. Inventing a byline so that a field is populated is fabricating a fact in a machine-readable format, which is the worst place to fabricate one.

The general rule: emit what you can derive from something real. If a field's value would have to be invented, guessed or defaulted, leave it out. Absent is honest. Wrong is not.

Getting it right mechanically

Most structured data failures are not conceptual, they are plumbing. The ones worth checking for:

  • It has to be in what the crawler receives. Markup injected by client-side JavaScript is invisible to any fetcher that does not run scripts, which is most of the non-search ones.
  • Every top-level node needs its own context. JSON-LD gives the members of an array no shared context — if you publish a list of nodes, each one carries its own @context and @type or it is not what you think it is. One object with a @graph is the way to share.
  • It has to be safe in the document. The block sits inside a script element, so any < in a string can terminate the tag early and take the rest of your page with it. Escape it or, better, let one function own serialisation.
  • It has to agree with the page. The headline in the markup and the headline on the screen should be the same sentence.

We hold ourselves to this. Every article on this site carries Article JSON-LD built from the same module that supplies the visible title and description, validated by the same function that gates every byte of structured data we publish on a customer's behalf, with dateModified present only where a revision exists. That is not a flourish — it is the cheapest available proof that the rule is followed rather than recommended.

The honest summary

Structured data is documentation your page writes about itself for machines. Good documentation does not make software good; it makes good software usable. Same here. Mark up your articles because it removes ambiguity and opens doors that are otherwise closed, and expect nothing from it on a page that had nothing to say.