AI SEARCH (GEO)

Plan structured data that matches the page

Use when you want schema markup that reflects what the page actually says.

schema-for-answers.md

Download .md

You are planning structured data for a page, based strictly on its visible content.

Page URL: {{PAGE_URL}}
Page content: {{PAGE_TEXT}}
Page purpose: {{PAGE_PURPOSE}}

Produce:
1. A recommendation of which schema types fit, with one line of justification each, ranked by usefulness.
2. For the top recommendation, a complete JSON-LD block. Every value must be traceable to text on the page.
3. A table: | Property | Value used | Where it appears on the page | Risk if wrong |
4. A list of properties you left empty and what content would need to exist on the page before they could be filled.

Constraints:
- Never populate a property with content that is not visible on the page. No invented ratings, prices, authors or dates.
- Do not recommend FAQPage markup unless the page has genuine question headings with answers beneath them.
- Flag any property where the page content is ambiguous rather than choosing a value.
- Output valid JSON-LD only in section 2, no commentary inside the code block.

Fill in before running

Replace each placeholder with your own detail. The more specific you are, the less the model invents.

{{PAGE_URL}}
{{PAGE_TEXT}}
{{PAGE_PURPOSE}}

Getting a better result

Schema that disagrees with visible text is worse than no schema at all.
Section 4 usually reveals the real work: the page is missing content, not markup.
Validate the block before shipping; a broken JSON-LD block is silently ignored.

Questions about this prompt

When is this worth doing for assistant visibility?

When the page content is settled and you want markup that describes it rather than chases a rich result. Whether structured data influences how assistants read a page is not well evidenced and is genuinely contested, so the defensible case is that consistent markup costs little while contradictory markup can be read against you.

What do I need before running it?

The visible page text, its URL and a plain statement of what the page is for. Every value must be traceable to text a visitor can see, so a summary of the page will not do. If a fact you want in the markup is not on the page, that is itself the finding.

What comes back, and which section is the real output?

Ranked type recommendations, one complete JSON-LD block, a property table with a risk column, and a list of properties left empty. Section four is where the work is. It usually shows the page is missing content rather than markup, and adding the content is worth more than adding the property.

What is the mistake to avoid?

Forcing FAQPage onto a page with no genuine question headings, which the prompt declines to do and people then add by hand. Markup describing a structure the visitor cannot see is the case search engines treat as spam. Validate before shipping, since a malformed block is silently ignored.