Structured data doesn't change how your WordPress site looks. It changes how well Google understands it, and that gap between "looks fine" and "is actually machine-readable" is where most sites leave visibility on the table. This is the checklist I run through on every WordPress build, based on what's actually paid off in Search Console over the years, not the theory.

Start with the schema types that apply to you

Google's documentation covers dozens of schema.org types, but most sites only need a handful. Before touching code, match your actual page types to real schema:

  • Organization or Person — homepage, once, identifying who's behind the site.
  • WebSite — homepage, enables sitelinks search box eligibility.
  • Article or BlogPosting — every blog post or news page.
  • BreadcrumbList — every page below the homepage, matching your actual navigation path.
  • Product and Review — only on real product/review pages, with real prices and real reviews.
  • LocalBusiness — only if you have a physical address or service area customers visit.

Resist the urge to add every type "just in case." Google's guidelines are explicit that structured data must describe content actually present and visible on the page. Marking up data that isn't there is treated as spam, not enthusiasm.

Where to add JSON-LD in WordPress

Google supports JSON-LD, Microdata, and RDFa, but recommends JSON-LD because it lives in a single script block instead of being woven through your HTML. That means your theme's markup can change without breaking your schema. In a WordPress context, there are three practical ways to add it:

1. An SEO plugin

Fine for standard types (Article, Organization, BreadcrumbList) and the fastest way to get baseline coverage. The trade-off is limited control over edge cases and the risk of duplicate markup if you later add your own.

2. A small functions.php snippet

For anything the plugin doesn't cover well, hook into wp_head directly:

function nb_person_schema() {
    if ( ! is_front_page() ) return;
    $schema = array(
        '@context' => 'https://schema.org',
        '@type'    => 'Person',
        'name'     => get_bloginfo( 'name' ),
        'url'      => home_url( '/' ),
    );
    echo '<script type="application/ld+json">'
        . wp_json_encode( $schema )
        . '</script>';
}
add_action( 'wp_head', 'nb_person_schema' );

3. Native block theme support

If you're on a full-site-editing block theme, template parts can output JSON-LD conditionally per template — useful when different post types need genuinely different schema rather than one generic block.

A practical page-by-page checklist

  • Homepage: Organization/Person + WebSite
  • Every page: BreadcrumbList matching the real nav hierarchy
  • Blog posts: Article, with datePublished, dateModified, and author filled in from real post data, not hardcoded
  • Shop/product pages: Product + aggregateRating, only where real reviews exist
  • FAQ content: FAQPage, only if the questions are genuinely visible as content on the page

Common mistakes worth avoiding

The most frequent issue isn't missing schema, it's schema that's gone stale. Because JSON-LD lives in the page's <head>, it's easy to update the visible content and forget the structured data underneath it, which leaves you describing a page that no longer exists. The fix is boring but effective: pull schema values from the same post fields that render on the page, so they can't drift apart.

The second most common issue is duplication: a plugin outputs Organization schema, and a theme or custom snippet outputs it again. Search Console's Enhancements reports will flag this, but it's worth checking manually after any theme or plugin change.

How to verify it actually worked

Two checks, every time. Run the page through Google's Rich Results Test to confirm the markup parses and is eligible for the enhancement you're targeting, then watch the relevant report under Search Console's Enhancements section over the following days to confirm Google is picking it up at crawl time. Validation and real indexing aren't the same thing, and only the second one moves the needle.

Structured data is one of the few SEO levers with genuinely clear cause and effect: mark it up correctly, and Google can represent your content more richly in results. Mark it up carelessly, and you're either wasting effort or risking a manual action. Worth doing once, and doing properly.