Schema Markup Generator

Schema markup is a standardised vocabulary — defined at schema.org — that you add to a web page to describe what the page is about in a way machines can parse reliably. Instead of making a search engine infer that '£49.99' is a price and '4.8 stars' is a rating, you state it explicitly. Search engines and AI answer engines use that structured description to understand the page, and in some cases to display richer results.

JSON-LD (JavaScript Object Notation for Linked Data) is a way of expressing schema markup as a standalone block of JSON inside a <script> tag. The two alternatives — Microdata and RDFa — require you to weave attributes through your existing HTML, so they break whenever the markup changes. JSON-LD sits in one self-contained block, which makes it far easier to maintain. Google explicitly recommends JSON-LD, so this tool outputs only that.

Anywhere inside the <head> of the page it describes. It also works inside <body>, but <head> is conventional and makes it easier to find later. Paste the entire block, including the surrounding <script type="application/ld+json"> tags. One page can carry several JSON-LD blocks, though this tool produces a single connected @graph instead, which is cleaner.

No. Paste a URL, and the tool reads the page and builds the markup for you. You only need to be able to paste the resulting block into your page's HTML — every CMS has somewhere to do this, whether that's a theme header file, a 'custom code' field, or a plugin.

Not directly. Schema markup is not a ranking factor. What it does is make you eligible for rich results and help search engines and AI systems understand your content with less ambiguity. The practical effect is usually a higher click-through rate from the same position, rather than a higher position. Anyone promising rankings from schema alone is overselling it.

Yes — no signup, no account, no usage limit. The page analysis runs on our server and the schema generation runs in your browser. Nothing you analyse is stored.

The tool detects one for you and shows its confidence along with the evidence behind the guess — existing markup on the page, og:type, URL patterns, whether a price was found, and so on. You can override it at any time. As a rule: use Article for editorial content, Product for anything with a price, LocalBusiness for a physical location, and Organization for a homepage or about page.

Deploy the page, then run it through Google's Rich Results Test and the Schema Markup Validator. After a few days, Search Console's 'Enhancements' reports will show whether Google has picked up the markup across your site. The audit score in this tool catches problems before you deploy, but only Google can confirm eligibility.

An @graph is a single JSON-LD block containing multiple connected nodes rather than one flat object. A typical page is not one thing — it is a WebPage, which is part of a WebSite, published by an Organization, containing an Article, written by a Person, with a primary ImageObject. In a flat object those entities get inlined and duplicated. In an @graph each gets a stable @id and the others reference it. That is the difference between describing a page and describing the entities on it, and it is what separates properly engineered markup from what a language model produces from a prompt.

@id is the unique identifier for a node — the thing that lets other nodes point at it instead of copying it. The critical rule is that an @id must never be the bare page URL. If your Article node uses @id: 'https://example.com/post' and the page's WebPage node uses the same string, both claim the same identity and consumers will merge or silently drop one. Always use a distinct fragment: '#article', '#webpage', '#organization'. This tool enforces that and flags any bare-URL @id in the audit.

It compares every text value in the generated schema against the text actually present on the page. Google's structured data guidelines require markup to represent visible content — inventing a rating, a price or a description that appears nowhere on the page is a spam signal and can attract a manual action. This is the characteristic failure mode of AI-written schema, because a language model will happily produce a plausible-sounding value it has no evidence for. Since the tool has already read your page, this check costs nothing and is on by default.

No. Google stopped showing FAQ rich results on 7 May 2026 and removed the FAQPage documentation entirely on 15 June 2026. The Search Console report and Rich Results Test support were withdrawn in June, and API data in August 2026. FAQPage remains valid schema.org and AI answer engines still parse it, so this tool still generates it — but it is labelled clearly, because anyone adding it expecting a Google rich result is going to be disappointed.

HowTo rich results were retired from mobile in August 2023 and desktop in September 2023. There is no Google surface for them today. As with FAQPage, the markup is still valid and still useful for AI answer engines, so the tool supports it with a clear label rather than pretending otherwise.

Switch to the 'Paste HTML' tab. Open your page in a browser, view source, select all, and paste. The analyser runs identically on pasted HTML — same extraction, same @graph, same audit — because it operates on a parsed DOM rather than on a network response. Your own browser is never blocked, so this path always works. This is the honest fix: some sites (Cloudflare and Akamai Enterprise in particular) fingerprint at the TLS layer and refuse any server-side request regardless of headers.

Your page is probably a JavaScript shell — the HTML contains a mostly empty container and the content is rendered client-side. The tool flags this explicitly as a warning rather than quietly returning thin data. It also mines embedded hydration state (__NEXT_DATA__, __NUXT__, Apollo caches) to recover fields like price and SKU that never reach the static HTML. If the warning appears, use the paste-HTML path with the rendered DOM from your browser's inspector rather than View Source.

