How to Migrate a WordPress Site to a Fast Static Site (Without Losing SEO).
Most WordPress migration guides just move a site to a new host. Here is how agencies move a client off WordPress onto a fast static site, and keep every ranking on the way over.
Andrew Lee Jenkins · 2026-06-30 · 9 min read · Updated 2026-09-04
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, keeps layout stability and responsiveness green 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.
WordPress, per client site
Core, theme, and a stack of plugins to keep updated
A database and PHP runtime that can be attacked
A caching layer to configure just to get a fast page
Security patches to apply forever, across every site
Upkeep that scales with your client count
Static site, per client site
Plain HTML and CSS served from the edge
No database, no plugin runtime, almost nothing to exploit
Fast by default, structural Core Web Vitals green
Nothing to patch on a schedule
Upkeep that stays near zero as you add clients
Make it something yours.
Explore Seedly's software and the guides to help you get started.
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, and 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. It ports 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, and 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.
Moving parts you maintain per client site
WordPress site core, PHP, database, theme, plugin stack, caching layera long list
Static site HTML and CSS on a CDNalmost none
Illustrative, and the exact count depends on the site. The point is the direction. Every piece you remove is one fewer thing to patch, to break, and to get exploited. After the move, the upkeep that used to scale with your client count mostly disappears.
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 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.
