AI Web Center

// blog

How to Move Off WordPress Without Losing Your Google Rankings

rankings belong to addresses. Search engines rank individual URLs, and every link pointing at your site points at a specific one. A migration that keeps every old URL working (either unchanged or permanently redirected to its new home) keeps almost all of its search value. A migration that breaks them starts over. Everything else on this checklist is about making sure that doesn’t happen.

Last updated 3 min read

I recently moved a clinical education site off WordPress: 35 articles, 141 reader comments, a question-and-answer forum and more than 260 clinical photos, onto a React front end with a C# back end and PostgreSQL. Every old address still works. Here’s how.

Why people leave WordPress

WordPress is fine software. People leave it because of what accumulates around it: a dozen plugins that each need updates, a theme nobody can safely change, page builders that make every page slow, and the steady stream of security patches. If your site is mostly content plus a few custom features (bookings, a portal, a forum), a modern stack can be faster, safer and cheaper to run.

But the migration is where most of the risk lives.

Step 1: inventory every URL before you touch anything

Build a complete list of the addresses your site answers on today:

  • every post and page, from the sitemap and from a crawl (Screaming Frog’s free tier handles small sites);
  • category, tag and author archives, and paginated pages (/page/2/);
  • attachment pages and image URLs (/wp-content/uploads/...), which are often linked from other sites;
  • feeds (/feed/), which readers and aggregators still use;
  • the top pages in Google Search Console’s Performance report, including old URLs you forgot existed;
  • external backlinks to deep pages, from Search Console’s Links report.

This spreadsheet is the contract for the whole project.

Step 2: decide the fate of each URL

For every row, choose one:

  1. Keep it exactly. The best option whenever possible. A new stack can serve /2019/04/my-article/ just as well as WordPress did.
  2. Redirect it permanently (301) to the closest new equivalent. Not to the home page: a redirect to an irrelevant page is treated much like a missing page.
  3. Retire it (410 Gone) if the content is genuinely gone and nothing equivalent exists.

Keep as many addresses identical as you can; redirects are for the ones you truly can’t keep.

Step 3: move the content faithfully

  • Export properly. The WordPress REST API or a WXR export gives you posts, pages, comments, authors and dates. Don’t scrape the HTML if you can avoid it.
  • Keep publication dates. They matter to readers and to search engines.
  • Bring the comments. On a community site the comments are content. On the clinical site, all 141 came across.
  • Rewrite internal links to the final URLs, so you aren’t relying on redirects inside your own site.
  • Move images and keep their alt text. Optimize them on the way (modern formats, correct sizes), but keep the old image URLs working or redirected.

Step 4: keep the on-page SEO you already earned

For each page, carry over the title, meta description, headings and structured data. Generate a fresh sitemap.xml with only the final URLs, set a canonical URL on every page, and make sure robots.txt doesn’t accidentally block the new site. (Staging environments often ship with “disallow everything” turned on. I check this one twice.)

Step 5: test before you switch

Run your URL spreadsheet against the staging site with a script: every row should return 200 or a single 301 to the right destination. No redirect chains, no 404s. Then check the top 20 pages by hand on mobile, and compare page speed before and after. A migration is a good moment to get a lot faster.

Step 6: launch and watch

  • Switch DNS during a quiet period and keep the old site available, read-only, for a few weeks.
  • Submit the new sitemap in Search Console and watch the Pages report for new “not found” errors daily for the first two weeks.
  • Watch your server’s 404 log too. Real visitors and old links will find the URLs you missed. Add redirects as they appear.

Expect a small wobble in traffic for a few weeks as search engines recrawl. Expect a big drop only if addresses broke, which is exactly what this checklist is designed to prevent.

The bottom line

A website migration is mostly a URL project with some design work attached. Inventory everything, decide the fate of every address, move content faithfully, test with a script, and watch the logs after launch.

I convert sites like this end to end: content, comments, images, redirects and the new platform, with every old address kept working. If your site is due for a rebuild, tell me about it.

// keep reading