Communicate like you mean business.

Start a Project
Moving Your Website From WordPress to Code

Moving Your Website From WordPress to Code

If you run a WordPress website, you probably know the routine. Something needs updating every week. A plugin update shifts a section of the homepage. A security warning lands in your inbox. The site that felt quick when it launched now takes a beat too long to load on a phone.

None of that means WordPress is bad. It runs a huge share of the web for good reasons. But for a lot of small businesses and nonprofits, it has become more website than they need and more upkeep than they want.

Over the past year I have been rebuilding websites as clean, hand-coded sites instead. My own site is one of them. This guide walks through the whole thing in plain English: what a coded site is, what you gain, what you give up, where all the things WordPress does for you end up, how the move works, and what life looks like afterward.

First, a simple way to picture the difference

Think of a WordPress site as a restaurant that cooks every meal to order. When someone visits a page, WordPress goes to the pantry (a database), pulls out your words and pictures, runs them through a set of appliances (the theme, the page builder and every plugin), and plates the page on the spot. It works, but the kitchen is busy, every appliance needs servicing, and if one breaks, dinner is late.

A coded site is the same meal, already prepared and ready to hand over. Each page is finished ahead of time. When someone visits, the page is simply handed to them. There is no pantry to raid, no appliances to service and no kitchen door to break into.

From the outside, both look like normal websites. Underneath, the coded one has far less going on.

What you gain

Speed. With nothing to assemble, pages load quickly, especially on phones. My own coded site scores between 91 and 100 on Google's mobile speed test. WordPress sites built with page builders usually land well below that, even after careful tuning.

Security. Most WordPress security problems don't come from WordPress itself. They come from plugins. Patchstack, a WordPress security company, found that 93 percent of the WordPress security holes reported in 2022 were in plugins. A coded site has no plugins, no login page and no database for anyone to break into.

Less upkeep. No WordPress updates, no theme updates, no plugin updates, and no update that quietly breaks your layout overnight.

Lower running costs. No premium theme or plugin licenses to renew each year. Hosting for a small coded site is often free or close to it.

Every change saved. Each version of the site is kept, like a document's version history. If a change doesn't work out, it can be undone in minutes.

Built exactly as designed. You are not limited to what a page builder allows. Accessibility and the structure Google looks for are built in from the start, not bolted on later.

And it costs about the same to build. Hand-coding used to cost far more than a template. Today I build with AI tools alongside a designer's eye, which puts a custom-coded site in the same range as a good WordPress build.

What you give up (the honest part)

A drag-and-drop editor. By default, a coded site has no login screen where you click and type. More on how changes work below.

Your plugins. Every job a plugin does for you today needs a new home. The next section covers where each one goes.

A few unsettled weeks with Google. Even a careful move gives Google a lot to re-learn. Some ups and downs in rankings and traffic for roughly two to eight weeks are normal. My goal is to preserve the rankings you have earned. No one can honestly guarantee what Google does, and I won't pretend to.

It is a project. A rebuild costs more this year than leaving your site alone. It pays you back in upkeep, security and speed over the years after.

Where everything WordPress does for you goes

This is the part most people worry about, so here it is item by item.

  • Contact forms. A form service built for websites receives your messages, filters spam and emails them to you. Several near-identical forms usually become one form that tells you which page it came from.
  • Events calendar. A simple event editor: you fill in the title, date, time, place, description, a photo and a ticket link, then click Publish. Each event gets its own page, the upcoming list and the past-events archive update themselves, and Google gets the event details it shows in search results.
  • News and blog posts. The same kind of simple editor, set up for posts. Your existing posts keep their web addresses.
  • Maps and locations. A lightweight map with your pins, often paired with a list that works better on phones and for Google.
  • Newsletter sign-up. Your email service (Constant Contact, Mailchimp and the like) provides a sign-up form or link that drops right in.
  • Donations, registrations and ticket sales. If these already run on an outside service, they simply link out as they do today.
  • Site search. A small search tool built into the site, or none at all if your visitors don't use it.
  • Videos, PDFs and downloads. Videos embed as usual. PDFs keep their exact web addresses so nothing that links to them breaks.
  • Analytics and ad tracking. Same tracking accounts, so your history stays continuous.

What if you sell things online?

On WordPress, selling usually means WooCommerce, a store that lives inside your website. On a coded site, you don't build a store. You plug one in.

A payment company handles the cart, the checkout and the card numbers on its own secure pages. Your site shows the products and sends people there to pay. Card details never touch your website, which is a safer arrangement than keeping a store, its orders and its customer data inside WordPress.

