Subscribe
Share
Share
Embed
A bite-sized, charm-filled podcast that demystifies Answer Engine Optimization (AEO) for everyday content creators. Each 5-10 minute episode breaks down one key AEO concept in an accessible, entertaining way. Listeners will learn how to optimize their content for AI-powered search tools like ChatGPT, Siri, and Google Assistant - without the technical jargon that makes their eyes glaze over.
Hello there, lovely listeners! Welcome back to AEO Decoded. I'm Gary Crossey, and I have to tell you, it’s dead good to be back with you all.
Season 1 was something special, wasn’t it? When I first sat down to record those episodes, there was this brilliant freedom in doing something completely new. No expectations, no pressure, just me, a microphone, and a fierce passion for AEO. I just kind of… did it. And I was okay with that. More than okay, actually.
The plan was simple: wrap up Season 1, take a few weeks off, set up for Season 2, and we’d be away. But here we are, a few months later, and I’m only now getting back to the mic. Want to know why? Because somewhere along the way, I started thinking I had to prove something, that Season 2 had to be “bigger,” “smarter,” more advanced than what we’d already done. And now, now I have listeners! Real people who stop me to tell me what they found useful in the episodes. Folk who had no idea I was Irish until they heard my voice. That's class, so it is, but it also brought this pressure I hadn't felt before. There's this weight that comes with knowing people are actually listening, you know? That they're expecting a certain type of content. That they're counting on me to deliver something worthwhile. And I let that get in my head for a wee while there.
But here's what I've come to realize, and it's taken me these few months to get here: I can do my best, and that is enough. That has to be enough. Because at the end of the day, I genuinely love doing this. I get excited about AEO and SEO and web tech in general, it's my happy house, as we say. This is where I want to be.
So I've looked that fear in the eye, the fear of not being good enough, of letting people down, of not living up to expectations, and I've made peace with it. Because the truth is, I'm not here to be perfect. I'm here to share what I love with people who want to learn it.
The truth is, Season 2 isn’t about proving anything. It’s about building on what we started together. If Season 1 was about learning to make your content speak AI, Season 2 is about designing the system underneath, the entity graphs, relationships, and structure that let answer engines recognize you as a true authority.
And sure, isn't that what it's all about?
So right, let's get stuck in. No more messing about. Season 2 is here, and we're going to dive into some proper advanced AEO strategies that'll have your content speaking AI like a native.
Are ye ready? Let's go!
The Breakdown: Entity Graphs in Practice
Right then, let's get stuck into what entity graphs are all about and why they're absolutely essential for Season 2 of your AEO journey.
Remember back in Season 1, Episode 4, when we talked about entity optimization? We covered the basics of how AI systems recognize entities, the people, places, things, and concepts that matter in your content. Well, today we're taking that foundation and building something much more sophisticated on top of it: a proper entity graph.
Now, what's an entity graph when it's at home? Think of it like this: if entities are the nouns in your content, the people, places, products, and concepts, then an entity graph is the map showing how all these nouns connect to each other. It's not just knowing that "Dublin" exists; it's understanding that Dublin is the capital of Ireland, home to Trinity College, birthplace of James Joyce, and a major tech hub for European operations. All those connections matter, so they do.
Here's why this is dead important: Large Language Models don't just look at your content in isolation. They're constantly building and updating their understanding of how concepts relate to each other. When you create a first-party entity graph, that's your own internal network of connected topics, you're essentially giving AI systems a clear roadmap through your expertise.
Let me give you a real‑world example from a long‑standing client of mine in the health space. They offered specialised treatments and had a strong reputation locally, but when people turned to AI systems for advice, they were barely showing up at all.
After we put some key GEO tactics in place, tightening how their services were described, clarifying their core expertise areas, and making sure their internal linking and structured data actually reflected what they were known for, things started to shift.
Suddenly, when people asked AI systems things like “trusted health providers for long‑term care in [their city]” or “who can help with [specific type of issue] near me,” this provider started appearing in the answers. Their brand was being cited, referenced, and recommended as a go‑to option, instead of getting lost behind bigger, more generic platforms.
Their mentions in AI responses took off quicker than a tourist seeing the sun in Belfast. And that didn’t happen by accident, it happened because we made it dead simple for AI systems to understand who they were, who they served, and why they were the business for that niche.
Let me break down the three core components of building entity graphs in practice:
Component 1: Consistent Entity Naming
This is where many websites fall down completely. You might refer to "SEO" on one page, "search engine optimization" on another, "search engine optimisation" (with an 's' for our UK friends) on a third, and maybe even "organic search optimization" on a fourth. To a human reader, these are obviously the same thing. But to an AI system trying to build a knowledge graph? That's four potentially different entities.
The fix is dead simple but requires discipline: Pick your canonical name for each entity and stick with it across your entire site. Create a style guide if you need to. On first mention, you can provide the alternative terms in brackets, "Search Engine Optimization (SEO)", but after that, use your chosen term consistently.
This applies to everything: product names, people's names, company names, technical terms, industry concepts. If you're writing about "machine learning," don't switch between "ML," "automated learning," and "AI learning" willy-nilly. Choose one primary term and maintain it.
Component 2: Entity Disambiguation Pages
Here's where it gets class. For your most important entities, the core topics and concepts central to your expertise, you need dedicated disambiguation pages. These are pages that exist primarily to define what an entity is and how it relates to other entities.
Think of these as your entity hub pages. If you run a fitness website, you might have disambiguation pages for "cardiovascular training," "strength training," "HIIT," "progressive overload," and other core concepts. Each page should clearly define the term, explain its significance, and, crucially, link to related entity pages.
The structure of a good disambiguation page includes: a clear, concise definition at the top (ideal for featured snippets and AI citations), a more detailed explanation in the body, explicit relationships to other entities ("Cardiovascular training is a type of aerobic exercise, which differs from anaerobic exercise like strength training"), and links to both broader and narrower concepts in your entity hierarchy.
Component 3: Relationship Pages and Internal Linking Strategy
This is where your entity graph becomes traversable by AI systems. It's not enough to have isolated entity pages; you need to explicitly show the relationships between entities through thoughtful internal linking and dedicated relationship pages.
A relationship page explores the connection between two or more entities. For example, if you have entity pages for "Content Marketing" and "SEO," you might create a relationship page called "How Content Marketing Supports SEO Strategy" or "The Intersection of Content Marketing and Search Engine Optimization."
Your internal linking strategy should reinforce your entity graph. When you mention an entity on one page, link to its disambiguation page. When you discuss relationships between concepts, ensure your linking reflects those relationships. This creates what I call "machine-readable authority", a content structure that AI systems can crawl and understand as easily as a human reader.
Now, here's the beautiful thing about this approach: You're not creating content for machines at the expense of humans. A well-structured entity graph actually improves the user experience. Clear definitions, logical connections between topics, and thoughtful internal linking help human readers just as much as they help AI systems.
Let me give you a practical example. Say you run a website about WordPress development. Your entity graph might include entities like "WordPress," "PHP," "MySQL," "Gutenberg Editor," "Classic Editor," "Plugins," "Themes," and so on. For each of these, you'd have a disambiguation page. Then you'd create relationship pages exploring connections like "How PHP Powers WordPress," "Understanding the Gutenberg vs. Classic Editor Debate," or "The Relationship Between WordPress Themes and Plugins."
When you write a tutorial about building a custom WordPress plugin, you'd link to your entity pages for "WordPress," "Plugins," and "PHP." These links aren't just helpful navigation for readers; they're signals to AI systems about the entities involved in your content and how they relate to your broader expertise.
The magic happens when AI systems start recognizing your site as an authoritative source for these entities and their relationships. When someone asks ChatGPT or Claude about WordPress plugin development, the AI doesn't just need to find information about plugins in isolation. It needs to understand how plugins relate to WordPress core, how they interact with themes, what languages they're built in, and so on. If your entity graph maps all these relationships clearly, you become the authoritative source the AI system turns to.
Here's another crucial aspect: disambiguation in specialized contexts. Sometimes the same term means different things in different fields. "Python" could refer to the programming language or the snake. "Apple" could be the tech company or the fruit. Your disambiguation pages should make clear which meaning you're addressing and in what context.
For specialized terms unique to your industry, your disambiguation pages become even more valuable. You're not just defining terms; you're establishing your authority in interpreting and explaining them. This is particularly powerful in emerging fields or niche industries where AI systems have less training data to work with.
Now, I know what you're thinking: "Gary, this sounds like a massive undertaking. How am I supposed to create entity pages for every concept on my site?" And you're right to be thinking that. The good news is you don't need to do it all at once.
Start with your core entities, the 10-20 most important concepts central to your expertise. Create disambiguation pages for these first. Then, as you create new content, take a moment to identify the key entities in that content. Do they already have disambiguation pages? If not, add them to your list. Over time, you'll build a comprehensive entity graph organically.
The other thing to remember is that entity graphs aren't static. As your field evolves, new entities emerge and relationships between existing entities change. Your entity graph should evolve too. This is actually one of the topics we'll cover in Episode 2.7 on AEO Resilience Engineering, how to maintain and update your entity graph over time.
One final point about entity graphs: They work in harmony with the structured data we talked about in Season 1, Episode 3. While your entity graph provides the semantic structure through content and linking, schema markup reinforces that structure for AI systems. You might use schema dot org types like Defined Term, Article with about and mentions properties, or even custom JSON-LD to make your entity relationships explicit.
Q&A Lightning Round
Right, let's tackle some questions you might have about entity graphs:
How is an entity graph different from topic clusters?
Brilliant question! Topic clusters are about organizing content around pillar pages and cluster content, primarily for SEO purposes. Entity graphs go deeper, they're about defining the entities themselves and mapping all the relationships between them. A topic cluster might have a pillar page on "Content Marketing" with cluster content about different aspects. An entity graph would have disambiguation pages for "Content Marketing," "SEO," "Social Media Marketing," and so on, with explicit relationship pages showing how these entities connect. Think of topic clusters as the content strategy and entity graphs as the knowledge architecture underneath.
Do I need to create separate pages for every single entity, or can I define entities within existing content?
You can absolutely start by defining entities within existing content, especially for less central concepts. The key is to use consistent formatting, perhaps a definition box or a highlighted section, so both humans and AI systems recognize these as entity definitions. For your core entities, though, dedicated disambiguation pages give you much more control and make the entity graph traversable. It's a matter of prioritization.
How do I know if my entity graph is working?
We'll cover measurement in depth in Episode 2.8, but here are some early indicators: Are AI systems citing your disambiguation pages when answering questions about those entities? When you search for "[entity name] + [your brand]," do your entity pages rank? Are you seeing increased internal link clicks between related entity pages? These are all signs your entity graph is functioning well.
What if my industry doesn't have well-established entities or my business uses unique terminology?
This is actually a massive opportunity! If you're in an emerging field or using specialized terminology, your entity disambiguation pages become even more valuable. You're not just optimizing for existing AI knowledge; you're helping to create it. AI systems will turn to your authoritative definitions when they encounter these terms. Just make sure your definitions are clear, context is provided, and relationships to more established entities are explicit.
Should I worry about keyword cannibalization when creating multiple entity pages on similar topics?
Not if you're clear about the distinct purpose of each page. An entity disambiguation page serves a different function than a comprehensive guide or tutorial. Use schema markup to signal the page type, make the distinctions clear in your content, and ensure each page targets distinct search intents. The whole point of an entity graph is precision, not redundancy.
Your One Actionable Item
Right, here's what I want you to do this week, and it's dead simple:
Identify your top 5 core entities and create disambiguation pages for them.
These are the most important concepts, products, services, or ideas central to your expertise. For each one, create a focused page that includes: a clear, concise definition (2-3 sentences maximum) at the very top, a more detailed explanation in the body (300-500 words), a list of related entities with links to their pages or placeholders if they don't exist yet, and internal links to 3-5 pieces of existing content where this entity is discussed in depth.
Don't overcomplicate this. These pages don't need to be your longest or most comprehensive content. They need to be clear, authoritative, and well-connected to your other content. Think of them as the nodes in your knowledge graph, clean, defined, and connected.
Once you've created these five disambiguation pages, update your most important existing content to link to them when these entities are mentioned. You're building the foundation of your entity graph, and it starts with these core definitions.
Resources
For more on the fundamentals of entity optimization that underpin today's advanced strategies, revisit Season 1, Episode 4 on Entity Optimization. We covered the basics of what entities are and why they matter, essential groundwork for understanding entity graphs.
If you haven't implemented structured data yet, go back to Episode 3: Structured Data: Making Your Content AI-Friendly. Schema markup reinforces your entity graph by making relationships machine-readable.
Looking Ahead to Next Week
Right then, that's entity graphs sorted! Next week in Episode 2.2, we're diving into Advanced Schema Stacks and Harmonization. You'll learn how to layer Article, FAQ, How To, Breadcrumb, Organization, and Person schema types coherently without creating the contradictory or orphaned nodes that confuse parsers. We'll build on the schema fundamentals from Season 1, but take it to a professional level that separates good AEO from world-class AEO.
If you're already using structured data, you'll discover how to stack multiple schema types on the same page without conflicts. If you're just getting started with schema, you'll learn the right way to build from the ground up. Either way, it'll be absolutely class.
Until next week, this is Gary Crossey reminding you: build your entity graph with care, keep your definitions clear, and may your content always speak AI fluently. Subscribe so you don't miss Episode 2.2, and post your questions on the website aeodecoded.ai and I'll feature select questions in future Q&A lightning rounds. Have a brilliant day, and see you next Thursday.