JSON-LD schema types explained

JSON-LD schema types help describe the meaning of content on a webpage in a machine-readable format. Instead of forcing search engines and other applications to infer everything from headings, text and HTML structure alone, structured data can explicitly identify things such as articles, organizations, products, events, people, breadcrumbs and local businesses.

In WordPress, structured data is commonly generated as JSON-LD and placed inside the HTML of the page. Plugins, themes and custom code can all produce it.

The confusing part is that JSON-LD, Schema.org and Google rich results are related but not interchangeable concepts.

JSON-LD is a data format. Schema.org provides the vocabulary. Search engines decide which parts of that vocabulary they support for specific search features.

For WordPress sites where structured data belongs to the broader SEO configuration, TheOneWP’s SEO Meta module provides structured-data controls alongside other page-level metadata, helping keep schema generation under one identifiable SEO system rather than scattering it across themes, snippets and unrelated plugins.

In this guide, we will look at how JSON-LD schema types work, which types are commonly useful on WordPress websites, how to choose the right one and which mistakes can turn structured data into a technically elaborate description of something the page does not actually contain.

What is JSON-LD?

JSON-LD stands for JavaScript Object Notation for Linked Data.

It is a way of representing structured information using JSON syntax while also describing relationships between entities.

A basic JSON-LD block might look like this:

<script type="application/ld+json">
{
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "WordPress Security Guide",
    "datePublished": "2026-08-18",
    "author": {
        "@type": "Person",
        "name": "Jane Example"
    }
}
</script>

The structured data sits inside a normal HTML page but is not intended to be displayed as visible content.

Instead, software can parse the block and understand that the page describes an article with a particular headline, publication date and author.

What is Schema.org?

Schema.org is a shared vocabulary for describing entities, content and relationships on the web.

It defines types such as:

• Article;
• Organization;
• Person;
• Product;
• Event;
• LocalBusiness;
• BreadcrumbList;
• SoftwareApplication;
• WebSite;
• many others.

The official Schema.org vocabulary contains the available types and properties.

Schema.org itself is not a WordPress feature and is not limited to Google.

WordPress simply provides the website and content from which structured information can be generated.

JSON-LD and Schema.org are not the same thing

This distinction is fundamental.

Schema.org defines concepts and properties.

JSON-LD is one format that can be used to express those concepts.

For example:

"@type": "Article"

uses the Schema.org Article type.

The surrounding JSON structure is the JSON-LD representation.

Schema.org information can also be expressed using other formats such as Microdata and RDFa, but JSON-LD is particularly convenient because the structured data can remain separate from the visible HTML markup.

Why is JSON-LD commonly used in WordPress?

JSON-LD works particularly well with content management systems because metadata can be generated programmatically from information WordPress already knows.

For example, WordPress may already know:

• the post title;
• the author;
• the publication date;
• the modification date;
• the featured image;
• the preferred page URL;
• the post type;
• the site name.

A plugin, theme or custom integration can use those values to generate structured data automatically.

This is considerably easier to maintain than manually writing a JSON-LD block for every article, product or landing page.

Structured data needs one clear owner

Automatic generation is useful, but WordPress makes it very easy for several components to decide that they should all generate schema at the same time.

You might have:

Theme
→ WebSite schema

SEO plugin
→ Article + WebPage

Commerce plugin
→ Product

Custom snippet
→ Organization

Another SEO plugin
→ another Article

Some of those entities may legitimately coexist.

The problem begins when multiple systems describe the same entity differently or create overlapping graphs without a clear ownership model.

Keeping structured data inside a defined SEO workflow, such as TheOneWP’s SEO Meta module, makes it easier to understand which component is responsible for the page-level schema rather than debugging a collection of anonymous JSON blocks after something becomes inconsistent.

What does @context mean?

A typical Schema.org JSON-LD block begins with:

"@context": "https://schema.org"

The context tells software how terms in the document should be interpreted.

Without it, a property such as:

"headline"

would simply be an arbitrary JSON key.

With the Schema.org context, the consuming application can interpret it according to the Schema.org vocabulary.

What does @type mean?

The @type property identifies the kind of entity being described.

For example:

"@type": "Article"

describes an article.

Meanwhile:

"@type": "Organization"

