You installed an SEO plugin, your theme claims to support structured data, and now you wonder which of them is actually writing the code in your pages. Schema markup WordPress setups usually come from a plugin, a theme or hand-added JSON-LD, and the real danger is rarely picking the wrong one. It is running two at once without noticing. The short answer is that a plugin is not mandatory. What matters is that one source describes each page accurately and that you check the output on the live URL. I will not promise rankings or rich results here, because valid markup only makes a page eligible to be understood, not to be shown in any particular way.
Table of Contents

Schema markup basics for beginners
Structured data is extra code that labels what a page is about in a form machines can read. The most common format is JSON-LD, which stands for JavaScript Object Notation for Linked Data. It is usually placed in a <script type="application/ld+json"> element in the head or body of the HTML, so visitors never see it.
Two terms cover most of what you will read. @type names the kind of thing being described, such as Article or Organization. Properties such as headline, author or datePublished are the details about that thing. Google Search Central says it supports several valid structured data formats and recommends JSON-LD when your setup allows it, so a search for JSON-LD alone is not a complete audit of everything a page declares.

Schema Markup WordPress Options: Plugin, Theme or Manual JSON-LD
Each approach suits a different skill level and site type. Pick by who maintains the site, not by which sounds most technical.
| Method | Best for | Strength | Main risk |
|---|---|---|---|
| SEO or schema plugin | Editors and many posts | Repeatable, page-specific settings without code | Settings may not produce what you assume, so inspect the output |
| Theme-generated | Simple sites whose theme already outputs accurate data | Nothing extra to install | Markup can vanish or change when you switch or update themes |
| Hand-added JSON-LD | Developers, unusual pages, controlled site-wide setups | Precise control over every value | Ongoing maintenance and easy conflicts with other output |
Do I need a plugin?
No. Google Search Central notes that a content management system may offer settings or plugins for structured data, but it does not require a particular WordPress installation method. A plugin is convenient when several people publish and you want consistent controls. If your active theme already emits accurate data and you rarely change it, you may not need anything else. WordPress developer documentation also advises putting functionality you need regardless of design into a plugin, which is a good reason to avoid tying important markup to a theme you might replace.
If you are researching how another site is built, the WordPress Theme Detector reports the theme and plugins it can find for a domain. That hints at which components might be producing markup, though only the page output proves it.

