How to Prompt Claude for a Website That Ships First Try

The five blocks, in order

Open a chat, type "build me a website for my consulting business," and a page comes back in under a minute. It is not a bad page. It is the average page, because the average is the only thing the message asked for. Nothing in that sentence said who reads it, what it has to claim, or what counts as finished.

The fix is not a longer prompt. It is a prompt with parts. Five labelled blocks in a fixed order produce something you can host, and the reason is mechanical rather than magical: each block removes a decision the model would otherwise invent, and invented decisions are what you spend the rest of the afternoon undoing.

I use plain headings inside the message. Literal lines reading MATERIAL, JOB, SHAPE, DO NOT, and ASK. XML tags do the same job and Anthropic's documentation prefers them once several documents are involved, but the labels matter more than the syntax.

Why the order inside the message matters

Putting the long material first is not a stylistic habit. Anthropic's prompting guidance says to place long documents and inputs near the top of the prompt, above the query, instructions and examples, and reports that queries at the end improved response quality by up to 30 percent in their tests on complex multi document inputs.

That maps onto a website build without much translation. Your copy, your product facts and any page you are using as a structural reference are the documents. The build request is the query. Open with "build me a landing page" and then paste eight hundred words of copy underneath, and you have handed over the instruction before the model has read the thing the instruction applies to.

Ordering also decides what survives a long message. The last instruction is the one the model is holding when it starts producing output, which is why a constraint buried in paragraph two gets quietly dropped and the same constraint restated in the closing line does not.

Block one: the material, pasted in whole

Material means anything the model would otherwise guess at. The offer, the price, the name of the thing, the copy if you have it, a URL whose section order you want borrowed.

Paste it in full. Summarizing your own copy before handing it over is the most common self inflicted wound in this process, because the summary is what the page gets built from. If the hero line matters, the hero line goes into the message word for word, not as "something about saving people time".

With a reference page, say which property you want taken from it. "Use the section order from this page, not the colours or the typeface" is actionable. "Make it like this site" is not, because it leaves the model choosing which properties to copy, and it tends to copy the surface ones.

Block two: the reader and the single action

Two sentences. Who lands here, and what you want them to do before they leave.

This block does more work than its length suggests. A page for someone who has never heard of you opens differently from a page for someone who just clicked a link in your newsletter. A page with one button behaves differently from a page with a button, a newsletter box and a pricing table, and you will get all three unless you say otherwise.

Anthropic's guidance frames this as supplying the reason behind an instruction rather than the instruction alone, noting that the model can generalize from the explanation. In practice, "visitors arrive cold from a search result, so the first screen has to say what this is" beats "write a good hero section", and it keeps working on the fifth revision instead of needing restating.

Block three: shape, not adjectives

Modern. Clean. Professional. Minimal. Each of those has a referent in your head and none in the message. The model resolves them to the statistical centre of everything ever described that way, which is the gradient hero, the three feature cards and the pastel illustration of a person at a laptop.

Replace adjectives with two things a model can act on: an ordered list of sections, and measurements.

Sections first. "Hero, then the three objections, then proof, then pricing, then one FAQ block, then footer" is a layout. It can be built, and you can check it without opening a browser. Then measurements for anything you actually care about: body text at 18px, one accent colour given as a hex value, one typeface, content width capped around 700px.

Which sections you leave out matters as much as which ones you list. Skip the scope fence and you get a testimonial block with three invented people in it. Once you are building more than one page, these values belong in a standing spec file the model reads every time rather than in each message.

Block four: every fence needs a replacement

Negative instructions work poorly on their own. "No gradients" leaves a hole, and holes get filled with whatever is most common, which is often a close neighbour of the thing you banned.

Pair each ban with the thing that takes its place. Not "no stock photography" but "no photographs, use flat colour blocks". Not "don't write marketing fluff" but "every sentence states a fact, a price or an instruction". Anthropic's documentation makes the same point in general terms: say what to do rather than what to avoid.

