How to Move From WordPress to a Claude-Editable Website

This is the whole method, written out properly.

I’m publishing it because the people who read this and think I could do that myself were never going to hire me, and the people who read it and think I am absolutely not doing that now know exactly what they’d be paying for. Both of those are better outcomes than a sales page.

The end state is a website made of ordinary files in your own account, which you change by describing what you want in plain English. No page builder, no dashboard, no plugin renewals, and nobody to email when a headline is wrong.

Here’s how you get there.

Phase 1 — Audit before you touch anything

Everything that goes wrong later goes wrong because this phase was rushed.

Find where your email points. Look up your domain’s MX records. If they point at Google or Microsoft, a site move won’t affect your email. If they point at your web host, moving DNS carelessly takes your inbox down, and that needs handling as its own separate step before anything else. I’ve written about this at length because it’s the one thing here that can genuinely hurt a business.

Find out who controls what. Where the domain is registered, who has the hosting login, who set the site up originally. This sounds like admin. It’s the most common reason a move stalls — not technical difficulty, an account nobody can get into.

Inventory what you’re paying for. Page builder licence, SEO plugin, forms plugin, backups, caching, theme, hosting. Write down each one with its renewal date. You’ll want this later, and you almost certainly don’t have it now.

Count your pages. Your sitemap is usually at /sitemap.xml or /sitemap_index.xml. Under a hundred URLs is a straightforward move. A hundred to two-fifty is a bigger job. Past that, plan properly.

Check for the disqualifiers. A store, a course platform, a membership, a forum, a searchable directory, a multilingual setup. If you have one of these, stop — the move costs more than it returns, and that’s a genuine answer rather than a hedge.

Phase 2 — Export everything

Posts and pages. WordPress will export an XML file of your content from Tools → Export. Take the whole thing even if you only plan to move some of it.

Images. Download the uploads folder. This is usually the largest and most annoying part, and the part people forget until they need it.

Your URLs. Save the sitemap. Every existing address needs to either still work afterwards or redirect somewhere sensible, and you can’t guarantee that without a list.

Screenshot every page. Not for nostalgia. When you’re rebuilding, you’ll want to check you haven’t dropped something, and memory is unreliable about what was on a page you looked at a thousand times.

Phase 3 — Decide what actually moves

This is the part most rebuilds skip, and it’s the part that determines whether the new site is better or just newer.

Go through the list of pages and sort them: keep as-is, rewrite, merge into something else, or delete.

Most sites carry pages nobody has read in two years. A services page for something you stopped offering. Three blog posts from a phase you’ve moved past. An about page written before you knew what you did.

Moving all of it faithfully is the wrong instinct. You’re being handed a rare opportunity to not carry something forward, and it costs nothing to take it.

Phase 4 — Build the new site

The new site is built with Astro, which produces plain HTML files. There’s no database, nothing to log into, and nothing that can be out of date and insecure.

Practically, this means:

Content lives in markdown files. One file per page or post, with a short block at the top holding the title, description, date and tags. Readable by a person, editable by anyone, and impossible to corrupt in the way a database can be.

Design lives in components. Your header exists once. Your call-to-action block exists once. Change it in one place and every page updates — which is precisely what doesn’t happen on a page-builder site, where the same block has been pasted onto fourteen pages and only eleven of them ever get updated.

The whole thing lives in a GitHub repository you own. Every change is versioned, which means anything can be undone.

It deploys to hosting that’s free at this size. Netlify, Cloudflare or Vercel. You push a change and the site rebuilds in under a minute.

Phase 5 — Move the content

Convert the WordPress export into markdown files, one per post.

Keep your URLs exactly as they are. If a post lived at yoursite.com/why-this-matters, it lives there afterwards. This is entirely within your control and there’s no good reason to break links you’ve spent years accumulating.

Then a pass over the frontmatter — titles, descriptions, tags — and a check that the images all landed. Meta descriptions want to be under about 160 characters, which is worth fixing while you’re in there, since half of most sites’ descriptions are three sentences long and get cut off in search results.

Expect this phase to be dull and to take longer than you estimated. It’s mechanical work, and it’s the part that most benefits from being handed to somebody else.

Phase 6 — Go live, in the right order

Move the email first if it’s with your host, and let it settle for days before anything else changes.

Screenshot your existing DNS records. All of them.

Set up redirects for anything whose address changed. Old links from other sites should still land somewhere real.

Point the domain at the new host.

Keep the old hosting running for a few weeks. It’s cheap, and it means a rollback is possible if something surfaces.

Then cancel the subscriptions. All of them, using the list from Phase 1. Almost nobody does this. Eighteen months later people are still paying licence renewals for a website that no longer exists.

Phase 7 — Learn to run it

This is the part that makes the whole exercise worthwhile, and it’s shorter than you’d expect.

You connect Claude to the repository holding your site. From then on, changing your website is a conversation:

Change the headline on my home page to X. Add a testimonial from this client under the services section. Make a new page for the workshop I’m running in October, matching my existing pages. Publish this as a blog post — here are my notes. That last change looks wrong on mobile, fix it. Undo what we just did.

You review what it did, and if it’s right, it goes live. If it’s wrong, it’s reverted, because everything is versioned.

The learning curve is being specific about what you want — which is the same skill as briefing a developer, minus the four-day wait and the invoice.

What it costs to do this yourself

Time, mostly, and it isn’t evenly distributed.

The audit is an afternoon. The export is an hour. Deciding what moves takes as long as you let it. The build is where the real work sits, and it depends entirely on whether you’re comfortable with the tooling. The content migration is a day or two of dull work for a hundred pages. Going live is a careful afternoon.

The risky parts are the email and the URLs, and both are risky in the same way — the failure is silent. Nothing tells you a bounce happened or a link broke. You find out later, from someone who assumed you were unreachable.

If you’d rather not

I do this for coaches and consultants as a two-week project. I design and build the site, handle the migration and the DNS, set it up on your own Claude account, and then teach you to run it — after which you change your own website by describing what you want.

You end up owning the code, the domain, the account and the process. There’s no retainer, because I’d be selling you a subscription to a problem I just removed.

If you want to know whether your site is a fit — including the cases where it isn’t, which I’ve written about separately — that’s a twenty-minute conversation.

The method isn’t the valuable part. Doing it in the right order, without taking your email down, is.