Structured Data Generator

How to use the Structured Data Generator

1. Choose the type that matches the page. Pick the schema.org type describing the page you are marking up — an article, a product, a business, a how-to, a breadcrumb trail and so on. If no type honestly fits the page, the correct answer is no markup, not the nearest type.
2. Fill in the form. A sample for the selected type is loaded for you; replace every value with your page’s real details. Required fields are marked with an asterisk. Questions, steps, breadcrumb levels and offers repeat — use the Add button for each extra item.
3. Watch the preview and the validation lists. The JSON-LD rebuilds as you type, so syntax is never in question. Anything in the red list must be fixed: a missing required field, a URL without its https://, a rating outside its scale, a price that is not a number. Amber items are worth checking — a missing recommended field, a value that still looks like placeholder text, or a product with no offer.
4. Copy or download the result. Copy the full <script> block into your page’s <head> or just before </body>, or download the JSON-LD object as a .json file or a ready-made .html snippet.
5. Test the live page, not just the snippet. After publishing, run the page URL through Google’s Rich Results Test and the Schema Markup Validator. They check the deployed page — including anything your template adds or strips — rather than the tidy block you copied.

Worked example

Say a guide page ends with two questions that readers ask again and again, answered in the page text. Choosing FAQPage and entering those two questions and answers exactly as they appear on the page produces the block below. Select Load the FAQ sample and the workspace above fills with these same two pairs, and the live preview generates this output character for character — so what you read here is genuinely what the tool produces, not a hand-typed imitation. Two details are worth noticing: the questions live inside mainEntity as Question objects, each with its own acceptedAnswer, and there is exactly one @type per object, which is the pattern validators expect.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "How do I add FAQ structured data to a page?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Write each question and answer as visible text on the page first, then add a FAQPage JSON-LD block whose mainEntity lists the same questions and answers word for word."
      }
    },
    {
      "@type": "Question",
      "name": "Does FAQ structured data guarantee a rich result?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. Valid FAQPage markup only makes a page eligible. Google currently limits FAQ rich results to well-known government and health sites, so most sites will not see the expanded FAQ display even with perfect markup."
      }
    }
  ]
}
</script>

Publish that block, and the page is honestly described: a crawler can lift the two questions without guessing which headings are questions and which prose answers them. Whether Google then shows an expanded FAQ listing is a separate matter — for most sites today it will not, for the eligibility reason given in the second answer itself.

What the form asks for — and what Google actually requires

Three different lists are easy to confuse: the fields this form collects, the properties Google requires for a rich result, and the ones it merely recommends. They are not the same list. The form sometimes asks for more than Google requires (because the extra data is genuinely useful to other consumers), and Google sometimes wants data the form treats as optional. This table puts the three side by side, checked against Google’s structured-data documentation on 24 October 2026 — re-check it there before relying on any row, because Google revises these requirements.

What structured data does, and why the details matter

Structured data is a standardised description of a page, written for machines instead of people. A visitor reads your headline, your price and your opening hours by looking at the layout; a search engine has to guess which of the hundreds of text fragments on the page is the price and which is a phone number in the footer. JSON-LD — JavaScript Object Notation for Linked Data — removes the guessing. It is a small block of JSON, placed in a script tag, that states plainly: this page is about a product, the product is called this, it costs this much in this currency, and it is in stock. The vocabulary comes from schema.org, a shared dictionary maintained by the major search engines, so the same block is understood by all of them.

That clarity buys two things. The first is eligibility for richer search displays — star ratings under a product, a breadcrumb trail instead of a raw URL, an article date beside a headline. None of those is promised; they are shown selectively, and Google has withdrawn or narrowed several formats over the years, most recently retiring HowTo enhancements on most surfaces and restricting FAQ enhancements to a small class of authoritative sites. The second benefit is quieter and more durable: an accurate, machine-readable summary helps search systems classify a page correctly even when no enhancement is ever displayed, and the same markup feeds shopping aggregators, voice assistants and other consumers of schema.org data.

Getting the details wrong quietly undoes both benefits. A price written as “£89.99” instead of the number 89.99 with a separate currency code fails validation. A review rating of 4.6 with no review count, or a rating nobody on the page can see, reads as decoration — and marking up content that is not visible on the page is a direct breach of Google’s structured data policies, punishable by the loss of rich results across a whole site. Dates in a local format such as 14/09/2026 are ambiguous to a parser and to a reader in another country; ISO format removes the doubt. Placeholder text left over from a generator’s sample — a logo still pointing at a stock URL, a business named “Your Company” — is worse than no markup, because it publishes false statements about your organisation in a format designed to be trusted.

That is why this tool validates as it generates rather than leaving checking to a separate step. Required properties are errors, not suggestions. URLs must be absolute, ratings must sit inside the scale they declare, currencies must be three-letter ISO codes, and anything that smells like a placeholder is flagged before it reaches your page. The generator builds the JSON itself from your form answers, so the syntax is valid by construction — the failures that remain possible are factual ones, and those are precisely the ones the error and warning lists are written to catch.

Common errors, and the limits of this tool

The most common failure is mismatched content: markup describing things the page does not visibly contain — FAQ answers that exist only in the JSON-LD, five-star ratings with no reviews behind them, prices that differ from the price on the page. Keep the two in step, and update the markup whenever the visible content changes. The second failure is relative URLs: an image given as /img/cover.jpg instead of the full address. A crawler reading your snippet out of context cannot resolve it, so every URL field here insists on the complete https:// form. Third is type confusion — marking a category listing as a Product, or a personal blog as an Organization with a trading name. Use the type the page honestly is.

Formatting errors still matter even though the generator prevents most of them. Hand-editing the output afterwards can reintroduce trailing commas, unquoted keys or a stray </script> inside a text value, which is why the copy button’s output escapes angle brackets. If you do edit by hand, re-validate the whole block, not just the line you touched.

The limits are these. This tool covers nine types — Article, FAQPage, HowTo, BreadcrumbList, Organization, Product, LocalBusiness, WebSite and WebApplication — with the properties most pages need. Schema.org defines hundreds of types and far more properties than any form should carry; specialist markup such as events, courses, job postings or recipes, and advanced patterns such as a multi-type @graph, are outside its scope and are better written deliberately, with the schema.org documentation open. The validator checks the rules encoded here — required properties, formats, ranges and the recommendations drawn from Google’s documentation at build time. It is not Google’s Rich Results Test and cannot see your live page, your template’s other markup, or policy changes published after this page was written. Treat a clean result here as “ready to test on the real page”, never as approval.

Frequently asked questions