describes an organization.

And:

"@type": "Product"

describes a product.

Choosing an appropriate type is one of the most important structured-data decisions because the properties that make sense depend on what the entity actually represents.

Do schema types improve rankings?

Structured data should not be treated as a direct ranking switch.

Adding:

"@type": "Article"

does not automatically make an article rank above competing pages.

Structured data can help search engines understand page information and, for supported features, may make a page eligible for richer search appearances.

Eligibility still does not guarantee that a particular rich result will be displayed.

The official Google Search Central structured data introduction explains the relationship between structured data and search features.

Schema.org types and Google rich results are not the same list

Schema.org contains a much broader vocabulary than the set of structured-data features supported directly by Google Search.

This means a Schema.org type can be perfectly valid without corresponding to a dedicated Google rich result.

A common mistaken assumption is:

If Schema.org defines the type, Google must have a rich result for it.

That is not how the system works.

Google publishes its supported search features separately in the Google structured data search gallery.

Choose schema based on the content, not the rich result you want

The structured data should describe what the page actually contains.

Do not begin with:

Which schema looks most impressive in search?

Begin with:

What entity or content does this page genuinely represent?

Then choose the appropriate type and properties.

If the page is an article, describe an article.

If it is a real product page, describe the product.

If it represents an organization, use organization information.

Schema markup is metadata, not cosplay for webpages.

Article schema

Article is one of the most common structured-data types on editorial WordPress websites.

A simple example might be:

{
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "How to Secure WordPress",
    "datePublished": "2026-08-18",
    "dateModified": "2026-08-18",
    "author": {
        "@type": "Person",
        "name": "Jane Example"
    }
}

Article structured data can describe information such as:

• headline;
• author;
• publication date;
• modification date;
• images;
• publisher;
• the page representing the article.

Editorial posts, news content and many long-form guides are natural candidates for article-related structured data.

Article vs BlogPosting

Schema.org provides more specific types beneath broader concepts.

BlogPosting, for example, is a more specific type of Article.

A blog article could therefore be represented as:

"@type": "BlogPosting"

rather than:

"@type": "Article"

The more specific type can be useful when it accurately describes the content.

Specificity is useful when it adds meaning, not when schema configuration becomes competitive taxonomy collecting.

NewsArticle

NewsArticle is another subtype of Article.

It is intended for news-oriented editorial content.

An evergreen WordPress tutorial should not automatically become a NewsArticle merely because it has a publication date.

Choose the type according to the real editorial nature of the page.

Organization schema

Organization describes a company, institution, association or other organization.

A basic representation might contain:

{
    "@context": "https://schema.org",
    "@type": "Organization",
    "name": "Example Ltd",
    "url": "https://example.com/",
    "logo": "https://example.com/logo.png"
}

Other appropriate properties can describe identifiers, contact information and relationships to other entities.

Organization information usually represents the business or publisher behind the website rather than pretending that every individual article is itself an organization.

Person schema

Person describes an individual.

For example:

{
    "@type": "Person",
    "name": "Jane Example",
    "url": "https://example.com/authors/jane/"
}

Person entities are frequently nested inside or referenced by other structured data.

An Article may contain:

"author": {
    "@type": "Person",
    "name": "Jane Example"
}

This expresses the relationship between the article and its author.

WebSite schema

WebSite describes the website itself.

A simple representation could be:

{
    "@context": "https://schema.org",
    "@type": "WebSite",
    "name": "Example",
    "url": "https://example.com/"
}

This is generally site-level information rather than a description of every individual webpage.

Do not confuse WebSite with WebPage.

WebPage schema

WebPage describes an individual webpage.

A site can therefore contain:

• one WebSite entity describing the overall website;
• many WebPage entities describing individual pages.

An article page can also connect its Article entity to the relevant WebPage.

This becomes particularly useful in structured-data graphs where entities reference one another instead of existing as unrelated fragments.

BreadcrumbList schema

BreadcrumbList represents a breadcrumb trail.

For example:

Home
→ Guides
→ SEO
→ JSON-LD Schema Types Explained

A simplified representation might look like:

