Before moving to South Africa, I worked for Ichtus Vlaanderen, a Christian student movement in Belgium. My brother is the GenSec for the NGO, and its site, ichtus.be, runs on WordPress.com. I help a bit with the site as a live testing ground for WordPress.
Last week I finally got to some open questions about the design of the website, starting with why the gap under the menu was so big. I had my own list: the photo section on the homepage looked uneven, some buttons were enormous, and the menu was boring.
Normally that’s an evening in the Site Editor, clicking through templates and settings to work out which one causes what. This time I described what I wanted to Claude, and Claude made the changes on the site through WordPress.com’s connector. Most of this ran in the background while I was working with me occasionally tweaking the prompts.
The changes Claude made
- The photo section. Six columns of photos, two of them wider than the rest. Now they’re all the same width and end on the same line, and the bottom photos have different heights so the top edge steps up and down. On a phone the columns shrink instead of stacking, with the student groups’ logos in the middle. Those needed to be clickable on phone as well and that is fixed now.
- The gap under the menu. About 115 pixels on the homepage, now 45. On other pages it went from 70 to 20. Claude used the normal spacing settings for this, no code.
- Buttons. Some were well over 100 pixels tall. Claude traced it to one site-wide style setting someone had changed, removed it, and then checked every button on the site.
- The menu. Contact is now a red button. The other items get a coloured underline when you hover over them, each in a different colour from the site’s palette. The dropdowns and the phone menu got a cleanup too.
- The group tiles. Clicking anywhere on a group’s tile now opens that group’s page, not just clicking the logo.
What I typed was mostly a sentence or two in plain language, typos and all:
I find the menu looking extremely boring, can you make it look just a bit more intereseting?
the blocks on the side now don’t have any spacing between them, fix that
Claude said what it planned to change, I said yes or asked for something different, and it went live.
So how can you do this yourself?
You need the following things:
- A WordPress.com site on a paid plan. A free site gets this for its first 30 days. A self-hosted WordPress site works too, if it’s connected through Jetpack with a Jetpack AI or Jetpack Complete plan.
- Claude, in the desktop app or at claude.ai. You can use your AI tool of choice as well, but with Claude it’s simpler.
If you’d rather watch than read, my colleague Wes made a video of the setup:
Step 1: Turn on MCP access
In your WordPress.com account, go to Preferences > AI and MCP, and switch on “Enable MCP access”. MCP is the name for the connection that lets an AI assistant work with an app. You don’t need to know more than that.
Step 2: Connect Claude
Open Claude’s connectors page in the browser, or Settings > Connectors in the desktop app. Click Add, then Browse connectors. Search for WordPress.com and click Connect. On the WordPress.com page that opens, pick Full access if you want Claude to make changes, or Read only if you only want it to look. Then click Allow. WordPress.com’s guide has the exact clicks.
Step 3: Start small
Ask it something that only reads first, like “Which of my sites can you see?” or “Look at the homepage of [your site] and tell me what’s on it.” Once that works, ask for one change at a time.

Some things to bear in mind
Here are some tips and tricks for making the most of your site:
- Design changes go live straight away. Posts and pages can be saved as drafts, but templates, menus and site-wide styles can’t. A change shows up for every visitor the moment it’s saved, so ask Claude to explain what it’ll change and wait for your yes. At the same time, don’t get too worried about that. It’s easy to ask Claude to revert a change, and in many cases, the visitor might not even notice what you are doing.
- Ask for the version someone else can maintain. Claude seems to default towards using custom CSS. It’s in a sense faster to write, but it’s more complex to maintain. So I early on set the rule that Claude was only allowed to use custom code if my requests weren’t possible from the code editor. For the Contact button, Claude first suggested a few lines of CSS. I asked for a real button block instead, so the person who runs the site can change the text or link in the editor. Some things still needed CSS, like the hover effects and the phone menu, because the editor has no setting for them. Claude put each piece under a comment that says what it does, and told me how to undo it.
- Ask what’s causing it. The enormous buttons and the missing space between the cards down the side of the homepage both came from site-wide settings someone had changed. Fixing the setting fixed it on every page at once.
- Agree who’s editing when. Someone else was working on the homepage at the same time as Claude. Claude re-read the page right before saving, saw their new edits and kept them. If they’d saved after Claude, the old version could have come back.
- Screenshots depend on where you run it. I used the Code tab in the Claude desktop app, which can open the site in a browser, so I saw screenshots of each change before it went live. In a regular chat you get a description instead.
If you try this on your own site, I’d like to hear what you changed first.
Leave a Reply