JSON-LD Schema.org Markup Generator

Choose the entity that is actually described on the page, fill in its properties, and get JSON-LD code ready to embed in your HTML. The generator helps you assemble the syntax, but before publishing you must verify that the markup matches the visible content, meets the requirements of your chosen data consumer, and that all values are current and accurate.

Schema.org, JSON-LD, and the rich result are different things

Schema.org

This is a shared vocabulary of types and properties: Article, Product, Organization, Event, name, image, offers, and many more. It defines what entities and relationships can be represented in a structured way.

JSON‑LD

This is one of the formats for writing structured data. The code is placed inside:

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

Google recommends JSON‑LD when it fits your implementation, but Schema.org can also be expressed using Microdata or RDFa.

Google’s rich result

This is a special presentation of a search result that supports only a limited set of types and requires following Google’s specific guidelines. Valid Schema.org markup does not guarantee a rich result, a high ranking, or even that all properties you provide will be used. Therefore, you should not evaluate markup solely by asking “will it show a fancy snippet?” It must first and foremost describe the real entity of the page correctly.

How to choose the markup type

Choose the type based on the main object of the page, not on the appearance you want in search results.

Type	When to use	Key points to verify
Article	article, news, review, blog post	headline, author or publisher, dates, image, relationship to the current page
BreadcrumbList	visible or logical navigation trail	correct order of items and URL for each step
Event	a specific event with date and format	date and time zone, location or online URL, status, and timeliness
FAQPage	a page with one official answer per question from the site	all Q&As are visible to the user; do not mark up forums or user-submitted answers
HowTo	a real step‑by‑step instruction	steps match the visible material; do not rely on Google’s HowTo rich result
JobPosting	a specific open job position	employer, location or remote format, publication date, expiration date, description
LocalBusiness	a specific physical location or local organization	most precise subtype, address, phone, hours, and the URL of that specific location
Organization	company, institution, brand, or association	official name, URL, logo, contacts, and a stable @id
Person	profile of a specific individual	name, role, affiliation, official profiles; do not present assumptions as facts
Product	a specific product or product variant	product exists on the page; price, currency, availability, offer, and reviews are current
Recipe	a culinary recipe	ingredients, steps, time, servings, and image are available to the user
VideoObject	a standalone video on the page	title, description, thumbnail, upload date, and a working URL to the video or player
WebSite	the site as a single object	main canonical URL, name, and relationship to the organization; this type is often not needed on every page as an independent entity

Multiple related objects can be placed on one page. For example, an article may have an author Person, a publisher Organization, breadcrumbs BreadcrumbList, and an embedded video VideoObject. It is better to link them via @id rather than creating contradictory copies.

Important current Google limitations

FAQPage

Google has significantly restricted the display of FAQ rich results; they are now generally available only to well‑known authoritative government and health websites. For a typical commercial or informational site, correct FAQ markup may not produce a noticeable enhancement in the SERPs. This does not make the FAQPage type invalid in Schema.org, but you cannot promise users that “questions will appear in Google.”

HowTo

Google has discontinued the display of HowTo rich results. The HowTo type remains in the Schema.org vocabulary and may be used by other consumers, but adding it solely for the former Google rich result is no longer meaningful.

Other types

Organization, Person, and WebSite help describe entities, but not all of them create a separate visual rich result. Support and the appearance of search features change over time, so before implementing, always check the current Google Search Central gallery.

The golden rule: markup must match visible content

Do not add information to JSON‑LD that is missing from the page or contradicts it. This is especially critical for:

• price and availability of a product;
• rating and review count;
• questions and answers;
• event date and location;
• author of the content;
• address and operating hours of a company;
• job posting conditions;
• recipe ingredients and steps.

Markup is not a place for hidden promotional text or extra keywords. Both the user and the search engine should receive consistent information.

Required fields depend on who reads the markup

Schema.org defines a vocabulary, but it does not provide a single universal list of “required fields” for all systems. A specific consumer—for instance, Google Search—sets its own required and recommended properties for a given search feature. Thus, there are three different levels of validation:

1. JSON syntax is correct.
2. The types and properties exist in Schema.org.
3. The markup meets the requirements of the specific Google rich result.

Passing the first or second stage does not guarantee the third.

How to fill in URLs, dates, and identifiers

Use absolute URLs

Preferred:

https://example.com/catalog/product-1

Instead of:

/catalog/product-1

Links must be accessible to search bots, not require login, and point to a stable resource.

