How to Change WordPress Hosting Without Losing SEO Rankings

Why Migrations Risk SEO Rankings (And How to Avoid It)

A migration appears deceptively simple: copy files, update DNS, go live. The reality is far more complex. Search engines, user browsers, caching layers, SSL certificates, and database content all interact in ways that create cascading failure points. Understanding these failure modes, before they happen, is the foundation of a successful migration strategy. This section breaks down the most common risks and how proper planning eliminates each one.

Broken Redirects and 404 Errors Orphan Your Ranking Signals

When URLs change during a migration, you lose every accumulated ranking signal if the old URL doesn’t redirect to the new one. Every backlink pointing to the old URL becomes worthless without a 301 redirect, because Google treats the old URL as deleted, not moved. Each missed redirect leaks SEO equity: link authority, keyword rankings, click-through history, and user signals all evaporate into the void.

The financial cost is enormous. A high-traffic page with 50 backlinks from authoritative sites is worth thousands in organic search value. Forgetting a single 301 redirect on that page means Google sees it as a 404 error and downranks it. Users who find the old link in a blog or external mention see a broken page instead of your content. Recovery means waiting weeks for Google to discover the new URL, re-crawl it, re-evaluate it, and pass the redirected authority from the old URL to the new one. During that window, you lose traffic and conversion opportunities.

A comprehensive redirect map, created before migration day, is your insurance policy. This map documents every old URL and its new equivalent, so no backlink equity gets lost in translation. Without it, you leave money on the table and hope Google finds your new URLs on its own.

Extended Downtime Signals Unreliability and Reduces Crawl Frequency

When Googlebot repeatedly encounters errors while crawling your site, it interprets this as a sign of unreliability. Google prioritizes crawling sites it trusts, sites that are available and responsive. If your site is offline for days, Google assumes you don’t care about it and allocates its crawling budget elsewhere. Googlebot visits less frequently, misses updates, and takes longer to re-index your content after you come back online.

The duration matters enormously. Brief downtime under 24 hours, when handled properly with 503 Service Unavailable status codes, is tolerated by Google. Cutts, a senior engineer at Google, has stated publicly that a one-day migration outage causes minimal SEO impact if executed professionally. Extended outages, days or weeks, are different. They trigger a cascade of negative signals: reduced crawl frequency, de-indexing of pages Google can’t reach, user frustration, and a collapse in search traffic.

Proper sequencing eliminates this risk. By preparing everything on a staging server before touching production, you minimize the DNS propagation window where traffic is in flight. By provisioning SSL certificates, testing redirects, and verifying database integrity offline, you reduce the time the new site spends unstable. Professional migrations often achieve zero user-visible downtime or brief interruptions measured in minutes, not hours.

Performance Regression on the New Host Harms Core Web Vitals Rankings

Google officially confirmed in 2021 that Core Web Vitals, LCP (Largest Contentful Paint), INP (Interaction to Next Paint), and CLS (Cumulative Layout Shift), influence search rankings. If your new host is slower than your old host, your Core Web Vitals scores will degrade, and Google will rank your pages lower in search results. This happens automatically; Google doesn’t need to recrawl your content to notice the slowdown.

TTFB (Time To First Byte), the server response time, sets a ceiling on LCP performance. If your server takes one second to respond, your LCP score cannot be “good” because the browser can’t even start rendering until the server responds. Choosing a new host that’s slower than your current one guarantees performance regression and ranking loss, regardless of how well you execute redirects and DNS changes.

This is why testing on staging is non-negotiable. Before committing to a new host, you must compare its Core Web Vitals performance to your existing host. If the new host can’t match or exceed your current performance, you need to find a different provider or optimize further.

WordPress Pricing Plans

Choose the WordPress hosting plan that fits your website needs, with reliable performance, security, storage, backups, and tools to help your site grow.

WordPress Basic

$8.99 per month

A great way to get started.

• 1 website
• 10 GB NVMe storage
• Unmetered bandwidth
• Free SSL Certificate *
• WordPress pre-installed
• Weekly backups
• Web Application Firewall
• Daily malware scans
• One-time malware removal

Order Now

WordPress Deluxe

$11.99 per month

Improve your site performance with Cloudflare CDN.

