SEO decided at the page plan, before anything is designed
Quietly derives the section list for a page from real search demand, then generates against it. The optimization work happens where the structure is decided, which is the only place it can still change the structure.
Proof in the workflow
Sections carry their evidence
The page plan names, per section, the keyword volume, search intent, community question or Search Console query that put it there. You can argue with the plan before a layout exists.
The plan outlives the first build
It is stored on the project and injected into every later build call, so iterating on copy or design does not quietly dissolve the structure the research justified.
The build critiques itself
Before reporting done, the model must file a critique carrying at least two weaknesses and one concrete next step. A major severity forces another pass.
What this landing is built to rank for
Demand-derived page architecture
Give it a topic and a page type. It uses the site's existing keyword research, or runs one live lookup when there is none yet, and returns a section-by-section plan with internal link targets and a JSON-LD skeleton for that page type.
A design system written for the brief
Font pairing, palette and personality are authored per brand, then constrained by a modular type scale, an 8-point spacing grid, AA contrast and a 45 to 75 character measure. Every section generated afterward inherits those tokens.
Reference sites read live, per category
Three to five live reference sites in your category are pulled with semantic search and their palette, layout and motion signals folded into the generation prompt.
Media and deploy in the same place
Images, short video and voiceover are generated into your media library, and one instruction ships the build to Vercel and registers the site in your account so audits and tracking can reach it.
How it works
Set the page objective
Give the topic, the page type and who it is for. That is enough for the plan step to run.
Derive the architecture
A section list comes back with the demand signal behind each entry, plus link targets and a JSON-LD skeleton, and is saved to the project.
Settle the design, then build
The system is authored from the brief, references are pulled, hero directions are offered, and sections are generated against the plan and the tokens.
Deploy and connect
Ship to Vercel from the chat. The site registers in your account, so audits, bulk meta and internal links point at the real deployment.
Best fit use cases
Launch and campaign pages
When the page has to rank as well as convert, and the section list is the decision that determines whether it can.
Agencies producing pages at volume
The plan and the design tokens are stored per project, so the fifth page for a client inherits the same system as the first.
Teams tired of the SEO cleanup pass
Metadata written after the fact can only describe the page. Structure derived from demand can still change it.
Supporting content
FAQ
Where does the SEO work actually happen?
At the plan step, before design. The builder derives the section list from keyword research, community questions and Search Console queries, and cites the signal for each section. Meta title, description, canonical, robots and a schema field are editable on the project throughout, and the plan ships a JSON-LD skeleton for the page type you chose.
Does it publish to WordPress?
No. The builder deploys to Vercel. Quietly's WordPress integration is in Content Studio, for posts, and it is separate from this builder.
What about a custom domain?
You point a CNAME at Vercel and the app verifies that it resolves. The final alias step has no API in the v0 SDK the builder runs on, so you complete it in the v0 dashboard. The domain panel says exactly that.