Schema Markup Best Practices That Actually Hold Up in 2026

Schema markup best practices have a stable core, but the patterns that produce results in 2026 reflect lessons from years of seeing what actually works at scale — and what breaks silently six months after a CMS update. I have been implementing and auditing structured data long enough to see which practices hold up and which ones are cargo-culted from blog posts written when Schema.org was still in early adoption.

What follows is my working list of practices I apply to every engagement. Not theory — the things that consistently produce better structured data coverage, fewer Google Search Console errors, and sustained rich result eligibility over time.

Use JSON-LD as Your Delivery Format

JSON-LD keeps structured data in a separate script block rather than tangled into your HTML attributes. That separation matters for auditing — you can read and update a JSON-LD block without touching the presentation layer. Google has explicitly recommended JSON-LD since 2016, and in practice it produces fewer implementation errors than Microdata or RDFa. For any new implementation, JSON-LD is the right starting point.

One caveat: if you are on a platform that already injects schema via Microdata and you cannot override it, prioritize removing conflicts before adding JSON-LD on top. Duplicate and competing blocks are worse than a single correct implementation in the less-preferred format.

Structure Multi-Type Pages with a Top-Level @graph

For any page with more than one schema type, structure the markup as a single JSON-LD block with a @graph array instead of multiple separate script blocks. This approach makes the relationships between entities explicit and reduces the chance that Google treats the blocks as competing rather than complementary signals. It also simplifies auditing — one block per page is easier to scan than three.

<script type='application/ld+json'>
{
  '@context': 'https://schema.org',
  '@graph': [
    {
      '@type': 'WebPage',
      '@id': 'https://terrysamuels.com/schema-markup-best-practices/#webpage',
      'name': 'Schema Markup Best Practices',
      'url': 'https://terrysamuels.com/schema-markup-best-practices/',
      'isPartOf': { '@id': 'https://terrysamuels.com/#website' },
      'about': { '@id': 'https://terrysamuels.com/#person' }
    },
    {
      '@type': 'WebSite',
      '@id': 'https://terrysamuels.com/#website',
      'name': 'Terry Samuels',
      'url': 'https://terrysamuels.com'
    },
    {
      '@type': 'Person',
      '@id': 'https://terrysamuels.com/#person',
      'name': 'Terry Samuels',
      'url': 'https://terrysamuels.com',
      'sameAs': [
        'https://www.linkedin.com/in/terrysamuels',
        'https://salterra.com'
      ]
    }
  ]
}
</script>

Each entity in the graph gets a stable @id URI. Entities reference each other by that ID rather than repeating all the properties. This is how you tell Google these things are connected — not just co-located on a page.

Use @id to Create Entity References Across Pages

Assigning a persistent @id URI to key entities — your Organization, your WebSite, your authors — lets you reference those entities from other schema blocks without repeating all the properties. It also helps Google build a coherent entity model for your site rather than treating each page’s schema in isolation.

The convention is to use a canonical URL with a fragment identifier: https://example.com/#organization, https://example.com/#website, https://example.com/author/terry/#person. The fragment makes the URI non-dereferenceable (no HTTP request gets made), which is intentional — it is a logical identifier, not a page URL. Once you establish these IDs in your site-wide schema, every page can reference them without re-declaring all the properties.

Prioritize Completeness Over Coverage

A common mistake is adding schema to every page type but leaving most properties empty or as placeholders. A fully populated LocalBusiness block on your homepage does more than sparse schema spread across fifty pages. Work through required and recommended properties for each type before moving on to additional schema types.

Google’s documentation for each rich result type distinguishes required from recommended properties. Treat recommended properties as required wherever the data exists — they are not optional in any practical sense if your goal is rich result eligibility. For Product schema, that means name, image, description, sku, offers with price and availability, and aggregateRating if reviews exist. For FAQPage, every Question entity needs an acceptedAnswer with real, non-empty content.

Match Every Schema Property to Visible Page Content

Google’s guidelines require that schema content be accessible to users on the page. Marking up a 4.9 star rating when no visible review content exists, or including an event date in schema that does not appear anywhere on the page, violates the spam policies and can result in rich result suppression or a manual action.

The rule I follow: if you cannot show it to the user, do not put it in the schema. The exceptions are properties that Google explicitly allows to be non-visible — @id, @type, license, certain URL fields. Everything else should have a corresponding visible representation. This is also why I avoid generating schema from a template with hardcoded values — a developer copies the block, forgets to update the star rating, and the site now misrepresents its content in structured data.

Choose the Most Specific @type Available

Schema.org has a detailed type hierarchy. Organization is the parent of LocalBusiness, which is the parent of MedicalBusiness, which is the parent of Dentist. Using the most specific type that accurately describes the entity gives Google finer-grained signals about what the page is about. For service businesses, check Schema.org’s LocalBusiness subtypes — there are over sixty, covering everything from ChildCare to FinancialService to SportsClub.

The same principle applies to content types. Using Article when the content is actually a NewsArticle, BlogPosting, or TechArticle is imprecise. Using Product for a service offering is incorrect. Using Person for a sole proprietor instead of Organization is more accurate when the entity really is a person, not a legal entity. Specificity is free — use it.

Audit on a Quarterly Cycle

Schema markup breaks silently. CMS updates, theme changes, plugin conflicts, and template edits all introduce errors without any visible frontend symptom. A site that had clean schema in January may have three conflicting Organization blocks in April because a plugin auto-updated and started injecting its own output.

I run a structured data audit on every active site at least quarterly. The process: pull the Rich Results Test on key page templates (homepage, a product page, a blog post, a location page); review Google Search Console Enhancements reports for new errors or warnings; spot-check the raw page source for application/ld+json blocks to confirm no new conflicts have appeared. The sites that maintain clean schema over time do it through process, not through a one-time implementation. See schema markup errors and how to fix them for the checklist I use during these reviews.

Schema and AI Search: The 2026 Layer

AI Overviews and LLM-powered search features draw on structured, unambiguous signals when synthesizing answers. Clean entity markup with complete properties reduces the interpretive work these systems have to do. An Organization entity with sameAs links to authoritative external profiles (LinkedIn, Wikidata, Crunchbase) gives AI systems an entity anchor they can verify. A Person entity with explicit knowsAbout properties signals topical authority without relying solely on prose inference.

This is not a guarantee of AI Overview inclusion, but it removes friction. Sites with well-formed schema give these systems a structured answer to start from. For more on how structured data fits into the broader SEO picture, see structured data for SEO.

Rich Snippets and the Practical Output of Clean Schema

The most visible payoff from following schema markup best practices is rich result eligibility. When your structured data is complete, correctly typed, and matched to visible page content, Google can surface enhanced treatments in the SERP: star ratings for Product and Review schema, expandable FAQ accordions for FAQPage, step previews for HowTo, sitelinks search boxes for WebSite with SearchAction. These do not directly change your ranking position, but they change how much real estate your result occupies and how much trust it signals before the click.

Not every type qualifies for a rich result on every query. Google decides whether to surface an enhanced treatment based on the query intent, the completeness of your markup, and competition in the SERP. What you can control is eligibility — clean, complete, policy-compliant schema is the only path to being in the pool. For a full breakdown of which types produce which enhanced features, see rich snippets.

For help applying these practices to your specific site, I offer schema markup consulting and a schema audit that covers every page template. For a deeper dive on implementation mechanics and CMS-specific approaches, see how to add schema markup.