{
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
        {
            "@type": "ListItem",
            "position": 1,
            "name": "Home",
            "item": "https://example.com/"
        },
        {
            "@type": "ListItem",
            "position": 2,
            "name": "Guides",
            "item": "https://example.com/guides/"
        }
    ]
}

Breadcrumb structured data should reflect the actual logical navigation hierarchy rather than inventing a different architecture exclusively for search engines.

Product schema

Product describes a product or offering.

Relevant properties may include:

• name;
• image;
• description;
• brand;
• SKU;
• offers;
• availability;
• review information where genuine and appropriate.

For example:

{
    "@context": "https://schema.org",
    "@type": "Product",
    "name": "Example Product",
    "offers": {
        "@type": "Offer",
        "price": "49.00",
        "priceCurrency": "EUR",
        "availability": "https://schema.org/InStock"
    }
}

Do not create fake prices, ratings or availability merely to satisfy optional fields.

Structured data should describe real information.

SoftwareApplication schema

SoftwareApplication is intended for software applications.

Depending on the actual product and available information, properties can describe:

• application name;
• operating system;
• application category;
• offers;
• ratings when genuine;
• software-related information.

The existence of a WordPress plugin does not justify inventing every property supported by SoftwareApplication.

If information cannot be represented accurately, do not fabricate it merely because a validator has discovered another optional property.

LocalBusiness schema

LocalBusiness describes a business with a physical or locally relevant presence.

More specific subtypes can represent particular kinds of businesses.

Information may include:

• business name;
• address;
• telephone number;
• opening hours;
• geographic information;
• business category.

Use real business information and keep it consistent with what visitors can see on the website.

Event schema

Event describes an event occurring at a particular time and, where relevant, a physical or online location.

Examples include:

• concerts;
• conferences;
• workshops;
• webinars;
• festivals;
• public meetings.

A typical event entity can contain:

{
    "@context": "https://schema.org",
    "@type": "Event",
    "name": "WordPress Developer Conference",
    "startDate": "2026-09-20T09:00:00+02:00",
    "location": {
        "@type": "Place",
        "name": "Example Conference Center"
    }
}

Do not use Event markup for an ordinary article merely because that article mentions a date.

Course schema

Schema.org defines Course for educational courses.

This can make sense for WordPress installations containing:

• online training;
• learning platforms;
• professional courses;
• educational catalogs.

The existence of a custom post type called:

course

does not automatically prove that every entry satisfies the semantic meaning associated with Course.

The public page remains the source of truth.

Recipe schema

Recipe describes recipes and can include properties such as:

• ingredients;
• instructions;
• cooking time;
• preparation time;
• yield;
• nutrition information where provided;
• images.

Recipe markup should only be used when the page actually contains a recipe.

A blog article discussing the history of pizza does not become a Recipe merely because pizza appears frequently enough to frighten a keyword-density tool.

FAQPage schema

Schema.org defines FAQPage for pages containing questions and answers supplied by the site.

A conceptual example is:

{
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
        {
            "@type": "Question",
            "name": "What is JSON-LD?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "JSON-LD is a format for linked structured data."
            }
        }
    ]
}

The questions and answers represented in structured data should correspond to information genuinely available to visitors.

FAQPage does not mean guaranteed FAQ rich results

A page can contain valid Schema.org FAQPage structured data without receiving a visible FAQ treatment in Google Search.

Schema vocabulary and search-engine presentation policies evolve independently.

Do not add FAQ markup merely because you expect a giant block of questions to appear underneath every result.

The markup should first make semantic sense for the page.

QAPage is different from FAQPage

QAPage represents a different content model.

A Q&A page generally focuses on a question and one or more answers, often contributed by users.

An FAQ page instead contains questions and answers provided by the publisher.

Using QAPage for a static corporate FAQ simply because both formats contain question marks confuses two different structures.

HowTo schema

Schema.org defines HowTo for instructions explaining how to achieve a result through a sequence of steps.

Conceptually:

{
    "@context": "https://schema.org",
    "@type": "HowTo",
    "name": "How to configure WordPress",
    "step": [
        {
            "@type": "HowToStep",
            "text": "Install WordPress."
        },
        {
            "@type": "HowToStep",
            "text": "Configure the site settings."
        }
    ]
}

This may accurately describe procedural content.

However, the existence of a Schema.org type should not be confused with current rich-result support from a particular search engine.

