WordPress vs Opus: build the site you need

Have Claude Opus build the site. Add a CMS only if someone actually needs an editor. That's my recommendation over starting with WordPress. Needing a Publish button means someone needs to publish, not that the whole website has to be built a particular way.

For a business that changes a few pages occasionally, ask the agent to make the changes. For a team publishing regularly, have it build a focused publishing interface with Payload, following Path B of this guide.

The design should belong to the business. The editor should fit the people using it. I don't want either decision made by habit.

Separate the website from the job of publishing

A website has at least two different jobs. It has to make sense to visitors, and it may have to let staff change the content. Those jobs do not need the same interface.

Suppose you run a small arts venue. Visitors need dates, useful event descriptions, accessibility information and a way to book. The person adding events needs fields for the title, image, start time, venue and booking link. They don't need to design a new web page every Tuesday.

Have Opus design the public site around the visitor. Then have it build the editor around the event. That's the approach I recommend: a custom presentation with deliberately ordinary forms behind it.

The alternative isn't incapable. WordPress has publishing tools, revisions, user roles, themes and plugins. You can build excellent things with it. My objection is to choosing it before you've worked out what this particular site needs.

When an agent can build the implementation, “that's the system everyone uses” stops being a convincing brief.

First, see how much software you can leave out

If you change your opening hours twice a year, you may not need a CMS at all. Ask Opus to update them and show you the preview. Keep the content in files, with the rest of the project in your GitHub account.

That leaves out an editing interface you would otherwise have to configure, teach and maintain. You haven't lost the ability to change the site. You've chosen a different way to request the change.

Claude Code works on project files and can run commands. In this guide, Opus is the model you use to do that work. The practical unit is a request: change a service, add a case study, make the contact page clearer. The agent implements it; you check it.

For a mostly stable business site, this is where I'd stop. Path A gets you the site without adding an admin panel simply because admin panels are traditional.

If you need an editor, build the right one

A staff member posting weekly news is a good reason for a CMS. A volunteer updating events is another. Those people should not need an agent session for every date correction.

So give them fields for their content. Make the ordinary jobs easy, and keep design changes out of the ordinary jobs.

This is the point of Path B. The agent builds the site and the CMS together. You don't have to find a theme that almost fits, then make the business's content fit the theme's idea of a page.

The guide chooses Payload. Its documented capabilities include drafts and versions and live preview. Opus still has to configure those properly. Put them in the brief, then ask to see them work with an ordinary editor account.

Save a draft. Preview it. Publish it. Restore a previous version. Have the actual editor try it. A handsome admin screenshot isn't a handover.

Let the site grow through requests, not workarounds

Six months later, the venue starts offering workshops. An event now needs an age range, a materials list and a different booking message.

With your own project, you can ask Opus to change the content model, editor and public pages together. The requirement is the starting point. The agent works out the files and implementation steps.

That doesn't mean every request is trivial. It means you don't need to decide in advance which combination of general-purpose tools might approximate the request. You can commission the specific feature, review its scope and test the result.

WordPress can be extended with plugins and custom code too. The advantage I want here is a coherent project built around the business, with the agent doing the implementation and the source in your account. I would choose that deliberately rather than assemble a larger system by default.

Keep content separate from presentation, document the design direction and have changes made on a preview first. Those are instructions for the build, not magic properties of the word “AI”. The after-launch chapter explains how to keep working this way.

Free software isn't the deciding argument

WordPress.org is free, open-source software. Paid themes and plugins are optional. WordPress.com is a managed service with its own plans. Treat them as different arrangements when looking at costs.

Likewise, a custom site isn't free because Opus wrote the code. Count the agent, domain, hosting, data storage, extra services and maintenance. The stack chapter explains the tools this guide uses; check Claude's current pricing and Cloudflare's current allowances for the budget.

My reason for choosing Opus isn't that every WordPress installation costs more. It's that the build can start with the exact site and editing workflow you want. Price that result, including the time it takes staff to use it, rather than awarding a trophy to whichever software download says “free”.

Own the upkeep as well as the design

A custom site and CMS need updates, backups and a way to recover from mistakes. Have Opus set up and document those jobs. Name the person who checks that they are happening. Keep the access and recovery instructions somewhere you can find them.

WordPress also needs an update strategy, though security and minor updates can run automatically and managed hosts may handle more. “WordPress breaks every Saturday” isn't a fact. “AI means no maintenance” isn't one either.

The reason to keep your own source is control over the work, not exemption from it. You can ask an agent to investigate a problem, review the proposed change and restore the previous version if necessary. You can bring in a developer without first recreating the site from screenshots.

WordPress gives you source access too. Ownership isn't an exclusive advantage over WordPress; I'm choosing the agent-led build and the deliberately tailored workflow. Keep that control useful by documenting the project and testing the handover.

Already on WordPress? Move for a reason

If a working WordPress site has essential plugins or a publishing team that depends on its workflow, don't throw it away for a fashion statement. Identify the improvement you want, then check that the replacement delivers it.

For a new site, my recommendation remains Opus. For a rebuild, give it a real migration brief: content, images, existing URLs, redirects, metadata, forms and publishing permissions. Check those on staging before switching. Rankings can change during a move; there is no honest promise that a new framework preserves every position in Google.

The go-live chapter gives you the launch process. Keep the old site available until the replacement has passed its checks.

Build the site. Add the editor if you need it.

Start with the guide's setup. If changes are occasional, use Path A. If someone needs to publish without the agent, use Path B and test the handover with that person.

In both cases, Opus builds the site around your business. That's the recommendation. The CMS is a tool inside the project, not the reason the project has to look and work a particular way.

Still considering a hosted editor? Read why I'd use Opus instead of Wix or Squarespace. Selling products too? Build the storefront with Opus and use Stripe for checkout.