When an AI system needs to say what your company is, it needs a source stating what your company is. For most organisations no such page exists in usable form, because the About page was written as narrative rather than as a factual record.
The entity based AEO guide covers why entity recognition matters. This is about the specific page that grounds it, and what happens when that page contains a story instead of facts.
Founding Stories Are Not Facts
A typical About page says the company was born out of frustration with legacy tooling and a belief that things could be better. That describes a feeling. It does not establish what the company does, where it operates, how large it is, or what category it belongs to.
The facts a machine needs are unglamorous. Legal entity name. Founding year. Headquarters location. Approximate size. What the company actually sells, stated plainly. Who founded it. Where else it exists online.
None of that is exciting to write and all of it is what gets used when a system assembles an answer about you. I would keep the story, and I would put the facts above it rather than instead of it.
Organization Schema Belongs Here in Full
Organization schema often sits in a site wide template as a minimal stub, name and logo and nothing else. The About page is where the complete version belongs.
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://notioncue.com/#organization",
"name": "NotionCue",
"url": "https://notioncue.com",
"logo": "https://notioncue.com/logo.png",
"foundingDate": "2024",
"description": "AI visibility tracking across ChatGPT, Perplexity, Claude, Gemini and Google AI surfaces.",
"sameAs": [
"https://www.linkedin.com/company/example",
"https://x.com/example"
]
}The @id is the part that makes this an anchor rather than an isolated block. Every other schema object on your site referencing the organisation should point at this identifier instead of repeating a name string, which is how a set of separate pages becomes one entity.
The sameAs array does the corroboration work described in the author entity guide, at organisational level. Each profile that confirms the connection strengthens it.
Name Consistency Is Where This Breaks Most Often
A company writing itself as NotionCue on the website, Notion Cue Ltd in legal footers, and NotionCue Inc on LinkedIn has created three candidate entities.
Pick one public form and use it everywhere, including on third party profiles you control. Where a legal name differs from the trading name, both belong on the About page with the relationship stated explicitly, so a system encountering the legal name in a filing can connect it to the brand name it sees elsewhere. Schema supports this through legalName alongside name.
This is the same problem as the subdomain entity split in the subdomain guide, arriving through naming rather than architecture.
Category Language Determines Which Questions You Appear In
A system deciding whether to mention you in an answer about a category needs to know you are in that category. If your About page describes you as a platform empowering teams to do their best work, you have not claimed a category.
State it plainly in a sentence. We build AI citation tracking software for marketing teams. That sentence is doing more work than three paragraphs of vision language, because it is the sentence that gets pulled when someone asks what your company does.
Use the words buyers use rather than the category you wish existed. Inventing a new category name is a positioning strategy with real costs, and one of them is that nobody searches for it.
Team Pages Compound the Entity Signal
Named people with real roles connect your organisation to individuals who may have their own recognition. A founder with a public track record brings that recognition to the company entity when the connection is explicit.
Link team members to their profiles, mark them up as Person objects with worksFor pointing at the organisation @id, and keep it current. A team page listing people who left two years ago is a factual error sitting on your most factual page.
Anonymous team pages showing stock photography and first names only contribute nothing here, and I would either do it properly or leave it out. Named people with verifiable histories are also the clearest expression of the trust signals covered in the E-E-A-T guide.
What About Pages Should Not Do
Do not bury facts under scroll animations that load content client side, per the rendering guide. About pages are frequently the most design heavy page on a site and frequently the least readable to a crawler as a result.
Do not split the facts across a company page, a story page, a leadership page, and a careers page with no clear primary. One canonical About page carrying the schema, with others linking to it, keeps the anchor unambiguous.
Checking What Is Believed About You
Ask an engine what your company is, when it was founded, and where it is based. Wrong answers here propagate into everything else, because a system that has your category wrong will not consider you for the right questions.
The NotionCue Citation Tracker captures how engines describe your organisation over time, which distinguishes a stable wrong belief from a one off. Corrections take time to propagate and tracking is how you know whether they landed.
Start your free NotionCue trial and track basic company facts alongside your product prompts. Foundational errors are cheap to fix and expensive to leave.
Ask an AI what your company does, then read your About page and check whether the answer could have come from it. If it could not, the page is not doing the job it exists to do.
Common Questions
Does Organization schema need to be on every page or just About?
A minimal reference site wide with the full object on the About page works well. What matters is that all of them share one @id rather than describing separate entities.
Should employee count be published?
A range is enough and it is useful signal. Exact figures date quickly and require maintenance nobody does.
What if a system has our company confused with another of the same name?
That is the disambiguation problem in the brand hallucination guide. Stronger sameAs corroboration and consistent category language are the levers, and it resolves slowly rather than immediately.