Specify dates in ISO 8601

Date:

2026-08-04

Date and time with time zone:

2026-08-04T18:30:00-05:00

For events, it is especially important not to lose the time zone. Otherwise, the time may be misinterpreted.

Create a stable @id

@id is the entity identifier, often a URL with a fragment:

https://example.com/#organization https://example.com/article/#webpage https://example.com/article/#author

The same organization on different pages should refer to one stable identifier, not appear as many independent companies.

How to describe multiple entities using @graph

For related objects, it is convenient to use one block:

{ "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://example.com/#organization", "name": "Example Company", "url": "https://example.com/" }, { "@type": "Article", "@id": "https://example.com/blog/article/#article", "headline": "Article Title", "publisher": { "@id": "https://example.com/#organization" } } ] }

This way the objects are explicitly linked, and you do not have to repeat all the organization details inside each article.

Where to insert JSON‑LD

The <script type="application/ld+json"> block can be placed in the <head> or <body> of the HTML page. More important is that:

• the code is present in the final HTML or becomes available after proper rendering;
• it refers specifically to the current page;
• your CMS escapes it without breaking quotes and special characters;
• a single template does not inject the same data into different pages;
• dynamic prices, availability, and dates are updated together with the visible content.

After implementation, check not only the code from the generator but also the published URL: the template, plugin, or JavaScript may alter the final markup.

Two different validation levels

Schema Markup Validator

Checks syntax and usage of the Schema.org vocabulary. Suitable for identifying discovered types, properties, and general markup issues.

Google Rich Results Test

Shows whether Google recognises a supported rich result type on the page and whether its specific requirements are met. The tool does not guarantee that the enhancement will actually appear in search. After publishing, also use URL Inspection in Google Search Console to see the processed version of the page and the detected elements.

Error and warning are not universal categories

A validator may treat a missing property as a warning, while for a specific consumer it could be required. Conversely, Schema.org may allow a property that Google does not use for the feature you want. Evaluate each message by asking four questions:

1. Is the JSON syntax broken?
2. Do the type and property exist in Schema.org?
3. Is the property nested correctly and does it have a valid value?
4. Is it required by the chosen search feature or other integration?

Common mistakes

• Wrong type: a category page marked up as a single Product even though there is no individual product or offer. Or a regular article gets FAQPage just because it has a small Q&A section at the bottom.
• Markup does not match the page: the code contains an old price, a non‑existent rating, hidden questions, or a different author.
• Conflicting entities: multiple plugins produce different Organization blocks with varying names, logos, and URLs. The objects are not linked via a common @id.
• Incorrect nesting: for instance, price is placed directly inside Product, whereas the offer should usually be described through an Offer object in the offers property.
• Wrong value type: a date is written as free‑form text, price includes currency in the same string, a boolean is passed as a phrase, or a field expecting a URL contains a relative path.
• Inaccessible images and pages: the URL returns an error, is blocked by login or robots.txt, points to a temporary unstable link, or refers to an image that the crawler cannot retrieve.
• Outdated dynamic data: an event has already ended, a job is closed, a product is out of stock, yet the markup still transmits the old status.
• JSON errors: single or curly quotes; trailing comma after the last property; unclosed bracket; comments inside JSON; unescaped line breaks inside string values; duplicate keys in the same object.

Implementation workflow

1. Identify the main object and the purpose of the markup.
2. Check the current requirements of Schema.org and the intended data consumer.
3. Select the most precise type.
4. Fill in only trustworthy properties that are present on the page.
5. Generate the JSON‑LD.
6. Validate with the Schema Markup Validator.
7. If you need a supported Google rich result, test with the Rich Results Test.
8. Insert the code into a staging version of the page.
9. Re‑validate the published URL, not just the snippet.
10. Set up updates for dynamic values and re‑validate after template changes.

Short pre‑publication checklist

• the type matches the real entity of the page;
• data matches visible content;
• no fabricated ratings, reviews, or properties;
• URLs are absolute, accessible, and canonically consistent;
• dates are in a clear format with time zone where needed;
• price and currency are in separate fields;
• identical entities are linked via a stable @id;
• no conflicting markup from another module;
• the code passes appropriate validations;
• the published URL contains the same correct JSON‑LD;
• dynamic data will be updated.

Frequently asked questions

Does Schema.org guarantee a rich snippet?

No. Correct markup makes the page eligible for processing, but the search engine decides whether to use it and how to display the result.

