Open any well made web page and you are looking at the top layer: headlines, paragraphs, a photo, some links. A person reads it, understands who the page is about, and moves on. Google does not read it that way. Underneath the visible page there is often a second layer, a block of structured data that describes the page's subject in terms a machine can act on. That layer is where knowledge panels, AI answers and citations are assembled from, and most personal websites do not have it.
Two layers, one page
The visible layer says: "Maria Chen is the founder of Northwind Analytics and the author of Counting What Matters."
The machine layer says, roughly: there is a thing of type Person, called Maria Chen, with a stable identifier. She has a worksFor relationship to a thing of type Organization called Northwind Analytics. She is the author of a thing of type Book called Counting What Matters. She is the same person as the profiles at these LinkedIn, X and Wikidata addresses.
Same facts, but the second version has no ambiguity. Nothing has to be inferred from grammar. The name is attached to an identifier, the relationships are typed, and the links to other sources are explicit.
Why it is a graph
Each thing in that description is a node, and each relationship is an edge. Person to Organization, Person to Book, Person to Place of birth, Person to the Podcast she appeared on. Across the whole web, those nodes and edges connect. The Organization on Maria's page can carry the same identifier as the Organization on the company's own site. The Book can point at its listing on a bookseller. The Podcast can point at the show's page.
Google's Knowledge Graph is, in large part, this web of typed relationships collected and reconciled across millions of pages. When two sources describe the same node with the same identifier and the same facts, confidence goes up. When they disagree, or when a person exists only as a name in prose with no typed relationships, confidence stays low and nothing gets built.
What the vocabulary is
The shared vocabulary is schema.org, a set of types and properties agreed between the major search engines. Person, Organization, Book, PodcastEpisode, Place. jobTitle, worksFor, alumniOf, author, sameAs. The usual way to write it on a page is JSON-LD, a small block of text in the page's head that browsers ignore and search engines read. JSON-LD, explained with one example you can copy shows one.
The three properties that do most of the work
@id gives the node a stable address, usually your own domain plus a fragment, such as https://yourdomain.com/#person. Every other reference to you, on your media kit, on your company's site, in Wikidata, can point at that one address.
sameAs is a list of other pages that are about the same thing. For a person it holds every profile you control. It is how the machine learns that the LinkedIn, the YouTube channel and the author page are one human, not three.
worksFor, author, alumniOf and their relatives are the typed edges that attach you to other nodes. They turn "founder of Northwind" from a phrase into a relationship the graph can follow.
Where the graph came from
The idea is older than the AI assistants. In 2011 Google, Bing and Yahoo agreed on schema.org as a shared vocabulary so that a page could say, in a form all three could parse, what it was about. In 2012 Google launched the Knowledge Graph, its database of things rather than strings, and began showing panels assembled from it. Wikidata launched the same year as the open, editable counterpart. For a decade the practical effect for most people was a few rich results: star ratings, recipe cards, event listings. Pages that marked themselves up got the cards; pages that did not were still ranked, so most personal sites never bothered.
What changed is that the answer engines read the same layer, and for a person the answer is now the whole result. An AI Overview or a ChatGPT answer about a named person is drawn from the entity if one exists and from guesswork if it does not. The vocabulary did not change. The cost of ignoring it did.
How the machine resolves a name to a person
It helps to see the problem from the machine's side. A name is a string. "Maria Chen" is six characters and a space, and it matches a dentist, a software engineer, a novelist and the founder you are looking for. The machine has to decide which thing the string refers to before it can say anything true about it. That decision is called entity resolution, and it is made on evidence.
The evidence it weighs: is there a page that is clearly the canonical home for one of these people, with a stable identifier? Do other pages point at that identifier, or at the same profiles, when they use the name? Do the facts agree across those pages, so that "founder of Northwind" on an interview page matches "founder of Northwind" on the home page? Is there an entry in a database it already trusts? The person with the most consistent, connected evidence wins the string. Where no one has it, the machine hedges, which is the "several people share that name" answer.
Your structured data is the part of that evidence you control outright. It gives the machine the identifier to point at, the typed relationships to compare, and the list of profiles to reconcile. It does not make you win on its own. It makes you resolvable, which is the precondition for everything else.
What this looks like for one person
What a personal site usually gets wrong
Most have no structured data at all. Some have a generic WebSite block their template added, which says nothing about the person. A few have a Person block, but it has no @id, no sameAs, and sits beside a second Person block the media kit template added, so the site describes two people with the same name on one domain.
The fix is one Person node, on the person's own domain, with a stable identifier, a complete sameAs list, typed relationships to the organizations and works, and every other page on the site pointing at that one node instead of repeating it. Person schema and the sameAs line that matters most walks through exactly what goes in it.
How to see your own layer
Open your home page, view the source, and search for "application/ld+json". If nothing is there, you have no machine layer. If there is a block, paste the page's address into Google's Rich Results Test, which shows what Google parsed and any errors. Once your site is in Search Console, the Enhancements reports show the same thing over time.
Why appearances matter here
Every podcast episode you appear on can be described in the graph as well: a PodcastEpisode node naming you as a guest, on a Podcast node, with a date. Added to your site, each one is another typed edge connecting you to a third party's page. That is why a record built this way compounds, and a page that just lists links does not. The links are visible to people. The graph is visible to the machine.