This is exactly why Schema.org vocabulary and search-engine feature support need to be evaluated separately.

Review schema

Review represents an evaluation of an item.

It can describe information such as:

• the item being reviewed;
• the author of the review;
• the review text;
• a rating where one genuinely exists.

Review markup is an area where accuracy matters particularly strongly.

Do not create fictional review scores or mark up ratings users cannot actually verify.

AggregateRating schema

AggregateRating represents an aggregated rating calculated from multiple ratings.

For example:

{
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "ratingCount": "126"
}

Those numbers need to come from real ratings.

A developer should not type:

"ratingValue": "5",
"ratingCount": "5000"

because five stars look cheerful in a search preview.

Structured data is supposed to describe information, not manufacture testimonials in JSON.

VideoObject schema

VideoObject can describe video content.

Useful information may include:

• video name;
• description;
• thumbnail;
• upload date;
• duration;
• content URL or embed information.

This is most appropriate where video is a meaningful part of the page rather than a decorative background asset.

ImageObject schema

ImageObject can represent an image as an entity.

It may be used as a nested object inside other structured data.

An Article, for example, may reference an image containing its own URL, dimensions or other properties.

This is different from Open Graph image metadata, which exists primarily for social sharing presentation.

See Open Graph and Twitter Cards for WordPress for that separate metadata layer.

Can one page contain multiple schema types?

Yes.

A single webpage may legitimately describe several related entities.

An article page might contain:

• a WebPage;
• an Article;
• a Person author;
• an Organization publisher;
• a BreadcrumbList;
• an ImageObject.

The key is that these entities describe real things and meaningful relationships rather than duplicating the same information randomly.

What is a JSON-LD graph?

JSON-LD can connect multiple entities using a graph.

For example:

{
    "@context": "https://schema.org",
    "@graph": [
        {
            "@type": "WebSite",
            "@id": "https://example.com/#website",
            "url": "https://example.com/"
        },
        {
            "@type": "Organization",
            "@id": "https://example.com/#organization",
            "name": "Example Ltd"
        },
        {
            "@type": "Article",
            "@id": "https://example.com/guide/#article",
            "headline": "Example Guide",
            "publisher": {
                "@id": "https://example.com/#organization"
            }
        }
    ]
}

The @id values allow entities to reference one another without repeatedly reproducing the complete object.

This creates a connected model instead of several isolated JSON objects occupying the same document while pretending not to know each other.

What does @id mean in JSON-LD?

@id gives an entity an identifier.

For example:

"@id": "https://example.com/#organization"

Another entity can then refer to that organization:

"publisher": {
    "@id": "https://example.com/#organization"
}

The fragment does not need to correspond to a visible HTML anchor.

It functions as an identifier inside the linked-data graph.

Schema relationships are often more useful than isolated blocks

Consider an Article, author and publisher.

Instead of describing them as three disconnected objects, structured data can express:

Article
    → author → Person
    → publisher → Organization

This better represents the meaning of the page.

A website is not simply a bag of unrelated metadata properties. Its content contains entities with relationships to one another.

Schema for WordPress custom post types

Custom post types do not automatically map to Schema.org types.

A WordPress post type called:

property

might describe real-estate listings.

A post type called:

course

might describe courses.

But the internal WordPress identifier is an implementation detail.

The correct schema type depends on what the resulting public page actually represents.

This is part of the broader architectural planning discussed in WordPress custom post types and SEO.

Manage schema by content type, not by post type name alone

A useful structured-data system should allow the public meaning of a content type to drive its metadata rather than assuming the WordPress database key is a semantic definition.

For example:

WordPress post type:
course

Possible public meaning:
Course

WordPress post type:
portfolio

Possible public meaning:
CreativeWork, WebPage or another appropriate type

WordPress post type:
internal_template

Possible public meaning:
No public search-oriented schema required

TheOneWP’s SEO Meta module keeps structured-data decisions within the broader content metadata workflow, where they can be evaluated according to what the public page represents rather than mechanically mirroring WordPress internals.

Do not map every custom post type automatically

Imagine a site has these post types:

product
testimonial
layout_template
documentation
internal_notice

It would make little sense to assume every structure needs elaborate search-oriented structured data.