Should I add Schema.org to every page?

Only where there is an entity and useful, reliable properties to describe it. Mass‑inserting the same block without regard to content creates errors and contradictions.

Can I keep properties that the user cannot see?

Technical links and identifiers may not be displayed as separate text, but factual information about products, ratings, questions, events, and other objects must correspond to the content available to the user and to the consumer's rules.

Where should I place the code — in the head or body?

JSON‑LD can be in either location. The key points are correct final HTML, accessibility to the processor, and relevance to the current page.

Why does the Schema Markup Validator not show an error, but Google does?

The first tool checks the Schema.org vocabulary and the structure of the markup, while Google additionally applies the requirements of the specific search feature.

Is it worth marking up FAQPage now?

You may do so when the page truly is an FAQ and the type is useful to other data consumers. But for most sites, you should not count on Google’s FAQ rich result.

Is HowTo worth using for Google?

Google no longer shows HowTo rich results. The type may still be useful as a semantic description for other systems, but you should not expect the former search effect from Google.

Related tools

Diffchecker, text processing utilities, Base64 encoder/decoder.

Official resources

• Schema.org vocabulary
• Google Search Central — Introduction to structured data
• Google — General structured data guidelines
• Google — Structured data feature gallery
• Schema Markup Validator
• Google Rich Results Test

---

Editorial recommendations for this section

1. Do not repeat the same commercial block inside every piece of useful content

The current block about “comprehensive SEO audit, AI visibility tools, and automation” can remain as a separate visual CTA after the main material. Do not embed it into the structure of the article between useful sections — that breaks the reading flow and looks identical on all nine pages. Instead, use a short contextual call‑to‑action that matches the tool. For example:

• after a UTM builder — link to channel and conversion reports;
• after a keyword combinator — link to frequency checks, clustering, and query assignment;
• after Schema — link to a structured data audit;
• after Diffchecker — link to page change monitoring;
• after duplicate removal — link to importing semantic or URL data into a project.

2. Do not create identical “Benefits” and “Who it suits” sections just for the sake of a template

Their content almost always becomes repetitions: “fast”, “convenient”, “free”, “for marketers and specialists”. It is more useful to keep specific scenarios, limitations, examples, and FAQs. The short indicators “free”, “in‑browser”, “no registration” are already shown next to the tool.

3. Align promises with the actual implementation

Before publishing, developers should confirm:

• whether processing is done entirely in the browser or data is sent to a server;
• what limits exist for text volume and number of lines;
• whether original data or results are stored;
• which algorithm and library are used for language detection;
• how exactly Diffchecker compares words and lines;
• whether duplicate removal is case‑sensitive and whitespace‑sensitive, and in what order actions are applied;
• whether the password generator uses a cryptographically strong source of randomness;
• what encoding the Base64 converter uses;
• whether it supports Base64url or only standard Base64.

After confirmation, these details can be moved to a short “Processing and privacy” block on each page. You cannot promise local processing and no storage simply because the tool visually runs in the browser.

4. Show limitations near the feature, not hidden at the bottom

Especially important warnings:

• UTM parameters should not be placed on internal links;
• Diffchecker does not verify meaning or factual correctness;
• a keyword combinator does not confirm demand or automatically create a site structure;
• Base64 does not encrypt data;
• you should not blindly lowercase the entire URL;
• a password should not be considered cryptographically strong without verifying the generator;
• valid Schema.org does not guarantee a rich result.

5. Add internal links for the user’s next logical action

Instead of a general list of all utilities, place two‑three genuinely relevant links at the end of the page. The link text should explain the continuation of the scenario: “Clean up the resulting list”, “Compare two versions”, “Remove duplicate combinations”, “Check the language of the text”.

6. Do not mark up FAQ solely for the promise of a rich snippet

The FAQ in these texts is useful for the user and can remain on the page. But the decision to add FAQPage should be made separately, taking into account Schema.org rules and current search engine limitations. For typical sites, Google currently seldom shows FAQ rich results.

7. Suggested order of implementation

1. Diffchecker, language detection, and UTM — currently these have the least amount of useful material.
2. Duplicate remover — urgently fix the advice about lowercasing all URLs.
3. Base64 — replace the word “decipher” with “decode” and add Base64url.
4. Password generator — update length recommendations and verify the randomness implementation.
5. Schema.org — replace the current overly long repetitive text with a more compact but technically accurate guide.
6. Combinator and text processor — keep the strong parts, add limitations and a practical workflow.