AI Website Prompts: Six That End at a Live URL

Copy any of the six below into Claude or ChatGPT and you get a page. Copy the fifth and the page gets an address you can send to somebody.

That is why this list exists. Prompt collections stop at the code, which is the easy half. These are ordered the way the work goes: state the product, get the page, interrogate the vague parts, change one section without wrecking the rest, publish it, then collect remarks and fix them in the same draft.

What makes a website prompt work

Three things, all from the people who build the models.

Anthropic's prompt-engineering guidance puts specificity first: "The more specific you are about what you want, the better the results." Its list of what a working prompt carries is short: explicit instructions, context for why the thing matters, constraints, an example where format is what you care about, and permission for the model to say it is unsure instead of guessing. Lead with a verb.

OpenAI's guide for GPT-5 sounds like the opposite and is not: modern models need less scaffolding, so shorter and clearer beats longer and more elaborate. What they want up front is context. Who the model is, what it is doing, what rules it follows.

Lovable's documentation adds the website-specific part. Before you ask for pixels, answer four questions.

Every prompt below puts those answers in front of an agent in the order it can use them. Where a prompt borrows a documented pattern, it says so.

Prompt 1: the brief

Use this when the site does not exist yet and you have not decided what it says.

I want a one-page website. Before you write any code, restate my brief back to
me in four lines:

1. What this page is.
2. Who it is for.
3. Why they would read it.
4. The one action I want them to take.

Then list the sections you would build, in order, with one line each on what
that section has to accomplish. Do not write code yet. If any of my four
answers is too vague to design from, say which one and what you need.

Here is what I have: [two or three sentences about the business, the audience,
and the action].

Why this shape: the four lines are Lovable's planning questions, and the closing instruction is Anthropic's permission-for-uncertainty principle. A model allowed to say "this is too vague" will say it; one that is not will invent something plausible. The "do not write code yet" line matters more than it looks, because once there is code on screen you both start editing instead of deciding.

Prompt 2: the one-page site

Use this once the brief survives being read back to you.

Build the page we just agreed on as a single static bundle: index.html plus one
style.css, no build step, no framework, no client-side router. Everything has
to work when the files are served as-is from a static host.

Style: [two style words, for example "minimal and premium"], and specifically:
oversized headline, high contrast, one accent colour, generous whitespace,
system fonts.

Content: use the real copy from my brief. No lorem ipsum, no placeholder
company names, no stock-photo captions describing photos we do not have.

Structure, in this order: [your section list from prompt 1].

Why this shape: the style-word-plus-specifics pairing comes from Lovable's documentation, and it works because "minimal" alone is a mood while "oversized headline, one accent colour" is an instruction. The constraint block is the part people skip and the part that decides what the addresses look like: ask for a framework with client-side routing and you get an app that needs a build step, and one whose regular paths need a server to rewrite them.

The "no lorem ipsum" line saves a round. Agents fill gaps with placeholder text by default, and placeholder text hides every layout problem real copy exposes.

Prompt 3: ask me questions first

Use this when you can feel that you have underspecified something but cannot tell what.

Ask me any questions you need in order to fully understand what I want from
this page and how I envision it. Ask them all at once, numbered, then wait for
my answers before building anything.

Why this shape: the first sentence is Lovable's own clarification technique, quoted as they wrote it. "All at once, numbered" stops the drip of one question per message, and "wait before building" stops the agent answering its own questions.

The cheapest prompt on the list, and the one that most often changes the output. Expect four to eight questions, and expect at least one to be something you had not decided.

Prompt 4: change one section only

Use this after the page exists and something in the middle of it is wrong.

Change only the pricing section.

What to build: three plan cards side by side, the middle one marked as
recommended, monthly price large and the feature list small.
Where it goes: replacing the current pricing block, same position on the page.
What stays untouched: the header, the hero, the footer, style.css outside the
pricing rules, and every other section's markup.

Show me the diff for the pricing block before you apply anything else.

Why this shape: what-to-build, where-it-goes, what-stays-untouched is Lovable's boundary format, and it exists because an unbounded edit request invites a rewrite. Agents are helpful. Ask one to fix the pricing section and it will notice your header spacing on the way past.

After a few rounds of this, the pattern is worth reading on its own: re-prompting to edit is the habit, and this prompt is the shape it takes when the edit has to stay in its lane.

Prompt 5: publish it

This is the one that separates a preview from a website. Connect Birta to your agent once, then this prompt works in the same conversation that wrote the page. If your draft is sitting in a browser tab instead, such as a Gemini Canvas build, it has to come out of the panel first.

claude mcp add --transport http birta https://birta.dev/mcp

The endpoint is https://birta.dev/mcp, and the setup lives in the Claude Code guide. Then:

Publish this site through Birta.

Create a project called [name], write the files we just built into it with
write_file, create a draft version, and publish it. Then give me the version's
address.

If anything in the bundle would not be served correctly from a static host,
tell me before publishing instead of publishing it broken.

Why this shape: create_project, write_file, create_version and publish_version are the connector's actual tools, so naming them keeps the agent from improvising. create_version and publish_version each return that version's own permanent address, which is what you send somebody. It is the version's address, not the live site's, and that distinction makes the next prompt possible.

Two honest notes. A custom domain needs a Solo or Pro plan, so on the free tier your address is a Birta subdomain and the badge stays on. And the free tier is a real free tier rather than a countdown, which is a longer story in free web hosting.

Prompt 6: collect remarks and fix them in the same draft

Nobody else's prompt list has this one, because it needs somewhere for the remarks to live.

Send me the version address to share with my client.

After they have marked it up, read their remarks with list_version_comments,
make each change in this same draft, and publish a new version. Tell me which
thread numbers you addressed and which ones you could not.

Why this shape: the person you send the link to needs no account. Version access defaults to a link, the guest gets a nickname, and they mark remarks straight onto the page, pinned to the element they mean. Your agent reads those threads by number, with author and time on each message, and numbers are permanent so a remark can be named later.

One limit before you promise anything: the agent reads remarks and cannot reply in the thread. The comments endpoint refuses agent writes, and it cannot mark a thread resolved either. So the loop is "they mark, the agent fixes, you resolve," and anyone whose agent holds the conversation is describing something else.

Remarks trigger an email digest roughly fifteen minutes after the first, to everyone with project access, minus their own. The walkthrough is in version comments.

What these prompts will not get you

The output is static. Not a limitation of the prompts, the shape of what they produce, and worth knowing before you spend an afternoon.

The routing line in the prompts is about what a search engine indexes, not about what publishes. A single-page app can be published. Its in-app navigation has to run through #: with regular paths, opening or refreshing any path other than the root returns “page not found”. The prompts ask for one file per page because that is what a search engine indexes as a page of its own, which an address after # does not get.

If you need an app with accounts and a database, no prompt will make this the answer. If you need a page that says the right thing and can be sent to somebody today, the six above are the whole path.

Frequently asked questions