When clients ask me how to add schema markup, the first thing I clarify is that there are three distinct delivery methods: inline JSON-LD in the page head, Microdata embedded in HTML elements, and RDFa attributes woven into existing tags. I recommend JSON-LD for almost every project because it keeps the structured data separate from your presentation layer, making it easier to audit and update without touching the template HTML. This guide covers the full process — format choice, code patterns, WordPress-specific methods, and validation.

Schema markup is not a direct ranking factor, but it is the mechanism that makes rich results, knowledge graph entries, and AI Overview eligibility possible. Getting the implementation right from the start saves hours of audit work later.

Choosing Your Delivery Method

JSON-LD is injected as a script block in the <head> or just before the closing </body> tag. Google has explicitly stated a preference for JSON-LD, and in practice it produces fewer implementation errors than Microdata. Microdata works but requires annotating every visible HTML element with itemscope, itemtype, and itemprop attributes — manageable for a single static page, unmaintainable at scale. RDFa is rarely worth the complexity unless you are inheriting a CMS that already uses it.

The practical decision tree: if you control the HTML or are building a custom theme, use JSON-LD in the <head>. If you are on a hosted platform (Shopify, Squarespace), check whether the platform already injects schema and what it outputs before adding your own. Duplicate blocks from platform defaults and custom additions are one of the most common errors I find in audits.

The Basic JSON-LD Pattern

Every JSON-LD block follows the same structure: a <script> tag with type='application/ld+json', then a JSON object with @context and @type as required keys, then the type-specific properties. Here is how to add schema markup for a local business page:

<script type='application/ld+json'>
{
  '@context': 'https://schema.org',
  '@type': 'LocalBusiness',
  'name': 'Salterra Digital',
  'url': 'https://salterra.com',
  'telephone': '+1-480-555-0100',
  'priceRange': '$$',
  'address': {
    '@type': 'PostalAddress',
    'streetAddress': '123 Main St',
    'addressLocality': 'Tempe',
    'addressRegion': 'AZ',
    'postalCode': '85281',
    'addressCountry': 'US'
  },
  'geo': {
    '@type': 'GeoCoordinates',
    'latitude': 33.4255,
    'longitude': -111.9400
  },
  'openingHoursSpecification': [
    {
      '@type': 'OpeningHoursSpecification',
      'dayOfWeek': ['Monday','Tuesday','Wednesday','Thursday','Friday'],
      'opens': '09:00',
      'closes': '17:00'
    }
  ]
}
</script>

Place this block once per page. If you have multiple schema types on the same page, use either multiple script blocks or a single block with a top-level @graph array. I prefer the @graph approach because it makes entity relationships explicit — see schema markup best practices for how to structure that correctly.

How to Add Schema Markup in WordPress

WordPress gives you four practical paths for adding schema markup.

Plugin-based (Yoast, Rank Math, Schema Pro): The fastest option for non-developers. Yoast and Rank Math both generate a JSON-LD block automatically based on your content type and site settings. The downside is that these plugins often produce bloated or conflicting output — I frequently see sites with three separate Organization blocks from three different plugins. If you use a plugin, audit its output with the Rich Results Test and disable any competing schema from themes or other plugins.

Custom function in functions.php: The most precise option. Hook into wp_head and output your JSON-LD block as a string. This gives you full control over every property and prevents plugin conflicts. Here is a minimal example for adding Organization schema to every page:

add_action( 'wp_head', 'salterra_output_org_schema' );
function salterra_output_org_schema() {
  echo <script type='application/ld+json'>
  {
    '@context': 'https://schema.org',
    '@type': 'Organization',
    '@id': 'https://salterra.com/#organization',
    'name': 'Salterra Digital',
    'url': 'https://salterra.com'
  }
  </script>;
}

Dedicated schema plugin (Schema & Structured Data for WP): A middle ground — more control than Yoast but less code than a custom function. Useful if you need to add several different schema types across different post types without writing PHP.

Gutenberg block with custom HTML: For one-off pages or landing pages where you need precise control without modifying the theme, paste the JSON-LD block into a Custom HTML block. This works but is fragile — easy to accidentally delete during an edit session.

Handling Multiple Schema Types on One Page

Most pages need more than one schema type. A blog post might need Article, Person (author), BreadcrumbList, and FAQPage. A product page might need Product, Offer, AggregateRating, and Organization. Rather than stacking multiple script blocks (which works but is harder to audit), consolidate into a single block using @graph:

<script type='application/ld+json'>
{
  '@context': 'https://schema.org',
  '@graph': [
    {
      '@type': 'Article',
      '@id': 'https://terrysamuels.com/how-to-add-schema-markup/#article',
      'headline': 'How to Add Schema Markup to Your Website: 2026 Guide',
      'author': { '@id': 'https://terrysamuels.com/#person' },
      'datePublished': '2026-01-08',
      'mainEntityOfPage': 'https://terrysamuels.com/how-to-add-schema-markup/'
    },
    {
      '@type': 'Person',
      '@id': 'https://terrysamuels.com/#person',
      'name': 'Terry Samuels',
      'url': 'https://terrysamuels.com'
    },
    {
      '@type': 'BreadcrumbList',
      'itemListElement': [
        { '@type': 'ListItem', 'position': 1, 'name': 'Home', 'item': 'https://terrysamuels.com/' },
        { '@type': 'ListItem', 'position': 2, 'name': 'Schema Markup', 'item': 'https://terrysamuels.com/schema-markup/' }
      ]
    }
  ]
}
</script>

Notice each object in the @graph array gets its own @type, and I connect them with @id references instead of repeating data. The Article references the Person by @id rather than nesting the full author object again. That single change is what lets Google (and any other consumer of the data) understand that the same entity shows up in multiple places on your site, which matters more than most people realize once you start asking how to add schema markup consistently across dozens or hundreds of pages rather than one.

Testing and Validating Your Markup

Every block goes through two checks before I consider it done. First, Google’s Rich Results Test, which tells you whether the markup is eligible for a specific rich result and flags outright errors. Second, Schema.org’s own validator, which is less opinionated about rich results but catches type and property mismatches the Rich Results Test sometimes lets through. I run both because they disagree often enough that relying on one leaves gaps.

Warnings are not the same as errors. A warning usually means you are missing a recommended-but-not-required property — aggregateRating on a Product, for instance. Errors mean the markup will not be read as intended at all, usually because a required property is missing or a value is the wrong type (a string where a number is expected, most commonly). Fix every error before publishing. Warnings are worth clearing when you have time, but they will not block eligibility on their own.

One thing the validators will not catch: whether the schema matches what a visitor actually sees on the page. Google’s guidelines are explicit that structured data has to reflect visible content, and mismatches between the two are one of the more common reasons rich results get suppressed even when the code validates cleanly. If your JSON-LD says a product is in stock and the page shows a sold-out badge, expect that markup to eventually stop earning rich results, manual review or not.

Keeping Schema Markup Accurate as the Site Changes

The part nobody budgets time for is maintenance. Schema markup that was accurate on launch day drifts out of sync as prices change, staff turns over, and pages get redesigned. A few habits keep it from rotting: pull structured data from the same source as the visible content wherever your CMS allows it, rather than hardcoding values in two places; re-run validation after any template change, not just after schema-specific edits; and check Search Console’s Enhancements reports monthly for a spike in errors, which usually means a plugin update or template change broke something upstream of the JSON-LD itself.

On larger sites this becomes enough work that clients bring in outside help rather than manage it in-house — which is essentially what a schema markup consultant gets hired to keep on top of: not just the initial build, but the ongoing audit as templates, plugins, and content all keep moving.

Which Schema Types to Prioritize First

Clients often want to know how to add schema markup for everything at once, and I usually talk them out of it. Start with whichever type maps to how people actually find the site. A local service business gets more value from LocalBusiness and Service schema than from anything else, because those directly support the local pack and knowledge panel results that drive calls. A content site with an active blog gets more value from Article and Person schema, plus BreadcrumbList to reinforce site structure. An ecommerce site should prioritize Product, Offer, and AggregateRating before touching anything else, because those three are what actually unlock star ratings and price display in search results.

FAQPage and HowTo schema are the two types I get asked about most and recommend least often as a starting point. Both can produce visually prominent rich results, which is exactly why they get requested first — but both also require the marked-up content to be genuinely visible on the page in the form described, and Google has taken enforcement action against sites that added FAQ or HowTo markup for content that was not actually presented that way to visitors. Add them once your core types are solid, and only for content that already exists on the page in that format.

A Note on E-E-A-T and Schema

Schema does not create expertise, experience, authoritativeness, or trust — it documents information that should already be true and visible elsewhere on the site. Person schema describing an author’s credentials only helps if that author’s bio, byline, and background actually appear on the page in a form a human reader would find convincing. I have reviewed schema audits where a site had detailed knowsAbout and alumniOf properties on a Person entity for an author whose actual bio was two sentences with no visible credentials at all. The markup was technically valid and functionally useless, because it was documenting expertise the page itself did not demonstrate. Get the visible content right first. Schema is the wrapper, not the substance.

Where to Go From Here

Adding schema markup is not a single task you finish once. It is closer to a system you set up and then maintain: pick JSON-LD as your format, decide where in your stack it gets generated, build the basic types your content actually needs, validate before and after each change, and revisit the whole setup whenever the site itself changes shape. The four guides below cover the pieces of that system I get asked about most — adding markup without a plugin, deciding where in the page it should live, wiring it through Google Tag Manager instead of code, and the mistakes I see most often in audits.