• 1 website
• 20 GB NVMe storage
• Unmetered bandwidth
• Free SSL Certificate *
• WordPress pre-installed
• Daily backups
• Web Application Firewall
• Daily malware scans
• One-time malware removal
• Up to 2x faster performance with global Cloudflare CDN **
• Enhanced security with DDoS protection
• Staging site

Order Now

WordPress Ultimate

$15.99 per month

Add online marketing with more sites, storage and security.

• 1 website
• 30 GB NVMe storage
• Unmetered bandwidth
• Free SSL Certificate *
• WordPress pre-installed
• Daily + on-demand backups
• Web Application Firewall
• Daily malware scans
• Unlimited malware removal
• Up to 2x faster performance with global Cloudflare CDN **
• Enhanced security with DDoS protection
• Staging site
• WordPress code optimizer
• Smart WordPress plugin manager
• Sell online with WooCommerce

Order Now

Pre-Migration SEO Audit and Baseline Assessment

Before you move a single file, establish a clear picture of your site’s current SEO health. This baseline serves three critical purposes: it proves your migration succeeded (compare after launch), it identifies high-value assets you must protect, and it gives you targets for post-migration recovery. Skipping this step means launching without knowing what you had to lose, a dangerous position if rankings drop and you need to diagnose the cause.

Document Current Rankings, Traffic, and Crawl Health

Pull a full report from Google Search Console’s Coverage report showing how many pages Google has indexed, how many are excluded, and any crawl errors. Take screenshots of your current top keywords and their ranking positions from Search Console’s Performance report. Export organic traffic data from Google Analytics broken down by page, landing keyword, and device (mobile vs. desktop) for the past 3–6 months. This data becomes your recovery benchmark; if organic traffic drops 50% after migration, you know something went wrong and needs fixing immediately.

Also run a technical crawl of your entire site using a tool like Screaming Frog or Ahrefs. Document existing 404 errors, broken internal links, redirect chains, or blocked resources. These issues aren’t caused by your migration, but you may mistake them for migration problems if you don’t document them in advance. If Screaming Frog reports 50 broken images before migration and 50 after, you know the migration didn’t break images. Still, if you find 100 broken images after migration and didn’t check before, you’ll waste days investigating a pre-existing problem.

Take screenshots of your Core Web Vitals scores from Google PageSpeed Insights or Search Console’s Core Web Vitals report on both mobile and desktop. Record your site’s average TTFB (Time To First Byte) from Search Console or your hosting provider’s monitoring dashboard. Use these metrics as your baseline for comparing the new host’s performance. If your current host delivers LCP under 2.5 seconds and your new host delivers 3.2 seconds, you’ve made a mistake in choosing the new host; performance has regressed, and your rankings will follow.

Identify High-Value Pages and Traffic-Driving Content

Export your top 100 pages by organic traffic. These are your crown jewels; every redirect must point these pages accurately, and every internal link must stay functional. If your site has 5,000 pages but 100 of them drive 80% of your traffic, focus your redirect mapping and testing effort on those 100. A perfect redirect for a low-traffic page that nobody links to is worth far less than a perfect redirect for a high-traffic page with 50 backlinks.

Use Search Console’s Links report to identify pages with exceptional backlink profiles. If one page has 100 backlinks and another has 2, the first page is an SEO asset worth protecting. Mark these for priority testing during the migration. A single broken redirect on a highly linked page costs more in lost authority than broken redirects on 10 low-traffic pages.

Also note any pages that rank in Google’s top 10 for high-value keywords. If you rank in position 3 for a keyword worth thousands in conversion value, that page is mission-critical. Losing that ranking due to a migration mistake isn’t just an SEO problem; it’s a revenue problem. Treat these pages as priority one for redirect mapping and testing.

Mapping URLs and Building Your Redirect Strategy

A redirect map is a simple document: old URL → new URL → HTTP status (301 permanent, or 404 if the page is being deleted). This document is the foundation of your entire migration. Without it, you’re gambling that Google will find your content on the new URL without any guidance. With it, you ensure every backlink, every search result, and every user who finds an old link still reaches your content.

Create a Complete Old-to-New URL Map