Some post types exist primarily for application functionality.

Before creating schema mappings, ask:

• Does the entry have a meaningful public URL?
• Does it represent a recognizable entity or content type?
• Is the relevant information visible to visitors?
• Is there a suitable Schema.org type?
• Does the structured data add useful semantic information?

Structured data should match visible content

One of the most important structured-data principles is consistency with the page.

If the JSON-LD says:

"price": "29.00"

while the page tells visitors the product costs:

€79.00

the structured information is not accurately representing the visible content.

The same principle applies to:

• ratings;
• authors;
• publication dates;
• event information;
• availability;
• FAQ answers;
• product names;
• images.

Do not create invisible facts solely for structured data.

Required vs recommended properties

Search-engine documentation often distinguishes between required and recommended properties for a particular feature.

Required properties may be necessary for eligibility under that feature’s specification.

Recommended properties can provide additional information and improve completeness.

This does not mean you should fabricate a recommended value that does not exist.

Missing genuine optional information is preferable to inventing false information merely to make a validator panel greener.

Schema validity does not guarantee rich-result eligibility

A JSON-LD document can be valid according to Schema.org while still failing the requirements of a specific search feature.

There are therefore several different questions to ask:

1. Is the JSON syntactically valid?
2. Is the Schema.org vocabulary used correctly?
3. Does the structured data match the page?
4. Does it meet the search engine’s requirements for the desired feature?

Passing only the first question is a rather low bar for declaring technical SEO victory.

Do not confuse structured data with meta tags

Structured data is separate from traditional HTML metadata.

A page may contain:

<title>JSON-LD Schema Types Explained</title>

<meta name="description"
      content="Learn how JSON-LD schema types work.">

<link rel="canonical"
      href="https://example.com/json-ld-schema/">

and separately contain:

<script type="application/ld+json">
{
    "@context": "https://schema.org",
    "@type": "Article"
}
</script>

These pieces can describe related information but have different purposes.

Why managing schema with SEO metadata is still useful

Structured data is not the same thing as a title tag, meta description or canonical URL.

But operationally, they often describe the same underlying page.

A page’s SEO configuration may need to coordinate:

Canonical URL
SEO title
Meta description
Open Graph metadata
Structured-data entities
Page type
Author
Publication information

Keeping those controls inside one broader SEO system can make inconsistencies easier to spot.

TheOneWP’s SEO Meta module follows this approach by keeping structured-data configuration alongside other page-level SEO information while still treating each metadata layer according to its own purpose.

Do not confuse schema with Open Graph

Open Graph metadata is primarily concerned with social sharing representation.

For example:

<meta property="og:title"
      content="JSON-LD Schema Types Explained">

JSON-LD structured data describes entities and relationships:

{
    "@type": "Article",
    "headline": "JSON-LD Schema Types Explained"
}

It is completely normal for both to appear on the same page.

See Open Graph and Twitter Cards for WordPress for the social metadata side.

Do not confuse schema with XML sitemaps

An XML sitemap helps search engines discover URLs.

Structured data describes the meaning of information associated with a page.

They solve different problems.

A page can have excellent schema markup and still be poorly connected to the rest of the website.

Conversely, a page can appear correctly in an XML sitemap without containing any JSON-LD at all.

The discovery side is covered in What is an XML sitemap, and why does it matter?.

Structured data does not replace normal SEO

JSON-LD cannot compensate for:

• thin content;
• poor internal linking;
• broken canonical URLs;
• incorrect indexing directives;
• server errors;
• duplicate content;
• inaccessible pages;
• weak website architecture.

Structured data is one technical layer inside a wider SEO system.

Be careful when multiple plugins generate schema

WordPress websites frequently have several components capable of producing structured data.

These can include:

• SEO plugins;
• themes;
• e-commerce plugins;
• recipe plugins;
• event plugins;
• review plugins;
• custom code.

Multiple schema generators are not automatically a problem.

The issue appears when they describe the same entity inconsistently.

For example, two plugins might output different Organization names or conflicting Article authors.

Duplicate schema is not always literally duplicated schema

Two blocks can both describe an Article without being identical.

For example:

Plugin A:
Article → author Jane

Plugin B:
Article → author Company Name

