A Short History of Linked Data, for People Who Just Want to Be Found

What Linked Data actually is

In 2009, Christian Bizer, Tom Heath, and Tim Berners-Lee published Linked Data, The Story So Far. Berners-Lee had invented the web two decades earlier as a way to link documents. The 2009 paper argued for something more demanding: a web of data, where the things a page is about, a business, a person, a service, a location, are each given a stable identifier and connected to each other by typed, machine-readable links.

The distinction matters. A document web lets a person read a page and understand it. A data web lets a machine read the same page and understand what it is about: that this string is a business, that this business is located here, that these are its services, that this person works for it. The paper set out a small number of principles for publishing information that way, so that separate sources could be joined into one connected graph rather than sitting as isolated pages.

Things, not strings: how search adopted the idea

The clearest moment Linked Data left the research literature and entered everyday search was May 2012, when Google introduced its Knowledge Graph under the slogan things, not strings. The announcement described a shift from matching the words on a page to understanding the real-world entities behind them, and it launched with roughly 500 million entities and 3.5 billion facts about how those entities relate to one another.

That is Linked Data operating at scale. A knowledge graph is a large, connected set of entities and the relationships between them, built so a machine can reason over facts rather than only rank keywords. When you ask an engine a question and it answers with a named business, a person, or a place, it is drawing on a structured representation of that entity, not on a document that happened to contain your search terms. The search box still takes words, but underneath, the unit of work has become the entity.

The entity: the thing a machine is trying to recognize

For a local business, the entity is you: the single, recognizable thing an engine wants to resolve your web presence to. Your business is an entity. So is each location, each named practitioner, and each service you offer. Entity based search means the engine is trying to answer a quieter question than "which pages contain these words". It is asking "which real thing is this, and can I identify it with confidence".

This reframes what a web presence is for. Pages are no longer only content for a reader; they are evidence for a machine trying to build and confirm an entity. Every place your business appears, your own site, your listings, your profiles, the mentions of you elsewhere, is a data point the engine reconciles into one identity. When those data points agree, the entity is strong and easy to surface. When they contradict each other, the entity is weak, and a weak entity is easy to overlook or to confuse with someone else.

Why being the same business everywhere is harder than it sounds

It is tempting to assume that declaring "this listing is the same business as that one" is a simple lookup. The Semantic Web literature says otherwise. In a foundational 2010 paper, Harry Halpin and colleagues examined owl:sameAs, the formal mechanism for stating that two identifiers refer to the identical real-world thing, and found it used inconsistently across the Linked Data web, with publishers applying at least four looser, non-equivalent senses of "same" in practice.

That finding survives into today's local search as the sameAs property in schema.org markup, the field where a business links its site to its authoritative profiles. The underlying difficulty has not been solved so much as worked around with platform-specific heuristics. The practical lesson for a business is that identity is not automatic and it is not forgiving. If your name, address, category, or the profiles you point to disagree even slightly across the web, you are handing a genuinely hard problem, entity resolution, to a machine that will resolve it conservatively, sometimes by declining to identify you at all.

Schema.org: the shared vocabulary that made it practical

Linked Data would be an academic curiosity without a common vocabulary that every engine agrees to read. That vocabulary is schema.org, founded jointly by Google, Bing, Yahoo, and Yandex in 2011 to standardize machine-readable markup for the web. It is not a proprietary SEO trick and not one vendor's invention; it is a standards effort governed by the major search companies together, which is why markup written to it is read consistently across engines and tends to outlast individual ranking tactics.

Schema markup, usually written as JSON-LD, is how a page states its facts in the structured form Linked Data calls for: this is a LocalBusiness, here is its name and address, here are its services, here is the person who provides them, and here, via sameAs, are the profiles that corroborate it. It is the concrete, present-day expression of the 2009 idea. Done honestly, marking up only what is true and visible on the page, it lets an engine read your site the way you intend rather than guessing. It is worth being precise about what it does: schema earns its place through clean parsing and eligibility for rich results, and Google has stated that no special markup is required to appear in its AI features. It is foundation, not a lever anyone can promise.

What this means for your web presence

Translated out of the research entirely, Linked Data sets a short, concrete standard for what a machine-understandable web presence looks like. None of it is exotic. All of it is frequently missing.

• Your business, locations, people, and services are each stated as clear, consistent entities, named the same way everywhere they appear.
• Your core facts, name, address, phone, hours, categories, and services, are expressed in structured markup a machine can read, not only in prose a person has to interpret.
• Your entity is connected, via sameAs and corroborating profiles, to the well-known sources an engine already trusts, so it can confirm who you are.
• Those connections agree with each other. Contradictions across your site, your listings, and third-party mentions are the single most common reason a machine identifies you weakly or not at all.

Why the substrate outlasts the trend

It is fair to ask whether any of this survives the current wave of generative answers. The evidence suggests the entity layer is exactly what does survive. The architecture underneath most answer engines, retrieval-augmented generation, was formalized by Lewis and colleagues in 2020: a language model paired with a searchable index it queries at answer time, which the authors showed produces more specific and factual output than a model working from memory alone. That index is a web of passages and entities. The visible interface keeps changing, from a list of links to a synthesized answer, but the thing being retrieved over has been an entity graph since 2012.

The index was never the destination; it was always the substrate. A business that is a clean, consistent, well-connected entity is legible to the ranked list, to the map pack, and to the generative answer at the same time, because all three read the same underlying representation. The work of being machine-understandable is not a bet on one engine or one trend. It is the foundation the trends are built on.

What Linked Data will not do for you

Being a well-formed entity makes you legible to machines. It does not, on its own, guarantee a citation, a ranking, or a place in an AI answer.

Two claims in particular deserve caution. The first is the idea that a special file such as llms.txt is how you control AI visibility. An analysis of 137,210 domains found that 97 percent of valid llms.txt files received zero requests in a single month of 2026, and Google has stated the file is "not done for search". The second is the widespread treatment of E-E-A-T, Experience, Expertise, Authoritativeness, and Trust, as a machine-computed score you can optimize into a page. Google's own documentation is explicit that E-E-A-T is a framework for human raters evaluating the search algorithm's output, not a direct ranking factor. The durable work is the unglamorous kind: a consistent entity, accurate structured data, and connections that corroborate rather than contradict.