Build a Landing Page

A landing page is the most common first build. You describe the page in plain English, and your AI composes it section by section, binds everything to your design system, and checks the live render before handing it back. This guide walks the full path from a fresh design system to a published page.

Before you start

A landing page build needs a few things in place. Most of these are one-time. Once your design system is ready, you can build as many pages as you want without repeating the setup.

• An active BuildPress license (Solo, Team, or Agency).
• MCP connected and set to Read + Write so your AI can build, not just read. Set this at WordPress Admin -> BuildPress -> Connection.
• A base builder chosen (the BuildPress Builder or Elementor). You pick this during onboarding and can change it later in Settings.
• A design system that is ready. Every page build stops and routes you to set this up first if it is not. See Design System for the full model.

Build it step by step

1. 1

   Set up the design system once

   Your AI runs one purpose-fit interview, then writes your tokens and reports back every color and typography style it created. Give it a brand, color and type references, and a couple of sites you like so the result fits your direction. A calm SaaS and an editorial site do not get the same scale, so the references matter. You only do this once per project.

2. 2

   Describe the page

   List the sections you want and ask for placeholder copy so you have something real to react to. Be specific about the hero and the call to action. If your ask is vague, your AI asks a few scope questions first (who the page is for, what it should make the visitor do) before it builds anything.

3. 3

   Your AI composes the page widget-first

   It lists the widgets already in your library, maps each section to reuse-or-create, then creates the page as a draft. Each section is built as a token-bound BuildPress widget, never raw hardcoded hex or px, and your AI verifies each section's live render as it goes. An empty library on a fresh project is normal: it just means your AI creates the widgets now.

4. 4

   Review the verification report

   Your AI runs a final render check and reports what it built: which sections it reused versus created, any warnings, and any manual steps left for you. It hands back an edit URL and a preview URL so you can open the draft and look before anything goes live.

5. 5

   Refine or publish

   Iterate in plain English until the page is right, then publish on your explicit confirmation. Pages stay drafts until you say so. Nothing is published unless you ask.

Step 1: set up the design system

Tell your AI about the brand, then point it at references. The more concrete you are about color, type, and sites you admire, the closer the first pass lands. Here is a prompt you can adapt:

Your AI applies the tokens to the central design store, then reports back every color (name and value) and typography style (name and size per breakpoint). If you already have tokens, it offers Keep, Extend, or Replace instead of overwriting them. To pull tokens straight from a Figma file or scan an existing site, see Design System.

Step 2: describe the page

Spell out the sections and ask for placeholder copy. A clear, sectioned request skips the scope interview and goes straight to building:

Step 3: how your AI composes the page

Builds are widget-first by default. Instead of dropping loose generic elements onto a canvas, your AI builds the page from named, reusable, design-system-bound blocks. For each section it either reuses a library widget that genuinely matches or creates a new BuildPress widget from BuildPress's own blueprints. The flow looks like this:

1. Lists the widgets already in your library.
2. Maps each section to reuse-or-create.
3. Creates the page as a draft.
4. Builds each section as a token-bound BuildPress widget, with every color and typography bound to your kit globals.
5. Verifies each section against the live render, then moves to the next. See render verification for how that check works.

Each build is held to a non-optional Design baseline: one focal point per section, a coherent spacing scale, rem-based type, a real display tier above H1, and dramatic type on the hero and closing CTA. This is what keeps pages looking designed, not generic. If you would rather assemble raw native widgets, say so explicitly (for example just use Elementor's page builder) and your AI opts out of library reuse for that build.

Step 4: review the verification report

Tool-call success is never treated as a working page. After the last section, your AI runs a final render check and reports back. A typical report includes:

• Each section with a pass, warn, or fail line.
• Which sections were reused from your library versus created new.
• Any manual steps left for you.
• An edit URL to open the draft in the builder and a preview URL to see the live render.

Step 5: refine or publish

Open the preview, then iterate in plain English. Token edits re-theme everything bound to them, so small changes ripple cleanly. Some prompts you can paste:

Your AI applies each change, re-verifies the render, and reports back. The page stays a draft until you explicitly tell it to publish.

Optional: add a touch of motion

Once the page reads well, a little motion can sharpen the hero. Ask for something specific and restrained:

For what GSAP can do and how to enable it, see GSAP.