Category: Google

Making a brand machine-readable and improving its odds of being selected for AI-generated answers are important, but I see them as only part of the larger shift. Under the surface, a retrieval layer is changing how AI systems identify entities, connect facts, and decide which brands deserve to be cited.

That layer is GraphRAG. Once I understand how it works, “optimize for AI” stops feeling like a vague instruction and starts looking like a practical SEO strategy.

What is GraphRAG, actually?

GraphRAG extends traditional retrieval-augmented generation (RAG) by adding a knowledge graph. That graph helps AI understand entities and the relationships between them, instead of treating content as disconnected text fragments.

Microsoft Research introduced GraphRAG in 2024, and a broader ecosystem has formed around it since then. Instead of pulling from a flat sea of text chunks, GraphRAG builds a map.

In that map, nodes are the entities: a company, product, person, certification, location, or concept. Edges are the relationships between those entities, such as “offers,” “is certified by,” “authored,” or “operates in.”

I think of it as a system of things and the lines connecting them. When a model works from a map instead of a pile of scraps, it does not have to guess its way toward an answer. It can follow the relationships.

If the map says Entity A holds Certification B in Region C, the system can follow that path with confidence instead of inferring the connection and hoping it is right. That is why graph-based retrieval can produce more complete, better-grounded answers to complex questions with fewer hallucinations.

Microsoft described this failure mode in its GraphRAG patent, “Knowledge Graph Extraction” (US20250131289A1). The patent calls out a recall problem in naive RAG: a less prominent entity can disappear inside chunk embeddings, which means the system may retrieve nothing useful.

It also describes one of the fixes: entity resolution. When duplicate spellings or variations of the same thing are merged, the system can treat them as one entity instead of scattering their authority across several weak signals. That is one of the core building blocks behind graph-based retrieval.

Dig deeper: What patents reveal about the foundations of AI search

Why strong content still gets passed over

Traditional RAG works by chopping content into fixed chunks, turning each chunk into a vector, and storing those vectors in a database. When I ask a question, the system retrieves the closest chunks in vector space and passes them to a language model to generate an answer.

That can work for simple questions like “What is the capital of France?” It struggles with the questions that usually matter most in business: the multi-step questions.

If I ask a system to find a provider that offers a specific service, holds a specific certification, and operates in a specific region, naive RAG may stitch together an answer from scraps that merely sound related. It does not truly understand how the facts connect, so it guesses across the gaps.

When a system has to guess, the safer move is often to leave a brand out rather than risk saying something inaccurate about it. That is the part I think many SEO teams need to sit with.

This explains a common frustration: “Our content is strong, but AI systems still do not cite us.” The issue may not be content quality. GraphRAG consistently outperforms naive RAG on complex, multi-hop questions where vector search falls apart. That is where the visibility leak often starts.

In many cases, the machine could not reliably tell what the brand is, how its facts fit together, or whether it could trust those relationships enough to cite the brand by name.

The three problems GraphRAG is built to fix

I see GraphRAG lining up with three SEO problems that show up again and again: disambiguation, attribution, and relationships.

Disambiguation matters when the same entity appears under different names and gets counted as several weaker signals instead of one strong one. If “the firm,” “the agency,” and the actual brand name never resolve to a single entity, authority gets split.

Attribution matters when the fact survives but the credit disappears. When content is blended into an AI answer, the brand behind the original insight can easily vanish.

Relationships matter when the connections that give expertise meaning stay buried in prose instead of being declared in a way a machine can read.

If I have ever watched AI repeat something a company wrote without naming it, or credit a competitor for a specialty the company actually owns, I have seen all three problems in action.

What ties them together is simple: this is not only a content problem. It is an identity problem.

Same sentence, more machine-readable context

I want to make the idea of an entity concrete, because it can become abstract quickly. I will use one real-world example and one fictional example.

Start with Wayne Gretzky. Search his name in almost any AI client and I expect to see a confident summary: facts, former teams, records, and related links. That confidence is not luck. It is what a well-established entity looks like. His identity is nailed down and agreed upon across the web, so the system does not have to guess who he is.

Now imagine the opposite. Picture a goaltending coach in Moncton. I will call her Marie Tremblay. Her About page says: “Our head coach, Marie ‘Lefty’ Tremblay, has run elite goaltending camps across the Maritimes for 20 years.”

That is a good sentence. A parent understands it immediately. I would not rewrite it into robotic prose just to satisfy a machine. Optimizing for AI does not mean abandoning human voice.

The better move is to keep the sentence and add context around it. I need to make explicit what a human reader infers automatically.

That means clarifying that “Lefty” and “Marie Tremblay” are the same person. It means connecting Marie to the academy, to goaltending as a discipline, and to the Maritimes as the region she serves. It also means making “20 years” and “elite” verifiable claims rather than loose adjectives.

A human gets all of that from one sentence. A machine may not. My job is to close the gap between what the reader understands and what the system can verify, so Marie becomes as legible to AI retrieval systems as a famous entity like The Great One already is.

Why a flat triple is no longer enough

Knowledge graphs are built on triples: subject, predicate, object. “Acme offers consulting” is clean and useful, but it is flat. A bare triple cannot easily carry the high-stakes details that matter, such as whether the relationship is true, where it applies, who says so, and what evidence supports it.

The standards community is working on that gap. The W3C is extending the model with Resource Description Framework (RDF)-star, which allows site owners to make statements about statements. In practice, that means source, date, confidence, and other metadata can attach directly to a relationship instead of floating around as a disconnected claim. It is moving through the RDF 1.2 standardization process, with the RDF 1.2 Primer serving as a plain-English introduction.

