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.

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 is describing 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 the 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, this part:

"@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 canonical URL;
• the post type;
• the site name.

A plugin or theme can use those values to produce structured data automatically.

This is much easier to maintain than manually writing a JSON-LD block for every article.

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 competitors.

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.

For example, Schema.org can define types useful for general semantic description while Google may choose not to provide a special search appearance for them.

This distinction prevents a common mistake:

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

That is not how the system works.

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

Choose schema based on the content, not the desired rich result

The structured data should describe what the page actually contains.

Do not begin with:

Which schema looks most impressive in Google?

Begin with:

What entity or content does this page genuinely represent?

Then choose the most appropriate type and properties.

If a 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;
• main page entity.

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 the broader:

"@type": "Article"

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

Specificity is helpful when it adds real meaning, not when it turns schema configuration into competitive taxonomy collecting.

NewsArticle

NewsArticle is another subtype of Article.

It is intended for news-oriented editorial content.

A normal evergreen WordPress tutorial should not automatically be labelled NewsArticle merely because the publication date exists.

Choose the type according to the editorial nature of the content.

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 is commonly associated with the website or business entity rather than repeated as though every individual article were 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 other structured data.

An Article may contain:

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

This expresses a relationship between the article and its author rather than creating two unrelated blocks of metadata.

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 entity is normally site-wide information rather than page-specific content.

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 have relationships connecting its Article entity to the relevant WebPage.

This becomes especially useful in structured-data graphs where separate entities reference one another.

BreadcrumbList schema

BreadcrumbList represents a breadcrumb trail.

For example:

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

A simplified JSON-LD 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 markup should reflect the actual logical navigation hierarchy rather than inventing a completely different architecture exclusively for search engines.

Product schema

Product describes a product or service offering.

Relevant properties may include information such as:

• 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 available to users.

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 version or related information.

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

If information such as price, operating system or ratings cannot be represented accurately, do not fabricate it because a validator has discovered the concept of optional fields.

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, depending on the event, location or online venue.

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 simply because the article discusses something happening on a particular 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 by itself prove that every entry satisfies the semantic meaning or search-engine requirements associated with course structured data.

The visible 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 a list of 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 the structured data should correspond to information genuinely available to visitors.

FAQPage does not mean guaranteed FAQ rich results

This is an important distinction.

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

Search-engine support and display policies can change independently from the Schema.org vocabulary.

Therefore, do not add FAQ markup merely because you expect a giant block of questions to appear beneath every Google result.

The markup should first make semantic sense for the page.

QAPage is different from FAQPage

QAPage is designed for a different content model.

A Q&A page generally focuses on one question and one or more submitted answers.

This can apply to communities where users contribute responses.

An FAQ page instead contains questions and answers created by the site itself.

Using QAPage for a static corporate FAQ simply because both contain question marks confuses two different content 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 the Schema.org type should not be confused with current Google rich-result support.

Google’s current structured-data search gallery does not list HowTo as one of its supported rich-result features.

This is an excellent example of why Schema.org vocabulary and Google Search features must 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 that users cannot actually find on the page.

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 can be useful for pages where a video is a meaningful part of the content rather than a decorative background element.

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.

For that separate layer, see Open Graph and Twitter Cards for WordPress.

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 should describe different real things and their relationships rather than duplicate 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 entire object.

This creates a connected model instead of several isolated JSON objects that happen to occupy the same document.

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 completely disconnected things, structured data can express:

Article
    → author → Person
    → publisher → Organization

This better represents the underlying meaning of the page.

A website is not simply a bag of unrelated metadata properties. Its content contains entities that have 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.

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 that every publicly queryable structure needs its own 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 that 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 are 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 simply 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 but still fail the requirements of a specific search feature.

For example, Schema.org may allow many properties while Google requires a particular subset for one rich result.

There are therefore multiple questions to ask:

1. Is the JSON syntactically valid?
2. Is the Schema.org vocabulary used correctly?
3. Does the 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 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.

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.

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 within a larger 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 identical schema

Two blocks can both describe an Article without being literally 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.

Check schema when migrating SEO plugins

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

The old plugin 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.

Validate syntax separately from meaning

A validator can tell you that the 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 Google-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.

Remember that a passing result means the markup satisfies the technical requirements detected 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 one of Google’s supported rich results.

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 with more options.

Avoid manually duplicating automatically generated schema

If an SEO plugin 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 the database or configuration is copied to production incorrectly, those staging references may remain inside the live structured data.

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

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.

JSON-LD and TheOneWP

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

This allows structured data to be managed as part of the broader SEO configuration rather than treated as an unrelated code fragment inserted manually into every page.

When schema controls are available for a content type, the important part is still choosing markup that accurately represents the page.

A guide may need article-oriented metadata.

A product may require product information.

A generic landing page should not automatically inherit a specialized type simply because another post on the site uses it.

The objective is not to maximize the number of schema types being emitted.

It is to create a coherent machine-readable representation of the actual content.

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;
• required visible information is present;
• 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

Google supports a specific subset of structured-data-driven search 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 plugins can create contradictory representations of the same entity.

7. Treating valid JSON as valid semantics

Correct braces do not make an incorrect entity type appropriate.

8. Leaving staging URLs inside production schema

Entity IDs 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.

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 specific rich result, 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: Validate the output

Check syntax, vocabulary and feature-specific requirements.

Step 7: Inspect the live rendered source

Verify that the actual production HTML contains the expected values.

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 Google’s current feature documentation before targeting a rich result.
• Review custom post types individually.
• 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.

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 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 verify what the target search engine currently supports rather than assuming every Schema.org type produces a special search result.

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 and entities the page never actually represented.

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