Schema markup has been a Google recommendation for over a decade. It’s well understood. The documentation is extensive. There are free testing tools. And yet, after auditing hundreds of enterprise and mid-market websites in 2026, we consistently find the same errors — basic, preventable mistakes that prevent structured data from triggering rich results, feeding AI search systems with bad data, and creating the kind of technical debt that compounds over time.
The problem isn’t knowing about structured data. The problem is implementing it correctly, maintaining it as content changes, and catching errors before they impact search visibility. This guide is a diagnostic walkthrough of the most common schema mistakes we see, why they break things, and exactly how to fix them.
The Duplicate ID Problem: Where Most Schema Breaks Down
The single most common structured data error we encounter — across sites of every size and industry — is duplicate or inconsistent @id values across schema blocks. It’s a subtle issue that doesn’t generate error messages in most testing tools but completely breaks the semantic meaning of your structured data.
Why @id Uniqueness Matters
When you set an @id on a Schema.org entity, you’re establishing its unique identity. If two separate schema blocks on the same page use the same @id, search engines interpret them as referring to the same entity — even if the properties are completely different. This creates impossible contradictions: a Person with properties of both “John Smith” and “Jane Doe.” An Article that simultaneously has two different dates. An Organization with conflicting location data.
The fix is straightforward: every @id on a page must be unique. If you have both an Article schema and an Organization schema on the same page, they cannot share an @id, even if the organization is the publisher of the article. Each entity gets its own unique identifier — typically a URL fragment that distinguishes it from all other entities on the page and site.
The Cross-Page ID Collision Problem
More insidious than duplicate IDs on a single page is the pattern where the same @id appears across multiple pages. This happens when developers use a template-based approach to generate schema — for example, generating Organization schema with a static @id that appears on every page. While this is technically correct for the Organization entity itself, it creates problems when the Organization @id is also used for other entities — like the author Person — on some pages.
Use a consistent naming convention: organization @ids use the site’s canonical URL as the base, author @ids use author profile page URLs, and article @ids use the article’s canonical URL. This creates a predictable, collision-free schema architecture that scales across any site size.
Diagnosing ID Conflicts in Complex Schema Graphs
When your page contains a schema graph with multiple interconnected entities — an Article published by an Organization, authored by a Person, part of a BreadcrumbList, with FAQPage children — the @id references form a graph. Each reference must resolve to an @id that exists within that graph. Broken references, where an @id points to something that doesn’t exist on the page, cause the entire graph to be treated as invalid by some parsers.
Use Google’s Rich Results Test to identify where references break. The tool will flag references to @ids that don’t exist. Fix each broken reference by ensuring the referenced @id is present and correctly typed.
Wrong Schema Types: Matching Reality, Not Assumptions
Schema.org has 800+ types. Choosing the right one requires understanding both what the type means and what your content actually is. Most schema type errors come from developers using the most obvious type rather than the most accurate one.
Article vs. WebPage vs. BlogPosting: The Right Type for Your Content
The three most commonly confused types for blog and news content are Article, WebPage, and BlogPosting. Each has a specific meaning and use case:
Article is a generic type for written works — appropriate for most informational and news articles. WebPage is the type for the page itself — it’s too generic to trigger most rich results on its own. BlogPosting is specifically for blog posts — a subclass of Article with additional blog-specific properties.
The most common mistake: using WebPage as the primary type for a blog post because it “feels like a web page.” This won’t trigger Article rich results. Use BlogPosting for blog posts, Article for news and informational articles, and use WebPage only as a supplementary type when needed. When in doubt, use Article — it’s the broadest appropriate type for written editorial content.
LocalBusiness and the Specific Subtype Problem
LocalBusiness is abstract — Google will reject it for most rich result types. You must use the most specific subtype available: Restaurant, Hotel, Store, DentalClinic, AutoRepair, and dozens of others. Using LocalBusiness directly is one of the most common reasons LocalBusiness schema fails to trigger LocalBusiness rich results.
Before implementing LocalBusiness schema, check Google’s supported LocalBusiness subtypes list. If your specific type isn’t listed, use the closest parent type that’s supported. And always include all required properties for your specific subtype — Restaurant requires servesCuisine, openingHoursSpecification, and priceRange; Hotel requires starRating. Missing required properties is an automatic disqualification for rich results.
Event Schema: Temporal Property Errors
Event schema is widely used but frequently implemented incorrectly. The most common errors involve dateTime formatting and timezone consistency. Event dates must be in ISO 8601 format — specifically, full-date with time and timezone offset, like “2026-04-17T19:00:00+04:00”. Using formats like “April 17, 2026” or “17/04/2026” won’t parse correctly.
Another frequent error: using startDate without endDate, or using the same value for both. An Event must have a distinct endDate that’s logically after startDate. For ongoing events or multi-day events, use proper date ranges. Also ensure you’re using the correct property names: dateStart and dateEnd are NOT valid Schema.org properties — use startDate and endDate.
Ready to dominate AI search?
Over The Top SEO gets you ranked where it counts — in AI answers, not just blue links.
Nested Entity Problems: Getting the Hierarchy Right
Structured data entities rarely exist in isolation. Most schema implementations involve nested entities — an Article authored by a Person, published by an Organization, with a publisher that’s also an Organization. Getting the nesting right is where many implementations fall apart.
The publisher vs. author Organization Confusion
When an Article has both a publisher and an author, the publisher should be an Organization, and the author should be a Person. This is straightforward — but when companies try to represent their own content, they sometimes make the author an Organization (their company) rather than a Person, which is semantically incorrect and won’t trigger Author rich results.
The author of an article is a Person — the individual human who wrote it. Even if the article is ghostwritten, attributed to a company executive, or published under a brand name, the author field should point to a Person entity with a name, url, and ideally a description. The publisher Organization is separate and represents the publishing entity.
Properly Nested address and geo in LocalBusiness
For LocalBusiness schema, the address and geo (geographic coordinates) properties must be properly nested under the correct parent. The address goes directly on the LocalBusiness entity — not inside a nested ContactPage or other parent. The geo property (GeoCoordinates) must contain latitude and longitude properties — not just the coordinates as a string.
Common errors: putting address on a nested entity instead of directly on the LocalBusiness, using a text string for coordinates instead of structured latitude/longitude properties, and omitting the countryCode or streetAddress components that Google expects for local markup validation.
Referencing Entities That Don’t Exist on the Page
Schema graphs can reference entities defined on other pages via @id URLs. This is useful for Author entities defined on author profile pages, referenced from articles. But when these references point to pages that don’t exist, return 404 errors, or don’t contain the matching @id, the reference breaks — and some parsers treat the broken reference as invalidating the entire parent entity.
Always verify that @id URLs resolve to actual pages that contain the matching @id declaration. This is especially important for author and publisher references. If you reference an author via @id and the author profile page is 404, your Article schema will have broken publisher/author references that may prevent rich results.
Missing and Malformed Required Properties
Each schema type has required properties for rich result eligibility. These aren’t suggestions — missing them disqualifies your content from rich result types. Most are straightforward; some are easy to overlook.
Article Schema: The Headline, Image, and Date Requirements
For Article schema to trigger Google’s Article rich results, you need: headline (max 110 characters, must match the H1), image (must be a URL to an actual image, not a logo or placeholder), datePublished (ISO 8601), dateModified (ISO 8601, must be current), and author (Person or Organization, properly nested). Many implementations skip dateModified — they only include datePublished — which causes validation failures because Google expects dateModified to be present and up to date.
Another common mistake: using the same image URL across all articles. Google expects each Article to have its own representative image. Using a site-wide logo or default image for every article is flagged as a quality issue and can prevent rich results.
FAQPage Schema: The Question and Answer Formatting Rules
FAQPage schema is one of the most valuable types for SEO in 2026 — it can trigger expanded results in both traditional search and AI overviews. But it has specific structural requirements that many implementations violate.
Each Question must contain both the name (the question text) and acceptedAnswer (an Answer object containing the answer text). The answer must be a direct response to the question, not a redirect or placeholder. You cannot use the same Question across multiple FAQPage schemas on different URLs — each FAQPage must have unique questions. Using FAQPage schema for pages that aren’t actually FAQs (like product category pages) will be flagged as schema abuse.
HowTo Schema: Step Structure and Image Requirements
HowTo schema triggers instructional rich results and is increasingly valuable for AI search systems that need to extract procedural information. The requirements are precise: each HowToStep must be a named step (not just a paragraph of text), must contain text describing the step, and should reference images for each step where possible.
The most common HowTo error: using heading tags (H2, H3) as steps without corresponding HowToStep markup. The semantic markup and the visual structure must match. If you have three H2 headings that represent your how-to steps, each H2 should be wrapped in its own HowToStep markup with the same text. Using a single HowToStep for an entire article’s worth of content won’t trigger the rich result.
JSON-LD Placement and Rendering Problems
Getting the schema syntax correct is only half the battle. Where and how you deliver your structured data matters equally — for parsing reliability, rendering performance, and long-term maintainability.
The Render-Blocking vs. Lazy-Loading Trap
Structured data in the head or early in the body is parsed reliably. Structured data injected via JavaScript after initial page render — common with tag management systems and JavaScript frameworks — is less reliable. Google states that JavaScript-rendered structured data is supported, but in practice, JS-rendered schema is more likely to be missed, particularly for new pages before Google’s rendering infrastructure has processed them.
For critical schema types (Article, Product, FAQPage, LocalBusiness), render the structured data inline in the HTML server-side or at minimum in the initial page payload — not injected via third-party scripts after load. Use Google Tag Manager for analytics and non-critical tags; keep core structured data in the document itself.
Multiple Schema Blocks vs. Single Graph: Which to Use
You can have multiple separate
Next.js SEO: Complete Technical Guide for React-Based Websites
React is everywhere, and Next.js has become the default framework for teams that want React…
Read More →-
By Guy Sheetrit
- Apr 17, 2026
By Guy Sheetrit
