How to Add Schema to WordPress

What Schema Markup Is

Schema markup is a shared vocabulary that tells search engines what your content actually means. A page might show a headline, a date, an author name, and a photo, and a human reads all of that in a second. A crawler sees text and tags. Schema fills the gap. It labels the headline as a headline, the date as a publish date, and the author as a Person, so Google, Bing, and others can understand the page instead of guessing.

The vocabulary comes from schema.org, a project backed by Google, Microsoft, Yahoo, and Yandex. When you add schema to WordPress, you are describing your content using types and properties that every major search engine already recognizes. That shared language is why a recipe page in Toronto and a recipe page in Tokyo can both earn the same rich result. They speak the same structured data.

Structured data does not change what your visitors see on the page. It lives in the source code, usually as a small block of JSON, and it speaks only to machines. The payoff shows up later, in the search results, where a well marked page can appear with star ratings, FAQ dropdowns, breadcrumb trails, event dates, and other extras that a plain blue link never gets.

Why bother with structured data at all

Three reasons make it worth the effort. First, rich results take up more space and draw more attention, which tends to lift clicks even when your ranking position stays the same. Second, clear structured data helps search engines trust and categorize your content, which supports your wider SEO work. Third, assistants and voice search increasingly pull answers from structured data, so marked up content has a better chance of being the source that gets read aloud.

None of this is a ranking cheat. Schema will not push a weak page to the top of Google. Think of it as a way to present a strong page more clearly and to qualify for features that plain pages simply cannot show. If you are building out your wider search strategy, our complete WordPress SEO guide covers how structured data fits alongside content, speed, and technical work.

A quick analogy

Picture a librarian receiving a stack of unlabelled books. She can read each one and work out where it belongs, but it takes time and she will make the odd mistake. Now imagine every book arrives with a clean label on the spine: title, author, subject, publication date. Shelving becomes fast and accurate. Schema is that label for your web pages. The content is still the book, but you have made it trivial for the search engine to file it correctly and to know when it is the right answer to a reader's question.

This matters more every year. Search results are no longer just ten blue links. They are carousels, panels, answer boxes, and cards, and most of those surfaces are built from structured data. A page without schema can still rank, but it competes with one hand tied behind its back on any result that shows more than plain text. Adding schema to WordPress is how you make sure your content can compete for the whole range of modern search features, not only the oldest and plainest one.

JSON-LD vs Microdata

There are three ways to write structured data on a web page: JSON-LD, Microdata, and RDFa. You will meet the first two most often in WordPress, so it helps to understand the difference before you pick a method.

Microdata

Microdata weaves the markup directly into your HTML using attributes such as itemscope, itemtype, and itemprop. The labels sit inside the visible elements of the page. Here is a stripped down example so you can see the shape of it:

<div itemscope itemtype="https://schema.org/Article">
  <h1 itemprop="headline">How to Add Schema to WordPress</h1>
  <span itemprop="author">Hamza Hai</span>
</div>

Microdata works, but it tangles your data into your template. Every time you restyle the page, you risk breaking the markup, and reading it is harder because the meaning is scattered across the HTML.

JSON-LD

JSON-LD stands for JavaScript Object Notation for Linked Data. Instead of decorating your HTML, it places a single self contained block in the page, usually inside a <script type="application/ld+json"> tag. The block describes the page as a tidy object, separate from your markup. Google states plainly that JSON-LD is its recommended format, and for good reason.

• It is clean. All of your structured data sits in one place, not sprinkled through the template.
• It is easy to generate. A plugin or a PHP function can build the object and drop it into the head without touching your theme markup.
• It is easy to test. You can copy the block, paste it into a validator, and read it like a normal object.
• It survives redesigns. Because it does not live inside your visible HTML, restyling a page will not break the data.

For almost every WordPress project, JSON-LD is the right choice. The rest of this guide uses it. RDFa exists too, and it is similar to Microdata in that it uses HTML attributes, but you rarely need it on a modern WordPress site, so we will set it aside.

How Schema Drives Rich Results

A rich result is any search listing that shows more than the standard title, web address, and description. Star ratings under a product, a set of expandable FAQ questions, a recipe card with a photo and cook time, breadcrumb trails in place of a raw URL: these are all rich results, and each one is powered by a specific schema type.

The path from your page to a rich result runs through a few clear stages. Understanding the chain helps you see why a missing property or a validation error quietly costs you the feature.

