I’m planning to migrate my existing website to WordPress, but I’m worried about losing search rankings, traffic, and indexed pages. What steps should I follow for redirects, URLs, metadata, and sitemaps to preserve SEO during the migration?
Don’t launch WordPress with a new URL structure and plan to “fix the redirects later.” That is the easiest way to lose indexed pages. Crawl the existing site first and export every indexable URL, including PDFs, category pages, and URLs that still receive backlinks or traffic. Map each old URL to the closest equivalent new page. Use permanent 301 redirects page by page, and avoid sending everything to the homepage.
Keep the URLs unchanged wherever practical. If /services/web-design/ already ranks, there is little benefit in changing it just because WordPress offers a different permalink format. For URLs that must change, redirect directly to the final destination rather than creating redirect chains. Update internal links, navigation, canonicals, image references, and hreflang tags so they point to the new URLs instead of relying on redirects.
Move the SEO elements as content, not just the visible page copy. Preserve title tags, meta descriptions, headings, image alt text, structured data, canonical tags, and index/noindex settings. Check that the WordPress theme has not added duplicate headings, thin archive pages, attachment pages, or conflicting canonical tags. Keep the staging site blocked from indexing, but make absolutely sure any site-wide “discourage search engines” setting is removed before launch.
At launch, verify that important pages return 200 status codes, redirects return 301, and missing pages return a real 404 or 410 where appropriate. Generate a new XML sitemap containing only canonical, indexable URLs, submit it in the relevant search engine webmaster tools, and keep the old sitemap available temporarily if it helps crawlers find the redirects. Don’t delete the old domain or hosting configuration until you have confirmed the redirects work consistently.
Expect some ranking movement while search engines recrawl the site, even with a clean migration. Monitor indexing, crawl errors, organic landing-page traffic, and redirect logs for several weeks. A pre-launch crawl and a post-launch crawl compared side by side will usually catch problems faster than checking pages manually.
WordPress itself is not the SEO risk. Changing the CMS, design, content, and site structure in a single launch is. Keep the migration as close to a platform swap as possible, then redesign or rewrite pages after rankings stabilize. Before launch, record organic landing-page traffic, indexed-page counts, and key rankings so you can tell whether a drop comes from redirects, missing content, slower page speed, or tracking that broke during the move.
Moving the same pages onto WordPress is mostly a rebuild; changing the domain, URL paths, content, and design at the same time is a full search migration. If possible, separate those jobs. I agree with @rustywolf77 here: launch WordPress with the existing content and structure first, then make larger changes after you know the migration is stable.
Build and test the WordPress site on staging, but inspect it as a search engine would. Check rendered page copy, status codes, canonical tags, robots directives, structured data, mobile layout, and page speed. A page can look correct in a browser while important text is missing from the HTML or a theme setting quietly marks it noindex. Password-protect staging rather than relying only on robots.txt, then confirm the protection and any noindex settings are gone at launch.
Put redirects at the server or CDN level when you can, rather than depending entirely on a WordPress plugin. That way they still work if WordPress has an error, a plugin is disabled, or the database is unavailable. Test the redirect map with an automated crawl and pay attention to capitalization, trailing slashes, HTTP versus HTTPS, subdomains, encoded characters, and old URLs with query parameters. Those small variations are where migrations often leak traffic.
Don’t forget the operational pieces: keep analytics tags and search-console verification working, save a crawl and traffic export before launch, lower DNS caching ahead of a hosting move, and avoid a long maintenance window. After launch, compare old and new landing pages instead of looking only at total traffic. If a particular section drops, you can usually trace it to missing content, an incorrect canonical, a blocked resource, or a redirect that lands somewhere too generic. Keep the old hosting account and redirect configuration available until logs show that search engines and users are consistently reaching the new pages.
A 40-page brochure site can be checked URL by URL; a large site with filters, tags, pagination, and downloads needs an automated migration map or something will slip through. WordPress can quietly create extra indexable URLs such as author archives, attachment pages, feeds, tag pages, and parameter variants, so decide which page types should exist in search before generating the sitemap.
Preserve existing paths where possible. For every changed path, use a direct 301 to the closest replacement and test the full list after launch. Copy titles, descriptions, canonicals, robots directives, structured data, and headings, then confirm them in the rendered HTML rather than trusting the WordPress editor.
I agree with @goldenhub7899 about crawling before and after. The comparison should flag more than broken links: look for pages that changed from 200 to 404, became noindex, point to the wrong canonical, or disappeared from internal navigation. Your new XML sitemap should contain only final, canonical 200-status URLs. Keep a backup of the old URL list even after launch, since forgotten legacy pages often show up later in crawl reports or server logs.
WordPress will add its own redirects behind your back, and that trips people up more than the redirect map itself. It normalizes trailing slashes, forces https, and sometimes bounces uppercase to lowercase, so an old URL can hit your 301 and then get bounced again by core before it lands. That turns a clean single hop into a chain without you writing a single rule for it. @vibergirl is right about handling redirects at the server level, but even then, test the actual URL a link points to and watch how many hops it takes, not just whether it eventually resolves. The other thing that quietly leaks is old absolute links buried inside your own post content pointing at the old domain. Those still fire the redirect on every internal click, so fix them in the database instead of leaning on the redirect layer forever.
If the current site changes every day, a single URL export done weeks before launch is not enough. New posts, products, renamed pages, and deleted content can fall into the gap. Either pause publishing briefly before the move or run a final crawl immediately before cutover and update the redirect map from that. Otherwise you can do everything “right” and still launch with recent indexed URLs returning 404s.
I’d make the launch checklist fairly boring: preserve existing paths where possible, move the page titles and other SEO fields, update internal links to their final destinations, and generate a sitemap from the live WordPress site rather than importing an old file blindly. Check that the sitemap URLs return 200, are indexable, and use the preferred protocol and hostname. Meta descriptions are worth carrying over, but a missing description is less damaging than a missing page, bad canonical, or redirect to an unrelated category.
Set clear rollback conditions before changing DNS. If core sections suddenly return errors, canonical tags point to staging, or the redirect rules fail, rolling back for a few hours is better than leaving a broken migration live while everyone edits WordPress settings under pressure. Keep a database backup, files backup, old crawl, redirect map, and copy of the previous server configuration.
After launch, check individual landing pages rather than staring at the total organic traffic graph. Search engines may take time to process the move, but a whole directory dropping out usually means something specific is wrong. The common culprits are an incomplete final crawl, pages published after the original migration export, or WordPress archive settings creating a different indexable structure than expected.