Why “schema-only” entities quietly damage brand answers
LLMs don’t just “read pages.” They build internal representations of entities (brands, products, people, locations) from many signals: page text, link graphs, metadata, and structured data like JSON-LD. When those signals disagree or arrive without supporting context, the model may still create an entity record—but it can be thin, misattributed, or duplicated.
A common failure mode is the orphaned “schema-only” entity: an entity that exists because it was declared in structured data, but has little or no supporting evidence in the visible content, navigation, or internal links. These orphans pollute the knowledge layer that LLMs and AI search interfaces rely on. The result is familiar: brand answers that cite the wrong product name, mix two organizations, or confidently claim capabilities you don’t offer.
Index hygiene is the discipline of detecting these orphans, fixing the causes, and maintaining a stable entity graph over time. If you’re working on AEO/GEO, it’s foundational work—not glamourous, but decisive.
What orphaned schema-only entities look like in practice
They rarely announce themselves. You notice them through symptoms:
- Duplicate brand nodes: “Lunem,” “Lunem AI,” “Lunem.ai,” and a stale variant each appear as separate entities in AI answers.
- Wrong associations: a product gets attached to the parent company incorrectly, or a founder is linked to a different org with a similar name.
- Phantom offerings: services appear in AI summaries because the schema suggests them, but there’s no page that clearly describes them.
- Broken citations: an AI system cites an “About” page for a claim that only exists in JSON-LD, not in the visible content.
These can stem from good intentions: adding Organization markup, Product markup, FAQ schema, or JobPosting schema “for SEO.” But if the markup is detached from canonical pages and consistent internal linking, you can accidentally create a set of entities that live only in the markup layer.
Root causes that create schema-only pollution
1) Markup without a canonical home page
Entities should have a canonical URL where a human can confirm what the entity is. When markup describes a product, team member, location, or offering that doesn’t have a dedicated page (or the page is noindexed / hidden behind a script), LLMs may retain the entity but lack grounding context.
2) Inconsistent identifiers across templates
Small variations—different @id values, inconsistent url, mixed http/https, trailing slashes, or alternating brand names—encourage entity splits. A split entity graph is one of the fastest paths to contradictory AI answers.
3) Syndication and duplicated boilerplate
If the same JSON-LD block is copied across many pages (especially syndicated content) but the page body doesn’t reinforce it, you amplify the orphan. You also increase the chance that an AI system learns the markup as the “truth,” even when it’s outdated.
4) Over-modeling the business too early
It’s tempting to publish a complete schema universe: every service, every feature, every integration. If the site doesn’t yet have strong information architecture to support it, you’re creating entities faster than you’re creating evidence for them.
How to detect orphaned schema-only entities
You can treat this as an audit with a clear output: a list of entities, their identifiers, their supporting pages, and a “grounding score.” Here’s a practical detection workflow.
Step 1: Inventory entities from structured data
Crawl your site and extract JSON-LD (and Microdata/RDFa if present). Build a table with:
- Entity type (Organization, Product, Service, Person, Article, etc.)
- Name
@idandurl- Pages where it appears
- Key properties (sameAs, brand, offers, founders, areaServed)
Red flags: entities that appear on many pages but don’t have a unique canonical page, and entities whose identifiers vary by template.
Step 2: Compare schema claims to visible page evidence
For each entity, ask: “Could a user validate this entity from what they can read?” You’re looking for mismatches such as:
- A Product entity with no product page, only homepage mention
- A Service entity described in schema but missing a service section
- A Person entity with no bio page or author box
When you find a mismatch, mark it as a likely schema-only orphan.
Step 3: Cross-check with AI-facing tests
Run targeted prompts in your evaluation harness (or manual checks) that force an AI system to summarize your brand, list products, or describe capabilities. Watch for “hallucinated structure” that matches your schema more than your copy. This is where synthetic testing is especially useful; a disciplined approach like synthetic Q&A loop testing can reveal repeatable failure patterns.
Step 4: Look for citation drift
If your RAG layer or AI search previews cite pages that don’t contain the claim in visible text, that’s often an orphan signal. It means the claim is learned from markup or ambiguous snippets, not from grounded content.
How to fix orphaned entities without ripping out all schema
The goal isn’t “less schema.” It’s schema that is anchored to stable pages and consistent identifiers.
1) Create canonical entity pages for what you declare
If you mark up a Product, give it a page. If you mark up a Service, give it a page or a strong, clearly labeled section with an anchored URL. Then make that page the canonical home of the entity with consistent @id and url.
2) Normalize identifiers and naming
Pick one canonical brand name and one canonical URL format. Then enforce it everywhere: headers, footers, Open Graph, JSON-LD, and internal links. A single stable @id per entity is a major de-duplication lever.
3) Reduce “global schema blocks” that declare too much
Sitewide JSON-LD in templates is fine for Organization basics. It becomes risky when it starts declaring detailed offerings everywhere. Move rich markup to the pages where that offering is actually explained.
4) Add internal links that reinforce the entity graph
When an entity has a canonical page, link to it from relevant pages using natural anchors. This gives LLMs a stronger signal that the entity is real, distinct, and important in your site’s structure.
5) Version and monitor entity changes
Entity graphs evolve: rebrands, new products, retired features. Track changes explicitly so older identifiers don’t linger. If you operate AI workflows, apply strict schema conventions and input normalization to prevent ambiguity, especially when tools consume structured data; patterns from canonical schemas and input normalization translate well to entity hygiene.
Maintaining LLM index hygiene as an ongoing practice
Think of hygiene as a feedback loop: extract entities, score grounding, fix orphans, and retest AI outputs. This is exactly where an AI visibility agent can help, because the hard part isn’t writing JSON-LD—it’s continuously verifying how models interpret your site as it changes.
lunem fits naturally into this workflow by monitoring how content is interpreted and surfaced across LLM-driven environments and by using PEEC data to improve the accuracy of those insights. The practical win is faster detection of entity splits and schema-only drift—before they become the “facts” repeated in AI answers.