1. You add schema. A JSON-LD block describes the page using a schema.org type such as Recipe or FAQPage.
2. Google crawls the page. The crawler reads your HTML and finds the JSON-LD block in the head or body.
3. Google parses the data. It checks the type, reads the properties, and validates them against the requirements for that type.
4. The page qualifies. If the required properties are present and valid, the page becomes eligible for the matching rich result.
5. The rich result may appear. Google decides whether to show it, based on quality, relevance, and its own judgement.

That last step matters. Valid schema makes a page eligible for a rich result. It does not guarantee one. Google reserves the right to show a plain listing even when your markup is perfect, and it will drop the feature if it decides the content does not deserve it. Your job is to earn eligibility and keep the markup clean. The rest is out of your hands.

Common Schema Types

Schema.org defines hundreds of types, but a handful cover most WordPress sites. Pick the type that matches the true purpose of each page. A blog post is an Article. A service business homepage is often an Organization or a LocalBusiness. A single product page is a Product. Do not stack types that do not belong just because you can.

The table below pairs the most useful types with the rich result each one can produce, so you can decide which are worth adding.

A note on FAQ and HowTo

Google has narrowed where FAQ and HowTo rich results appear. FAQ rich results now show mainly for well known authoritative government and health sites, and HowTo rich results have been scaled back too. That does not make the markup useless. It still helps search engines understand your page, and policies change over time. Just do not add FAQ schema expecting guaranteed dropdowns in every listing. Add it because it describes the page honestly.

Nesting and the @graph

Real pages often need more than one type. A blog post might carry an Article, a BreadcrumbList, an Organization for the publisher, and a WebSite. Rather than dumping four separate script blocks, mature schema uses a single @graph array that holds several connected objects and links them by @id. Good plugins such as Yoast and Rank Math build this graph for you automatically, which is one of the strongest reasons to let a plugin handle the heavy lifting.

How to choose the right type for a page

When you are unsure which type a page should use, ask what the page is fundamentally for, then pick the most specific type that answers that. A single tutorial is an Article, and if it walks through discrete steps you can also express it as a HowTo. A page selling one item is a Product. A page describing your company is an Organization, and if that company serves customers from a physical location it becomes a LocalBusiness, which is a subtype of Organization with extra properties for address and hours.

Two rules keep you out of trouble. First, do not force a type onto a page that does not match it just to chase a rich result. A services page is not a Product, and marking it as one will confuse search engines rather than help you. Second, prefer the specific subtype over the generic parent when it fits. LocalBusiness tells Google far more than the broad Organization type, and Recipe tells it far more than Article for a cooking page. Specificity is what earns the better result.

Article, Product, and LocalBusiness in practice

These three cover a large share of real WordPress sites. Article suits every blog and news page and wants a headline, an image, publish and modified dates, an author, and a publisher. Product suits ecommerce and needs a name, an image, and an offer with price and availability, plus a review or rating if you have genuine ones. LocalBusiness suits any business with a location and wants a name, address, phone number, and opening hours, and it feeds the details that can appear in local search and maps. Get these three right and most sites are covered before you ever reach the rarer types.

Plugins vs Manual Methods

You have two broad routes to add schema to WordPress: use a plugin that generates it, or write the JSON-LD yourself. Both are valid. The right one depends on your comfort with code, how custom your needs are, and how much you want to maintain.

The plugin route

Most WordPress sites already run an SEO plugin, and the popular ones output structured data out of the box.

• Yoast SEO builds a connected schema graph for your whole site automatically. It marks up your Organization or Person, your WebSite, breadcrumbs, and each Article or Page, and it links them cleanly. It covers the common cases with almost no setup.
• Rank Math ships with a flexible schema generator. It supports many types, lets you set defaults per post type, and includes a template builder for custom schema. It is a strong pick if you want control without writing code.
• Schema Pro is a dedicated schema plugin. You map fields once, and it applies the chosen schema across a post type. It is useful when you need types your SEO plugin does not cover well.

Plugins win on speed, maintenance, and safety. They keep your markup valid as schema.org and Google guidelines shift, and they spare you from hand editing every page. For the large majority of sites, a plugin is the sensible default.

The manual route

Hand coded JSON-LD gives you total control. You decide exactly which properties appear and how the object is shaped. You add it either through a function in your theme or a small custom plugin that prints the block in wp_head, or by dropping a Custom HTML block on a specific page.

