How to migrate to WordPress without losing your SEO rankings

A website migration is one of the highest-risk, highest-reward moments in a site's life. Done well, it is invisible — visitors and Google barely notice anything changed except that the site got faster. Done carelessly, years of accumulated rankings can evaporate within days.

We have moved dozens of client sites onto WordPress — from Squarespace, Wix, Shopify, custom builds, and tired older WordPress installs — and we migrated our own site onto its current build using the exact process below. The failures we have seen and fixed for other people follow a small, predictable set of patterns. This is how we avoid them.

Before you touch anything: audit and map every URL

The single biggest predictor of a migration going badly is skipping this step. Every URL on the existing site needs to be identified and accounted for before any development work starts — not after launch, when the list has to be reconstructed from Search Console's angry emails.

• ✓Crawl the live site with Screaming Frog (or a similar crawler) and export every indexable URL
• ✓Export the full list of indexed URLs from Google Search Console's Page Indexing report as a cross-check — a crawler can miss pages a sitemap crawl catches, and vice versa
• ✓Pull your top landing pages by organic traffic from Search Console or GA4 and flag them for extra attention — these are the pages you cannot afford to get wrong
• ✓Note any URLs with meaningful backlinks pointing at them — those need to survive the migration intact or redirect precisely

Build a URL migration map

Every old URL gets a row in a spreadsheet: old URL, new URL, and a note on what changed (title updated, content merged, page removed). This map becomes the single source of truth for the redirect rules and the QA checklist after launch. Skipping this step and 'figuring out redirects at the end' is how pages quietly go missing.

301 redirects for every changed URL — never break-and-hope

Every URL that changes needs a 301 redirect to its closest equivalent on the new site. Not the homepage — the actual replacement page. A blog post that moved from /blog/post-name to /resources/post-name should redirect there directly, not to /blog or to the homepage as a catch-all.

• ✓Use 301 (permanent), not 302 (temporary) — this is what tells Google to transfer the page's ranking signals to the new URL
• ✓Redirect to the single closest matching page, one hop — chains through two or three intermediate redirects slow crawling and can dilute the signal
• ✓Redirect every URL from your map, including old query-string variants and any URLs you know have external backlinks pointing to them
• ✓Test the full redirect map before launch, not after — a spreadsheet of 200 URLs is worth spot-checking with a crawler against the staging environment

Preserve or improve titles and meta descriptions

Page titles and meta descriptions are part of what earns a click in search results, and a page's title is a meaningful on-page ranking signal. If a page currently ranks well, carry its title over deliberately rather than letting a new CMS or template auto-generate a fresh one. Improving a title is fine — dropping the keyword phrase it was ranking for because the new template generated something generic is how a well-ranking page quietly slides down the results.

Keep canonical tags consistent

Canonical tags need to point at the final, live URL — not a staging domain, not an old URL that is about to redirect elsewhere, and not left blank so the CMS defaults to something unexpected. We check canonicals as part of the same pre-launch crawl that verifies the redirect map, because a wrong canonical can undo a correct redirect.

Resubmit your XML sitemap after launch

Once the new site is live, generate a fresh sitemap reflecting the new URL structure and submit it in Google Search Console immediately. Do not leave the old sitemap in place — it will list URLs that no longer exist and slow down how quickly Google discovers and indexes the new ones.

Watch the Page Indexing report closely for the first few weeks

This is the step people skip because the migration feels 'done' at launch. It is not. Search Console's Page Indexing report is where problems surface first, usually days before they show up as a traffic drop.

• ✓Check daily for the first week, then a few times a week for the following month
• ✓Watch for a spike in 404 (Not Found) errors — this usually means a redirect was missed in the map
• ✓Watch for pages marked 'Crawled — currently not indexed' — often a sign of thin content, a canonical pointing elsewhere, or a robots.txt issue introduced during launch
• ✓Use the URL Inspection tool on your five or ten most important pages specifically and request indexing if they have not been picked up within a few days

Some ranking fluctuation is normal — here is what to expect

Even a well-executed migration usually produces some short-term movement in rankings as Google re-crawls the new URLs, revalidates the redirects, and transfers signals across. This is normal and expected, not a sign something went wrong.

When the migration is done correctly — full URL map, clean 301s, consistent canonicals, fast resubmission — that fluctuation typically settles within two to four weeks, and most pages return to their prior positions or better, since the new site is usually faster. When it is done poorly — missing redirects, broken canonicals, or a robots.txt left blocking the new site — recovery stretches into months, and some rankings never fully come back because Google has already dropped the old URLs from its index by the time the mistake is caught.

Do not change the URL structure unless you have to

A migration is often treated as an opportunity to 'clean up' the URL structure. Resist this unless there is a real reason — a genuinely broken structure, a rebrand, or a required platform change. Every URL you change is a redirect that has to be perfect, a canonical that has to be updated, and a small amount of risk you did not need to take. If the old URLs work and are indexed, moving to WordPress is not, on its own, a reason to restructure them.

Other things we check on every migration

• ✓SSL/HTTPS carries over cleanly with no mixed-content warnings on the new site
• ✓The staging site's noindex tag is removed at launch — a shockingly common mistake that leaves the live site invisible to Google for days before anyone notices
• ✓Analytics and Search Console properties are connected to the new site before launch, not scrambled together after
• ✓hreflang tags are carried over correctly on any multilingual pages
• ✓The top pages by backlinks get a manual, individual check post-launch — these are worth more attention than an automated report alone
• ✓404 monitoring stays in place for at least a month after launch, not just the first week

The pages that matter most on a migration are not always the ones with the most traffic. A page with a handful of visits but a dozen quality backlinks pointing at it can do more damage to your domain authority if its redirect gets missed than a high-traffic page with no external links at all.

A realistic migration timeline

1. 1.Full crawl and URL export of the existing site, cross-checked against Search Console's indexed pages
2. 2.Build the URL migration map — old URL, new URL, notes — covering every single indexed page
3. 3.Develop the new WordPress site on staging with redirects, canonicals, titles, and schema in place before launch
4. 4.QA the full redirect map against staging, not production, before going live
5. 5.Launch, remove any staging noindex, and resubmit the sitemap the same day
6. 6.Monitor Page Indexing daily for week one, then a few times a week for the following month
7. 7.Manually verify your top pages by traffic and by backlinks are indexed and ranking within two to four weeks