The problem is not merely repeated markup.

The problem is inconsistent semantics.

Choose which system owns each part of the structured-data graph and inspect the final rendered source.

Choose one primary schema owner

Specialized plugins may legitimately add structured data that belongs specifically to their domain.

A commerce plugin, for example, may have access to product information that a generic SEO layer does not own.

The objective is therefore not necessarily:

Only one JSON-LD block may exist.

The better objective is:

Every important entity has one clear and consistent source of truth.

If TheOneWP’s SEO Meta is responsible for the page-level SEO graph, make sure a theme or previous SEO plugin is not simultaneously generating contradictory versions of the same Article, WebPage or Organization entities.

Check schema when migrating SEO plugins

Changing SEO plugins can affect more than titles and meta descriptions.

The old system may have generated:

• Article schema;
• WebPage entities;
• BreadcrumbList markup;
• Organization data;
• Person entities;
• social metadata;
• canonical URLs.

After switching systems, inspect representative pages to make sure the previous graph is not duplicated by the new implementation and important values have not disappeared.

The broader migration process is covered in Migrating SEO fields between WordPress plugins.

How to inspect JSON-LD manually

Open the rendered source of the page and search for:

application/ld+json

You may find something similar to:

<script type="application/ld+json">
{
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "Example"
}
</script>

Check:

• which entities are present;
• whether values are correct;
• whether URLs use the production domain;
• whether entities contradict one another;
• whether required visible information actually exists;
• whether several plugins are generating overlapping graphs.

Inspect the rendered output, not only WordPress settings

A WordPress settings screen can tell you what one plugin intends to output.

It cannot automatically tell you what every other plugin, theme and snippet is adding to the final document.

The browser source is therefore the useful final authority.

If TheOneWP’s SEO Meta is configured to provide structured data, inspect the resulting production HTML after activation or migration and verify that another system has not left an older graph behind.

Validate syntax separately from meaning

A validator can tell you that structured data is syntactically readable.

It cannot replace understanding the page.

This JSON may be perfectly valid syntax:

{
    "@context": "https://schema.org",
    "@type": "Recipe",
    "name": "WordPress Login Security"
}

but it would be an absurd description of an article about protecting login accounts.

Validation is necessary.

Semantic accuracy is necessary too.

Use Google’s Rich Results Test for supported features

For structured-data features supported by Google, the Rich Results Test can help identify whether the page contains markup eligible for those search experiences.

A passing result means the detected markup satisfies the technical requirements evaluated by the tool.

It does not guarantee that Google will display the corresponding rich result for every query.

Use the Schema.org validator for broader vocabulary checks

Google’s tooling focuses on Google Search features.

Schema.org validation is useful when you want to inspect broader vocabulary usage that may not correspond to a Google rich result.

This again illustrates the difference between:

Schema.org vocabulary
and
Google Search feature support

Do not add every possible schema type

A webpage does not become semantically superior because its source contains fourteen entity types.

Add entities that genuinely describe important information.

A typical article page might reasonably contain:

• WebPage;
• Article;
• Person;
• Organization;
• BreadcrumbList.

That does not mean it also needs Product, Recipe, Course and LocalBusiness because somebody discovered a dropdown containing more options.

Avoid manually duplicating automatically generated schema

If an SEO system already creates an accurate Article and WebPage graph, adding another hard-coded Article block may achieve little besides creating another object to maintain.

Before adding custom JSON-LD:

1. inspect what WordPress already outputs;
2. identify missing information;
3. determine which component should own the schema;
4. extend or replace the existing graph deliberately;
5. validate the final output.

Keep schema URLs canonical and consistent

Structured-data entities frequently contain URLs.

For example:

"url": "https://example.com/guide/"

or:

"@id": "https://example.com/guide/#article"

These should normally reflect the preferred production URL structure.

Watch for:

• staging domains;
• HTTP URLs on an HTTPS site;
• obsolete permalinks;
• redirecting image URLs;
• inconsistent trailing-slash behavior;
• incorrect canonical destinations.

Check schema after staging-to-production deployment

A staging site may generate entities such as:

"url": "https://staging.example.com/guide/"

If database or configuration values are copied to production incorrectly, those references may remain in the live structured data.

