Definition and FAQ blocks that answer engines can quote

Paste into any coding agent: Claude Code, Cursor, Codex, Copilot, Windsurf or Cline.

# Definition and FAQ blocks that answer engines can quote

When someone asks an AI assistant what the production site does, who it is for, or how it compares, the assistant quotes whichever page states it most plainly. Most product pages bury that under slogans. Add short, factual, self-contained blocks to the key pages, as reusable components, so assistants and search features can quote them accurately.

Site: not given. Find the production URL in the project config, or ask me.

## Ground rules

1. Read before you write. Explore the parts of the codebase this job touches and tell me what is already in place.
2. Plan, then stop. Give me a numbered plan: what you will change, in which files, and why. Wait for my approval before editing anything.
3. Fix things at their source (the shared layout, the config, the generator), not with one-off patches page by page.
4. Keep the project's conventions: its framework APIs, file layout, naming and code style. Add no new dependency without asking.
5. Where something is already done well, say so and leave it alone.

## You will not

- Edit `.env` files, secrets or API keys, or print their values.
- Deploy, push, merge or publish anything.
- Delete data, or run migrations or scripts against a production database.
- Add tracking, third-party scripts or links to any site I did not ask for.
- Change copy, design or behaviour that this job does not need.
- Invent facts, numbers, customers or testimonials.
- Publish copy I have not approved.

## Your stack

- Framework: Work out the framework, router and build output from the project files (package.json, lockfiles, framework config) before planning, and say which you found.
- Host: Work out where the site is hosted from the config files (vercel.json, netlify.toml, wrangler config, Dockerfile, fly.toml) and say which you found.

## Steps

### 1. Pick the pages and gather the facts

Start with the homepage, pricing, and the main product or feature pages. From the existing copy, docs and code, collect the facts: what the product is, who it is for, what it costs, platforms, integrations, limits. Where a fact is unclear, ask me rather than guessing.

### 2. Build the blocks as components

- **Definition:** one sentence that names the product and its category and says what it does, for example "Acme is an invoicing app for freelancers that sends quotes and chases late payments." Place it high on the page, as real text in the HTML.
- **Who it is for:** two to four specific audiences or use cases.
- **Facts table:** pricing model and starting price, platforms, key limits, and a "last updated" date.
- **FAQ:** five to eight real questions (from support, sales calls, launch comments; ask me for them) with direct answers that make sense on their own, starting with the answer.

### 3. Mark them up

Add `FAQPage` JSON-LD that matches the visible questions and answers exactly, and make headings real `<h2>`/`<h3>` elements. Use the existing structured data helper if there is one.

### 4. Write for quoting

Short sentences, the subject named in each answer ("Acme costs $9 a month", not "It costs $9"), numbers with units and dates, no claims the page cannot back up. Show me every new sentence before it goes live.

## Done means

- [ ] Each chosen page opens with a one-sentence definition in the HTML.
- [ ] Each has a who-it-is-for block, a facts table with a date, and an FAQ of real questions.
- [ ] FAQPage JSON-LD matches the visible FAQ word for word.
- [ ] I have approved every new sentence.

## Report back

When you finish, give me:

- what you changed, file by file;
- anything you skipped, and why;
- anything I must do by hand (DNS records, dashboards, accounts, deploys);
- how to check each change on the live site.