Structured data has long been held as a central pillar of technical SEO. It helps search bots understand the content on your page with a higher degree of certainty. Many SEOs have spent considerable time updating and improving the schema on their sites to reflect this importance.
In this new era of AI search, it would be understandable for those SEOs to think they’ve got structured data covered off. However, there are some very common mistakes that impact how useful schema actually is for aiding in LLM visibility.
The latest question asked in Ask An SEO was:
“What are the most common structured data mistakes that hurt AI visibility?”
In this article we’ll take a look at some of the most prevalent misunderstandings.
Treating Structured Data Markup As A Checklist And Not An Entity Strategy
One of the most understandable mistakes is to treat structured markup as something that just needs to be done without considering the wider “why?”.
When marking-up content for SEO, often marketers will look to cover off the main schema types for their page as a matter of rote. After all, the main reason is to help the search engines understand that content clearly.
However, the key for AI search is realizing that the LLMs are looking for reassurance of entities and relationships.
This means that using schema to improve AI search visibility needs greater consideration and a more strategic approach. Instead of just considering the structured data markup as complete if there is some on the page, organizations need to ask, “Does our structured data make it easier for machines to understand the context and relationship of information on our page?”
Practically, this looks like using schema to reinforce brand identity, content authorship, product entities and relationships between them. The goal is to give context across your website. For example, an article on an ecommerce website’s blog might use article schema.
Technically, this is correct schema implementation. The content of that page is indeed an article. It helps the search bots to understand that this is not product content, or commercial content. It’s informational. A blog article.
However, what this doesn’t do is give the relationship between this article and other entities on the site. A better implementation would be to look at this page’s schema in relation to the whole site. For example, this page’s schema should link to the blog’s author pages. Thinking strategically with structured data for improving AI visibility would look more like connecting the article with its author, and the company the author works for. It would mean that instead of just marking the content up with article schema, you would also want to include author and organization schema.
See also: The Integrity Graph: The Missing Infrastructure Layer For AI Visibility
Relying Solely On Structured Data To Clarify Entities
Thinking strategically about using schema for AI visibility means realizing that simply clarifying what type of information is on the page isn’t enough. The information that is being marked up needs to be in alignment with information that the LLMs might ingest elsewhere. It is not a given that your marked up content will be the information the LLMs trust as the most authoritative.
This means part of the structured markup strategy needs to be correcting misinformation online.
This can be something as simple as websites using your old brand name, or carrying old pricing information about your products.
Marking up the correct brand name and product prices on your website might not be enough to convince the LLMs that your data is the one to trust.
See also: Beyond Brand Sovereignty: How To Build An AI-Ready Source Of Truth
Not Using Consistent Entity Identifiers
Entity identifiers are a way of using the same schema markup across the website, without needing to repeat the code. Using @id to define an entity means that you can keep referring back to that @id instead of creating new schema per page for that entity. For example, if you want to markup references to your organization on multiple pages and templates you can simply define the organization entity once and refer back to it on the subsequent pages.
In the below example, I am marking up the organization entity for a fake website, helensecommercestore.example.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://www.helensecommercestore.example/#organization",
"name": "Helen's Ecommerce Store",
"url": "https://www.helensecommercestore.example/",
"logo": {
"@type": "ImageObject",
"url": "https://www.helensecommercestore.example/images/logo.png"
}
}
</script>The important aspect of this is “@id”: https://www.helensecommercestore.example/#organization
This isn’t a real URL, but it acts as a unique identifier. It labels the entity with a shorthand that means subsequent uses of this @id will bring through all of the same information as the originally described entity.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "How to Choose the Right Running Shoes",
"publisher": {
"@id": "https://www.helensecommercestore.example/#organization"
}
}
</script>In the above example, there’s no need to redefine the entity. It will be explicit to the bots that this organization is the same as the one initially referenced.
By doing this, not only are you providing a shortcut for coding, you are providing consistency. This lessens the risk of conflicting information being provided across your website.
In this example, it could be that organization schema was added to Helen’s Ecommerce Store product pages in 2022, with the old company name of “Helen’s Shop” as the organization name. Whereas the schema on the homepage was updated in 2026, with the organization name being corrected to “Helen’s Ecommerce Store.” This would provide some conflict for the agents: Which is the correct name of this organization?
By using an @id for the organization schema, the homepage update would have been inherited across all the other pages using that @id. Meaning no conflicts, no need to provide multiple updates.
Using Valid Schema That Doesn’t Accurately Represent The Visible Content
This is a risk both for traditional SEO, and optimizing for LLMs. Intentionally using structured data markup for content that doesn’t exist on a page risks a manual penalty from Google. It’s also just plain confusing for LLMs. The signals provided to the LLMs by schema markup need to be reinforced by the content on the page itself. The bots understand that the schema is meant to be representing on-page content, so it is a confusing signal if the content cannot be found on the page that it references.
For example, for the ecommerce store, one of the product pages is about a coffee machine:
Helen’s Premium Coffee Machine
Price: £79.99
In stock
No customer reviews are shown on the page
However, the schema markup reads:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Helen's Premium Coffee Machine",
"offers": {
"@type": "Offer",
"price": "79.99",
"priceCurrency": "GBP",
"availability": "https://schema.org/InStock"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.9",
"reviewCount": "127"
}
}
</script>This shows a conflict between the information present on the page and the schema. On the page, there is no reference to reviews, or a review score. However, the schema directly refers to a ratingValue of 4.9 and a reviewCount of 127.
This is ripe for a Google manual penalty, and a very confusing experience for AI bots.
Allowing Structured Data To Become Stale Or Conflict With Other Sources
Similarly, it can be confusing for the bots when the marked up content is not in alignment with schema itself. For example, the schema might reference a product being in stock, but the product is actually out of stock on the webpage. The AI systems are trying to establish fact. When the two “statements” of fact are directly contradicting each other, this reduces the reliability of the webpage as a source of information about the product.
For example, here’s the same coffee machine page. This time the price is the source of conflict.
Helen’s Premium Coffee Machine
Price: £79.99
In stock
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Helen's Premium Coffee Machine",
"offers": {
"@type": "Offer",
"price": "59.99",
"priceCurrency": "GBP",
"availability": "https://schema.org/InStock"
}
}
</script>The price on the page is £20 higher than the price in the schema markup. At best, this is a confusing experience for the bots, as worst it could directly impact customer satisfaction and potentially leave you open to a manual penalty.
Summary
More Resources:
- The Technical Signals AI Search Uses That Most SEOs Still Aren’t Optimizing
- Schema For AI Citations: How To Become A Trusted Source
- How Structured Data Shapes AI Snippets And Extends Your Visibility Quota
Featured Image: Paulo Bobita/Search Engine Journal