Export every URL from your current site using a site crawler (Screaming Frog) or by exporting your WordPress posts and pages. For each URL, determine where it lives on the new site. If you’re keeping the same domain and URL structure (host-only migration), many URLs won’t change. If you’re changing domains or restructuring URLs, you need a one-to-one mapping for every page that will exist on the new site.

Ask yourself: “Is this page worth keeping?” For pages you’re deleting with no replacement (old blog posts, archived content, outdated services), decide whether to return a 404 or redirect to a related page. Avoid mass-redirecting everything to your homepage, as this wastes the authority of individual pages. Instead, redirect old blog posts to a blog archive page, old product pages to a current products page, and old service pages to relevant current service pages. If there’s genuinely no good replacement, returning a 404 is more honest than misleading users with an irrelevant redirect.

Use a spreadsheet to document this map. Columns: Old URL, New URL, Status Code (301, 404, or 302 temporary). This spreadsheet becomes your implementation guide on launch day. If your map has 2,000 rows, you need to implement 2,000 redirects, either through bulk .htaccess rules, WordPress plugin rules, or your hosting provider’s redirect tool.

Test Redirects Before Going Live

Before flipping DNS to the new host, test your redirects on the staging server. Access the new site using a temporary hosts file modification or a test subdomain so you can simulate the new site already being live. Click through your top 50 pages and verify each one redirects correctly to its new location. Use a tool like Redirect Checker or your browser’s Network tab to confirm the redirect returns a 301 status code (not 302 or 307), so Google knows this is a permanent move.

Also test redirect chains. If old URL A redirects to URL B, which redirects to URL C, you have a redirect chain, and Google discounts the authority transfer through chains. Chains should be minimal (one hop ideally, two at most). If you find a three-hop chain, simplify it so the old URL redirects directly to the final destination.

Test both HTTP and HTTPS versions of your URLs. If your old site is HTTP and your new site is HTTPS, the full chain should be: old HTTP URL → old HTTPS URL (automatic) → new HTTPS URL. This can create a two-hop chain, which is acceptable. But verify it works smoothly before going live; a broken HTTPS chain causes certificate errors and lost traffic.

Planning DNS, TTL, and SSL Certificate Provisioning

DNS is the traffic switch that tells the internet where your website lives. Getting DNS timing right can mean the difference between a seamless migration and hours of confusion, where some users see the old site and others see the new one. This section covers the technical sequencing that minimizes this window of unpredictability.

Lower TTL Before Migration Day

TTL (Time To Live) is a DNS setting that tells resolvers how long they can cache a DNS record before checking for updates. If your TTL is 86,400 seconds (one day), a resolver that queries your DNS record at 9 AM will use that cached record until 9 AM the next day, ignoring any updates you make in between. For migration purposes, this is terrible: some parts of the internet won’t know about your DNS change for up to 24 hours.

Lower your TTL to 300 seconds (5 minutes) at least 24 hours before your planned migration. This tells resolvers to refresh your DNS record every 5 minutes instead of every 24 hours. When you change your DNS on migration day, the new record spreads much faster because resolvers aren’t hanging onto a day-old cached copy.

Critical timing: lower TTL at least 24 hours before migration, not the day of or the hour before. If you lower TTL on launch day at 8 AM and plan to switch DNS at 6 PM the same day, resolvers that have already cached your 24-hour TTL value won’t respect the new 5-minute TTL until that 24-hour window expires. Timing matters enormously.

After lowering TTL, verify the new value is live using a DNS checker tool. Query your DNS from multiple locations and confirm that TTL values show 300 seconds, not 86,400. This ensures resolvers around the world begin caching short-lived copies of your DNS record before you make the big switch.

Provision SSL Certificates Before Switching DNS

The SSL/TLS handshake, the encryption negotiation between browser and server, happens before any HTTP redirect code can execute. If your domain uses HTTPS (which it must for modern WordPress sites), you need a valid SSL certificate on the new hosting server before DNS points traffic there. Provisioning the certificate after flipping DNS causes HTTPS certificate errors: browsers show security warnings, users panic and leave, and Google crawlers encounter errors that prevent indexation.

