One Source of Truth: Product Data and Self-Description

Engines do not punish you for being specialized. They punish you for contradicting yourself. The fix is not more markup. It is a single source of truth for what your product is, published consistently everywhere your product appears.

This chapter covers Layers 3 and 4 of the audit together, because they are one problem seen from two sides: the data behind your descriptions, and the descriptions themselves.

What the 2026 evidence says about structured data

For two years, the default GEO advice was to add structured data: mark up your product, your FAQs and your organization, and engines will understand and cite you. The 2026 research tested that claim properly, and it did not hold up.

Ahrefs tracked 1,885 pages that added JSON-LD between August 2025 and March 2026 and compared them with about 4,000 matched pages that did not. Citation changes were near zero: +2.2% on ChatGPT and +2.4% on AI Mode, neither distinguishable from no change, and a small -4.6% on AI Overviews (Ahrefs). Google's own guide says structured data "isn't required for generative AI search, and there's no special schema.org markup you need to add," while still recommending it for rich results (Google Search Central).

Two caveats keep this honest. Every page in the Ahrefs dataset already had more than 100 AI Overview citations before the markup was added, so it cannot tell us whether markup helps a page that engines have not yet discovered (Ahrefs). And correlational studies that find more citations on pages with schema are measuring the kind of site that does schema well, not the schema.

My reading: structured data helps machines classify you, and classification is not the same as being chosen. It is hygiene, like a clean sitemap. Do it correctly, do not expect it to win citations on its own.

That conclusion moves the weight of this layer somewhere more interesting: to the facts the markup describes, and whether they are the same everywhere.

Why contradiction is so costly

Chapter 1 showed engines building an entity from many sources at once. Think about what happens when those sources disagree.

Your homepage says you integrate with 200 tools. Your integrations directory lists 140. A review site says "limited integrations." Your pricing page says SCIM is an enterprise add-on; your docs say it is included in the business tier; a two-year-old press release says it is coming soon. An engine asked whether you support SCIM on the business tier now has three answers and no way to know which is current.

Engines handle that uncertainty in predictable ways. They hedge ("some sources suggest"), they go vague ("offers various integrations"), they pick the most widely repeated version (often the outdated one), or they leave you out of an answer where a competitor's facts are cleaner. None of those outcomes is a citation you want.

The pattern shows up in the description test from Chapter 4. When engines get a product wrong rather than missing it, the cause is almost always conflicting product facts in public, not a lack of content.

The product fact model

The fix starts with a decision: one system, with one owner, holds the canonical facts about your product, and every public surface draws from it.

The product information management world has understood this for years in commerce. Fragmented product data breaks reuse, and centralized data can be published reliably to many channels. B2B software rarely applies the same discipline, because its "catalog" is small and lives in people's heads. It needs it now, because engines and agents are a channel that reuses everything.

A product fact model does not need special software to start. A structured document or table works if it has an owner and a review cadence. What it needs is the right fields.

Fact type	Examples	Typical owner
Identity	Product name, company name, category, one-line definition	Product marketing
Editions and pricing model	Tiers, what each includes, how pricing scales	Product and finance
Capabilities	Core features with brand name plus functional term	Product management
Standards and protocols	SAML 2.0, OIDC, SCIM 2.0, FIDO2, SOC 2 Type II	Product and security
Integrations	Named integrations with depth (native, API, partner)	Partnerships and product
Limits and performance	Rate limits, quotas, SLAs, regions	Engineering
Deployment and data	Cloud, self-hosted, data residency regions	Engineering and security
Trust	Certifications, audits, subprocessors	Security and compliance

Each fact carries three pieces of metadata: who owns it, when it was last verified, and where it is published. The last one matters most, because it tells you what to update when the fact changes.

Publish from the source, do not copy it

The failure mode is copying. Someone updates the pricing page and forgets the docs. A partner manager writes a marketplace listing from an old deck.

The better pattern is to publish from the source wherever you can:

• Feature pages, pricing tables and docs pull capability and edition facts from one place
• Structured data is generated from the same facts that render on the page, so markup and visible content cannot drift apart
• Integration directories are generated from the integration records, not maintained by hand
• Trust centers list certifications from the same record security maintains
• Marketplace and directory listings are refreshed from the fact model on a schedule

Not every surface can be automated. Third-party review sites and analyst profiles will always need a human. But every surface you automate is one that can no longer contradict you.

Canonical descriptions

Alongside the facts, write the product's self-description once, at three lengths, and use them verbatim:

• One line: what it is and for whom, in category terms buyers use
• About 50 words: adds the two or three capabilities that define it
• About 150 words: adds standards, integrations and deployment

Add a short is / is not statement. "An identity platform for B2B SaaS applications. Not a workforce IAM or HR directory product." Engines blur adjacent categories, and saying what you are not is often the fastest way to stop being compared to the wrong products.

Use these descriptions word for word on your homepage metadata, directory profiles, marketplace listings, social profiles and press boilerplate. I apply the same rule to author bios across my own properties: when the descriptions are identical, engines resolve one entity; when they drift, they may resolve two weaker ones.

Consistency off your own site

Your own site is where you have control. The engine's picture includes everything else.

Once a quarter, check the surfaces you do not own:

• Review sites and software directories
• Cloud marketplaces and partner listings
• Company databases and professional networks
• Knowledge bases such as Wikidata, where your company legitimately has an entry
• Old press releases, launch posts and analyst notes still ranking for your name

Correct what you can directly, request updates where you cannot, and publish clear current statements on your own site for what neither will fix. A dated "what changed" page or a current changelog gives engines a recent, authoritative source to prefer over stale ones.

Structured data, done as hygiene

Structured data still belongs in this layer, with modest expectations.

• Mark up your organization with consistent names and links to your official profiles
• Mark up your product with accurate category, offers and descriptions drawn from the fact model
• Never mark up claims that are not visible on the page
• Validate after every template change

The value is in correctness and consistency, not volume. A small set of accurate markup generated from the source of truth beats a large set maintained by hand.

Multi-vertical without contradiction

Chapter 2 promised to return to multi-vertical products. The fact model resolves it. Core facts never vary by vertical: the product, its category, its capabilities, its limits. What varies is selection and emphasis: which compliance regimes a healthcare page leads with, which integrations a fintech page highlights. If two vertical pages ever state different facts about the same capability, the fact model is being bypassed.

Keep it current

A source of truth decays unless it is wired into how the product ships.

• Add "update the fact model" to the release checklist for any change to capabilities, limits, pricing or integrations
• Review every fact's "last verified" date quarterly and re-verify anything older than two quarters
• Run the description test from Chapter 4 after major releases to catch new contradictions

Who owns it

The fact model needs a single accountable owner, usually in product marketing or product operations, with named owners for each fact type. This is the most cross-functional piece of product-resident GEO, and it fails without a clear owner. It is also the piece that most improves everything else: naming, docs and capability exposure all draw on it.

Key takeaways

• Adding schema markup did not lift AI citations in Ahrefs' matched study. Treat structured data as hygiene, not a lever.
• Contradictory product facts make engines hedge, go vague or repeat the outdated version.
• Keep one product fact model with an owner, a last-verified date and a list of where each fact is published.
• Publish from the source instead of copying, and use canonical descriptions at one line, 50 words and 150 words, verbatim.