Writing a prompt that produces a better first draft
Here is a prompt that many first drafts start from, and the reason most of them come out forgettable:
Make a website for my bakery. Modern and professional.
Everything that would make a bakery site worth visiting is missing: who it is for, what it sells, what is true about it, what it should sound like. The tool fills those gaps with averages. A better first draft is not a cleverer phrase; it is a prompt in which every gap has been closed with something real.
One note on evidence before the method. How a model responds to wording is an observed tendency, not a law, and it differs between tools and versions. Where this page cites a model vendor, it is quoting that vendor's recommendation for its own models. Treat each tip as something to test on your tool, not as a guarantee.
The anatomy of a useful prompt
Think of each element as a decision you make so the tool does not.
| Element | What to write | Why it matters |
|---|---|---|
| Audience | Who is reading, and what they want to do | Sets vocabulary and what to put first |
| Offer | One plain sentence on what you provide | Prevents vague "solutions" language |
| Facts | A list of verified details the draft may use | Boundaries invention |
| Tone | Three adjectives, plus a sample sentence | Adjectives alone are interpreted loosely |
| Structure | Pages or sections, in order | Gives the layout a spine |
| Constraints | Length, reading level, language, banned words | Makes output easy to review |
| Examples | A short passage you like and why | Anchors voice |
| Exclusions | What must not appear, stated as what to do instead where you can | Removes the usual padding |
Audience
Name a specific reader and the job they are trying to do: "someone in the neighbourhood who wants to order a birthday cake for next week and needs to know the lead time, sizes and how to pay". A stated task gives the copy a reason to be concrete. Anthropic's prompting guide offers a test that fits here: show your prompt to a colleague with minimal context on the task and ask them to follow it. If they would be confused, it advises, the model will be too.
Offer
One sentence a stranger could repeat. If you cannot write it, no tool can. "We bake sourdough loaves and celebration cakes to order, for pickup only" is something a draft can build on. "Delicious baked goods for every occasion" is not.
Facts, and a rule about missing ones
This is the part that changes the draft most. Give a list of facts and a rule:
Use only the facts below. If a sentence needs a detail that is not
listed (hours, address, awards, dates, names), write
[CONFIRM: what is missing] instead of inventing it.
The rule turns invention into a visible marker you can search for before publishing. It is consistent with Anthropic's hallucination guidance, which lists giving the model explicit permission to admit uncertainty as a basic technique. It will not make the tool perfectly obedient, so the list still has to be read against the draft, but it shifts the failure from "plausible and wrong" to "obviously unfinished".
Tone
"Warm but plain" can be read many ways. Add a sample sentence in the voice you want and one you do not: "We bake in small batches, so order early. Not: We are passionate about delivering exceptional baked experiences."
Examples carry weight. Anthropic describes examples as one of the most reliable ways to steer format, tone and structure, and suggests including 3 to 5 that are relevant to your use case and varied enough that the model does not copy an accidental pattern. OpenAI's guide likewise recommends a diverse range of inputs with the desired outputs. For a website draft, two or three short passages in the voice you want are usually enough, and they must be passages you have the right to use.
Constraints
Make the output checkable. Examples: "Home page hero headline under 10 words", "no sentence over 25 words", "Grade 8 reading level", "Canadian spelling", "no exclamation marks". Plain wording also serves readers: the W3C accessibility guidance on writing recommends simple language and formatting suited to the context, descriptive headings, and meaningful link text that avoids phrases such as "click here" and "read more".
A constraint you cannot check is a wish. Word limits and punctuation rules can be checked in seconds with a few lines of shell, so check them instead of trusting the tool's claim that it complied. Save the draft as draft.txt with the headline on line one and run:
head -n 1 draft.txt | awk '{ if (NF >= 10) print "headline has " NF " words (limit: under 10)" }'
tail -n +2 draft.txt | tr '\n' ' ' | sed 's/\([.!?]\) /\1\n/g' | awk 'NF > 22 { print "sentence of " NF " words" }'
grep -n '!' draft.txt
grep -c 'CONFIRM' draft.txt
Run on a fictional draft whose second paragraph ran long and ended with an exclamation mark, the checks printed: one sentence of 29 words, one exclamation mark on line 2, and one open CONFIRM marker. The headline passed. That is three concrete edits for the next round instead of a vague sense that the copy is "a bit wordy". The counts are crude (they split on punctuation followed by a space, so abbreviations confuse them), but they are enough to catch an obvious breach.
Exclusions
List what the draft should leave out. Typical ones: superlatives you cannot prove ("best", "award-winning"), invented testimonials, stock phrases ("your trusted partner"), competitor names, and any claim about health or safety you have not verified.
Anthropic's guidance adds a refinement: tell the model what to do instead of what not to do, for example asking for smoothly flowing prose paragraphs rather than saying "do not use markdown". Applied to a site draft, convert an exclusion into an instruction wherever you can:
| Exclusion as written | Instruction instead |
|---|---|
| No superlatives | Describe each product by its ingredients and how it is made |
| No invented testimonials | Leave the testimonials section empty with a [CONFIRM] marker |
| No stock phrases | Write each sentence so it could only be about this bakery |
| No history claims | Leave the history section out until facts are supplied |
Keep the plain exclusion for things with no positive form, such as competitor names, and treat the table as a starting point to test.
A fictional before and after
Everything here is fictional: the business, the people and the facts.
Before
Make a website for my bakery. Modern and professional.
After
Audience: people in the neighbourhood who want to order a loaf or a cake
for pickup and need to know how far ahead to order.
Offer: Harbour Bakery bakes sourdough and celebration cakes to order.
Pickup only. (Fictional business.)
Facts you may use:
- Sourdough loaves: plain, rye, seeded.
- Cakes in three sizes, ordered at least 3 days ahead.
- Ordering by the form on the contact page.
- Located on Example Street.
Use only these facts. For anything else you need (hours, awards,
dates, contact details), write [CONFIRM: ...] instead of inventing it.
Tone: warm, plain, brief. Sounds like: "We bake in small batches, so
order early." Does not sound like: "We are passionate about delivering
exceptional baked experiences."
Structure: Home (headline, 2-sentence intro, three product cards, order
button), Menu, Order, Contact.
Constraints: Canadian spelling. No sentence over 22 words. Headline under
10 words. No exclamation marks. Leave alt text for images as
[CONFIRM: describe the real photo].
Leave out: superlatives, testimonials, claims about history, any
competitor comparison.
What to expect from the second prompt, and what to check:
- The structure follows your page list rather than the tool's guess.
- Missing facts appear as visible
[CONFIRM: ...]markers. Resolve each one with a real answer or delete the sentence. - The tone should be closer to the sample sentence, but check each paragraph against it.
- Nothing is promised about quality. The draft is still a draft, and the review in what an AI website builder can and cannot do still applies.
Iterate in diffs, not rewrites
Regenerating the whole site every time is the quickest way to lose the parts you liked. OpenAI's guide notes that generated content is non-deterministic, which is one reason a full rerun can drop a sentence you were happy with, and that different model snapshots can respond differently to the same prompt. It recommends tests and evaluations that measure prompt behaviour as you iterate. For a website draft the equivalent is small: a checklist you run on every version. Treat each round as a small, named change.
- Read the draft against your facts and tone sample. Mark each problem as one of: false, vague, off-voice, too long, missing.
- Fix inputs before outputs. If copy is vague, the cause is usually a thin fact list. Add specifics, not adjectives.
- Ask for one change at a time, and name the part. "Rewrite only the Home intro: keep the headline and cards unchanged. Make it two sentences and mention the three-day lead time."
- Tell it what to preserve. "Do not change the Menu section."
- Keep a log. Save each version of the prompt and the draft it produced. When a change makes things worse, you can go back to the last good prompt instead of guessing.
| Problem you see | Likely cause | Change to the prompt |
|---|---|---|
| Interchangeable copy | Few concrete facts | Add two specific details per section |
| Wrong voice | Adjectives only | Add a sample sentence and a counter-example |
| Rambling intro | No length limit | Add a word or sentence cap |
| Invented details | No facts rule | Add the use-only-these-facts rule |
| Repeated phrases | Many sections with the same job | Give each section a different purpose |
| Headings that say nothing | No heading rule | Ask for headings that describe the content below them |
When a change helps one section and breaks another
A common surprise: you tighten the intro and the tool also shortens the menu descriptions you liked. The cause is usually an instruction phrased globally ("make it shorter") when you meant one section. Diagnose it by diffing the two drafts with a plain text comparison (diff draft-v2.txt draft-v3.txt), which shows exactly which lines moved. Then restate the instruction with the section name and an explicit "leave everything else as it is". If the tool keeps drifting, paste only the section you want changed, with its neighbours as read-only context.
Prompts for the small stuff
The same anatomy works for metadata and image text, which are easy to forget and often show up in search results:
- Titles and descriptions. Ask for one title and one description per page, each unique, each stating what the page contains, with no keyword repetition, then edit them yourself. See titles, descriptions and snippets.
- Alt text. Do not ask the tool to guess from a filename. Give it the purpose of the image and write or review the result. Google's guidance on generative AI says the review should cover metadata like title elements, meta descriptions, structured data and image alt text, not only visible copy.
- Project or service entries. State what it is, who it is for and one fact you can honestly give, as in a work page that explains itself in ten seconds.
What not to paste
Do not put anything into a prompt that you would not be willing to have stored under the tool's terms: customers' personal information, private contracts, passwords, or unreleased details belonging to someone else. Check what the tool does with your inputs before you rely on it for sensitive material.
Why this is worth the effort
Google's guidance on helpful content asks whether content provides original information, reporting, research or analysis, and whether someone reading it will leave feeling they have learned enough about the topic. It also asks whether you are using extensive automation to produce content on many topics. A draft built from your real facts has a chance with those questions, because the substance came from you; a draft built from a vague prompt has none, because there was no substance to start from. The tool saves time on wording and layout. The knowledge has to come from you.
Checklist
- Name the audience and the task they want to complete.
- State the offer in one sentence a stranger could repeat.
- List the facts, and tell the tool to mark anything else as
[CONFIRM: ...]. - Give a tone sample and a counter-example, plus constraints you can measure.
- Change one named part per round and keep a log of prompts and drafts.
Questions and answers
How long should a prompt for a website draft be?
As long as it takes to state your facts, audience, tone and limits, which is usually a few short paragraphs or a structured list. Length is not the goal; every line should remove a guess the tool would otherwise make.
How do I stop the tool inventing details?
List the facts it may use and tell it to write a visible placeholder wherever a needed detail is missing. Anthropic's guidance also recommends giving a model explicit permission to say it does not know. Then check every sentence against your list, because no wording guarantees obedience.
Should I paste in examples of writing I like?
Yes, short ones that you wrote or have the right to use, with a note on what you like about them. Vendor guidance describes examples as one of the most reliable ways to steer tone and format. Do not paste a competitor's copy to be imitated.
Why does the second draft sometimes get worse?
Generated text is not deterministic, and rewriting from scratch re-rolls everything. Ask for specific changes to named parts and tell the tool what to keep unchanged.
Sources
- Creating helpful, reliable, people-first content (Google Search Central) developers.google.com
- Google Search's guidance on using generative AI content developers.google.com
- Writing for Web Accessibility (W3C WAI) w3.org
- Prompting best practices (Claude Platform Docs) platform.claude.com
- Prompt engineering (OpenAI API docs) developers.openai.com