Request or generate your SSL certificate on the new host at least 2–3 days before migration. If you’re changing domains, request a certificate that covers the new domain (and optionally the old domain during the transition period). Test the certificate by accessing the new site via HTTPS using a temporary URL or hosts-file modification; you should see no certificate errors or warnings.

If you’re using Let’s Encrypt (a free, automated SSL service), note that some ACME challenges require DNS to already point to your new server. Plan accordingly: if your provider’s ACME challenge requires DNS pointing, you may need to provision the certificate earlier or use an alternative validation method.

Common mistake: provisioning the certificate AFTER switching DNS. You flip DNS at 6 PM, traffic arrives, and browsers ask your new server, “Do you have an SSL certificate for this domain?” Your server doesn’t have one yet, so browsers show an error, users bounce, and you scramble to provision it under pressure. Avoid this by provisioning 48+ hours in advance.

Staging Environment Setup and Pre-Launch Testing

Never migrate directly from old production to new production. Instead, create a staging copy of your site on the new host, test everything exhaustively, and only then switch traffic. Staging is your risk-free sandbox where you can break things, fix them, and verify success without affecting real users or search engines.

Clone Your Site to Staging and Configure Caching

Use a migration tool, Duplicator, All-in-One WP Migration, or your hosting provider’s built-in migration service, to copy your entire WordPress installation to a staging subdomain on the new host. This copy includes all files, the database, theme settings, plugin configurations, and media. After cloning, access staging and verify basic functionality: can you log in? Do pages render correctly? Do images display? Are plugins active and functioning?

Once the clone succeeds, configure caching. Many WordPress hosts offer server-level caching (Redis, Memcached, or built-in caching layers) that significantly improve page load times. Enable caching on staging and monitor your site’s performance before and after. Use Google PageSpeed Insights to test mobile and desktop performance and compare Core Web Vitals scores to your current site.

If staging shows poor performance, investigate before launch. Is caching properly configured? Are database queries slow? Are large images unoptimized? Are JavaScript assets large and render-blocking? Fixing these issues on staging is far easier than diagnosing performance problems on live production while search engines crawl and users wait.

Audit Redirects, Robots.txt, and Canonical Tags on Staging

With staging live, test your redirect rules by accessing old URLs and verifying they redirect to new ones. Use your browser’s developer tools (Network tab) to confirm each redirect returns a 301 status code, not 302 or 307. Also check that redirect chains are minimal.

Examine your robots.txt file on staging, and make sure it doesn’t contain “Disallow: /” from a staging configuration. This is a common mistake: staging sites are often configured to block all search engines, and developers forget to remove this rule before going live. If your robots.txt blocks Google, your new site will never be indexed, and your rankings will plummet to zero.

Verify that canonical tags on staging pages point to the new domain (not the old domain). Canonical tags tell Google which version of a page to rank if duplicates exist. If your staging page has a canonical tag pointing to the old domain, Google will rank the old version instead of the new one, defeating your migration.

Run a site crawl on staging using Screaming Frog or a similar tool. Look for: broken internal links, missing images, 404 errors, mixed-content warnings (HTTPS pages with HTTP resources), JavaScript errors. Fix each issue on staging before launch. Every problem you catch now is one you won’t have to troubleshoot under pressure on launch day.

Verify Plugin Compatibility and Theme Rendering

Update all plugins and your theme to their latest versions before launching. Old versions sometimes have compatibility issues with new servers or configurations. Test critical plugins: WooCommerce (if you sell products), contact form plugins, SEO plugins, cache plugins, backup plugins. Verify they activate, function correctly, and don’t cause errors.

Check theme rendering by viewing your homepage, blog page, single post, single page, archive pages, and category pages. Ensure all elements load correctly, images display, buttons work, forms submit, and layout doesn’t break on mobile. Test on real devices if possible; mobile responsiveness issues you miss on desktop can devastate mobile rankings and user experience.

Database Migration and URL Search-Replace

Moving your WordPress database to a new server or domain requires more than just copying the database file. WordPress stores absolute URLs throughout the database, in post content, settings, plugin options, serialized PHP data, and countless other places. Every old URL reference must be replaced with the new one, but doing this wrong can corrupt data or break plugins.

Backup Before Any Database Modifications