Hand-added JSON-LD that survives theme updates
If you add markup yourself, the location matters. The WordPress child-theme documentation says parent-theme updates can overwrite direct edits to the parent, while child-theme changes survive those updates. A child theme’s functions.php loads alongside the parent’s, not instead of it. Even so, code in a theme disappears when you switch themes. For markup that must outlive a redesign, a small maintained custom plugin is the safer home. WordPress documents wp_head as the hook for output in the HTML head.
This minimal plugin outputs BlogPosting data on single posts only. Treat it as a starting point and test it on a staging copy first.
<?php
/**
* Plugin Name: Example Post Schema
* Description: Outputs BlogPosting JSON-LD on single posts. Example only.
*/
add_action( 'wp_head', function () {
if ( ! is_singular( 'post' ) ) {
return;
}
$post = get_queried_object();
$data = array(
'@context' => 'https://schema.org',
'@type' => 'BlogPosting',
'headline' => get_the_title( $post ),
'mainEntityOfPage' => get_permalink( $post ),
'datePublished' => get_the_date( 'c', $post ),
'dateModified' => get_the_modified_date( 'c', $post ),
'author' => array(
'@type' => 'Person',
'name' => get_the_author_meta( 'display_name', $post->post_author ),
),
);
echo '<script type="application/ld+json">' . wp_json_encode( $data, JSON_HEX_TAG | JSON_UNESCAPED_SLASHES ) . '</script>';
} );
The prerequisite is that no plugin or theme already describes the same article, otherwise you create the duplicate problem covered below. For a single unusual page, the Article Schema Generator can draft Article, NewsArticle or BlogPosting JSON-LD with author, dates and publisher fields. A static block like that fits one page, but it will not update itself when you edit the post.
How to see what a page really outputs
Before you change anything, look at what the published page emits. Do not trust a settings screen alone.
- Open the published post in your browser, not the editor preview.
- Choose View Page Source, or type
view-source:before the address. - Search for
application/ld+jsonand note every script block you find. - Open each block and check for an
@grapharray, which holds several objects inside one script. - Search for
itemtypeandtypeofas well, because Microdata or RDFa will not appear in a JSON-LD text search. - Use Spider Simulator for an additional crawler-style view of the page. It complements, and does not replace, the rendered-page checks below.
One precise limit: View Page Source shows the HTML response, not necessarily the page after JavaScript runs. If a script adds markup later, nothing will show in source even though the rendered page contains it. Inspect the live DOM in Chrome DevTools, then use a URL-based Rich Results Test or Google’s URL Inspection tool to see Google’s rendered view. Google’s JavaScript troubleshooting guide documents rendering limitations, so absence from source alone does not prove absence from the rendered page.
Why do you see two Article blocks?
Two script tags are not inherently wrong. A plugin may output one block for the website, one for the organization and one for the article, and these describe different entities. Even two Article objects are a reason to investigate, not proof of a penalty. I treat it as a consistency and maintenance risk rather than an established ranking problem.
To investigate, compare these fields in each object:
@type, sinceArticleandBlogPostingmay both describe the same post.- The page or entity URL.
- The headline, author and dates.
- The image.
If a theme and a plugin describe the same article with contradictory facts, find which component emits each object. Turn off the schema option in the theme or plugin settings on staging, reload, and see which block disappears. Then configure or remove the redundant output at its source and retest. Do not edit rendered output by hand, because the next update will bring it back.
When an @graph array makes the code hard to read, paste it into the Structured Data Visualizer. It shows JSON-LD as a tree and checks required fields for 12 schema types, which makes duplicate objects easy to spot.
Check page-level accuracy and validate the live URL
Google Search Central says markup should describe the page’s content and should not assert information unavailable to users. Use this checklist on representative pages:
- Choose a type that describes the actual page. A blog post might use
ArticleorBlogPosting, while a product page needs product-specific evaluation. - Match the markup to the visible title, author, dates, product details and images.
- Confirm URLs refer to the intended page and values are current.
- Check Google’s documentation for the specific search feature instead of treating every schema.org property as a Google requirement. Google’s Article documentation, last updated September 8, 2026, lists no required properties for Article and shows recommended ones, so do not present author or date as universally required.
Then validate in order:
- Inspect what the published page emits, as described above.
- Run the live URL through the Schema Markup Validator. It reports JSON-LD blocks, syntax issues and suggested-property warnings from a pasted block or a fetched URL. Compare its results with the visible page.
- Use Google’s Rich Results Test for supported Google search appearances. Google separates that feature-focused test from generic schema.org validation, and passing it does not promise a rich result.
- Use the Schema Markup Generator only if you need to create a suitable block, then check the live URL after installation rather than the pasted code.
Title and meta description are related HTML metadata, not JSON-LD. Use Meta Tag Generator when drafting them and Meta Tags Analyzer when checking what the page outputs. For wider context, the guide on schema markup benefits for Shopify SEO explains what structured data can and cannot do.
How to test schema markup WordPress output after a theme change
A theme switch can drop markup, change its types or add a second copy. Treat it like any other migration.
- Before the switch, record a small baseline of representative live URLs: a post, a static page, and any product or other specialized page.
- For each URL, note the types, headline, author, dates and image from the page source.
- Install the new theme on staging and inspect each URL’s source and rendered output.
- Compare types and values with your baseline. Look for missing objects and newly duplicated ones.
- Fix the problem at its source, whether theme setting, plugin setting or custom code, then retest.
- After launch, validate the resulting live URLs again.
- Where Google Search Console is available, use URL Inspection after deployment, and allow time for recrawling rather than expecting an immediate change in search results.
Recheck after later theme or plugin updates too, since either can change the output without any action from you.
Frequently asked questions
Do I need a plugin to add schema markup in WordPress?
No. Google Search Central says a CMS may offer settings or plugins, but it does not require a specific method. A plugin helps when many editors need repeatable controls. A theme that outputs accurate data or carefully maintained custom code can also work.
Why do I see two Article blocks in my page source?
Usually a theme and a plugin both output markup, or one component outputs Article and another BlogPosting for the same post. Two blocks are not proof of a penalty, but compare their URL, headline, author, dates and image. Then remove or configure the redundant output at its source and retest.
How do I test schema after changing my WordPress theme?
Record the types and values for a post, a static page and any specialized page before the switch. Inspect the same URLs on staging, compare against the baseline, look for missing or duplicated objects, and validate the live URLs after launch.
Why is my JSON-LD missing from View Page Source?
View Page Source shows the HTML response, not necessarily the page after JavaScript runs. If a script adds the markup later, inspect the live DOM in browser developer tools and use a URL-based rich results test or Google’s URL Inspection tool to see the rendered view.
Should I use Article or BlogPosting for a blog post?
Either can describe a blog post. What matters is that the type fits the page and that only one object describes the same article. Check Google’s documentation for the search feature you care about instead of assuming a type is required.
Are author and publication date required for Article markup?
Google’s Article documentation, last updated September 8, 2026, says its Article implementation has no required properties and lists recommended ones. Include accurate author and dates when they are visible on the page, but do not treat them as universal requirements.
Does passing a validator mean I will get rich results?
No. A passing test shows the markup parses and meets a tool’s checks. Google decides whether to show any enhanced result, and generic validation differs from Google’s feature-focused Rich Results Test. Always compare the markup with the visible page as well.
Next steps
Schema markup WordPress sites can run well on a plugin, a theme or hand-written JSON-LD, as long as one source describes each page and the values match what visitors see. Start by viewing the source of a live post, search for application/ld+json, and compare every block. Validate the live URL, keep a baseline before any theme change, and recheck after updates. Keep expectations modest: clean, accurate markup helps machines understand a page, but it does not guarantee rankings, indexing or rich results.
Related tools and resources on AllEasySEO:
- Schema Markup Validator
- Schema Markup Generator
- Article Schema Generator
- Structured Data Visualizer
- WordPress Theme Detector
- Schema Markup Benefits Shopify SEO Structured Data
Sources and further reading
- https://developer.wordpress.org/themes/advanced-topics/child-themes/
- https://developer.wordpress.org/themes/classic-themes/basics/theme-functions/
- https://developer.wordpress.org/reference/hooks/wp_head/
- Learn About Article Schema Markup | Google Search Central | Documentation | Google for Developers
- https://developers.google.com/search/docs/crawling-indexing/javascript/fix-search-javascript
- https://developer.wordpress.org/plugins/plugin-basics/
- https://developer.chrome.com/docs/devtools/dom/
- https://developer.wordpress.org/themes/getting-started/what-is-a-theme/
- https://developers.google.com/search/docs/appearance/structured-data/sd-policies
- Schema Markup Testing Tool | Google Search Central | Google for Developers