How to Write a Good Prompt for a Website: Four Blocks

Answer four questions in the prompt: what you are building, who it is for, which sections it contains, and the one action a visitor should take. Those four blocks turn a vague request into a specific brief, and the difference shows up immediately in how much editing the first draft needs.

Everything else people put in prompts, adjectives, frameworks, colour theories, matters far less than those four. This is what each block looks like in practice and what to leave out.

What are the four blocks of a good prompt?

Type, audience, structure, action. Each one removes a category of guesswork, and a prompt missing any of them hands that decision to inference.

Type is the shape of the thing: a landing page, a multi-page site, a small app with a database, a 2D browser game. This decides how the build is planned, so it belongs in the first sentence rather than being implied.

Audience is who reads it. "For homeowners who just had a leak" produces different copy from "for property managers", even when the business is the same plumber. Naming the reader is the single cheapest upgrade to any prompt.

Structure is the list of sections or pages. Four named sections beat any amount of description, because they convert an abstract request into a checklist the build can satisfy and you can verify.

Action is what one visitor should do: call, book, buy, sign up, download. A page with three equal calls to action has none, and stating the priority in the prompt prevents that outcome rather than fixing it later.

Together they take two minutes to write and typically halve the number of edits afterwards. Given that an edit costs 3 credits and a fresh build costs 6, those two minutes are the highest-return part of the whole process.

What does a weak prompt look like next to a specific one?

The same request at three levels of specificity, with what actually changes in the output.

The third row is not longer because longer is better. It is longer because it contains decisions, and every decision you make is a decision the model does not have to invent.

Notice what the third prompt does not say. It does not name a colour palette, a font, a framework or a layout style. Those are either offered as choices during the build or adjusted afterwards in seconds, and spending prompt space on them displaces the information only you have.

What should you leave out of the prompt?

Three categories, all of which crowd out useful detail.

Technology. Naming a framework or a stack does not improve the output and takes room from your audience and structure. The build produces real source code that exports to a GitHub repository you own, so the technical shape is already settled.

Adjectives without referents. "Modern", "clean", "professional" and "premium" describe nearly every site ever made and constrain nothing. If a visual direction genuinely matters, one concrete comparison does more work than five adjectives.

Everything at once. A first prompt containing fifteen features returns fifteen half-implemented features. Build the core, look at it, then add the rest as edits against something real. This is also cheaper, because you stop paying to generate parts you turn out not to want.

The general principle: put your specific knowledge in the prompt and leave general knowledge out. You know your customers, your objections, your prices and your pages. The model already knows what a navigation bar is.

How do you prompt an app rather than a page?

Name the nouns of your domain instead of naming the category. "Build a CRM" is a category; "a client tracker for a tutor, with a student card holding lessons and payments, a week view, and a mark-lesson-complete button" is a specification.

Say explicitly whether people sign in. Whether users have accounts changes the whole shape of an app, and it decides whether you need a connector like Supabase for the database, login and file storage. Leaving it implicit is the most expensive omission in app prompts.

Say what data each screen shows and what each screen can change. Reads and writes are the two things an app does, and describing them in your own vocabulary is more useful than any architectural instruction.

Then accept that the unusual parts arrive through iteration. Very specific business logic, awkward permission rules and edge cases in your own workflow come from follow-up edits rather than from one perfect paragraph. Multi-page platforms take a few minutes to generate and several rounds to get right, which is discussed in how long it takes.

How do you prompt a game?

Describe the loop, then the numbers you want to feel. A game is not a document, so the useful detail is what the player does over and over, what makes it harder, and how a run ends.

"An endless runner where a cat jumps over crates, speed increases every twenty seconds, one hit ends the run, score is distance travelled" is a complete brief. It names the verb, the failure condition, the difficulty curve and the score, which is everything the first build needs.

Say the game must be playable by touch if you want it on a phone, because keyboard controls that work on a laptop do nothing on a handset. Zugo games are 2D and run in the browser, which is a real boundary and also the reason they are playable within a minute of the build finishing.

Then tune by playing. Jump height, spawn rate and difficulty are numbers nobody can judge by reading, and adjusting them one at a time is the enjoyable hour that turns a working game into a fun one.

What do you do when the first build is wrong?

Change one thing at a time. A rewritten prompt produces a different site rather than a corrected one, and you lose the parts that were already right along with the parts that were not.

Be concrete about the fix. "Make it better" is not actionable; "replace the hero headline with 'Same-day leak repair in Bristol' and move the phone number above the fold" is. The clearer the edit, the more likely one edit is enough, which matters when each one costs 3 credits.

Fix content before layout. Most disappointment with a first draft is really disappointment with placeholder copy, and once the real words are in, half the layout complaints disappear on their own.

Keep the prompt that worked. The four-block description is reusable for the next project and for the next person you explain this to, and it is the part of the process that improves with practice. The step after the draft is covered in how to edit after generation, and if you want to check the arithmetic on what all this costs first, see is an AI website builder really free.

Write your four blocks in a notebook before you open anything. Then paste them in at zugo.dev and see how much closer the first draft lands.