Cursor and WordPress usually means one thing: an editor with an AI in it, pointed at a theme or plugin folder, writing PHP. That is a fine way to build a plugin. It is a slow way to build a site, because the site is not in the folder. It is in the database, in templates, in a design system, in menus and plugin settings.
With an MCP connection, Cursor’s agent can work on the site itself. This walkthrough uses Delta, a theme with the MCP server built in, so the agent in Cursor creates pages, templates and design tokens directly. The folder is still useful: it holds the brief, the copy and the references, and the agent reads those alongside the site. You end up using Cursor for what it is good at (files, context, iteration) without writing a line of theme code.
Set up the project
Make an empty folder and open it in Cursor. Put three things in it:
brief.md: who the site is for, what it must do, the look in a few adjectives, the pages you know you need, anything you already have (logo, colours, a site you admire).content/: one Markdown file per page, even if half of them are a heading and a TODO.refs/: screenshots or images the design should take cues from.
This folder is yours. It can live in git. The site’s own rules for the agent live on the site, which we come back to.
Connect Cursor to the site
On a WordPress site with Delta active (staging, or a local site such as mysite.test; Cursor connects from your machine, so both work), open Delta → Connect as an administrator and pick the Cursor tab. Connect in Cursor opens Cursor with the server prefilled. Confirm, then sign in from Cursor’s MCP settings: a browser tab opens on your WordPress login and you approve. If you would rather see the file, this is all it is:
{
"mcpServers": {
"delta-example-com": {
"url": "https://example.com/wp-json/21press-delta/mcp"
}
}
}Put it in .cursor/mcp.json in the project to scope it to this folder, or in ~/.cursor/mcp.json for every project. The Cursor connection guide has the Application Password variant and the fixes for a server that stays red.
The first conversation
Open the agent chat and ask it to look before it builds:
Look at delta-example-com and tell me what's there. Then read brief.md and tell me what you'd build first.The agent reads Delta’s briefing, inspects the design system and reports. On a fresh site it will tell you there are seed tokens and no templates, and it should propose the order a careful builder would: design system first, then header and footer, then page templates, then pages. If it proposes building the homepage first, tell it no; everything later depends on the tokens.
Design system from the brief
Create the design system from brief.md and the images in refs/. Propose two directions on a Sketchbook board first; don't change tokens until I pick one.Cursor’s agent can see the images in the folder, which makes the brief richer than text alone. Delta’s Sketchbook is where it draws the two directions, on the site but off the live pages. Pick one, and the agent writes the tokens and the notes that describe the look. From here on, every page it builds uses var(--…) tokens rather than raw values. That is a rule in the briefing the agent reads before it works, and the conformance check recipe audits the site against it whenever you ask.
Templates, pages, content
Build the header, footer and default page template, then create one page per file in content/, using each file's text. Build the menu from the brief. Link me to each page when you're done.This is where the folder pays off. The agent reads the Markdown, builds each page as plain HTML, CSS and JavaScript against the tokens, and reports with links. Edit a content file, say “update the About page from content/about.md”, and the page follows. Copy stays in files you can diff; layout stays on the site.
A content type (“add a Projects type with a client, a year and a sector taxonomy, with archive and single templates”), a form, SEO metadata and redirects work the same way: Delta drives the plugin that owns each job through that plugin’s own abilities, so the form is a real form in your form plugin’s admin. Installing a plugin waits for your approval.
Rules: Cursor’s and the site’s
Cursor has project rules in .cursor/rules. Delta has skills and rules on the site. Keep them separate on purpose:
- Cursor rules are about how you work in this folder: “always read brief.md first”, “copy lives in content/, never write copy directly into a page”.
- Site rules are about the site: “no gradients”, “headings in sentence case”, “every page needs a meta description”. They apply to any client that connects, so when a colleague uses Claude Desktop on the same site, the same rules hold.
When you correct the agent about the site twice, ask it to add the correction to the site’s rules. When you correct it about your workflow, add a Cursor rule.
Review on the live site, not in the chat
Keep the site open in a browser beside Cursor. The agent’s summary tells you what it believes it did; the page tells you what happened. Delta’s Front panel lets you click an element on the live page and send it to the agent as “this one”, which is faster than describing a box in prose. Take a snapshot before a redesign (“snapshot the site as before-nav-change”) so a wrong turn is one restore.
When you do want code
Sometimes a site needs a small script or a stylesheet rule the agent should not improvise. Write it in the folder, review it in Cursor’s diff view, and ask the agent to add it to the site’s JS or CSS through Delta. You get Cursor’s code tooling where code is involved and the agent’s site tooling everywhere else. That split, rather than any one prompt, is what makes Cursor a good place to build a WordPress site.
If you work in the terminal rather than an editor, the same build runs in Claude Code. The site, and its rules, are the same either way.