How that looks depends on how much you sell:

  • A few things: donations, deposits, class fees, gift cards or a handful of products. Each one gets a Buy button that opens a secure checkout run by a company like Square, Stripe or PayPal. The receipt goes out automatically. No cart and no monthly fee, just a fee on each sale.
  • A small shop: a few dozen products with shipping, sales tax and discount codes. A shopping cart service adds a cart to your own pages and handles orders, inventory, tax and shipping. You add and edit products in its dashboard, not in code.
  • A store that is the business: hundreds of products, customer accounts or subscriptions. The store runs on a platform built for exactly that, like Shopify, styled to match your site, while everything else is coded.

Every option carries a fee per sale, and the cart services add a monthly fee, so I compare them against what you pay today before recommending one. If your store depends on a lot of WooCommerce add-ons, the honest answer may be to leave the store where it is and rebuild only the rest of the site.

How you make changes after launch

There are three ways, and most clients use a mix:

  1. Ask me. Send the change by email. I make it, send you a preview link, and publish it once you approve. Most changes are live the same day.
  2. Use a simple editor for the things you change often, like events, news or partner listings. It is a short form, not a page builder, so you can't accidentally rearrange the homepage.
  3. Use your other services' dashboards for products, donations or tickets, the same as you would on any website.

Decide who edits what before the build starts, not after. That one conversation shapes the whole site.

How the move works

  1. Measure first. I record how your site performs today, page by page, so we can prove afterward that nothing was lost.
  2. Map everything. Every page and every web address, plus a new home for every plugin and a plan for who edits what.
  3. Build on a hidden preview. Same addresses, same content Google already knows, a new look and better code. Google and the public can't see it yet.
  4. Test side by side. The new site is checked against the old one before anyone else sees it: addresses, headings, forms, phones and speed.
  5. Launch carefully. Any address that changes forwards to its new home, Google is told about the new site, forms and analytics are checked, and the old site is kept as a backup.
  6. Watch for 12 weeks. I monitor Google's reports, fix anything that turns up, and report the before-and-after in plain language. Then the real improvements begin.

One detail that trips people up: your website, your domain and your email are often tied together at the same company. Before anything is cancelled, I make sure your email keeps working exactly as it does now.

For the Google side in more depth, read my Website Transition Guide.

How upkeep changes after launch

  • Software updates. WordPress: The core software, the theme and every plugin, all year. Coded site: None.
  • Security. WordPress: Firewall, security plugin, login protection. Coded site: No login or database to attack.
  • Backups. WordPress: Scheduled; restore when something breaks. Coded site: Every version kept; roll back any change.
  • Making a change. WordPress: Log in, edit, hope nothing shifts. Coded site: Ask, preview, approve; or a simple editor for events and news.
  • Speed over time. WordPress: Slows as plugins pile up. Coded site: Stays fast.

The time your monthly plan used to spend on updates goes into actually improving your site.

Common questions

Will I lose my Google rankings? The whole process is built to protect them: same addresses, same content, side-by-side testing and 12 weeks of watching. Some short-term movement is normal. No one can honestly guarantee Google, so I guarantee the process instead.

What if you're not around someday? The site is yours. It is standard web code that any web developer can work on, and it lives in your own hosting account.

We already built a draft with AI. Do we still need you? AI can build a page. It doesn't know which of your pages Google ranks, which addresses carry years of history, or how to move your forms, calendar and donations without losing anything along the way. That's the part I handle.

Is it more expensive? Up front, it's a project. Over three to five years, fewer licenses, no update hours and fewer emergencies usually make it the cheaper website to own.

Is it right for you?

A coded site is a great fit if your website is mostly about who you are, what you do, your events and your stories, and you would rather not live inside WordPress. Selling a few things, or running a small shop, works well too.

It is probably not the right move if you need member logins, have a team that publishes new posts every day on its own, or run a large store built on WooCommerce add-ons. In those cases, a well-built WordPress site, or a coded site with the store on Shopify, is the better tool, and I'm happy to help with either.

You can see how I build websites on my Website Design page. Not sure which side of the line you're on? Start a project and we'll talk it through.

Sources

  • Patchstack, "State of WordPress Security in 2022" (93% of reported WordPress vulnerabilities were in plugins): https://patchstack.com/wp-content/uploads/2023/03/State-of-WordPress-Security-in-2022-by-Patchstack.pdf
  • Google, "About PageSpeed Insights" (the mobile speed test referenced above): https://developers.google.com/speed/docs/insights/v5/about

Wondering whether your website would be better off as a coded site? I can take a look.

Start a Project