Schema markup generator
Built in your browser · nothing is uploaded
Builds JSON-LD for nine schema.org types: Organization, FAQPage, Article, Product, LocalBusiness, BreadcrumbList, Event, Recipe and HowTo. Pick the type across the top of the panel and the form changes to its fields. It opens on Organization, the block that tells a search engine which entity a site belongs to; that one goes on the homepage only, and the other eight should reference it by @id rather than repeating the organisation on every page.
How to use the schema markup generator
The sameAs list is what does the real work in an Organization block. It links the site to its social and directory profiles, which is how a search engine establishes that they are all the same organisation and not several with similar names, and that entity understanding is what feeds a knowledge panel and separates a brand from a common word. Two practical rules follow from it: put this one on the homepage only, since it describes the organisation and not the document, and give every other structured-data block a publisher that references it by @id instead of repeating the whole organisation everywhere.
That cross-reference is the reason to give the block a stable @id of your own, usually shaped like https://example.com/#organization, and then write "publisher": { "@id": "https://example.com/#organization" } wherever a publisher is wanted. One definition, one place to correct it when the company name or the logo changes. Two smaller things the validator will not tell you: the logo has to be a URL a crawler can fetch, so not a data URI and not a file behind a login, and a business with a street address and opening hours is better described by LocalBusiness, a subtype of Organization and not an alternative to it.
What each type turns on
The other eight types are the rest of the switcher, and each fails in its own specific way. A generator gets the syntax right; knowing which failure you are looking at is what gets the content right, and that is the part no form can do for you. Article turns on dates. dateModified should change only when the content genuinely changed; bumping it on every deploy to look fresh is a well-known tactic whose effect is at best nothing. Dates want ISO 8601 with an offset, because a bare date is read as midnight UTC and can put a post on the wrong day for readers on the other side of the world. NewsArticle is the variant Google treats specially for news surfaces, so using it on a non-news blog is a misrepresentation rather than an optimisation. Product is enforced more strictly than anything else here: a price in the markup that differs from the price on the page produces a rich result that misleads shoppers, and Google issues manual actions for it, so the markup has to be generated from the same data as the page and never maintained beside it. An Offer without a price is invalid and should be omitted instead of emitted empty, and review properties now require reviews genuinely present on the page and about the product itself.
LocalBusiness wants two-letter day codes and 24-hour times, so Mo-Fr 09:00-17:00 and never "Monday to Friday, 9am to 5pm", which is ignored outright. The name, address and phone should match the Google Business Profile exactly, because mismatches undermine the entity matching local results depend on. A specific subtype such as Restaurant or Store carries properties the generic type does not, and is worth using where one fits. Event needs the UTC offset: a time written 2026-09-01T19:00:00 with none is read as UTC, which puts a 7pm Amsterdam event at 9pm in the listing, and the offset moves with daylight saving. Set eventAttendanceMode on anything online, and update eventStatus on a cancellation instead of deleting the page. Recipe and HowTo use ISO 8601 durations, where P opens the period and T starts the time part, so twenty minutes is PT20M and ninety is PT1H30M; a recipe ingredient list should match the page including quantities, since that list is what a voice assistant reads aloud. BreadcrumbList runs top level first and current page last, describing the site hierarchy and not the route the visitor took, which is why a "back to search results" step does not belong in one. FAQPage must mark up questions a visitor can actually see; marking up hidden content is a policy violation, not a shortcut.
Which of them still pays
Worth knowing before investing effort in any of these. Breadcrumb has the most reliable visible payoff, replacing the URL in a result with a readable path for the same space. Recipe genuinely pays for a recipe site. FAQ rich results were cut back sharply in 2023 and now show mainly for government and health sites, and HowTo rich results were removed for all users in late 2023, so neither is worth adding on the expectation of a search appearance. A great deal of the advice still online predates both changes.
What people use it for
- Marking up the organisation behind a site
- Linking a brand to its social and directory profiles from one block
- Giving the organisation a stable @id the rest of a site can point at
- Turning a page’s visible questions into FAQPage markup
- Writing Article or BlogPosting markup with dates that mean something
- Building a Product block whose Offer matches the price on the page
- Writing LocalBusiness hours in the Mo-Fr 09:00-17:00 format that is actually accepted
- Getting a breadcrumb trail into the right order, numbered from the top level down
- Marking up an event with the UTC offset its start time needs
- Writing Recipe ingredients and steps with ISO 8601 times
- Producing HowTo markup for the consumers that still read it
- Deciding whether FAQ or HowTo markup is still worth adding at all
Questions
No. It makes a page eligible for a rich result, which can raise click-through rate. Google has been explicit that it is not a ranking factor in itself.
Google’s Rich Results Test reads a live URL or pasted code and tells you which rich results the page qualifies for. Do that before assuming it worked.
The one that describes the page. Organization for the homepage, Article for a post, Product for a product page, LocalBusiness for a business with an address. The switcher across the top of the panel changes the form to that type’s fields.
Yes, and it often should: a product page with a breadcrumb trail wants both. Build them one at a time and paste both blocks into the head; each goes in its own script tag.
The homepage. It describes the organisation, not the page, so repeating it everywhere adds nothing.
Linking to your profiles elsewhere. It is how a search engine confirms those accounts are the same entity as your site.
It helps, but panels are not granted on request. Google decides based on entity confidence overall.
Yes. Marking up content a visitor cannot see is a policy violation, not a shortcut.
Probably not. Google cut FAQ rich results back sharply in 2023 and they now show mainly for government and health sites.
Structurally almost nothing. NewsArticle is the one treated specially for news surfaces, and should only be used for actual news.
No. It should reflect a real content change. Bumping it for freshness is a known tactic that does not work.
ISO 8601, with a time and offset where you can. A bare date is read as midnight UTC.
The markup must change with it. A price in the markup that differs from the page is a manual-action risk, not a minor inconsistency.
Only with genuine reviews present on the page and about the product. Self-serving or invented ratings are a policy violation.
Two-letter day codes and 24-hour times, like Mo-Fr 09:00-17:00. Prose is ignored.
Not directly, but the name, address and phone should match it exactly. Mismatches weaken the entity matching local results rely on.
Top level first, current page last. Position one is the root.
Yes. A time without one is read as UTC, which shifts your event by hours in the listing.
ISO 8601 duration: P opens the period, T starts the time part, so PT20M is twenty minutes and PT1H30M is ninety.
No. Google removed HowTo rich results for all users in late 2023. A lot of advice still online predates that.