How to leave WordPress for a site you actually own

Because it genuinely is a good way out. A builder like v0 by Vercel turns a description of your site into real Next.js code. Not a template locked inside a product. Actual files, the same kind a developer would write.

So they did what most people do. They opened the builder, described the site, and got something that looked a lot better than the old one in an afternoon. That part worked.

Inside the builder. Every change after that first build happened as another message to v0. Move this. Warmer color. Put the old headline back. Each one cost credits, and each one cost more than the last, because the builder carries your whole project along with every message. We wrote up exactly why that happens in our one-pager guide.

The bigger problem was quieter. The site only really existed in the builder. There was no copy of the code anywhere they controlled, no history of what changed, and no way to fix a typo without paying for a round of AI.

So they’d left WordPress and landed in a new box. A nicer box, but still a box.

Four moves, in this order. Each one has its own guide in this series, so this is the map, not the manual.

1. 01Get the code out. The builder pushed the project to a GitHub repository the client owns. From that moment, GitHub is the real site and the builder is retired.
2. 02Connect a host to that repository. Every saved change on GitHub now publishes the site by itself. No uploads, no FTP, no dashboard.
3. 03Point the domain at the new host, and redirect every old WordPress URL to its new page so search rankings carry over.
4. 04Edit outside the builder. Small text changes right on GitHub, bigger ones with an AI assistant that works on the code directly and costs a fraction of a builder round.

If “repository” and “commit” already lost you, that’s normal, and it’s exactly what part two covers: what Git and GitHub are and why your site needs them.

The thing they noticed most wasn’t on the table, though. It was not having to think about the site. It just stays up.

Here’s the whole move start to finish. It works for most small business sites: a home page, a few service pages, an about page, a contact page, maybe a blog.

1. 01List every page you have now. Open yoursite.com/sitemap.xml (or /wp-sitemap.xml) and save the list. This becomes your redirect list later, so don’t skip it.
2. 02Export your content. In WordPress, go to Tools, then Export, then All content. Download your images from the Media library too. Copy the words you want to keep into one document.
3. 03Write the spec before you open the builder. Final copy, colors, fonts, every page. One finished spec, one or two builder rounds.
4. 04Build it, then push the code to GitHub straight away and stop using the builder.
5. 05Connect a host and get a working preview link.
6. 06Rebuild your forms. WordPress forms run on your old server, so they won’t come with you. Use a form service, then actually test that a message arrives.
7. 07Set up redirects from every old URL to its new home. Old blog addresses like /2024/05/post-name/ need one too.
8. 08Point your domain at the new host. Leave your email records alone.
9. 09Keep the WordPress site and a full backup for 30 days, then cancel the hosting.

Step six is where we see the most quiet damage. A form that shows a checkmark and sends nothing is worse than no form, so check yours with the steps in how to tell if your contact form is silently dropping leads.

Redirects are the step that protects your Google rankings. Every old URL should land on a real page, never on a 404.

Each part takes one step of the move and walks it properly.

• Part 2: what Git and GitHub are, why you need them, and how to undo a mistake.
• Part 3: editing your own Next.js site, from a one-word fix to a new page.
• Part 4: deploying from GitHub to Cloudflare or Vercel, including your domain.
• Part 5: editing your site with Claude, ChatGPT or Grok, with prompts you can copy.

Start with part three, editing your own Next.js site, if your code is already on GitHub.

If several people who never want to see a file publish posts every day, WordPress’s dashboard is doing real work for you. A coded site can add an editing dashboard later, but that’s a project, not a free upgrade.

If your business runs on a big WooCommerce store, a membership plugin or a booking system that lives inside WordPress, moving the marketing pages is easy and moving the machinery is not. Price that part separately before you commit.

And if your WordPress site is fast, secure, and someone else keeps it updated for you, that’s fine. Leaving is for people who are stuck maintaining it. It isn’t a moral position.