How to Migrate a WordPress Site to a Fast Static Site (Without Losing SEO)

The first client I moved off WordPress was a local services firm whose site I had babysat for three years. Every month was the same drill: plugin updates, a caching plugin to coax back to life, a security scanner crying wolf. I did not want to move them to a faster WordPress host and reset the same clock. I wanted the whole machine gone.

So I rebuilt the site as fast static HTML. No database, no plugins, no caching stack to babysit. I have since taken a whole portfolio across the same way, and the one thing that decides whether it goes cleanly is brutally simple: you have to do it without losing a single ranking. This is the guide for that.

Why move a client off WordPress, not just to a new host

A new host fixes nothing that actually hurts. The site still builds every page from a database on every request, still leans on a caching plugin to hide the lag, still carries a stack of plugins that each need updating, and still presents the same attack surface for someone to compromise. You have moved the maintenance burden, not removed it.

A static site is clean HTML on a CDN. There is no database to query, no plugin runtime to exploit, and nothing to patch on a schedule. It loads fast by default, passes Core Web Vitals out of the box, and sits there working without you touching it. For an agency hosting dozens of client sites, that difference compounds across the whole portfolio. I wrote up the full case in why agencies are leaving WordPress; here is the short version of what changes.

The part every guide skips: don't lose the SEO

Here is why the standard guides stay in WordPress-to-WordPress land. As long as the URLs, titles, and structure stay byte-for-byte identical, you can be sloppy about SEO and mostly get away with it. Google barely notices a host swap.

Rebuild the site on a new platform and that safety net is gone. Now you are responsible for every URL Google already knows, every title and meta description that earns clicks, every internal link, and every backlink pointing at the old site. Get this wrong and the client watches their rankings fall off a cliff two weeks after launch, and they will blame the rebuild, correctly. Get it right and the migration is invisible to search. The whole job is making the new site look, to Google, exactly like the old one lived here all along.

A clean migration is one Google never notices. Same URLs, same titles, same links, faster pages.

Step 1: Audit and inventory every page

You cannot preserve what you have not written down. Before you build anything, make a full inventory of the existing site. This is the spreadsheet the rest of the migration runs on.

• -Crawl the live site so you have every indexed URL, not just the ones in the menu. Old blog posts and orphaned landing pages count.
• -For each URL, record the page title, meta description, and H1. These are what earn clicks in search; you are going to copy them across exactly.
• -Pull the top pages by traffic and by backlinks. These are the ones you protect at all costs. Losing a low-traffic tag archive is fine; losing the page with forty referring domains is not.
• -Export the XML sitemap so you have the canonical list of what the site itself claims should be indexed.
• -Note any redirects already in place. They have to survive the move too.

Step 2: Export the content

With the inventory done, get the content out of WordPress. You are pulling the words, the images, and the structure, not the WordPress machinery. Use the built-in export, grab the media library, and copy the real text of each page. The goal is the raw content, free of the theme and plugin wrapping, ready to drop into a clean build.

Step 3: Rebuild on the new platform

Now you build the site as static pages. Recreate each page from the inventory, keeping the same content and the same heading structure, and apply the client's brand properly while you are in there. This is the step where a good builder earns its keep, because rebuilding twenty pages by hand is exactly the switching cost that keeps agencies stuck on WordPress in the first place.

This is the work Seedly Sites migration is built to absorb: porting an existing site into the builder so you are editing real pages, not starting from a blank canvas. However you rebuild, the rule is the same. The new pages keep the old content, and you do not improvise new URL structures just because you can.

Step 4: Preserve the SEO, point by point

This is the heart of the migration, and it is a checklist, not a vibe. Work through every item against the inventory from Step 1.

• -Map old URLs to new ones, one for one. The best map is no change at all: keep every path identical so nothing needs redirecting. Where a path has to change, write down the exact old-to-new pair.
• -Set 301 redirects for anything that moved. A 301 is a permanent redirect that passes ranking signals to the new URL. On a static host you set these as redirect rules at the edge, so an old link still lands on the right page instead of a 404. Never leave a previously-indexed URL with nowhere to go.
• -Carry over titles and meta descriptions exactly. Paste them from the inventory. A rewritten title can swing a page's click-through rate; migration day is not the day to "improve" them.
• -Keep one canonical URL per page. Set a self-referencing canonical so Google knows the static page is the real one, and you are not accidentally splitting signals between a trailing-slash and non-slash version.
• -Fix the internal links. Make sure links between pages point at the new URLs, not at old WordPress paths or, worse, the staging domain. Broken internal links bleed crawl budget and confuse the rebuild.
• -Protect the backlinks. The pages with referring domains are pure equity. Their URLs should not change, and if one absolutely must, it gets a 301 and a note to chase the bigger linkers for an update.
• -Publish a fresh sitemap. Generate a new XML sitemap from the static site so the new set of URLs is laid out cleanly for Google to recrawl.

Step 5: Test before anyone sees it

Build and check the whole thing on a staging URL first, before you touch DNS. This is where you catch the mistakes that turn into ranking drops.

• -Click through every page. Confirm the content matches, images load, and forms work.
• -Run a crawl of the staging site and compare the URL list against your inventory. Anything missing is a page you forgot to redirect.
• -Spot-check titles, meta descriptions, and canonicals against the spreadsheet on your highest-value pages.
• -Verify the redirect rules actually fire by hitting a few old URLs and confirming they 301 to the right place.
• -Check it on a phone. Static is fast, but a broken mobile layout still costs you.

Step 6: Cut over the DNS

Once staging is clean, point the domain at the new static host. Lower the DNS TTL a day ahead so the switch propagates quickly, then update the records. Keep the old WordPress site alive but untouched for a little while as a fallback. Plan the cutover for a quiet traffic window, not Monday at 9am, so a propagation hiccup costs you the fewest visitors.

Step 7: Verify in Search Console

The migration is not done when the site is live. It is done when you have confirmed Google is following you over. Open Google Search Console and watch.

• -Submit the new sitemap and request indexing on the top pages so Google recrawls sooner rather than later.
• -Watch the Coverage and Pages reports for a spike in 404s or redirect errors. That spike is your missed-redirect list; fix each one.
• -Keep an eye on impressions and average position for a few weeks. A small wobble right after a move is normal; a steady slide means a mapping problem to hunt down.
• -Recheck Core Web Vitals once Google has fresh data. This is the move paying off: the static site should be reporting green where WordPress was amber.

The reason this whole checklist is worth the effort is what you are trading into. A static site strips the rebuild down to a handful of moving parts you actually control.

Where to land the client

The migration steps above work no matter where you rebuild. What I care about, running an agency, is not renting another platform with the same lock-in I just escaped. The point of leaving WordPress was to stop paying a tax on every site forever.

So the destination that makes this worth doing is one you own. A static site you control means you own the HTML output, you host it where you like, and there are no per-site fees stacking up every month behind your client list. That is the model I packaged as Seedly Sites: a self-hosted, white-label builder that ports an existing site in and ships it as static HTML, bought once instead of rented per seat. The migration page walks through how the port works.

Leave WordPress for something you rent, and you have changed landlords. Leave it for something you own, and you have changed the business.

The migration is the upgrade

Moving a client off WordPress is not a risky downgrade you have to apologize for. Done in this order, with the SEO checklist held tight, it is the cleanest upgrade you can sell: the same content and the same rankings, on a site that is faster, safer, and almost free to maintain. The host-to-host guides will never tell you that, because they are trying to keep you in WordPress. You do not have to stay.

Want to see the rebuild side of it before you plan a migration? Read why agencies are leaving WordPress, look at how the migration port works, or try it live.