There’s a sentence Google’s engineers use internally that most SEO guides never quote:
“Things, not strings.”
It came from a 2012 blog post announcing the Knowledge Graph, and Google meant it literally. A string is a sequence of characters — “jaguar” — that could mean the car brand, the animal, a Mac OS version, an NFL team, or a guitar manufacturer. A thing is the actual concept those characters point to. Google said, clearly, that it was moving from matching strings to understanding things.
That was 2012. It’s 2026. And most SEO content is still written for a search engine that reads strings.
This article is about what changed, why it matters more now than ever, and what you actually do differently when you optimize for things instead of words.
Why “Jaguar” Is a String (And Why That Matters for How Google Reads Your Page)
Type “jaguar” into Google and your results will depend heavily on what Google infers you want. If you’re searching from a car-buying context — recent browsing history, location near a dealership — you’ll probably see Jaguar Land Rover results. If your past searches skew toward wildlife or National Geographic, you might see the big cat. The word is identical in both cases. The thing Google tries to surface is completely different.
That’s entity disambiguation. Google looks at the string “jaguar,” identifies the multiple real-world things it could refer to — the British luxury car brand, the Panthera onca, a discontinued Apple OS, a Jacksonville NFL franchise — and uses surrounding signals to decide which one you probably meant.
Google doesn’t scan your page looking for the word “jaguar” and decide you’re relevant because you used it 14 times. It tries to understand which entity your page is about, what that entity’s relationship is to other entities, and whether your page adds genuine information about those relationships.
The difference is harder to see than it sounds. A page stuffed with the keyword “best project management software” looks like it’s about project management software. But a page that clearly establishes its author as someone with verified experience using these tools, cites specific named software products (entities), discusses their relationships to specific team types and use cases, and gets mentioned in the same breath as other authoritative sources on the topic — that page is about project management software in a way Google can verify and trust.
The first is a string. The second is a thing with relationships.
How Google Moved from Matching Characters to Understanding Concepts
The old model — pre-2012, pre-Knowledge Graph — was largely lexical. A search engine looked for documents containing the query terms, ranked them by how often the terms appeared and how many pages linked to them. A sophisticated word-count system, basically.
The new model is semantic. Google builds a graph of entities (people, places, organizations, products, concepts) and the relationships between them. When someone searches, Google maps the query to a point or path in that graph, then finds content that speaks accurately to that part of the graph.
BERT (2019) improved Google’s ability to understand words in context rather than in isolation. RankBrain (2015) helped Google handle queries it had never seen before by relating them to known concepts. The Knowledge Graph — now containing hundreds of billions of facts — is the structured map all of this runs on.
Google reads your page the way a knowledgeable editor would, not the way a concordance does. It asks “what is this page actually about, and is that well-established?” rather than “does this page contain the target phrase enough times?”
What an Entity Actually Is in Google’s Knowledge Graph
An entity is a real-world thing that can be distinctly identified: a person, a company, a location, a product, a concept. Google’s Knowledge Graph stores entities and the connections between them.
Some examples:
- “Notion” is an entity — a specific software product, made by a specific company, categorized as a productivity tool, used for specific purposes, competing with other specific tools.
- “Productivity software” is an entity — a category that contains Notion, Asana, Trello, and others, with its own set of properties.
- “Marie Curie” is an entity — a person with specific attributes (physicist, chemist, Nobel laureate), connected to other entities (University of Paris, radioactivity, Pierre Curie).
When Google encounters these names on a page, it doesn’t just see strings. It connects them to their Knowledge Graph nodes and reads the relationships your content establishes between them.
This is why entity co-occurrence matters. A page that mentions “Notion” alongside “project management,” “remote teams,” “Kanban boards,” and “Asana” is clearly about a specific topic area. A page that mentions “Notion” without any of those surrounding entities is harder for Google to classify and trust.
You can check what entities Google associates with a topic using the Google Natural Language API — paste a block of text and it will show you which entities it extracted and how it classified them. It’s a useful gut-check before publishing a page you’ve optimized the old way.
Keyword Research Is Not Dead — It Just Became the Wrong Starting Point
A lot of the “entity SEO vs keyword SEO” framing treats them as opposites. They’re not. Keyword research is still useful. It’s just not where to start.
Old workflow: find keywords, build content around the keywords, optimize on-page signals for the keywords.
New workflow: identify the entities your content needs to cover, map the relationships between them, build content that establishes your authority on those relationships, then confirm that the keywords people use to search for those entities appear in natural contexts throughout the page.
The keyword shows up. It’s just not the organizing principle anymore. The entity is.
This matters most in competitive niches. Two pages can target the exact same keyword. The one with richer entity relationships — more specific, more accurate, more connected to what Google already knows about the topic — will rank better, hold the ranking longer, and appear in AI Overviews more often.
The page optimized only for the keyword string is more vulnerable to algorithm updates and less likely to get cited in AI-generated answers, regardless of where it ranks.
How to Map Entities Before You Write a Single Word
This is the part most guides skip because it takes more work than opening a keyword tool.
Before writing a page on any topic, you want to identify the entity map — the set of things that Google expects to find on a page about this subject, and the relationships between them.
Step 1: Start with the seed entity. What is the primary thing this page is about? Not the keyword — the thing. “Project management software for remote teams” is a keyword phrase. The entity is more like: “cloud-based project management tools used by distributed teams.” Name it as a concept, not a search query.
Step 2: Find the related entities. What other things does Google associate with this topic? Use a few methods:
- Run your target query in Google and look at the “People Also Ask” box. Each question points to a related entity or sub-concept.
- Check the Knowledge Panel if one exists for your topic. The “People also search for” section at the bottom lists related entities.
- Use the Google Natural Language API on a competitor’s well-ranking page. See which entities Google extracts.
- Look at the “Entities” tab in SEO tools like Semrush’s SEO Writing Assistant or similar NLP-aware platforms.
Step 3: Map the relationships. For each related entity, ask: what is its relationship to your primary entity? Is it a sub-type? A competing option? A component? A prerequisite? These relationships are what your content needs to address — not exhaustively, but accurately.
Step 4: Identify your entity gap. Compare your entity map to an existing page that ranks well. What entities does it cover that your content doesn’t? That gap is often a better optimization target than chasing a keyword variant.
This takes 30–45 minutes per page. It’s slower than opening a keyword tool. The pages it produces are harder to replicate, harder to displace, and more likely to get picked up by AI search systems doing exactly this kind of entity-relationship mapping when they decide what to cite.
Rewriting a Real Page: Keyword-First vs. Entity-First, Side by Side
This is easier to show than explain. Take a page targeting the keyword “time tracking software for freelancers.”
Keyword-first version (the old way): The page uses “time tracking software for freelancers” in the title, H1, first paragraph, and several times throughout. It lists features generically: “easy to use,” “generates invoices,” “tracks billable hours.” It’s clean, it’s structured, it hits the keyword.
What Google sees: a page that contains the right string in the right places. Probably fine. Will rank somewhere.
Entity-first version (the new way): The page establishes that it’s about time tracking tools — specifically for independent contractors and solo professionals. It names specific tools: Toggl Track, Harvest, Clockify, Timely. It discusses their relationships to adjacent entities: invoice generation, project management, accounting software (QuickBooks, FreshBooks), and client billing workflows. It addresses specific use cases: hourly billing, project-based billing, retainer tracking. The author bio connects to verified work experience with freelance finance tools.
What Google sees: a page with a rich entity graph. The primary entity (time tracking software) is clearly connected to a specific sub-audience (freelancers), to specific competing products, to specific adjacent tool categories, and to specific use cases. The author is an entity with verified relevance.
The keyword “time tracking software for freelancers” appears naturally in both. But only the second page has the entity depth Google uses to understand what it’s actually about and whether it’s worth trusting.
This is the difference between a page that ranks because it matched a string and a page that ranks because Google understands what it is.
The Tools That Show You Which Entities Google Associates With Your Topic
You don’t need to reverse-engineer the Knowledge Graph by hand.
Google Natural Language API (free, up to a point): Paste any block of text and it returns the entities Google extracts, their categories, and a salience score. Run it on your own draft to see if Google is finding the entities you intended. Run it on a competitor’s well-ranking page to see what they’re doing that you’re not.
Google Search itself: The Knowledge Panel, “People Also Ask,” and “Related searches” are all entity signals. They show what Google considers topically connected. Free, available right now, and underused.
Semrush SEO Writing Assistant: Has an NLP layer that surfaces recommended entities based on top-ranking pages. Not perfect, but practical for a first pass.
InLinks or similar entity SEO platforms: Purpose-built for this. They crawl competitor pages, extract entity relationships, and show where your content has gaps. More useful in competitive niches where the entity map is complex.
Wikidata: If you want to understand how Google structures knowledge about a specific entity, look it up here. The properties and relationships listed give you a model for what a complete entity representation looks like.
Pick one method and use it before writing, not after. Adding entities late feels like stuffing them in — because it is.
The Practical Shift: What You Actually Do Differently
Before writing:
- Identify the primary entity, not the primary keyword
- Map 8–12 related entities using the methods above
- Note the relationships your content needs to establish
- Check whether your site already has an established entity relationship to this topic
While writing:
- Use specific named entities rather than generic descriptions (“Asana” rather than “project management tools”)
- Establish relationships explicitly (“Asana integrates with Slack, which makes it common in teams using the Google Workspace ecosystem”)
- Cover sub-entities from your map even when they’re not the primary keyword target
- Write accurate, specific, verifiable claims — entity-based systems care about accuracy in ways keyword-based ones didn’t
After publishing:
- Run the Google NLP API on your published page
- Look for missing or wrong entity classifications
- Fix sections where entity context is thin
- Build internal links to and from related pages covering adjacent entities in your topic cluster
The change is in sequence and intent: start with meaning, confirm that keywords follow naturally, rather than starting with keywords and hoping meaning is implied.
The Underlying Point
When Google said “things, not strings” in 2012, most SEOs filed it as an interesting development and kept doing keyword research. For a long time that was a reasonable call — keyword signals still drove rankings, and you could usually get away with lexical optimization even in competitive niches.
That gap has closed. AI Overviews pull from entity-rich content. LLMs cite pages that establish clear entity relationships. Google’s core updates have gotten better at distinguishing pages that match queries from pages that actually understand the subject.
Your keyword still needs to be on the page. But it belongs there because you’re accurately covering the thing it points to, not because you hit a target density.
I know that sounds like a small change. In practice it means restructuring how you start every piece of content — before the brief, before the outline, before the first word. Most teams aren’t doing that yet. Which is, honestly, still the opportunity.