Before touching the database, take a full backup on the new host. Your provider usually handles this automatically, but confirm it. Then, if the search-replace corrupts data, you can restore and try again without losing work.

When replacing URLs, never modify the database directly with raw SQL unless you’re experienced with MySQL. Raw SQL commands can corrupt serialized data if you’re not careful. Instead, use WordPress’s built-in tools or safe plugins like Better Search Replace, which handle serialized data correctly.

Use WordPress CLI (command line) or a plugin to search for your old domain URL (e.g., http://olddomain.com) and replace it with the new domain (e.g., https://newdomain.com). Pay attention to the protocol: if you’re changing from HTTP to HTTPS, search for the exact HTTP URL and replace it with the exact HTTPS URL. Most plugins show a preview of how many replacements they’ll make before you confirm; always check this number to avoid surprises.

Verify Post Content and Settings After Replacement

After the search-replace finishes, spot-check several posts and pages. Click into the WordPress admin, open a few pieces of content, and verify internal links work, images display, formatting looks correct, and plugin data hasn’t broken. Click through a few published pages on the frontend to confirm everything renders correctly for visitors.

Check WordPress settings: navigate to Settings → General and confirm your Site URL and WordPress URL are set to the new domain (with HTTPS if applicable). If they’re not, update them manually. Plugins, themes, and WordPress core functionality often reference these settings, and leaving them on the old domain causes cascading errors across your site.

Some plugins store URLs in serialized arrays in the database. Search-replace sometimes breaks these if not handled carefully. Test all critical plugins after search-replace: WooCommerce checkout, contact forms, booking systems, payment gateways. If functionality is broken, you may need to deactivate and reactivate the plugin, or contact the plugin developer for support.

Hosting Performance and Core Web Vitals Comparison

Choosing a new host isn’t just about capacity or uptime; it’s about whether the host can deliver the performance Google needs to rank your pages well. A migration to a slower host defeats the entire purpose. Before committing to a new host, test its performance on staging and compare it to your current site.

Test Core Web Vitals on the New Staging Site

Use Google PageSpeed Insights to analyze your staging site on both mobile and desktop. Record the three Core Web Vitals metrics: LCP (should be under 2.5 seconds for “good”), INP (should be under 200ms for “good”), and CLS (should be under 0.1 for “good”). Compare these scores to your current site’s metrics.

If the new host scores significantly worse than your current host, investigate the reason. Is server-level caching disabled? Are database queries slow? Are plugins poorly optimized? Is the server overloaded? Ask your provider why staging performance is lagging. If they can’t explain or improve it, consider a different host; performance after migration will likely be worse than staging performance.

TTFB (Time To First Byte) matters: it directly affects LCP and shows how responsive your server is. A TTFB under 200ms is excellent, 200-600ms is acceptable, and over 600ms signals a slow or congested server. If your new host’s TTFB is 500ms and your old host’s is 150ms, you’ll see measurable performance regression and ranking loss. Don’t accept this; it’s a sign you need a faster host.

Monitor Uptime and Server Resources During Load Testing

Check your new hosting provider’s published uptime track record. Do they provide an SLA (Service Level Agreement) guaranteeing a minimum uptime percentage? Do they publish a status page showing historical uptime? If they’re vague about uptime, that’s a red flag; a quality host publishes these metrics proudly.

Ask your provider what resources your plan includes: dedicated or shared CPU cores, RAM allocation, disk type (NVMe SSDs are much faster than traditional HDDs), and bandwidth limits. NVMe SSDs make an enormous performance difference compared to older disk technologies; if your new host uses HDDs instead of NVMe, performance will suffer.

Simulate realistic traffic on staging using a load-testing tool like ApacheBench or LoadImpact. Send concurrent requests to your staging site and monitor how server response times change under load. If response times stay under 500ms even at 50 concurrent users, your server has good headroom. If response times spike to 2+ seconds under load, the server will struggle when real traffic arrives.

Final Pre-Launch Checklist and Cutover Day Logistics

Launch day is when everything you’ve prepared comes together. A written checklist prevents the chaos of improvisation when you’re tired and focused on making sure everything works. Review this checklist 24 hours before launch, then again 2 hours before DNS changes.

Confirm DNS Records, Redirects, and Search Console Setup

Document your current DNS records. Log into your domain registrar (GoDaddy, Namecheap, etc.) and screenshot your current DNS configuration showing A records, CNAME records, MX records for email, and any other records. Then document the new DNS records from your new hosting provider, the IP address or CNAME they want you to point to.

Create a DNS change ticket that documents the old and new records side by side, so you can make the switch quickly without fumbling for information. Also verify that you’ve already registered both your old domain and new domain in Google Search Console. This is critical: you need ownership verification on both domains to use Search Console’s Change of Address tool immediately after migration.

Test your redirects one final time using curl or your browser. Access 3–5 of your most important old URLs and verify they redirect to the correct new URLs with 301 status codes. Also verify you can access your new site directly using the new domain (or a temporary URL), and it displays correctly.

Alert Your Team and Plan the Launch Window

Brief everyone who touches your site about the migration and the expected timeline. Give them a staging URL so they can test functionality before DNS switches. Explain when downtime might occur (usually brief, 15–30 minutes max), and when things should be fully stable (within 1–2 hours).

Choose a low-traffic time for the migration. Weeknights and weekends are ideal; if something goes wrong, fewer users are affected. Avoid launch windows during peak traffic times, major marketing campaigns, or high-revenue sales windows. If your site makes significant revenue on weekday evenings, don’t migrate Thursday evening.

Designate someone to monitor Search Console, analytics, error logs, and uptime monitoring during and after migration. Have a rollback plan: if something goes catastrophically wrong in the first hour, can you quickly revert DNS to the old host? Document the rollback steps so whoever executes it doesn’t fumble under pressure.

Launch Day Execution and Monitoring

Launch day is where planning meets reality. You’ve tested everything on staging; now you execute the planned switches. Watch carefully for the first 2–4 hours; most issues surface immediately and are easiest to fix while fresh.

Switch DNS and Monitor Propagation in Real Time

At your designated launch time, update your DNS records through your domain registrar. Point your domain’s A record (or CNAME) to the new host’s IP address (or CNAME). This single DNS change directs all future traffic to your new host. DNS propagation begins immediately but takes time; some resolvers pick up the change within 15 minutes, others within a few hours, and some legacy resolvers might take up to 48 hours.

Use a DNS propagation checker tool to monitor changes in real time. You’ll see which nameservers globally have picked up your new DNS record. Within 30 minutes, most major ISPs and resolvers should show the new record. Within 2 hours, 90%+ of the internet should be pointing to your new host.

Immediately after switching DNS, open your site from multiple browsers, devices, and locations. Check from your phone, your computer, and, if possible, a different ISP or VPN location. Verify that pages load, HTTPS works without certificate errors, internal links function, and images display. Spot-check your 5 most important pages to confirm they’re serving from the new host without errors.

Submit New Sitemap and Monitor Crawl Errors

Within 30 minutes of DNS switching, log into Google Search Console for your new domain and manually submit your XML sitemap. This tells Google, “I’ve migrated; here’s the new site.” If your new domain is completely new (not just a host change), you should have already verified ownership in Search Console in advance; verify it now if you haven’t.

If you changed domains, use Google Search Console’s Change of Address tool immediately. This tells Google explicitly that your site moved from the old domain to the new domain, and Google should transfer ranking signals accordingly. The Change of Address tool continues forwarding signals for 180 days, giving plenty of time for all old URLs to be de-indexed and replaced with new ones.

Over the next 4 hours, check Search Console’s Coverage report every 30 minutes. You’re watching for crawl errors to spike, which would indicate broken redirects, blocked resources, or indexing problems. Some crawl errors are normal immediately after migration as Google discovers the new site, but watch the trends. Errors should decline as Google successfully crawls pages, not increase.

Post-Migration Monitoring and Recovery

The migration is live, but the work isn’t done. Ranking recovery takes time, and early intervention catches problems before they become weeks-long issues. Block off at least 30 minutes daily for the first two weeks to monitor Search Console, analytics, and uptime.

Check Coverage and Crawl Error Reports Daily

Log into Google Search Console each morning for 14 days post-launch and review the Coverage report. Healthy trends you should see: old URLs declining in count (as Google re-indexes the new ones), new URLs increasing, and crawl errors staying low (under 5% of total pages). If errors spike to 30%+ of your pages, this signals a structural problem, likely broken redirects, a misconfigured robots.txt, or the wrong Noindex setting.

If the Coverage report shows specific pages with indexation errors, click into each error and investigate. Can you access the page in a browser? Does it return a 200 OK status? Is there an accidental Noindex meta tag? Is the page blocked by robots.txt? Fix the underlying issue and resubmit the page to Google Search Console; Google will re-crawl it within hours.

Pay particular attention to your top 50 pages. If any of them show errors or aren’t being indexed, fix them immediately. These high-traffic pages drive revenue, and indexation errors directly hurt revenue.

Track Organic Traffic and Rankings for Early Recovery Signs

In Google Analytics, create a custom date range showing organic traffic for the post-migration period only (from the migration date onward). Compare daily organic visitors to the same dates last month. Some traffic fluctuation is normal; rankings bounce while Google re-evaluates new URLs, but watch for stabilization over 7–14 days.

Use Search Console’s Performance report to track keyword rankings week over week after migration. After a successful migration with proper redirects, rankings typically stabilize within 2 weeks. If rankings are still declining sharply after two weeks, you likely have a structural SEO problem that needs urgent diagnosis.

Create a spreadsheet tracking these metrics daily:

• Organic traffic from Google Analytics
• Number of pages indexed (from Search Console Coverage)
• Crawl errors (from Search Console Coverage)
• Average keyword ranking position (from Search Console Performance)
• Core Web Vitals scores (from Search Console or PageSpeed Insights)

This daily tracking gives you early warning of problems. If organic traffic drops 40% on day 3 but recovers to 90% by day 10, that’s normal fluctuation. If traffic drops 40% and stays there through day 14, that’s a problem.

Frequently Asked Questions

How long does a typical WordPress hosting migration take from start to finish?

A complete migration typically takes 5–10 days from initial planning to full recovery. Pre-migration planning and staging setup require 3–5 days, the actual DNS switch and migration happen within hours, and recovery (ranking stabilization) takes 7–30 days depending on site size and complexity. Larger sites with thousands of pages may extend timelines slightly.

Can I migrate WordPress without any downtime at all?

Yes, with careful planning, most migrations achieve zero user-visible downtime. Using a staging environment on the new host, provisioning SSL certificates in advance, reducing DNS TTL, and implementing redirects before the DNS switch all minimize the downtime window. Many professional migrations complete with users experiencing only brief connection hiccups measured in seconds, not minutes or hours.

What’s the difference between a 301 redirect and a 302 redirect, and why does it matter for SEO?

A 301 is a permanent redirect telling search engines a page moved forever; Google transfers ranking signals through 301s. A 302 is temporary, suggesting the redirect is temporary; Google doesn’t transfer signals through 302s. During migrations, always use 301 redirects for every URL that’s moving, so you retain the ranking value you’ve built.

Do I need to use Google Search Console’s Change of Address tool if I’m changing hosts (not domains)?

No, Change of Address is only for domain migrations. If your domain stays the same and you’re just moving to a new host, you don’t need Change of Address. You still need to verify the site in Search Console and submit your sitemap, but Change of Address is specifically for domain-to-domain moves.

What are Core Web Vitals and how do they affect my SEO ranking after migration?

Core Web Vitals are three user experience metrics Google uses to rank pages: LCP (how fast the page loads), INP (how responsive the page is), and CLS (how stable the layout stays while loading). Google officially made these ranking factors in 2021. If your new host is slower than your old host, your Core Web Vitals will degrade and your rankings will drop proportionally.

What’s TTFB and how does it impact migration success?

TTFB (Time To First Byte) is the server response time- how long it takes your server to start responding to a browser request. TTFB directly impacts your Largest Contentful Paint (LCP) score; if TTFB is slow, LCP cannot be fast. Comparing TTFB between your old and new host is a key way to evaluate whether the migration will improve or degrade performance.

How important is backing up my WordPress site before migration?

Absolutely critical. Always back up your entire site (files and database) before beginning migration. If something goes wrong during migration, you need to restore from backup to recover quickly. A backup is your safety net; without it, you’re gambling that nothing will go wrong during a high-risk operation.

What should I do if my WordPress site is still showing old URLs in Google search results weeks after migration?

This indicates incomplete redirect implementation or a failure to use the Change of Address tool. First, verify redirects are working by accessing old URLs directly. Second, use Search Console’s Change of Address tool if you changed domains. Third, manually request re-indexing of new URLs through Search Console. Finally, check that your canonical tags point to the new URLs.

Can external linking tools or plugins cause problems during migration?

Yes, if they’re not updated for the new domain. Services like Google Analytics, Facebook Pixel, Mailchimp, and other integrations may need API keys or tracking code updates after migration. Test all external integrations within 24 hours of launch to ensure they’re collecting data from the new site correctly.

How do I test if my redirects are working properly before launch?

Access the new site using a temporary URL or hosts-file modification so you can simulate the new site being live. Then access old URLs and verify they redirect to new ones. Use your browser’s developer tools (Network tab) to confirm each redirect returns a 301 status code. For larger sites, use a redirect testing tool or write a script to test dozens of redirects at once.

What’s DNS TTL and why do I need to lower it before migration?

TTL (Time To Live) tells internet resolvers how long to cache a DNS record. A high TTL (86,400 seconds) means resolvers cache your DNS for a full day, great for stability but terrible for migration because changes propagate slowly. Lowering TTL to 300 seconds at least 24 hours before migration ensures resolvers refresh frequently, so your new DNS record spreads quickly when you change it.

What should my robots.txt file look like after migration to avoid blocking Google?

Your robots.txt should allow Google access to all public pages and critical resources (CSS, JavaScript, images). Block only admin pages and private areas. A minimal production robots.txt looks like: User-agent: *, Disallow: /wp-admin/, Disallow: /wp-login/, Sitemap: https://yourdomain.com/sitemap.xml. Verify robots.txt doesn’t contain “Disallow: /”, which blocks all crawlers.

How long after migration should I keep my old hosting account active?

Keep your old hosting account active for at least 90 days post-migration, maintaining 301 redirects throughout. This gives Google ample time to re-crawl, transfer ranking signals through redirects, and de-index old URLs. After 90 days, you can deactivate the old account, but verify first that all old URLs have been removed from Google’s index.

What’s the most common reason WordPress migrations fail to recover rankings quickly?

Missing or incomplete redirects. If old URLs aren’t redirected to new ones, Google sees them as deleted pages, and you lose all accumulated ranking value. Every unredirected URL leaks SEO equity. A comprehensive redirect map created before launch and thoroughly tested on staging prevents this; the most common migration failures stem from skipping this step.

Should I expect my traffic to drop during the first week after migration?

A moderate traffic dip (10–30%) during the first week post-migration is normal and usually temporary. Google takes time to re-evaluate your new URLs and transfer ranking signals. However, if traffic drops more than 50% or doesn’t recover by week two, something structural went wrong (broken redirects, performance regression, indexation blocks) and needs diagnosis and repair.

Glossary

• 301 Redirect: A permanent HTTP status code that tells search engines a page has moved forever to a new location. Google transfers ranking signals (backlink authority, keyword rankings) through 301 redirects, making them essential for migrations.
• Core Web Vitals: Three Google-defined metrics measuring user experience: LCP (Largest Contentful Paint, target under 2.5 seconds), INP (Interaction to Next Paint, target under 200ms), and CLS (Cumulative Layout Shift, target under 0.1). These metrics influence search rankings.
• TTFB (Time To First Byte): The time it takes a web server to respond to a browser request. TTFB directly impacts page-load performance and acts as a ceiling for LCP scores; slow TTFB makes fast LCP impossible.
• DNS Propagation: The process by which DNS record changes spread across internet resolvers globally. Propagation typically takes 15 minutes to 48 hours depending on TTL values and ISP caching policies.
• Staging Environment: A copy of your WordPress site on the new host used for testing before directing real traffic. Staging allows risk-free testing of redirects, performance, plugins, and functionality.
• Canonical Tag: An HTML meta tag specifying which version of a page should be ranked by search engines when duplicates exist. During migration, canonical tags must point to the new domain after launch.