Module 5 — Structured data and entities

🏷This module turns your site into something AI understands "with proper nouns." It is a subtle but

Why AI needs proper nouns

There is a huge difference between a system understanding what topic you are talking about and understanding which concrete entity you mean. A model can perfectly grasp that your page is about "pricing plans" — that is topic — and at the same time be unable to distinguish your "Pro plan" from your "Team plan" or mix features from one with the other — that is entity. The GEO of the first modules makes you visible and readable; the GEO of this module makes you unmistakable.

An agent works far better when every important thing in your business has three stable attributes: a unique canonical name, a canonical URL where it lives, and a stable definition that does not change from page to page. When those three anchors are missing, classic problems begin: the system confuses plan A with plan B, attributes feature X to the wrong product, or merges two terms that "sound" similar into one thing that does not exist. These "mixed answers" are among the most damaging errors because they are subtle: the answer looks coherent and confident, but it is false, and the user has no way to know.

The invisible cost of inconsistency

It is worth understanding why name inconsistency does so much damage, because it is a problem almost nobody sees until they look for it. Imagine you call the same thing three ways depending on the page: on the home page it is "Professional Plan," on pricing it is "Pro," and on an old blog post it was "Business Plan." To you they are obviously the same thing, because you have the full context in your head. For a language model, they are three different text strings, and it has no guarantee they refer to the same entity. In the best case it treats them as synonyms with some doubt; in the worst, it treats them as three different products and builds an answer that invents a catalog you do not have.

This gets worse with the fragment retrieval mechanism you already know: if three different chunks use three different names for the same entity, none reinforces the others, and the signal of "this entity exists and matters" spreads and dilutes instead of adding up. Name consistency is not a stylistic obsession; it is what lets all your mentions of an entity accumulate into one strong signal instead of scattering into several weak ones.

Where BotPass fits: start with entities AI already touches

As in every module, BotPass keeps you from working blind. Not all your entities deserve the same canonization effort; the priority ones are those bots are already consuming. Use BotPass to find which pages about plans, policies, and key features are being read, because those pages define the entities that most need canonical names and URLs to avoid mixed answers. Starting there means starting where the risk of confusion is real and current.

There is also a concrete signal to watch: if BotPass shows bots consuming several different pages about the same entity, treat it as a consistency problem to resolve now. It means AI is receiving multiple versions of the same truth, probably with slightly divergent names or data — the exact recipe for a mixed answer. The solution is always the same: consolidate into one canonical source and point toward it, along the lines of what you worked on in Module 3.

The Entity Sheet: your business dictionary

If you only did one thing after reading this module, it should be building your Entity Sheet. It is, literally, your business dictionary: the master document where you define, once and for all, what each thing is called, where it lives, and what it means. Its power is that it is the source everything else in GEO drinks from: it feeds consistent copy, consistent schema, consistent clean views, and a consistent llms.txt. Without it, each of those pieces is built separately and ends up contradicting each other; with it, they all sing the same song.

The Entity Sheet also has an organizational benefit beyond GEO: it forces your team to agree on what things are called. Often the exercise of filling it in reveals there was not even internal consensus — marketing called it one way, product another, sales a third — and that consensus, once fixed, improves far more than AI visibility alone. This is the table that anchors it:

What schema is and why it really helps

If the Entity Sheet is the dictionary that lives in your head and documentation, schema is how you tell that dictionary to machines in their own language. Schema — structured data, usually in JSON-LD format — is a machine-readable block that explicitly declares "what is what": this is an organization, this is a product, this is a FAQ with its answer, this is a guide with these steps. Instead of forcing the system to infer structure from visible text, you serve it already digested.

Schema is especially useful in concrete situations: when you have real FAQs, a FAQPage makes them unambiguous; when you have clear steps, a HowTo orders them; when you want to reinforce who you are, an Organization fixes your identity; and when you describe services or plans, Service or Product delimits them. But there is a golden rule you cannot skip, and ignoring it will do more harm than good: schema must match visible content. If your schema says one thing and your page says another, it does not just fail to help — it lowers trust, because the system detects the inconsistency and learns to distrust your signals. Schema is a mirror of content, never independent decoration.

Implementing schema without breaking anything

Schema scares many people with its technical look, but with an orderly procedure it is approachable without being a developer, especially with BotPass's generator. The sequence is simple.

First, choose three pages to start, without trying to cover the whole site at once: a source of truth like pricing, policy, or documentation; a product landing; and a guide. This trio covers the most useful schema types and teaches you the pattern. Second, decide which schema applies to each: on pricing, FAQPage combined with BreadcrumbList usually fits; on the landing, site-level Organization along with Service or Product; and on the guide, HowTo or Article, with FAQPage if applicable. Third, and this is mandatory, do QA: verify names match your Entity Sheet, URLs are canonical, and conditions — currency, region, dates — are correct. That quality control is what guarantees schema is a faithful mirror and not a new source of contradictions.

What a well-defined entity looks like

To land it, look at how an entity reads when you apply everything above. Take "Pro plan." Its type is Plan; its canonical name is "BotPass Pro," and that name is used everywhere without exception; its canonical URL is /pricing#pro; its one-sentence definition is "Plan for teams that need X, includes Y, with limit Z"; its critical attributes are price in euros per month, optional annual billing, number of domains included, and support level; and its source of truth is /pricing. When an entity is defined like this, something almost magical happens: your copy, your schema, and your clean views stop contradicting each other, because they all drink from the same single definition. AI no longer has to choose between versions; there is only one version.