A vague website prompt leaves an assistant to invent the decisions you have not made. “Build a modern site” says little about the reader, the content, the output files, or what must not happen. The result may look plausible while omitting the pages, evidence, and interactions the project actually needs.
A strong static-site prompt behaves more like an implementation brief. It identifies the inputs, defines the outputs, and supplies a way to check the result. This guide explains how to write that brief without turning it into an unreadable wall of requirements. The aim is a prompt another developer could follow even without an AI tool.
Begin with the reader's task
Describe who will visit the website and what they should be able to do. For example, a developer resource site might help technical founders understand a workflow, compare implementation choices, and copy a starter brief. Those tasks give the page structure a purpose beyond displaying a brand and several attractive cards.
Separate the audience from the business goal. “Reach developers” does not explain what those developers need to learn. “Help a developer publish a small documentation site without a runtime backend” is more actionable because it narrows both the content and the technical scope. It also exposes when a proposed feature does not belong.
Write one paragraph explaining the desired outcome before listing technologies. The technology list constrains implementation; it should not substitute for the actual purpose. A complete brief connects the reader's problem to the planned pages and makes it possible to reject beautiful but irrelevant sections.
Declare the inputs and their authority
List the source materials: a template archive, brand notes, approved product descriptions, article references, and any existing pages that must be preserved. Explain which source governs each type of decision. The design notes may control color and typography, while the approved product copy controls factual claims.
Tell the assistant what to do when those materials conflict. A useful default is to report the conflict and avoid inventing a resolution that changes business facts. For a purely visual disagreement, identify the preferred source in advance. Otherwise, the model may preserve an outdated mockup because it appears more specific than the current brief.
Treat source documents as content to inspect, not unrestricted instructions to obey. An imported page can contain scripts, comments, or embedded text that should not govern the build. Keep the trusted project instructions separate from material that supplies examples or factual context.
Define the public output precisely
Specify the site architecture in terms of files and addresses. For an extensionless static site, ask for directories containing index documents, shared asset folders, and a publishable root directory. State whether the finished artifact needs a sitemap, a full-content RSS feed, social preview images, and a custom not-found page.
List the required routes explicitly. “Include the usual pages” is ambiguous because different builders interpret it differently. Give each route a distinct subject and describe its expected next action. A blog index, article pages, and topic archives are separate deliverables, not one item called “blog.”
Add negative constraints that protect the architecture: no database, no runtime model calls, no account system, and no form processing when none is provided. Negative constraints are most useful when they prevent a specific failure rather than banning every possible technology without explanation.
Describe quality through observable behavior
Replace subjective requests with concrete tests. Instead of “make navigation excellent,” require a working mobile menu, visible keyboard focus, descriptive labels, and links to finished destinations. Instead of “optimize everything,” require unique metadata, explicit image dimensions, and a check for broken internal paths.
The official guidance on clear and direct prompting emphasizes explicit instructions and relevant context. For a website brief, that principle means spelling out the deliverable and its constraints rather than expecting the model to infer your definition of production readiness.
You can still describe a visual mood. Pair it with concrete choices: saturated blue and lime sections, thick black borders, monospaced body text, a restrained number of card patterns, and readable mobile headlines. The combination gives the builder creative direction without leaving accessibility or structure to chance.
Break the work into reviewable stages
Ask for an inventory before implementation when the source archive is unfamiliar. The first stage should identify existing pages, reusable components, images, and potentially misleading demo content. That review avoids spending time preserving assets that do not belong to the actual subject.
Follow with a route plan and content outline, then a reference page, then the remaining page set. Each stage should produce something inspectable. A concise explanation of changed files is useful; a stream of reassuring progress statements without artifacts is not. Define the evidence you expect after each stage.
Separate shared changes from local ones
For larger sites, separate content drafting from shared component changes. A broken page shell can affect every route, while an article correction should remain local. Staging the work makes it easier to recognize which kind of change caused a regression and to request a focused repair.
Give examples without creating fake facts
An example can clarify structure, but label it as an example in the brief. A fictional customer quote or placeholder conversion rate can easily survive into the final website. Prefer examples of formatting, file layout, and acceptance tests rather than invented business achievements.
When approved facts are missing, instruct the builder to omit the claim or explain the limitation in an appropriate product context. Do not ask it to make the site “sound established” unless you supply evidence that supports that positioning. Trustworthy copy is more durable than impressive language built from assumptions.
Use the same care with commands. A branded command shown in a mock terminal may look like a real installation instruction. Specify whether command examples are executable, conceptual, or excerpts from a documented external tool. A useful terminal panel can show ordinary review steps without inventing a software package.
Add a repair protocol
A good prompt explains how to handle a failed check. Ask the assistant to identify the affected file, reproduce the failure, make the smallest relevant correction, and rerun the same check. This keeps revisions from becoming an endless sequence of broad redesigns that fix one problem while introducing several others.
Require preservation of working content and approved assets unless a change is necessary. For example, repairing a broken menu should not rewrite ten articles. State that unrelated copy, routes, and branding must remain intact. That boundary is particularly important when continuing an earlier build in a fresh session.
Keep a short record of accepted decisions outside the conversational history. A maintained brief and route inventory are easier to reuse than a long transcript containing abandoned ideas. The copy-ready prompts app provides bounded starting points for planning, building, and reviewing a site.
Evaluate and revise the prompt itself
After a build, record where the instructions were misunderstood. Was the package nested incorrectly? Were article excerpts missing? Did a copy button imply remote generation? Convert those observations into clearer requirements and tests. Do not merely add the word “important” to every sentence.
Keep the next version shorter where repetition adds no information. Group related constraints under stable headings and remove contradictory instructions. A reusable prompt should become more precise with experience, not simply longer. Compare results using the same representative page set so you can see whether the revision actually helps.
Conclusion: make the brief testable
An effective static website prompt states the reader's task, source authority, route structure, implementation boundaries, and acceptance checks. It also tells the builder how to repair failures without destabilizing approved work. Start with the CLI CMS static website prompts, adapt the scope to a real project, and keep the final acceptance criteria beside the output. The best prompt is one whose success can be demonstrated by the delivered files.