Inspect JSON-LD after deployment rather than assuming every stored URL has transformed itself out of professional courtesy.

For the wider environment workflow, see WordPress staging site best practices.

Schema and dynamic WordPress content

Structured data generated from WordPress should update when the underlying content changes.

For example, if an article’s modification date changes meaningfully, its dateModified value may need to change too.

If a product price changes, product structured data should not continue advertising the previous price.

If an event is rescheduled, the structured data needs to reflect the new date.

Dynamic generation is useful precisely because metadata can follow the actual content.

Do not output fields you cannot maintain accurately

Every additional property becomes another piece of information that needs to remain correct.

For example, if you output:

"availability": "https://schema.org/InStock"

you need a reliable process for changing that value when the product becomes unavailable.

More markup is not automatically better markup.

Accurate structured data is more valuable than an enormous block filled with stale values.

Managing JSON-LD with TheOneWP SEO Meta

TheOneWP’s SEO Meta module includes structured-data controls alongside other page-level SEO information.

This allows schema configuration to remain part of the same broader metadata workflow used to describe the page for search and sharing.

The purpose is not to emit as many Schema.org types as possible.

The useful objective is to establish a coherent source for the page’s structured data and select types that genuinely represent the content.

A practical workflow becomes:

Identify the public content type
→ choose appropriate schema
→ populate real page information
→ connect related entities where appropriate
→ render JSON-LD
→ inspect the final HTML
→ validate
→ monitor after updates or migrations

Use schema controls to describe content, not manufacture it

A schema interface can make structured data easier to configure, but it cannot decide whether a claim is true.

If the page does not contain genuine ratings, do not create ratings.

If there is no real event, do not use Event.

If a landing page is not a product, choosing Product does not transform it into one.

TheOneWP’s SEO Meta module can provide the structured-data controls, but the semantic decision still needs to reflect the actual page.

Use sensible defaults and specific overrides

Many WordPress sites contain hundreds or thousands of pages.

Manually configuring every structured-data value independently is rarely a scalable workflow.

A practical configuration may define sensible schema behavior according to content type while allowing important pages to receive more specific treatment where necessary.

For example:

Standard editorial post
→ Article-oriented metadata

Blog content
→ BlogPosting where appropriate

Generic page
→ WebPage-oriented metadata

Specific public content type
→ appropriate mapped schema when the content genuinely matches

The point of automation is consistency.

The point of overrides is accuracy.

Avoid running competing schema systems

If another SEO plugin or theme already generates page-level structured data, introducing another schema system without reviewing the existing output can create duplicate or contradictory entities.

Before making TheOneWP’s SEO Meta the primary metadata owner:

1. inspect the current JSON-LD;
2. identify which component generates each major entity;
3. determine which data needs migration;
4. disable overlapping output where appropriate;
5. inspect representative pages again;
6. validate the resulting graph.

A structured-data graph works better when its entities form a coherent model rather than a committee meeting between three SEO plugins and a theme.

Test schema before launching a WordPress site

Structured-data checks should be part of the final technical review before a website goes live.

Inspect representative:

• posts;
• pages;
• custom post types;
• product pages;
• archives where applicable;
• the homepage.

Check that:

• production URLs are used;
• schema types match the content;
• important visible information is consistent with the graph;
• there are no accidental duplicate generators;
• important entities reference one another consistently;
• the structured data validates appropriately.

This fits naturally into the wider checks in A WordPress pre-launch SEO checklist.

Common JSON-LD schema mistakes

1. Confusing JSON-LD with Schema.org

JSON-LD is the format. Schema.org is the vocabulary.

2. Assuming every Schema.org type has a Google rich result

Search engines support their own subsets and features.

3. Choosing schema based on the rich result you want

The type should describe the actual content.

4. Adding schema that contradicts the visible page

Prices, ratings, dates and other properties should match real information.

5. Inventing recommended properties

Optional information should remain truthful even when a validation tool would prefer more fields.

6. Running several conflicting schema generators

Multiple systems can create contradictory representations of the same entity.

7. Treating valid JSON as valid semantics

Correct braces do not make the wrong entity type appropriate.

8. Leaving staging URLs inside production schema

Entity identifiers and URLs should reflect the live site.

