Start With the Page, Not the List of Schema Types
Before generating anything, identify the page’s main subject and its visible evidence. Is it a published article, an individual product, a real-world event, or an organization profile? Select the most specific schema type that truthfully describes that subject. A category page containing many products is not necessarily an individual Product page, and a blog post about a restaurant is not automatically that restaurant’s own LocalBusiness page.
Write down the facts you can verify on the actual page: title, canonical address, author, publication date, prices, business contact details, and any relevant images. Use the fields offered by the generator for your chosen type; not every generator supports every schema type or property. The supported input fields, export controls, and template list in this installation must be confirmed through its live interface.
Schema.org Types and Google Search Features Are Different Things
schema.org defines a vocabulary of types and properties. Google supports certain structured-data applications for specific search experiences, with additional documentation for each one. Therefore, markup can be correctly structured according to schema.org without qualifying for a Google rich result. A type appearing in a generator’s menu does not establish that Google currently displays a special search feature for it.
These examples are not a verified list of supported SEOToolCheckers templates. For Google features, consult the current type-specific documentation.
Understand the JSON-LD You Are Generating
JSON-LD uses a JSON object to express relationships between facts. The @context entry identifies the vocabulary, while @type tells readers what kind of thing is being described. Properties such as headline, author, and datePublished supply the details. An author can be represented as a nested Person object instead of an unexplained text field.
This fictional article example illustrates JSON-LD structure, not a guarantee of Google Search eligibility.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "A Practical Guide to Indoor Herbs",
"mainEntityOfPage": "https://example.com/guides/indoor-herbs/",
"author": {
"@type": "Person",
"name": "Alex Rivera"
},
"datePublished": "2026-10-20",
"description": "An introductory guide to growing herbs indoors."
}
</script>
Replace the illustrative domain and person with authentic information. Include the <script type="application/ld+json"> wrapper only when your publishing method needs it; do not duplicate a wrapper around a WordPress field that expects raw JSON. Preserve valid quotes, commas, and escaped values.
Translate Visible Facts Into Reliable Properties
Make each field answer a simple question: where did this fact come from? A title should match the content, an image should refer to the correct item, and a price should agree with the currently visible offer. For dates, use a valid unambiguous date or date-time format. An event time may need an explicit time-zone offset, while an article publication date can often be represented by a calendar date where appropriate.
Do not add properties merely to make the code look comprehensive. A product without authentic reviews should not acquire invented rating values. A business should not claim a location it does not operate. Google specifically warns against misleading markup, irrelevant descriptions, and information that is not available to readers. Accuracy is more valuable than the number of keys in the JSON.
For connected entities, a stable @id can link the page to its publisher. Such an identifier does not establish ownership by itself.
Validate Syntax, Meaning, and Search Eligibility Separately
Validation involves several different checks. Start by confirming that the output is parseable JSON and uses actual schema types and properties. Next, determine whether the generated markup describes the visible page accurately. Finally, test whether the published page meets a specific search feature’s requirements. Passing one step does not automatically pass the others.
- Review the generated code: inspect names, URLs, nested objects, values, and any missing data. Use a JSON formatter and validator for basic JSON syntax when needed.
- Check schema vocabulary: use the Schema.org Validator to inspect detected types and properties.
- Check Google-specific support: use the Google Rich Results Test for eligible search features and relevant errors or warnings.
- Test the deployed URL: examine the actual published page, not only pasted source code. The final page may contain additional schema from a theme or plugin.
- Monitor after release: inspect Google Search Console’s relevant enhancement reports and URL Inspection information when available.
Not all schema.org types have a corresponding Google rich-result test. An unsupported rich-result type does not necessarily mean its schema vocabulary is invalid. Conversely, a successful Rich Results Test is not a guarantee that Google will display enhanced results. If you are auditing existing pages, a structured data extractor and syntax checker is a useful companion to code generation.
Avoid Duplicate Schema When Publishing in WordPress
WordPress SEO plugins such as Rank Math or Yoast may already output structured data for posts, pages, breadcrumbs, and site identity. Before adding generated markup, examine the existing page output and the SEO plugin’s schema settings. Two disconnected or conflicting descriptions of the same article, author, or organization can make maintenance harder and produce confusing information.
Prefer editing the existing schema through the site’s SEO plugin when that meets your needs. If a custom block is genuinely required, ensure it describes the same canonical page and agrees with existing properties. Keep code insertion within a trusted theme, plugin, or suitable WordPress integration. WordPress editors and security settings can strip or block script elements, so pasting JSON-LD into a visual content field does not prove it will appear in the final HTML.
After publishing, inspect the rendered page source or use a source versus rendered HTML comparison where appropriate. Confirm that the intended structured data is present exactly where expected and that your page remains accessible to crawlers. Do not create duplicate <script> wrappers or place a generated example inside an ordinary visible paragraph.
Why Correct Markup May Not Produce a Rich Result
There are several possible reasons. The page might not be eligible for a currently supported feature, a required property may be missing, or the underlying content may not meet the feature’s policy. Google also chooses when to show a rich result based on its systems and the search context. Structured data is a way to describe content, not a request that Google must honor.
Indexability is a separate consideration. If a page is blocked from crawling or carries a noindex directive, adding structured data does not remove that restriction. Use a website indexability checker to investigate access and indexability separately, then verify important pages in Search Console. Schema alone does not resolve canonical disagreements, weak content, or server errors.
Keep the Markup Synchronized After Publishing
A one-time generator output can become stale. Product availability changes, event dates move, employees leave, and company addresses are updated. If the page is dynamic, consider generating its schema from the same source of truth as the visible content rather than maintaining two independent copies.
Retest representative pages after template, domain, permalink, or SEO plugin changes. Focus on actual discrepancies, such as a price that differs between the visible offer and the Offer markup, rather than counting schema blocks.
Questions Website Owners Commonly Ask
Is JSON-LD better than Microdata or RDFa?
Google supports all three formats for structured data and generally recommends JSON-LD because it is often easier to maintain separately from visible HTML. The right choice also depends on the website’s existing implementation.
Can I use several schema types on one page?
Yes, when each type describes real content relevant to that page. A recipe page can also have breadcrumbs and information about its publisher. Connect related entities consistently and avoid adding unrelated types merely to increase coverage.
