--- title: "Migrating a WordPress site without losing rankings" id: "298" type: "post" slug: "migrating-a-wordpress-site-without-losing-rankings" published_at: "2026-05-05T09:00:00+00:00" modified_at: "2026-10-06T15:11:12+00:00" url: "https://danielpazwp.com/migrating-a-wordpress-site-without-losing-rankings/" markdown_url: "https://danielpazwp.com/migrating-a-wordpress-site-without-losing-rankings.md" excerpt: "The redirect map, the checks before and after launch, and what to watch in the first 30 days when you move a WordPress site." taxonomy_category: - "SEO" --- [SEO](https://danielpazwp.com/category/seo/) 6 min read # Migrating a WordPress site without losing rankings The redirect map, the checks before and after launch, and what to watch in the first 30 days when you move a WordPress site. Published **05/05/2026**Updated **06/10/2026**6 min read [Written byDaniel PazDaniel Paz has worked on the web for more than 14 years and has focused on WordPress since 2016. He is CEO and founder of WebOption, creator of WP Alta Performance (Brazil’s reference channel on WordPress optimization) and has shipped WordPress for Globo, Shell, Endeavor, Estratégia Concursos and Brazil’s Federal Government. He speaks at WordCamp Brazil, WordCamp Canada and WordCamp US, TDC and PHP Conference Brazil.](https://danielpazwp.com/author/daniel-paz/) You migrate a WordPress site without losing rankings by changing as little as possible from a search engine’s point of view, and by mapping everything that does change. Keep URLs identical where you can. Where you cannot, redirect every old URL to its closest equivalent with a single 301. Keep titles, content, internal links, canonicals and structured data intact, block staging properly, and check crawl errors and Search Console daily for the first weeks. Rankings rarely drop because of the move itself. They drop because URLs, content or signals disappeared along the way and nobody noticed. ## What causes ranking drops after a migration? “Migration” covers very different projects: moving to a new host, switching from HTTP to HTTPS, changing domain, redesigning the theme, restructuring URLs, or moving from another CMS into WordPress. Every one of those you combine in a single launch adds risk. When I review migrations that went wrong, I find the same causes almost every time: - Old URLs returning 404 because nobody built a redirect map. - Redirects pointing everything to the homepage instead of to equivalent pages. - The staging site’s noindex or “Discourage search engines” setting going live with the new site. - Content removed or thinned during the redesign: shorter category descriptions, deleted FAQs, merged pages. - Internal links still pointing at old URLs, so every click and crawl passes through a redirect. - Canonicals, hreflang or sitemaps still referencing the staging domain. - A slower server or heavier theme that pushes Core Web Vitals in the wrong direction. None of these is exotic. They happen because the migration gets run as an infrastructure task, and SEO is checked at the end, if anyone checks it at all. ## Before the move: inventory everything You cannot protect what you have not listed. Before touching anything, build a full inventory of the current site: - Crawl the live site and export every indexable URL, with status, title, meta description, canonical and H1. - Export the XML sitemaps. - Export the top pages by clicks and impressions from Search Console, and the top landing pages from analytics. - Export the URLs with external backlinks from your link tool of choice. Then merge the lists. Crawls miss orphan pages, and Search Console shows URLs that still earn traffic even when nothing links to them internally. The combined list is your baseline, and later it becomes your test suite. > The redirect map is the migration. Everything else is moving files. ## The redirect map: one old URL, one new URL If URLs stay the same, you are in the safest scenario. A hosting-only migration often should not change anything a search engine can see. If URLs change, every URL in your inventory needs a destination. Map each one to the most relevant equivalent page, not to the homepage or a generic category. Google treats mass redirects to the homepage much like soft 404s, so the authority of the old page does not carry over in any meaningful way. Implement the map with 301 redirects, one hop each, ideally at the server or edge level. Avoid chains. If the site also moves from HTTP to HTTPS or from non-www to www, the old URL should jump straight to the final version. And keep the redirects for a long time. Google recommends at least a year. I leave them in place indefinitely unless there is a reason to remove them, because old backlinks keep sending visitors and crawlers for years. ## Staging, database and launch-day checks On WordPress, a handful of technical details cause most launch-day problems. Protect staging with HTTP authentication, not just robots.txt or noindex. Robots.txt does not stop URLs that are linked from elsewhere from being indexed, and a noindex setting is easy to carry over to production by accident. With authentication, crawlers cannot get in, and there is nothing to remember to switch off at launch. When the domain changes, use `wp search-replace` from WP-CLI instead of a raw SQL replace. WordPress stores serialized data in options and post meta, and a plain text replacement breaks the serialized string lengths. WP-CLI handles that correctly, and the `--dry-run` flag shows you what will change before it does. On launch day, check at least these: - Settings, Reading: “Discourage search engines” is off. - robots.txt allows crawling and lists the new sitemap. - Canonicals, hreflang, Open Graph URLs and structured data point to the production domain. - A sample of old URLs from the inventory returns a single 301 to the right destination. - Key pages return 200 with the expected title, H1 and content. - Page cache, object cache and CDN are configured on the new server and actually hitting. ## After launch: monitor, then fix fast The first two to four weeks matter most. Re-crawl the old URL list against the new site and fix any 404 or chain right away. Submit the new sitemap in Search Console. If the domain changed, verify the new property and use the Change of Address tool, which exists for exactly this case. Then watch, daily at first: the Page indexing report, crawl stats, and clicks and impressions for the pages that mattered most in your baseline. Some fluctuation is normal while Google recrawls and reprocesses the site, and on larger sites it can take weeks to settle. What is not normal is one specific group of pages losing visibility while the rest holds steady. That almost always has a concrete cause: missing redirects, changed content, or a template that lost something important. Don’t forget performance. A move to a new host or theme is a good moment to improve Core Web Vitals, and an easy moment to make them worse. Compare field data before and after, and remember that CrUX uses a 28-day window and needs time to reflect the change. ## Should you do it yourself or hire help? Many site owners can move a small blog to a new host with unchanged URLs on their own, using a checklist like the one above. A domain change, a URL restructure, a WooCommerce store with thousands of products or a CMS switch carries a different level of risk, because the redirect map and the content parity checks turn into projects of their own. That is the kind of work my team at WebOption does in our [WordPress migration service](https://weboption.com.br/migracao-wordpress/) , where SEO and performance are part of the migration and not something we check afterwards. Whoever runs yours, the principle is the same: inventory first, map every URL, change as little as possible at once, and keep measuring until the numbers settle. [Work with Daniel](https://danielpazwp.com/#book) [More in SEO](https://danielpazwp.com/category/seo/) [About the authorDaniel Paz has worked on the web for more than 14 years and has focused on WordPress since 2016. He is CEO and founder of WebOption, creator of WP Alta Performance (Brazil’s reference channel on WordPress optimization) and has shipped WordPress for Globo, Shell, Endeavor, Estratégia Concursos and Brazil’s Federal Government. He speaks at WordCamp Brazil, WordCamp Canada and WordCamp US, TDC and PHP Conference Brazil.Author page](https://danielpazwp.com/author/daniel-paz/) ## Related articles [All articles](https://danielpazwp.com/blog/) [SEO Oct 2026Are Core Web Vitals a ranking factor?](https://danielpazwp.com/core-web-vitals-ranking-factor/) [SEO Jun 2026Technical SEO starts in the server response](https://danielpazwp.com/technical-seo-starts-in-the-server-response/) [Career Oct 2026How to become a WordCamp speaker (2026 guide)](https://danielpazwp.com/how-to-become-a-wordcamp-speaker/)