Schema Markup Generator from a Page

When to use this prompt

When a page should have schema markup but does not, or when existing markup is failing Google’s Rich Results Test, or when you want to layer additional schema types onto an existing page (e.g., adding FAQPage and BreadcrumbList to a service page that only has Service schema).

This prompt generates schema grounded in the visible content on the page. It does not invent fields. That alone fixes the most common reason schema gets ignored or rejected: claiming things in JSON-LD that are not visible to the user.

The prompt

<role>Schema markup engineer. You produce valid, conservative JSON-LD that matches visible page content and passes Google's Rich Results Test.</role>

<task>Generate JSON-LD for the page below using the schema types listed. Every field must be grounded in visible content. Do not invent values. If a recommended field has no source on the page, omit it rather than fabricating.</task>

<inputs>
<page_url>[FULL URL]</page_url>
<page_type>[ONE OF: Article, BlogPosting, Product, Service, Organization, LocalBusiness, FAQPage, HowTo, Course, Event, Recipe]</page_type>
<additional_types>[OPTIONAL: BreadcrumbList, ItemList, Person, etc.]</additional_types>
<page_content>
[PASTE FULL VISIBLE PAGE CONTENT, INCLUDING TITLE, BODY, AUTHOR BIO, FAQS, BREADCRUMBS]
</page_content>
<entity_ids>
[OPTIONAL: existing Person, Organization, or WebSite @id values used elsewhere on the site to maintain entity graph consistency]
</entity_ids>
</inputs>

<instructions>
1. Generate one consolidated JSON-LD block using the @graph pattern. Multiple types share the same @context.
2. Every required field for each type must be present. Reference Schema.org and Google's Rich Results documentation for what is required.
3. Every field must be grounded in the visible content. If a value is unverifiable, omit the field. Do not write placeholder values like "TBD" or "Lorem ipsum."
4. For BreadcrumbList, build it from visible breadcrumb navigation if present. If no breadcrumbs are visible, omit BreadcrumbList rather than fabricating.
5. For FAQPage, only include questions and answers that appear in the visible content. The answer text must match the page's wording, not paraphrase it.
6. For dates, use ISO 8601 format. If the page does not show a publish or modified date, omit those fields.
7. Reference existing entity_ids using `@id` references rather than redefining the same Person or Organization inline.
8. Do not include comments or explanatory text inside the JSON-LD. The output must be valid JSON.
</instructions>

<output_format>
A single JSON code block containing the @graph schema, ready to drop into a `<script type="application/ld+json">` tag.

After the JSON, list:

**Fields omitted (and why):**
- [field name] — [why it was omitted, e.g., "no publish date visible on page"]

**Validation checklist:**
- [ ] Every required field for each type is present
- [ ] All dates ISO 8601
- [ ] All URLs absolute
- [ ] No invented values
- [ ] @graph pattern used for multiple types
</output_format>

How it works

The “ground every field in visible content” instruction is the single most important constraint. The most common reason schema fails is mismatched claims: the JSON-LD says one thing, the page shows another, Google penalizes the page or ignores the markup. Forcing the model to omit unverified fields produces conservative but valid output.

Asking the model to use the @graph pattern matters because pages typically need multiple schema types (Article + BreadcrumbList + Person, or Service + FAQPage + Organization). Inline-duplicating Person across three types creates entity-graph confusion. The @graph pattern with @id references builds a clean knowledge graph instead.

The “fields omitted” report at the end is a forcing function. It surfaces the gaps in your visible content (e.g., “no publish date visible”) so you can decide whether to add the data to the page or live without that schema field.

Example output

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Article",
      "@id": "https://example.com/post/#article",
      "headline": "How Product Analytics Beats Web Analytics for Retention",
      "description": "...",
      "datePublished": "2026-04-15",
      "dateModified": "2026-04-22",
      "author": { "@id": "https://example.com/#person-jane-doe" },
      "publisher": { "@id": "https://example.com/#organization" }
    },
    {
      "@type": "BreadcrumbList",
      "@id": "https://example.com/post/#breadcrumb",
      "itemListElement": [
        { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://example.com/" },
        { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://example.com/blog/" },
        { "@type": "ListItem", "position": 3, "name": "How Product Analytics Beats Web Analytics", "item": "https://example.com/post/" }
      ]
    }
  ]
}

Fields omitted (and why):

• Article.image — no featured image visible in the pasted content
• FAQPage — no FAQ section on the page; would have been fabricated

Validation checklist:

• Every required field for each type is present
• All dates ISO 8601
• All URLs absolute
• No invented values
• @graph pattern used

Variations

• Schema retrofit: Paste the existing JSON-LD plus the page content. Ask the model to identify mismatches between markup and visible content, then output a corrected version.
• Multi-page batch: Paste 3-5 page contents at once with their URLs. The model returns one JSON-LD block per page. Useful for refactoring schema across a site section.
• Validation-only mode: Paste existing schema only. Ask the model to flag every unverifiable claim and every required field that is missing. Output a punch list, not a rewrite.