My standing list for a landing page runs about six lines. No invented testimonials, logos or customer names. No figures I did not supply. No icon font, no image CDN, no analytics. Flat background, no hero gradient. No em dashes. No sections beyond the ones listed in SHAPE.

Block five: the ask goes last and names the artifact

The final block is one or two lines, and it is the only part of the message that is an instruction.

Name the artifact exactly: one self contained HTML file, CSS inline, no build step, no package installs, no external requests except a fonts link. Name what you do not want back as well: no explanation above the file, no summary of changes underneath it. Both are small. Both are the difference between copying a file and fishing one out of a wall of commentary.

Saying what you will do with the output changes the output. "I am going to drag this file into a browser and then onto a host, so it has to run from the filesystem with no server" rules out a whole category of answers that would otherwise look reasonable. The step by step build walkthrough covers what happens to that file once it exists.

The acceptance test is one more line

Add a line telling the model how you are going to check the work, before it writes anything.

Something close to: "Before you output the file, confirm every heading uses copy from the MATERIAL block, no section exists that is not in the SHAPE list, and no number appears that I did not give you." That sentence catches the two failures that otherwise reach the browser, which are invented content and extra sections.

It is a filter, not a guarantee. It runs before you spend attention on the output and it costs one line of the message, which is a good trade. The scored self audit is the slower version of the same instinct, run against a site that already exists.

Message two has a different shape

Everything above is for the first message. Edits need the opposite: short, surgical, anchored to text that is already on the page.

An edit prompt has three parts. The exact string you want changed, quoted. The change. A fence naming what must not move. "Replace the line that reads 'Built for busy founders' with 'For people who already know what they are selling'. Do not touch the layout, the spacing or any other section."

Without that third part you get a redesign nobody asked for, because an open request reads as permission to improve the file. Describing the change without quoting the original is worse, since the model then has to work out which line you meant and will regularly pick a different one.

One change per message. Two changes in one message and you cannot tell which instruction caused the regression, and there will be a regression eventually.

Where this structure stops helping

A well formed prompt cannot decide what your business does. Vague offer, vague page, and no amount of structure in the message repairs that. The prompt is a transmission mechanism, not a thinking aid.

It will not rescue weak copy either. Your words get reproduced faithfully and the page reads exactly as well as the text you pasted in, which is the argument for settling the copy separately before any of this starts.

And it does not survive drift. Fifteen messages into a session, the original fences sit far enough back that they stop binding reliably. The repair is to restate the fences in the current message rather than trusting the history, or to open a fresh chat with the material block and the current file.

None of this is clever. It is a checklist for the inside of one message: material at the top, job, shape, fences, ask at the bottom. The first version takes ten minutes to write and most of that is deciding things you were going to have to decide anyway.

What comes back is not a perfect page. It is a page with your words in it, the sections you asked for, nothing invented, and a structure you can edit one line at a time. That beats forty messages of negotiation by a wide margin.

Common questions

How long should a prompt for a website be?

Long enough to carry the material and short enough that every line is doing work. A first build request with the copy pasted in usually runs 400 to 800 words, most of which is your own text rather than instructions. The instruction portion is rarely more than fifteen lines.

Should I paste my copy in or ask Claude to write it?

Paste it in if you have it. Copy written inside a page build request gets optimized for the layout instead of the reader, and you end up editing prose inside HTML tags. Settle the words as plain text in a separate conversation first, then hand the finished text to the build request as material.

Why does Claude ignore part of my prompt?

Usually because the instruction sat in the middle of a long message. The beginning and the end of a prompt carry the most weight, so a constraint buried in paragraph three competes with everything written after it. Move constraints into the final block, and restate them once a session runs long.

Do I need XML tags, or will plain labels work?

Plain capitalised labels are enough for a single page build. Anthropic's documentation recommends XML tags once you are passing several documents inside one prompt, since the tags make each document boundary unambiguous. For one page with one set of copy, labelled sections do the same job.

What is the single highest leverage line to add?

The output contract: one self contained HTML file, CSS inline, no build step, no external requests, and no explanation above or below it. That line decides whether you can deploy the result by dragging it into a browser window or have to reassemble it from a chat reply first.