Schema Generator

How the page type is decided

Detection is a precedence rule rather than a guess. The fetcher reads the title, meta description, H1, first eight H2s, author and publish-date signals, commerce markers, the URL path and any JSON-LD already on the page, then walks the rules in order and stops at the first match. The order is worth knowing, because a page carrying both an add-to-cart button and question headings will always be typed as a Product.

• ›Commerce signals such as add to cart, price markup or stock status: Product
• ›Two or more question-style H2s: FAQPage
• ›An author, a publish date, or a /blog/, /post/, /article/ or /news/ path: BlogPosting
• ›The site root: Organization
• ›Everything else: WebPage

Generation, validation and the fallback

The extracted signals go to the model, which returns one best-fit block using the real values from the page. That block is then run through a parser. If it does not parse as JSON it is discarded and a deterministic template for the detected type is used instead, so a run never hands you broken markup. Each result card shows the type chosen, the schema types already present on the page, the block itself and a short note on what to verify. The run summary counts how many of the fetched pages already had structured data.

Before you paste it live

Generated markup is a starting point, not a finished artifact. Templates carry explicit placeholders for an author name, an answer body or a price, and the generator can only use what the HTML exposes, so anything missing from the page will be missing from the JSON-LD. Fill those gaps by hand, check the existing-schema line so you are not shipping a second Organization block on top of one you already have, then validate the live page before you call it done.