Prompt: Suggest Schema Markup for a Page

A prompt for a JSON-LD schema suggestion built only from facts the page actually states, flagging any field it can't support.

The prompt

Open in Studio

You are a technical SEO specialist suggesting structured data for a page.

Objective: Build a JSON-LD schema block for the page described below, using the schema type {{SCHEMA TYPE — e.g. Product, Article, FAQPage, Recipe}}.

Context: Page content and facts:
{{PASTE PAGE CONTENT OR KEY FACTS HERE}}
Example: if a price of £28 is stated above, populate the `offers.price` field; if no rating is stated, leave `aggregateRating` out entirely rather than guessing a number.

Constraints:
- Only populate schema fields supported by facts stated above — do not invent a price, rating, author name or date not given
- Leave unsupported fields out entirely rather than filling them with a placeholder
- Use only properties that are valid for the stated schema type per schema.org
- List, after the code block, which commonly used fields for this schema type were left out and why

Output format: Return the JSON-LD as a fenced code block, followed by a "Fields omitted" list.

Before finishing, check every field in the JSON-LD is traceable to a stated fact, and that the omitted-fields list accounts for the commonly expected fields not included.

Example

Input

SCHEMA TYPE — e.g. Product, Article, FAQPage, Recipe: Product
PASTE PAGE CONTENT OR KEY FACTS HERE:
  Product name: Fernglow Overnight Repair Serum. Brand: Fernglow. Description: an overnight facial serum for calmer skin by morning. Available in a 30ml bottle. Price: £28. Currency: GBP. In stock.

Output

```json
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Fernglow Overnight Repair Serum",
  "brand": {
    "@type": "Brand",
    "name": "Fernglow"

  },
  "description": "An overnight facial serum for calmer skin by morning.",
  "offers": {
    "@type": "Offer",
    "price": "28",
    "priceCurrency": "GBP",
    "availability": "https://schema.org/InStock"
  }
}
```

Fields omitted:
- `aggregateRating` — no review count or rating value was supplied.
- `sku` / `gtin` — no product identifier was given in the source content.
- `image` — no image URL was supplied for the product.

Every populated field traces back to a stated fact: name, brand, description, price, currency and stock status were all given in the source content, and nothing beyond those was invented.

Why it works

Restricting fields to stated facts stops the model inventing a plausible rating or SKU that would create false structured data in search results.
Requiring unsupported fields to be left out, not placeholder-filled, avoids publishing schema that could trigger a manual action for misleading markup.
Listing omitted fields tells the page owner exactly what real data to gather next instead of hiding the gap.

Why the basic version fails

“Write schema markup for this product page” without strict constraints often returns a JSON-LD block with an invented star rating, review count or SKU, because most Product schema examples include those fields and the model pattern-matches to a complete-looking example rather than the facts actually given.

What this prompt fixes

Restricting every field to a stated fact stops invented ratings or identifiers reaching a live page, where they risk a structured-data manual action for misleading markup. Requiring omission rather than placeholder values keeps the schema strictly accurate, and the omitted-fields list tells the page owner exactly what real data would strengthen it further.

Tips per model

ChatGPT tends to fill in a plausible aggregateRating unprompted for Product schema — check the JSON-LD for any field not traceable to your source facts.
Claude is generally reliable about omitting unsupported fields rather than guessing.
Validate the output with Google’s Rich Results Test before publishing regardless of which model wrote it — this prompt reduces invented fields, but doesn’t replace validation against the live schema.org vocabulary.