Microsoft’s GraphRAG patent points in a similar direction. It pulls claims into a subject-action-object structure and weights relationships by how often they appear, instead of treating every stated link as equally reliable.

The practical lesson is clear to me: the future is not just saying two things are related. It is saying they are related and showing the proof in a form a machine can verify. A richer triple beats a flatter page.

The publishing layer is starting to respond

I am also watching the publishing layer, because that is where the shift is becoming visible outside the models themselves.

On June 1, the new open standard EntityMap launched a 33-day public consultation ahead of its July 1 launch. It was started by Fred Laurent, CTO of InLinks and Waikay, with backing from Dixon Jones. For anyone following entity SEO and the move from “strings to things,” those names matter.

The concept is deliberately familiar. Where sitemap.xml tells search engines which pages exist, an entitymap.json file tells AI systems what an organization knows: which entities it covers, how they relate, and where the evidence lives.

EntityMap aims at the same three problems: disambiguation, attribution, and relationships. It also builds in the richer-triple idea by allowing declared relationships to carry receipts, including a source URL, publisher, and timestamp.

I would treat it as a signal, not a mandate. EntityMap is a proposal in consultation, not a requirement. No major engine has committed to reading files like these, so I would not turn it into another box-checking exercise yet. The important point is that credible people are building entity-first publishing standards, and that direction is worth watching.

The honest state of GraphRAG

I do not think GraphRAG belongs in hype territory, because two realities keep it grounded.

First, GraphRAG is expensive. Building the map requires a language model to extract entities and relationships, and that is the costly part. By Microsoft’s own estimate, graph extraction accounts for roughly 75% of indexing costs. That LLM cost is one reason web-scale, real-time graph retrieval has not taken over everything overnight.

Second, the cost curve is bending. Recent research is attacking the infrastructure problem directly, including TurboQuant, a vector compression method from Google Research and NYU, presented at ICLR 2026. It reduces the memory footprint of vectors these systems traverse while preserving quality well enough to make the economics more interesting.

That does not mean every engine is running GraphRAG across the open web today. It means the economics are improving, which helps explain why entity-first standards are emerging now. I am cautious about anything framed as inevitable, but this shift makes practical sense.

Structured data still matters. Schema.org markup, a clean Knowledge Panel, consistent NAP, and strong entity signals are not going away. Entity-first work extends that discipline. It does not replace it.

My entity-first action plan

Here is how I would make this practical without betting everything on one standard.

Inventory entities, not just keywords. I would go beyond the search terms that historically brought traffic and list the things the brand genuinely knows about: products, services, people, methods, concepts, locations, and credentials. That becomes an entity map, whether or not it ever gets published as a formal file.

Disambiguate, then connect to the graph. I would claim and confirm the brand’s Wikidata entity and Google Knowledge Panel where possible. I would standardize naming, resolve variants, and keep sameAs links consistent across structured data. This is how “Lefty” and “Marie Tremblay” become one clear identity instead of two weak signals.

Make relationships explicit. I would use Schema.org types and properties such as Organization, Person, Product, knowsAbout, sameAs, and author so expertise is declared rather than implied. I would also mirror those relationships in internal linking.

Attach evidence to every claim. I would connect important facts to verifiable sources: named authors, first-party data, citations, documentation, and dated references. Graph-based systems increasingly need proof behind a relationship, not just the assertion.

Front-load defining facts. Retrieval still works through narrow windows, so I would place the clearest, most verifiable statement of what the brand is and what it does near the top of important pages.

Watch the publishing layer without overcommitting. I would read the EntityMap spec, follow how it develops, and decide later whether an entity index belongs in the stack. Schema.org work should continue either way.

Tie the entity map to revenue. I would map entity coverage to the queries and answer surfaces that influence leads, sales, margin, and retention. That helps leadership see entity work as revenue protection, not an academic exercise.

Measure what AI systems can recognize

Rankings and clicks still matter, but they describe the old search-page model. I would add metrics that show whether AI systems can recognize, trust, and cite the brand.

AI citation share measures how often the brand is named or cited in AI answers compared with competitors. I would track it monthly with an AI visibility tool.

Entity recognition asks whether priority entities have confirmed Knowledge Panels, Wikidata entries, and consistent identity signals. It is simple, but foundational.

Relationship completeness looks at how many priority entities have explicit, marked-up relationships and consistent sameAs links.

Attribution rate tracks how many core claims are backed by linked, verifiable evidence.

Answer-equity proxies include branded-query lift, assisted conversions from AI referrals, and lead stability as raw click volume softens. These business signals help show whether authority is compounding even when CTR is harder to read.

Where graph-based retrieval is heading

I expect graph-based retrieval to keep moving toward multimodal graphs, where text connects to images, audio, video, and structured data. I also expect more streaming and incremental indexing for live data, plus domain-specific ontologies for areas like medicine, finance, and law.

The move from strings to things is gaining momentum. The brands that stay visible will not simply be the ones publishing the most content. They will be the ones machines can understand without guessing, with clear entities, explicit relationships, and claims backed by evidence.

I do not need to wait for a new standard to launch before preparing. I can make a brand more legible now to systems that do not just read pages, but read what the brand knows. In the answer economy, I see the real battleground as identity, not just content.

---

Inspired by this post on Search Engine Land.

---