Structured data: entity graph, automatic generation and what it really delivers

Two opposite and wrong views of structured data are around: the ranking shortcut and the useless frill. The reality is in between, and it is technical: structured data describes entities and relationships in a format search engines read without ambiguity. Done well, it helps Google understand who you are, what you offer and how your pages connect. Done with a plugin adding isolated blocks, it does little.

From isolated block to graph

The most common mistake is treating each page as an island: an Organization block in the footer, an Article generated by the SEO plugin, a LocalBusiness pasted by hand on another page, each with slightly different data. Google sees three organisations that may be the same one.

The right approach is a graph with stable identifiers:

• each main entity has a unique, permanent @id (for example the site URL followed by #organization or #person);
• pages reference those entities by @id instead of re-declaring them: an Article has as author the person with that @id, and as publisher the organisation with that @id;
• sameAs links entities to their official external profiles, strengthening identification.

The result is a single, consistent description, repeated by reference across the site.

Generate, don't hand-write

Structured data must match what is visible on the page. The most reliable way to guarantee that is to generate it from the same source as the content: if an article's title, date, author and FAQs live in its frontmatter, the JSON-LD is built from there. When the content changes, so does the structured data, with no drift.

Writing it by hand page by page is the fastest way to end up with stale dates, outdated prices and FAQs that no longer exist in the text.

What still earns rich results

Google has scaled back several types in recent years. In short, today:

• Breadcrumb: still useful, it helps how the URL is presented in results;
• Product, Offer, aggregate Review: central for e-commerce, with precise requirements on price, availability and genuine reviews;
• LocalBusiness and related: useful alongside the Google Business Profile;
• Event, JobPosting, Recipe, Video: active in their respective fields;
• Article: helps interpret author and dates;
• FAQPage: rich result limited almost entirely to government and health sites;
• HowTo: no longer shown as a rich result.

Promising a client "star ratings" or "FAQs on the results page" without checking the current guidelines is the best way to disappoint them.

Non-negotiable rules

• Markup describes only content visible on the page.
• No self-written reviews about yourself to get stars.
• The right type for the purpose: a service is not a Product, an article is not a NewsArticle unless it is news.
• Each type's required and recommended properties are filled with real data, not placeholders.

How I check

1. Google's Rich Results Test for rich result eligibility.
2. The schema.org validator for overall graph correctness, including types Google does not use.
3. Search Console reports for errors and warnings at scale after publishing.
4. Spot checks that the JSON-LD matches the visible content, especially after an update.

Where it fits in SEO work

Structured data does not make up for weak content, slow pages or a confusing architecture. It comes afterwards: when the site is clear, fast and well linked, it makes explicit what is already there. In a migration it should be treated like redirects, preserved and verified (I explain this in Rebuilding your site without losing rankings).

An example graph, in words

On a professional's service page, the graph I set up contains:

• a WebSite node, with a stable @id, naming the person or organisation as publisher;
• a Person or ProfessionalService node (or the most specific type), with name, address, area served and sameAs to official profiles, always with the same @id across the site;
• a WebPage node for the page, with isPartOf pointing to the site and about pointing to the service;
• a Service node with name, description and a provider referencing the professional's @id;
• a BreadcrumbList consistent with the visible path.

On a multilingual site, each language has its own page with inLanguage, while the main entities (person, organisation) keep the same @id: they are the same entity described in two languages, not two different entities.

My take

On this site nobody writes structured data by hand. A single function adds to every page the profile with references to me and my business, pages add breadcrumbs and, for articles, author, dates and FAQs, all read from the same Markdown files the text comes from. The FAQs stay in the markup because they describe the content, even knowing Google rarely shows them today.

It is the same principle I apply to everything else: one source of truth, and everything derived from it generated automatically. A plugin adding independent blocks gets you the opposite.

And when I inherit a site, one of the first checks is the graph itself: it says a lot about how carefully the site has been looked after.

Why work with me

I have been programming since 1999, delivered more than 300 projects and work as an external developer with about 30 agencies, from Rome and remotely. I set up structured data as a coherent graph, generated from the content and verified, without promising results Google no longer gives.

If you want to see how Google reads your site, get in touch: in a call of about 20 minutes we look at what is there and what is missing. The service is in Speed and SEO.