Manual markup makes sense when you need a type or property your plugin will not produce, when you are building a custom theme and want tight control, or when you want to avoid loading a plugin for a single page. The cost is maintenance. You own every change, and you have to keep the markup valid yourself.

There is also a middle path worth knowing. Some sites keep their SEO plugin for the site wide graph and layer a single custom block on top for the one page that needs a special type, such as an Event or a Course the plugin handles poorly. This gets you the low maintenance of a plugin for the bulk of the site and the precision of hand coding only where it earns its keep. It is the approach we reach for most often on client work, because it keeps ninety percent of the site automatic and reserves manual effort for the pages that truly justify it.

The table below sums up the trade off.

Our usual advice is to let a plugin handle the site wide graph, then add hand coded JSON-LD only for the special cases the plugin misses. If you would rather have this set up properly from the start, our WordPress services team can build and test it for you, and you can get a free quote to see what it involves.

Add Schema With a Plugin

Let us walk through adding schema with Rank Math, since its generator is one of the clearest. The same ideas apply to Yoast and Schema Pro, with different menu names. This assumes you have the plugin installed and its setup wizard finished.

1. Set your site wide defaults. In Rank Math, open WordPress admin > Rank Math SEO > Titles and Meta. For each post type, such as Posts, set a default schema type. Articles for the blog and a suitable type for pages is a good starting point.
2. Confirm your Organization details. Under Rank Math SEO > General Settings > Others or the setup wizard, set whether the site represents a person or an organization, add the name, and upload a logo. This feeds the site wide Organization schema.
3. Open a post you want to mark up. Edit the post, then open the Rank Math panel in the editor. Move to the Schema tab.
4. Choose the schema type. Click Schema Generator, pick a type such as Article, Product, or FAQ, and click to use it. The current default is shown so you can override it per post.
5. Fill in the properties. Complete the fields the generator shows, such as headline, description, and images. Leave optional fields blank rather than guessing at values.
6. Add an FAQ block if relevant. For a genuine question and answer section, use the FAQ block in the editor. It writes the visible content and the FAQPage schema together, which keeps them in sync.
7. Update the post. Save your changes. Rank Math now prints the JSON-LD in the page head automatically.
8. Validate the result. Copy the live web address into the Rich Results Test, which we cover below, and confirm the type is detected with no errors.

Doing the same with Yoast

Yoast is even more hands off. Once you set your site representation and logo under Yoast SEO > Settings, it builds the graph for every post and page on its own. To adjust how a single page is described, use the Schema tab in the Yoast meta box below the editor, where you can change the page type and the article type. For most blogs, the defaults are already correct, and you may not need to touch a thing.

Whichever plugin you use, the principle holds: set sensible site wide defaults once, override per page only when needed, and always validate the output. That combination gives you clean, connected schema with very little ongoing work.

Add Schema Manually

Sometimes you need markup a plugin will not produce, or you are working in a custom theme and want to control the output yourself. Manual JSON-LD is the answer. There are two practical ways to do it: a Custom HTML block for a one off page, or a function that prints the block in wp_head for a repeatable, dynamic result.

Method one: a Custom HTML block for a single page

This is the quickest manual method and needs no code files.

1. Write your JSON-LD. Build the object for the page. Here is a complete, valid Article block you can adapt:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to Add Schema to WordPress",
  "description": "A practical guide to structured data and rich results in WordPress.",
  "image": "https://example.com/images/schema-guide.jpg",
  "datePublished": "2026-08-06",
  "dateModified": "2026-08-06",
  "author": {
    "@type": "Person",
    "name": "Hamza Hai"
  },
  "publisher": {
    "@type": "Organization",
    "name": "WP Developer",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/images/logo.png"
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/blog/how-to-add-schema-to-wordpress"
  }
}
</script>

2. Add a Custom HTML block. Edit the page, add a block, and choose Custom HTML.
3. Paste the script. Drop your JSON-LD into the block.
4. Match the visible content. Make sure the values in the schema, such as the headline and dates, match what the page actually shows. Mismatched markup can be flagged as misleading.
5. Update and validate. Save the page and run it through the Rich Results Test.

This method is fine for a handful of pages. It does not scale, because you hard code the values, so a change to your logo or business name means editing every block by hand.

Method two: print JSON-LD in wp_head with PHP

For anything repeatable, generate the schema in code so it stays in sync with your content. Add a function to your child theme functions.php or, better, to a small site specific plugin, and hook it to wp_head. The example below outputs LocalBusiness schema on the front page, pulling values dynamically where sensible:

