The fear with any migration is the same: you switch platforms, and three weeks later the phone stops ringing because your pages fell out of search. That fear is reasonable. It is also avoidable, because the cause is almost always one thing. Addresses changed and nobody told the search engines where the pages went.
Here is the process we follow when we retire a WordPress site. We used it to move a realtor's site to a static build with every page and article at its exact original URL.
Step one: inventory before you touch anything
You cannot preserve what you have not listed. Before any building starts, we produce a manifest of every address the old site answers to:
- Every published page and post, pulled from the WordPress REST API rather than the menu, because menus lie.
- The XML sitemap, which often lists things the menu does not.
- Old addresses that still get visits. Archive snapshots and backlink reports show URLs that were renamed years ago and are still linked from other sites.
The result is a plain file: old address, what it is, and what should happen to it. Keep, redirect, or retire. Every line gets a decision.
Step two: copy the content out, cleanly
WordPress content carries baggage: shortcodes, builder markup, inline styles from six redesigns ago. We convert each page to clean content and review it rather than pasting HTML across. For big sites we use a tool we wrote, WP Ripper, which crawls a site and extracts the real content and images.
Images come too, at their original paths where possible. An image that ranks in image search is a URL like any other.
Step three: build the new site at the old addresses
This is the part that gets skipped. The new platform has its own idea of what URLs should look like, and the easy path is to accept its defaults and redirect everything. Do not. A redirect is a fallback, not a plan.
Details that matter more than they look:
- Trailing slashes. If the old address ended in a slash, the new one does too. To a search engine, the slashed and unslashed versions are different addresses.
- Case and punctuation. Match them exactly.
- Titles and descriptions. Carry over the ones that were working. A migration is a bad moment to rewrite the title tag on your best page.
Step four: handle what is not coming along
Every address in the manifest that is not being rebuilt needs an explicit answer.
- Moved content gets a 301 redirect to its closest equivalent. Not to the homepage. Sending everything to the homepage tells search engines the page is gone.
- Content that should never have existed gets a 410. A 410 says gone on purpose, do not come back. It clears junk out of the index faster than a 404 does.
- Everything else gets a real 404 page with a way back into the site.
We keep redirects in a data file in the project, not in a hosting dashboard, so they are versioned and reviewable along with the code.
Step five: go live in the right order
The order protects you:
- Build and test the new site on a temporary address.
- Crawl the temporary site against the manifest. Every old address should return the status you decided on.
- Point the domain at the new site.
- Submit the sitemap and watch the coverage report.
- Only after all of that, shut down WordPress and delete the database.
Deleting first and rebuilding second is how content gets lost for good. Keep the old site reachable until the new one has proved itself.
What you gain
Once WordPress and its database are gone, there is no login page to attack, no plugin to update, and no server process to crash. The site is a set of files. It loads faster, costs less to host, and stops being a security chore.
The rankings carry over because, from a search engine's point of view, nothing happened. The same addresses answer with the same content. They just answer faster.
Not every site should leave WordPress, and we have written about how to tell which kind you have. If yours should, send us the address and we will tell you what the move would involve.