Audit your WordPress schema plugin

01Why audit your WordPress schema plugin?

A WordPress schema plugin is any plugin that generates structured data for your pages, whether that is its only job or one feature of an SEO suite. Most sites run at least one, often next to a theme and WooCommerce that print markup of their own, and few owners read the combined output until something breaks.

Google's guidance on AI features makes the audit more useful, not less. Its documentation on AI features and your website says there are no additional requirements to appear in AI Overviews or AI Mode, and lists making sure structured data matches the visible text on the page among ordinary best practices.

So the job is not adding new markup for AI. It is making sure the markup you already have is accurate, connected and printed once. That is what this audit checks. Run it after any change that touches the page head: a new plugin, a theme switch, a WooCommerce update or a move to a new domain.

02Why do schema plugins conflict?

Conflicts come from overlap. A theme may print microdata in its templates, WooCommerce prints Product JSON-LD, an SEO plugin prints a site-wide graph, and a review plugin prints its own Review block. Each is valid on its own. Together they can describe one page as two Articles with different authors, or one product with two prices. Child themes inherit the parent's templates, so old microdata can survive a redesign that only changed the styling.

Some plugins also assign a type to every post by default. Rank Math's schema markup documentation, for example, describes choosing a default schema type, such as Article, that is added to posts and pages and then customised per post. That is convenient, and it means a review post or a recipe carries Article markup unless someone changes it.

Several blocks on one page are normal and not a problem in themselves. The problem is contradiction: two nodes that each claim to be the page's main entity with different names, authors, dates or prices. A parser has no way to know which one you meant.

03How do you read the @graph?

A graph, in JSON-LD, is a list of separate nodes placed under an @graph key and connected by references instead of nesting. An @id is a URL-like identifier, such as https://example.com/#organization, that lets one node point at another without repeating it.

Yoast SEO is the best-known plugin built this way. Its documentation of its schema technology and approach explains that, because cross-page support for IDs is limited, every page outputs all of the relevant pieces and cross-references them through their IDs. Other plugins nest instead. Neither approach is wrong; what you are checking is that every reference resolves.

1{2  "@context": "https://schema.org",3  "@graph": [4    {5      "@type": "Organization",6      "@id": "https://example.com/#organization",7      "name": "Example Publisher",8      "url": "https://example.com/"9    },10    {11      "@type": "WebSite",12      "@id": "https://example.com/#website",13      "url": "https://example.com/",14      "publisher": {115        "@id": "https://example.com/#organization"16      }17    },18    {19      "@type": "Person",20      "@id": "https://example.com/#/person/example-author",21      "name": "Example Author"22    },23    {24      "@type": "Article",25      "@id": "https://example.com/example-post/#article",26      "headline": "Example Post",27      "author": {228        "@id": "https://example.com/#/person/example-author"29      },30      "publisher": {31        "@id": "https://example.com/#organization"32      },33      "datePublished": "2026-10-01T09:00:00+00:00",34      "dateModified": "2026-11-08T09:00:00+00:00",335      "mainEntityOfPage": "https://example.com/example-post/"36    }37  ]38}

Read it from the top. Copy each @id that appears as a reference and search the page source for a node that declares it. A reference with no matching node is a broken entity: the page says the author is something, then never says what. Nested markup gets the same check by eye: an author object inside an Article should carry a real name, not an empty string.

04What should author, Organization and dates show?

• Author. Every article names a Person, or an Organization for unsigned pieces, with a real name. A setup that falls back to a login name such as admin publishes a meaningless author.
• Publisher. One Organization or Person for the site, with the same name, URL and logo on every page.
• datePublished and dateModified. Both present, in ISO 8601 format, and equal to the dates readers see. A plugin that bumps dateModified on every save, or a theme that hides the updated date, creates a mismatch.
• URLs. The page's canonical URL, not a staging domain or an http address left over from a migration.

These rows matter beyond rich results. Author, publisher and dates are how a page states who stands behind it and when it was last checked, and they are the fields most likely to be wrong when a plugin fills them automatically. Check the type as well as the value: a Person node for an editorial team, or an Organization node for a named writer, is a mismatch that plugin settings can usually fix.

05Where do theme and plugin duplicates come from?

Once you know the sources, decide which component owns each type and switch the others off for that type. Yoast's Schema API documentation shows the kind of control to look for: a wpseo_json_ld_output filter that disables all of its schema output when it returns false, and a filter for adding or removing individual graph pieces. Check your own plugin's settings and developer notes for the equivalent.

06A 15-minute audit

1. Pick one URL per template: the home page, a post, a page, a product and an archive.
2. Fetch each with curl or view the source, and count the application/ld+json blocks and any itemscope attributes.
3. For each block, note which component printed it. Some plugins label their output in an HTML comment; if not, deactivate candidates on a staging copy and see which block disappears.
4. List the main entity each block describes. Two different main entities for one page is a conflict to resolve.
5. Check that every @id reference resolves to a declared node.
6. Check author, publisher and both dates against the visible page.
7. Run the URL through the Rich Results Test and the Schema Markup Validator.
8. Decide which component owns each type, switch the others off, and retest.

Write the result down. A short table of template, component and types owned is what you will need the next time a plugin update changes the output. The guide to testing structured data explains how to read each tool's results.

07When should you drop a schema plugin?

Drop or replace a plugin when it is abandoned, when it prints markup you cannot switch off, or when everything it does could be a few lines of your own code. An unmaintained plugin is a security and compatibility risk even if its markup still validates: JSON-LD does not expire, but PHP and WordPress keep moving. Keep the plugin if it prints one accurate graph and lets you switch off what you do not use; most of what this audit finds is fixed by configuration, not replacement.

That is the position former users of the WP Rich Snippets plugin are in, since its store closed and updates stopped. The record of what happened to the WP Rich Snippets plugin covers its add-ons and today's equivalents. Never install a copy from an unofficial download site to keep it running.

If your needs are narrow, adding schema to WordPress without a plugin replaces a single-purpose schema plugin with a small mu-plugin you control. Either way, rerun the audit after the change. The other how-tos are in the WordPress section of wprichsnippets, an independent handbook with no plugin to sell.