Yes, and most pages should. A blog post is legitimately a WebPage, a BlogPosting, and a BreadcrumbList at once. The mistake is emitting them as separate disconnected blocks that repeat the same publisher and image data. The @graph this tool builds expresses all of them as one connected structure, which is both smaller and less ambiguous.

Required properties are the minimum Google needs for your page to be eligible for a given rich result — omit one and you get nothing. Recommended properties are not gating, but they materially improve how the result is displayed and how confidently the content is understood. The audit separates the two: missing required properties are errors that cost significant points, missing recommended ones are informational suggestions.

It helps, though less deterministically than with traditional rich results. AI answer engines parse JSON-LD when it is present because it is unambiguous — an explicit author, date and organization is far easier to attribute than prose. It does not guarantee citation; content quality and authority still dominate. See our glossary entry on Generative Engine Optimization for how this fits into a broader strategy.

Whenever the underlying facts change. Prices, availability and dateModified are the ones that go stale fastest, and stale structured data is worse than none — Google may distrust markup that repeatedly contradicts the page. If your data changes frequently, generate the JSON-LD from your CMS programmatically rather than pasting a static block.

Use origin-level fragments for site-wide entities and page-level fragments for page-specific ones. The Organization and WebSite nodes are the same entity on every page, so they should be 'https://example.com/#organization' and 'https://example.com/#website' — identical strings sitewide, so consumers can consolidate them. Page-specific nodes hang off the canonical URL: 'https://example.com/post#webpage', '#article', '#primaryimage'. Consistency across pages is what lets a search engine build a coherent picture of your site rather than treating each page as unrelated.

Always the canonical. If a page is reachable at several URLs — tracking parameters, trailing slashes, pagination variants — basing @id on the requested URL generates a different identity for every variant, fragmenting the entity. This tool resolves the canonical first and uses it as the base for every @id and for the WebPage url property.

Validity and eligibility are different things. Valid markup with all required properties makes you eligible; it does not entitle you to a rich result. Google also weighs page quality, site-level trust, whether the markup matches visible content, and whether the feature still exists at all — the FAQ deprecation caught a lot of people whose markup was perfectly valid. Check Search Console's Enhancements report: it distinguishes 'valid' from 'valid with warnings' and shows actual impressions.

Yes. Google issues 'Spammy structured markup' manual actions for markup that describes content not visible on the page, marks up irrelevant or misleading content, or fabricates reviews and ratings. Self-serving review markup — a business marking up reviews of itself — is specifically disallowed for several types. This is precisely why the content-backing audit exists: it catches the most common trigger before you deploy.

Google renders JavaScript, so client-injected JSON-LD can work, but it adds a dependency on the render queue and gives you a slower, less predictable feedback loop. Server-render your JSON-LD wherever you can. If you must inject it client-side, use standard DOM APIs rather than a framework abstraction, and verify with the URL Inspection tool's rendered HTML view — not View Source, which shows the pre-render state. Note that AI crawlers are generally much weaker at JS rendering than Googlebot, so client-side-only markup is often invisible to them entirely.

Use ProductGroup as the parent with hasVariant pointing at individual Product nodes, each carrying its own sku, offers and variant-defining properties (size, colour). The older pattern — one Product with an AggregateOffer spanning a price range — still validates but communicates far less, and Google's merchant listing documentation now prefers the explicit ProductGroup structure. This tool normalises a detected ProductGroup onto Product for single-item output; model the full variant tree in your CMS.

sameAs links your entity to authoritative external profiles — Wikipedia, Wikidata, LinkedIn, Crunchbase, verified social accounts. The purpose is disambiguation: it tells a search engine that your 'Apex Digital' is the same entity as the one described elsewhere, which is how you get associated with a Knowledge Graph entry rather than being treated as an unknown string. Wikidata and Wikipedia carry disproportionate weight because they are already Knowledge Graph sources. This tool harvests sameAs candidates from your page's footer and header links automatically, since that is where they almost always live.

No. Each paginated URL should describe itself — its own canonical, its own @id fragments, its own ItemList contents. Copying page one's markup onto every page creates duplicate identities across URLs, which is exactly the ambiguity structured data is supposed to eliminate. Sitewide entities (Organization, WebSite) should stay identical; page-scoped entities must not.

Because modern frameworks emit JSON-LD late in the document, after the hydration payload. We measured the byte offset of the first JSON-LD block on real pages: nike.com at byte 332,285 and stripe.com at 592,285. Any tool capping at 200 KB silently discards the exact data it exists to read, and reports 'no structured data found' on pages that are full of it. Raising the ceiling was the single highest-value fix in this rebuild.

No. Google has never exposed a public API for the Rich Results Test, and schema.org publishes no official validator endpoint either. Any tool claiming real-time Google validation is running its own rules. This one is explicit about that: the audit encodes Google's documented required and recommended properties per feature as a hand-maintained table, checked against Search Central. Treat the score as a strong pre-flight check, and confirm with Google's own tools before you rely on it.