Does migrating WordPress to new hosting affect SEO if the URLs stay the same?
Not by itself. Google ranks URLs, and a host move leaves every one of them where it was, so there's nothing to redirect. What decides whether Google notices is how the new server answers when Googlebot asks for those same URLs, and checking that is the part of SEO help with a site migration that owners most often skip.
Google has its own guide for moves without URL changes, covering hosting and CDN changes, and the checks below follow it. The problems it guards against are rarely dramatic: an MX record that didn't come across, a test copy that still says noindex, bot protection that treats Googlebot as a scraper, or a server that's slower to answer.
The site moves as it is. If a move also changes URLs, that's a redirect map job, and a domain change has its own Search Console tool. If the new host is for a first launch with no old site, nothing needs protecting yet; that's planning SEO for a new website instead.
What do I record on the old host before copying anything?
Most host move problems come from something nobody wrote down, so before a file moves I record how the old setup behaves.
| What I record | Where it lives | Why it matters later |
|---|---|---|
| Every DNS record: A, AAAA, CNAME, MX and TXT | The DNS provider, which isn't always the web host | MX and TXT records carry email and verification. Lose them and mail stops, and Search Console can't verify |
| The current TTL on the A record | The same DNS zone | It gets lowered well before the switch and goes back up afterwards |
| Robots.txt, the robots meta tag and any X-Robots-Tag header | The live site and its response headers | These are the production values the new server has to match |
| Status codes and response times for 10 to 20 key URLs | Measured with curl and dated | Without a before number, nobody can say whether the new server is slower |
| Redirects in .htaccess or the server config | The old hosting account | Server level redirects from past moves don't travel with a WordPress export |
| The Search Console verification method | An HTML file, a meta tag or a DNS TXT record | Google's guide says an HTML verification file has to be copied across |
The key URLs are the top pages by clicks in Search Console. The TTL is the only item with a lead time: Google suggests lowering it to a conservative low value, a few hours for example, at least a week before the move. I set it on day one.
I also check who hosts the DNS. If the zone sits with the old host and that account's being cancelled, the zone moves too, and that's where email records get lost.
Plugin, manual or the host's tool: which migration method do I use?
Whichever copies the site cleanly on that host. The method matters less than people think, because every one of them moves WordPress and none of them checks what Google sees afterwards. That check is my part, whichever tool did the copying.
| Method | When I use it | What it misses for SEO |
|---|---|---|
| A migration plugin: Duplicator, All-in-One WP Migration or UpdraftPlus | A small or mid-sized site on ordinary hosting, where one archive is simpler than copying thousands of files | It packs WordPress, not the server. DNS records, email and server level rules outside the WordPress folder stay behind |
| Manual: files over SFTP, the database through phpMyAdmin or WP-CLI's wp db export and wp db import | Large sites, stores, or a host that caps upload sizes, since I see every file that moves | Hidden files such as .htaccess are easy to miss, and old redirects often live there |
| The new host's own migration tool or service | A standard install on a host that offers it | It reports the copy as done. Robots.txt, a testing noindex and response time are still unchecked |
UpdraftPlus's listing describes a built-in search and replace engine for the new location. On a same-domain move there's nothing to replace, so I check it changed nothing.
Rather have me do this? One person, whole job.
Book a call on UpworkHow I migrate WordPress to new hosting, step by step
To migrate WordPress to new hosting by hand, back up the files and the database, copy the files to the new server with hidden ones included, import the database into a new one, put its name, user and password in wp-config.php, test through a hosts file, then point DNS at the new server. WordPress's own documentation says that if the database and URL stay the same, you can move by just copying your files and database.
- Step 01
Pick a quiet window and freeze changes
Anything written to the old database after the export is lost. On a WooCommerce store that's orders, so edits wait until the switch.
- Step 02
Back up both halves
The whole WordPress directory, uploads included, plus a full database export, kept somewhere that isn't either server.
- Step 03
Copy the files, hidden ones included
If
.htaccessdoesn't come across, URLs that used to 301 can start returning 404. - Step 04
Import the database and fix wp-config.php
WordPress's documentation says that if the database name or user changes,
wp-config.phphas to be edited to the new values. That's usually the only edit a same-domain move needs. - Step 05
Leave siteurl and home alone
The domain isn't changing, so there's no search and replace. I test through a hosts file instead of editing those two values, so the database stays identical and there's nothing to change back.
- Step 06
Match the server to the old one
The same PHP version, or a newer one I've tested, a valid HTTPS certificate installed before DNS moves, and the same caching setup. I also resave the permalink settings on the new server, since WordPress's documentation says rewrites have to be reconfigured.
Don't cancel the old hosting when the copy's done. Google's guide says to check the old provider's server logs and shut it down once its traffic reaches zero. Until then it's still answering some visitors, and it's the fallback if the new server misbehaves.
How do I test the new server before DNS points at it?
I point my own machine at the new server with a hosts file entry: the domain and the new server's IP address, on one line. My browser and curl then load the real domain from the new host while everyone else still gets the old one.
Then I work through every page template, search, a form that has to reach a real inbox, the admin and, on a store, a test checkout.
Some hosts hand out a temporary URL instead. Google's guide says a test copy should carry a noindex rule, and that's the block most likely to follow the site into production, so every block I add goes on a list that's cleared before the switch.
Compare, don't just look. I run the same curl commands against both servers for the URLs on the record sheet: status code, final URL, robots meta tag, X-Robots-Tag header and canonical. A page can look perfect in a browser and still send a noindex header.
What do I check over HTTP on switch day?
Once the records change, I confirm the domain resolves to the new IP address from a few public DNS checkers, then run these checks against the live domain.
- i.
Robots.txt is the production file
I fetch
/robots.txtand compare it with the saved copy. A test copy'sDisallow: /that travelled across tells Google to stop crawling the whole site. - ii.
The indexing setting isn't ticked
WordPress's Discourage search engines from indexing this site box adds a noindex, nofollow robots meta tag to every page when it's ticked. I read the page source to confirm it's gone.
- iii.
Key URLs answer the way they did
Every URL on the record sheet returns the status code it had before, and old redirects still 301 in one hop.
- iv.
Response time is no worse than the baseline
Same URLs, same curl command, compared with the dated numbers. Google's Crawl Stats help says Googlebot throttles back when a site responds slowly, and that's where server response and caching work comes in.
- v.
Googlebot can reach the new server
I run a live test in the URL Inspection tool on a few key URLs and check the host's firewall or bot protection isn't blocking it.
- vi.
Email and verification still work
I send mail to and from an address on the domain, then check the Search Console property still shows as verified.
What breaks most often after a WordPress host move?
The same handful of faults, and a check above catches each one.
- i.
Error establishing a database connection
WordPress's documentation says it's usually caused by an error in your
wp-config.phpfile, so I check the database name, user, password and host. - ii.
Inner pages 404 while the homepage works
WordPress's documentation points at a corrupted
.htaccessor mod_rewrite not being enabled. Resaving the permalinks and the key URL check catch it. - iii.
A white screen or a critical error
WordPress's documentation says PHP errors and database errors can both show as a blank white screen. After a move the usual trigger is a different PHP version, which is why I match it.
- iv.
Certificate warnings
DNS moved before the new server had a valid certificate, so visitors and Googlebot get an error page. The certificate goes in before the switch.
- v.
Email stops arriving
The MX records didn't move with the zone. The record sheet has every one of them, so they can be put back that day.
What should Search Console show in the week after?
The report that matters most after a host move is Crawl Stats, under Settings, and it's only available for root-level properties. Its host status section checks robots.txt fetching, DNS resolution and server connectivity, which are exactly the three things a host move changes.
In the crawl requests chart I expect a dip right after the switch; Google's guide calls a temporary drop in crawl rate normal. What isn't normal is server errors climbing, or a response time that jumps and stays up.
In the Pages report nothing should change status, because no URL changed. New entries under Excluded by 'noindex' tag or Blocked by robots.txt mean a testing block survived, and I remove it that day. Important pages sliding into Discovered, currently not indexed usually point back at the server. I won't put a date on when everything settles.
Changing hosts soon? I can take the Google half of it: the record sheet, the switch-day checks and a week of Crawl Stats watching. The copy can stay with your host or developer, and I'll check their work at each stage.
Book a call on Upwork
