Schema Markup in WordPress: What's Worth Adding

It does two things. First, it can change the appearance of your search result — star ratings, FAQ dropdowns, breadcrumbs above the title, prices and availability on products. That affects click-through, which is worth real traffic.

Second, and less visibly, it removes ambiguity. It tells a search engine that this string is an author and that one is a publication date, rather than leaving it to infer from markup. For entity-heavy content — people, organisations, products, events — that clarity compounds.

What it doesn't do is improve your ranking directly. A page with perfect markup and thin content still loses to a better page without any.

• Organization or Person for the site itself, with a logo, contact details and sameAs links to real profiles. This is the foundation everything else references.
• WebSite, which is what enables a sitelinks search box and ties the site together as an entity.
• BreadcrumbList matching the breadcrumbs you actually display. This is one of the most reliably rendered enhancements.
• Article or BlogPosting on posts, with headline, author, datePublished, dateModified and an image.
• FAQPage where a page genuinely contains questions and answers visible to the reader.
• Product with offers and aggregateRating for ecommerce, which drives the price and availability shown in results.
• LocalBusiness for a business with a real address or service area, including opening hours and geographic coverage.

HowTo and several other rich result types have had their search appearance reduced or removed over time, so marking them up now buys you the semantic clarity and not much else. Review snippets on self-serving reviews — a business reviewing its own products or services — are explicitly against the guidelines and can earn a manual action.

Speakable, Course, and the long tail of niche types are worth adding only if you have a concrete reason. Marking up everything the vocabulary allows produces a large JSON blob that nobody reads and that you now have to keep accurate.

Structured data must describe content that a visitor can actually see on the page. FAQ markup for questions that aren't displayed, a rating you invented, an author who doesn't appear — these are all violations, and Google acts on them.

The penalty isn't subtle: rich results get removed for the site, sometimes with a manual action in Search Console. The upside from faking it is small and the downside is large.

This also means the markup has to stay in sync with the page. If your FAQ block is generated from the same data as the schema, it can't drift. If someone hand-writes both, it will.

This is the single most common WordPress schema problem. An SEO plugin outputs Article markup, the theme outputs its own Article markup, and a third plugin adds breadcrumbs — so the page has three overlapping graphs with different values.

Search engines will generally pick one, but you have no control over which, and the conflicting values can produce warnings in testing tools that mask real issues.

• Decide on one source of schema for the site: the SEO plugin, the theme, or your own code. Then disable the others.
• Most SEO plugins have a schema settings panel where you can turn types off. Most themes that emit schema have a filter or setting to disable it.
• Use @id references to connect nodes rather than repeating the same organisation details in five places.
• Test after every plugin change — a new plugin adding its own markup is a common cause of schema suddenly breaking.

If you're writing schema yourself, output JSON-LD in a script tag rather than using microdata attributes in the HTML. It's separate from your markup, so a design change doesn't break it, and it's far easier to read and debug.

Generate it from the same data the page renders. In a WordPress theme that means building the JSON from the post object, the ACF fields, the product data — not from a hard-coded template with placeholders. Generated markup can't contradict the page; hand-written markup eventually will.

Escape it properly. A less-than character inside a JSON string can close the script tag early and break the page, which is a genuinely confusing bug to track down.

• Google's Rich Results Test tells you which enhancements a page is eligible for, which is the question that actually matters.
• The Schema Markup Validator checks the vocabulary more broadly, including types Google doesn't use.
• Search Console's Enhancements reports show errors and warnings across the whole site over time — that's where you'll notice a plugin update breaking things.
• Test a representative page of each template, not just the homepage. Product, article, category and contact pages all differ.
• Re-test after plugin updates and theme changes. Schema breaks silently.

Testing tools distinguish between the two, and it's worth taking seriously. An error means the markup isn't valid for that type and the enhancement won't be shown. A warning means a recommended property is missing — the markup still works, but it may be eligible for less.

Fix errors promptly. Treat warnings as a to-do list rather than an emergency; adding a recommended property is often trivial, but not every warning is worth chasing on every page.

For most WordPress sites: let one SEO plugin handle Organization, WebSite, BreadcrumbList and Article, configured with real values rather than defaults. Add Product schema through WooCommerce if it's a store, and LocalBusiness if there's a physical presence. Add FAQPage only on pages that display an FAQ.

Then leave it alone and check Search Console's enhancement reports occasionally. Schema is a set-up-once job that people spend far more time on than it repays.