function wpdev_local_business_schema() {
    if ( ! is_front_page() ) {
        return;
    }

    $schema = array(
        '@context'  => 'https://schema.org',
        '@type'     => 'LocalBusiness',
        'name'      => get_bloginfo( 'name' ),
        'url'       => home_url( '/' ),
        'telephone' => '+1-000-000-0000',
        'address'   => array(
            '@type'           => 'PostalAddress',
            'streetAddress'   => '123 Example Street',
            'addressLocality' => 'Toronto',
            'addressRegion'   => 'ON',
            'postalCode'      => 'M1M 1M1',
            'addressCountry'  => 'CA',
        ),
        'openingHours' => 'Mo-Fr 09:00-17:00',
    );

    echo '<script type="application/ld+json">'
        . wp_json_encode( $schema )
        . '</script>' . "\n";
}
add_action( 'wp_head', 'wpdev_local_business_schema' );

A few points make this snippet safe and correct. It uses wp_json_encode rather than raw string building, so the output is always valid JSON and properly escaped. It checks is_front_page so the block only prints where it belongs. And it pulls the site name from get_bloginfo, so a rename in settings updates the schema automatically. You would swap the placeholder phone and address for your real details, ideally read from options rather than hard coded.

Hooking to wp_head is the standard way to inject anything into the document head in WordPress, and it is exactly where JSON-LD belongs. If you prefer to keep schema out of the theme entirely so it survives theme switches, put the same function inside a small custom plugin instead. That is the approach we take on client sites, because structured data is site behaviour, not theme presentation. If wiring this up by hand feels risky, our team can build it and hand it over tested. You can request a free quote to get started.

Which manual method to pick

• One special page, fixed values: a Custom HTML block is quick and fine.
• Repeatable, dynamic, or site wide: generate it in PHP and hook wp_head.
• Must survive theme changes: put the PHP in a small custom plugin, not the theme.

Testing and Validation

Never trust schema you have not tested. A single missing property or a stray comma can turn valid markup into markup Google ignores. Two free tools cover almost everything you need, and you should run both.

The Rich Results Test

Google's Rich Results Test tells you whether a page is eligible for a rich result and which one. Use it as your first check.

1. Open the Rich Results Test in your browser.
2. Enter the live web address of the page, or paste your code directly to test a draft.
3. Run the test and wait for it to fetch and parse the page.
4. Read the detected items. It lists the type it found, such as Article, and flags any errors or warnings.
5. Fix errors first. Errors block the rich result. Warnings are recommended fields that improve the result but do not block it.
6. Re-run the test until the type shows as valid and eligible.

The Rich Results Test is focused on features Google can actually show, so it is the tool that answers the practical question: can this page earn a rich result.

The Schema Markup Validator

The Schema Markup Validator, hosted at validator.schema.org, checks your markup against the full schema.org vocabulary rather than Google's feature list. Use it when you want to confirm that a type or property is technically valid, even if Google does not use it for a rich result. It is the right tool for custom or less common schema that the Rich Results Test does not recognize.

Search Console

Once your schema is live, Google Search Console reports on it over time. Its enhancement reports, such as the ones for Breadcrumbs or Products, show valid items, warnings, and errors across your whole site as Google crawls it. This is how you catch a problem that appears only on certain templates or after a change. Check it periodically, not just once. Structured data can drift when a plugin updates or a template changes, and Search Console is where that shows up.

A sensible testing routine looks like this: validate each new page in the Rich Results Test before you consider it done, use the Schema Markup Validator for anything custom, and review Search Console enhancement reports every few weeks to catch site wide issues early.

Reading the results without panic

The tools separate problems into errors and warnings, and the difference is important. An error means a required property is missing or invalid, and it blocks the rich result, so fix errors first and treat them as non negotiable. A warning means a recommended property is absent. Warnings do not block eligibility, they simply mean the result could be richer if you supplied the field. You do not have to clear every warning to earn a rich result, though filling the important ones, such as an image or an author, usually improves how the listing looks.

When a test reports the wrong type, or misses your markup entirely, the usual cause is that the JSON-LD is not in the raw HTML the crawler receives. Fetch the page source directly and search for application/ld+json. If the block is there and valid but the tool still misses it, check that nothing later on the page overwrites it and that you are testing the live URL rather than a cached or staging copy. Methodical checking beats guessing every time.