9. Hard-coding data that changes frequently

Dynamic values such as price and availability need reliable synchronization.

10. Adding every available type

Structured data should describe the page, not demonstrate how many Schema.org pages the developer has opened.

11. Assuming a WordPress post type name is a schema type

WordPress architecture and semantic meaning are separate concepts.

12. Adding manual schema before checking existing output

Inspect the current graph first so you do not duplicate information already generated correctly.

How to choose the right schema type

A simple process is usually enough.

Step 1: Identify the primary content

Ask what the page fundamentally represents.

For example:

Blog guide → Article or BlogPosting
Product page → Product
Event page → Event
Business location → LocalBusiness
Software product → SoftwareApplication
Author page → Person or ProfilePage
Recipe → Recipe

Step 2: Identify related entities

An Article may also reference:

• an author;
• a publisher;
• a webpage;
• an image;
• breadcrumbs.

Step 3: Check Schema.org

Verify that the selected type and properties actually mean what you think they mean.

Step 4: Check search-engine support separately

If you are targeting a particular search appearance, review the current search-engine documentation for that feature.

Step 5: Match the visible content

Do not include information that users cannot reasonably verify from the page or underlying offering.

Step 6: Decide which WordPress component owns the output

Before adding new JSON-LD, identify whether a theme, SEO plugin, commerce plugin or custom integration already generates the same entity.

Step 7: Validate the output

Check syntax, vocabulary and feature-specific requirements.

Step 8: Inspect the live rendered source

Verify that the actual production HTML contains the expected values and URLs.

JSON-LD schema checklist for WordPress

• Identify what the page genuinely represents.
• Choose the appropriate Schema.org type.
• Prefer more specific types only when they accurately fit the content.
• Use JSON-LD consistently when it is the site’s chosen format.
• Provide a valid @context.
• Use stable entity identifiers where appropriate.
• Connect related entities instead of creating unnecessary duplicates.
• Make structured data match visible content.
• Never fabricate ratings, prices, availability or authors.
• Distinguish Schema.org validity from Google rich-result support.
• Check current search-engine documentation before targeting a specific feature.
• Review custom post types individually.
• Choose a clear owner for page-level structured data.
• Avoid overlapping schema generators.
• Check schema after SEO plugin migrations.
• Keep entity URLs aligned with canonical production URLs.
• Remove staging URLs from live markup.
• Keep dynamic information synchronized with the page.
• Validate representative pages.
• Inspect the final rendered source before launch.

Use TheOneWP for a more coherent structured-data workflow

If a WordPress site’s structured data is currently spread between a theme, an SEO plugin, custom snippets and manual JSON-LD blocks, the first improvement is often not adding another schema type.

It is establishing one understandable ownership model.

TheOneWP’s SEO Meta module brings structured-data controls into the same broader workflow as other page-level SEO metadata.

This makes it easier to move from:

Theme
→ one entity

Plugin A
→ another entity

Snippet
→ duplicate organization

Manual JSON-LD
→ old staging URL

toward:

Content
→ appropriate schema configuration
→ coherent entity relationships
→ one rendered page-level graph
→ validation
→ production inspection

Specialized plugins can still provide domain-specific structured data where appropriate, but overlapping page-level entities should remain intentional rather than accidental.

Final thoughts on JSON-LD schema types

JSON-LD schema types are most useful when they describe a website accurately rather than when they are treated as a collection of SEO switches.

JSON-LD provides the format. Schema.org provides the vocabulary. Search engines decide which structured-data patterns they use for their own search features.

Keep those three layers separate.

Choose Article because the page is an article. Choose Product because a real product is being described. Use Organization for the actual organization behind the site. Connect authors, publishers, webpages and breadcrumbs when those relationships genuinely exist.

Then decide which WordPress component owns the structured-data output.

TheOneWP’s SEO Meta module can keep structured data inside the same broader SEO workflow as the page’s other metadata, reducing the need for disconnected schema generators and manual JSON-LD fragments.

Most importantly, make the structured data agree with the visible page.

A small, accurate graph is better than an enormous JSON-LD block containing properties nobody maintains, duplicate entities from several plugins and impressive-looking types the page never actually represented.

Structured data works best when it does exactly what the name suggests: structure real data.