Direct answer: You can generate schema markup online with the Schema Markup Generator tool: pick one of eight types — FAQPage, Article, LocalBusiness, Product, HowTo, BreadcrumbList, Organization, or WebSite — fill in its form, and the tool produces valid JSON-LD with live validation, warnings for missing required fields, and output as a script block or raw JSON, plus a download and a Rich Results Test link. No code writing is required.
Schema markup is structured data added to a page that describes, in a machine-readable format, what the page is about: that this block is a set of questions and answers, that this page is an article by a named author, that this business sits at a particular address. Search engines read that description and may use it to present the page more richly — an FAQ dropdown, a product price, a breadcrumb trail — instead of a plain title and snippet. The markup does not change what human visitors see on the page; it changes what machines understand about it.
The honest framing matters here, because schema markup is often oversold. It is not a ranking factor, and adding it does not push a page up the results. What it can do is make a page eligible for richer presentation when it already ranks, which can improve how the result looks and how often people click it. That is a real benefit, but it is a presentation benefit, and any claim that schema alone will lift rankings should be treated with scepticism.
The eight types and when each one fits
Each type describes a different kind of page, and choosing the right one is the first decision. FAQPage fits a page whose main content is questions with answers, such as a help page or a support article. Article fits news, blog, and editorial content with a headline, author, and publication date. LocalBusiness fits a business with a physical presence, an address, opening hours, and contact details. Product fits a product page with a name, description, and offer details. HowTo fits a page that teaches a task in steps. BreadcrumbList fits any page that sits in a hierarchy and should show its trail. Organization fits a company or institution itself, and WebSite fits the site as a whole, including its search function where one exists.
The common mistake is choosing a type for its perceived value rather than its fit. A product type on a page that does not sell anything, or an FAQ type on a page with no real questions, is mismatched markup — and mismatched markup is worse than no markup at all, because it misdescribes the page to the very systems you want to inform. Search engines can ignore mismatched markup, and repeated misuse can erode trust in a site's structured data generally. When no type fits the page honestly, the right move is to add nothing.
Most pages need at most one or two types. A blog article might carry Article alone, or Article plus BreadcrumbList for its trail. A product page might carry Product plus BreadcrumbList. A local business homepage might carry LocalBusiness plus WebSite. Adding every type to every page is not thoroughness; it is noise, and noise makes the accurate markup harder to trust.
| Schema type | Fits pages that | Key fields |
|---|---|---|
| FAQPage | Answer real questions | Question and answer pairs |
| Article | Publish editorial content | Headline, author, date |
| LocalBusiness | Serve customers locally | Name, address, hours, phone |
| Product | Sell or present a product | Name, description, offers |
| HowTo | Teach a task in steps | Ordered steps |
| BreadcrumbList | Sit in a hierarchy | Positioned trail items |
| Organization | Represent a company | Name, logo, contact |
| WebSite | Represent the site itself | Name, URL, search action |
One form per type, with repeatable items handled for you
Each type has its own form, so you only see the fields that belong to that type. That design prevents the most common beginner error, which is copying a generic example and leaving in fields that do not apply. A Product form asks about offers; an FAQ form asks about questions; a HowTo form asks about steps. The form shapes the markup, and the markup stays close to what the page actually contains.
Repeatable items are where a form-based generator earns its keep. FAQ pairs can be added one after another without hand-editing JSON arrays; HowTo steps are added in order and kept in that order; breadcrumb positions are auto-numbered, so inserting a level in the middle does not leave the numbering wrong. These are small conveniences, but hand-written JSON fails most often on exactly these points — a missing comma between items, a duplicated position number, a step out of order — and the form removes those failure modes entirely.
Fill the form from the page, not from aspiration. The FAQ answers in the markup should match the answers visible on the page, the product price should match the price shown to visitors, and the business hours should match the hours on the door. Markup that contradicts the visible page is mismatched markup by another name, and it will be ignored at best. Write the page first, then describe it accurately.
Describe the page you have, not the page you wish you had. Every field in the markup should be checkable against something a visitor can already see on the page.
Items in an example article page setup — hover or tap each bar for details.
Live validation and required-field warnings
Validation runs live as you fill the form, so syntax errors surface immediately rather than after pasting into a page. That matters because JSON-LD is unforgiving about small mistakes: a missing comma, an unclosed bracket, or a stray quote invalidates the whole block, and a broken block is the same as no block. Live validation turns that cliff edge into a gentle slope, flagging problems while the form is still open and the fix is obvious.
Required-field warnings are the second safety net. Some fields are required for a type to be useful at all — a Product offer, for example, is only emitted when a numeric price is present, because a price field without a number is meaningless to a search engine and misleading to a reader. The warning tells you what is missing before you copy the output, so you fix the form instead of publishing an incomplete block and discovering the gap weeks later in a testing tool.
Treat warnings as instructions, not annoyances. A warning that a required field is empty is the tool telling you that the markup would be incomplete; either fill the field from the page or reconsider whether this type is the right one. Skipping past warnings to get output faster produces markup that looks finished but behaves as if it were absent.
Output options, download, and the Rich Results Test
Output comes as a script block ready to paste into a page, or as raw JSON for systems that store structured data separately. The script block is the usual choice for a standard page: paste it into the head or body, and the page carries its description with it. Raw JSON suits developers and content systems that assemble the script block themselves, or anyone who wants to inspect the data without the surrounding tags. Both contain the same data; the choice is about where the data will live.
The .json download gives you a file copy of the markup, which is useful for version control, for handing to a developer, or for keeping a record of what was published on a page. Keep that file with the page's other records, because structured data drifts: a price changes, hours change, an FAQ is rewritten, and the markup must change with them. A saved copy makes the update a small edit rather than a reconstruction from memory.
The Rich Results Test link takes the finished markup to Google's own testing tool, where you can check that it parses and that it is eligible for rich presentation. Run that test before publishing and again after any significant page change, and treat a failed test as a blocker, not a warning to ignore. A block that fails the test will not produce rich results, and publishing it anyway wastes the effort spent creating it.
One block per type, several types per page, and the @graph option
The rule for combining types is straightforward: one block per type per page, with several types allowed to coexist. A page can carry an Article block and a BreadcrumbList block, because those describe different aspects of the same page, but it should not carry two competing Article blocks describing the same article differently. Duplication creates ambiguity about which description is true, and ambiguity is resolved by ignoring the markup — the opposite of the intended result.
Where several types belong together, they can either sit as separate script blocks or combine into a single block using @graph, which lists multiple items in one structured graph. Both approaches are valid, and the choice is largely about how the site's templates are built. Separate blocks are simpler to add and remove one at a time; a @graph block is tidier when a template always emits the same set of types together. What matters is not the packaging but the consistency: the same page described two different ways in two blocks is a problem in either format.
Before publishing, run through a short checklist: does each type match visible page content, are required fields filled, does the output validate, and does the Rich Results Test accept it? If all four answers are yes, publish. If any answer is no, fix it first — schema markup rewards accuracy and ignores effort. For related page checks, the Meta Tag Analyzer reviews titles and descriptions, and the Slug Generator builds clean URLs for new pages. More SEO guides live on the Asad Webs blog.
Build your markup now with the free Schema Markup Generator tool, explore more guides on the Asad Webs blog, or contact Asad Webs if you need help describing a page accurately for search engines.
Frequently Asked Questions
What is schema markup?
It is structured data, usually JSON-LD, added to a page to describe in machine-readable form what the page is about — that a block is a set of questions and answers, that a page is an article, or that a business has a certain address. It does not change what human visitors see.
Which eight types does the generator support?
FAQPage, Article, LocalBusiness, Product, HowTo, BreadcrumbList, Organization, and WebSite. Each type has its own form, so you only see the fields that belong to the type you picked.
Does schema markup improve search rankings?
No. Schema is not a ranking factor. It can make a page eligible for richer presentation, such as an FAQ dropdown or a breadcrumb trail, when the page already ranks, but it does not lift the page's position on its own.
What happens if I use the wrong type for a page?
Mismatched markup is worse than no markup: it misdescribes the page to search engines, which may ignore it, and repeated misuse can erode trust in a site's structured data. If no type fits the page honestly, add nothing.
How are repeatable items handled?
FAQ pairs, HowTo steps, and breadcrumb items can be added repeatedly in the form. Breadcrumb positions are auto-numbered, so inserting a level does not leave the numbering wrong, and JSON array errors from hand-editing are avoided.
Why does the Product form warn about a missing price?
A Product offer is only emitted when a numeric price is present, because a price field without a number is meaningless. The required-field warning tells you what is missing before you copy the output, so you fix the form instead of publishing an incomplete block.
Can I combine several types on one page?
Yes. One block per type per page, with several types coexisting — for example Article plus BreadcrumbList — or combined into a single block using @graph. Do not publish two competing blocks of the same type describing the same thing differently.
Be the first to share a useful question or thought.