Common Mistakes and Errors

Most schema problems fall into a short list of repeat offenders. Knowing them saves hours of confused debugging.

Marking up content that is not on the page

This is the biggest one. Your schema must describe content that is actually visible to users on that page. Adding FAQ schema for questions that do not appear on the page, or Review schema for ratings a visitor cannot see, breaks Google's guidelines and can trigger a manual action. Structured data should reflect the page, not invent extras for it.

Self serving review markup

Google does not allow a business to add Review or AggregateRating schema about itself on its own pages to show star ratings for the whole organization. Reviews should be about a specific product or item and genuinely present. Sites that stuff star ratings onto their homepage through a plugin often see the feature ignored or flagged.

Duplicate or conflicting schema

Running two plugins that both output structured data, or adding manual schema on top of what a plugin already prints, can produce duplicate or conflicting types. Search engines then get two different stories about the same page. Pick one source of truth for each type. If your SEO plugin already outputs Article schema, do not add a second Article block by hand.

Missing required properties

Each rich result has required properties. A Product without an offer or review, or an Event without a start date, will not qualify. The Rich Results Test flags these as errors. Read the requirements for the type you are using and supply every required field before you expect the feature.

Invalid JSON

Hand written JSON-LD is easy to break. A trailing comma, a missing quote, or an unescaped character makes the whole block invalid, and search engines skip it silently. This is exactly why generating schema with wp_json_encode in PHP is safer than typing it by hand. If you do write it manually, validate every block.

Wrong or vague types

Using a generic type such as Thing when a precise type such as Product fits better, or picking a type that does not match the page purpose, weakens the markup. Choose the most specific accurate type. Precision helps search engines and improves your chances of the right rich result.

Blocking the crawler

If your JSON-LD depends on JavaScript that Google cannot render, or the page is blocked in robots.txt, the schema never gets read. Server rendered JSON-LD in the head, which is what plugins and the PHP method produce, avoids this. If your structured data suddenly disappears from reports, check that the page is crawlable and that the markup is in the raw HTML. A broken template or a stray redirect can hide it, and our guide on fixing 404 errors in WordPress covers the crawl side of that problem.

Best Practices

Bring it together with a set of habits that keep your structured data clean, honest, and useful over the long run.

• Prefer JSON-LD. It is Google's recommended format, it is easy to maintain, and it survives redesigns. Reach for Microdata only when you have a specific reason.
• Let a plugin own the site wide graph. Yoast or Rank Math will mark up your Organization, WebSite, breadcrumbs, and articles and connect them properly. Do not rebuild that by hand.
• Add manual JSON-LD only for gaps. Reserve hand coding for types and properties your plugin does not cover, and generate it in PHP with wp_json_encode so it stays valid.
• Match schema to visible content. Every value in your markup should reflect what a visitor actually sees. This is a hard rule, not a preference.
• Use the most specific accurate type. Precise types describe your content better and improve your odds of the right rich result.
• Fill required properties, then recommended ones. Required fields make you eligible. Recommended fields make the result richer. Do the first, then the second.
• Validate before you publish. Run the Rich Results Test on every new page, and the Schema Markup Validator for anything custom.
• Watch Search Console. Review enhancement reports every few weeks to catch site wide errors after updates or template changes.
• Avoid duplicate sources. One source of truth per schema type. Turn off overlapping outputs so you never send conflicting data.
• Keep it honest. Do not add markup to fake ratings, invent questions, or claim features the page does not have. It risks a penalty and rarely lasts.
• Re-test after big changes. A theme switch, a plugin update, or a redesign can quietly alter or remove your markup. Run the Rich Results Test again after any major change so a broken block does not go unnoticed for months.

Where schema fits in the bigger picture

Structured data is one part of a healthy WordPress site, not the whole of it. It works best on pages that are already fast, well written, and easy to crawl. If your foundations need work, tighten those first. Our guides on speeding up a WordPress website and WordPress SEO pair naturally with this one, and the how to make a WordPress website guide covers the base you build on. Schema then presents that strong content clearly to search engines and qualifies it for features a plain page cannot earn.

Getting help

Adding schema to WordPress is approachable, but doing it cleanly across a real site, with the right types, valid markup, and no duplicates, takes care. If you would rather have it set up and tested properly, we can build the whole structured data layer for your site and confirm it in the Rich Results Test before we hand it over. Get a free quote and tell us about your site, or request a quote here and we will map out the schema your pages should carry.