iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
If WordPress shows “Server Not Found” immediately after a hosting move, check DNS before reinstalling WordPress. The usual causes are a nameserver or A-record change that has not reached every resolver, an old entry in your computer’s hosts file, a stale local DNS cache, or conflicting records left at the previous host. Keep the old hosting account available while you test the new site, then verify WordPress’s own domain settings after DNS reaches the new server.
What “Server Not Found” means after a host move
Your browser must first translate the domain name into a server address. That translation is handled by DNS. A hosting change is complete for visitors only when DNS sends requests to the new infrastructure. During the transition, different networks can still resolve the domain to the old server, to a test address, or to no address at all.
That is why one device may show the new site while another reports that the server cannot be found. The WordPress files can be perfectly intact; the request may simply never reach them.
Public DNS versus your computer’s hosts file
A hosts file is a local override. It maps a domain to an IP address on one computer before the operating system asks public DNS. Developers often add a line during migration so they can preview a new server. If that line remains after the move, the computer continues to use the old or test IP even though the public DNS records are correct.
#1 Best Overall
Because the override is local, changing it will not fix the same error for visitors elsewhere. Conversely, a colleague may be able to open the site while your machine fails because only your hosts file is wrong.
Why cached DNS causes apparently random results
Operating systems, browsers, home routers, offices and internet providers can cache DNS answers. A cached answer can outlive the record change you made at the registrar. Flushing the local cache and testing from another network separates a local stale result from a public DNS problem.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Use the symptom to identify the scope
| What you observe | Most likely scope | First action |
|---|---|---|
| The site fails only on one computer | Hosts-file override or local DNS cache | Inspect the hosts file, flush DNS, restart the browser, and retry. |
| The site works on mobile data but not on office or home Wi-Fi | A local resolver or router still has an old answer | Test another network, reboot the router if appropriate, and compare DNS results. |
| The site fails on several unrelated networks | Nameservers, A record, or a missing zone at the registrar | Check the registrar’s nameserver setting and the new host’s DNS records. |
| A propagation checker shows the new address, but your browser still fails | Local cache, hosts-file entry, browser state, or a WordPress/SSL routing issue | Flush local DNS, remove overrides, then check WordPress URL and SSL settings. |
A worldwide checker is useful evidence, not a guarantee. It reports what selected public resolvers see; it does not change your computer’s hosts file or clear every cached answer.
Step-by-step: restore access after changing hosting
1. Check and correct the hosts file
Do this first when the failure is limited to one machine or when you previously used a hosts-file preview.
- Open the hosts file with administrator privileges. On Windows it is
C:WindowsSystem32driversetchosts. On macOS and most Linux distributions it is/etc/hosts. - Search for your domain and its
wwwversion. A line such as203.0.113.10 yourdomain.com www.yourdomain.comforces both names to that address. - Remove or comment out migration-only lines once the public DNS records are correct. To comment a line, place
#at its beginning. Do not remove unrelated system entries. - Save the file with its original name and plain-text format. An editor that silently adds a second extension can leave the real hosts file unchanged.
Close every browser window after editing, then reopen the browser. If the domain still resolves to the old address, continue with the DNS-cache step.
2. Flush the local DNS cache
Use the command appropriate to your operating system. Administrative permission may be required, and command names can vary by release.
Recommended Free Tools
- Windows: open Command Prompt as administrator and run
ipconfig /flushdns. - macOS: in Terminal, run
sudo dscacheutil -flushcache, followed bysudo killall -HUP mDNSResponder. The second command may report that no process was found on some releases. - Linux with systemd-resolved: run
sudo resolvectl flush-caches. Systems using another resolver may need that resolver’s restart or cache command.
After flushing, test in a private browsing window and on a different device. A phone using cellular data is a useful comparison because it normally uses a different resolver and does not share your computer’s cache.
3. Check public DNS from more than one location
Use a worldwide DNS propagation checker to inspect the domain’s nameservers and A record. Look for the new host’s expected server address in multiple regions. If some locations show the old address, those resolvers have not refreshed their cached answer yet.
Do not treat an all-green result as proof that the site must load everywhere. A checker cannot detect your local hosts-file override, a router cache, a browser cache, or a WordPress plugin that redirects requests incorrectly. Use the result to decide whether to investigate public DNS or your own environment.
4. Verify the registrar’s nameservers
Log in to the registrar where the domain is registered and open the domain’s nameserver settings. The nameservers should match the DNS service you intend to use for the new host. If the registrar still delegates the domain to the old provider, edits made in the new provider’s DNS panel will not control public traffic.
After correcting nameservers, allow the change to become visible to public resolvers before judging the result. There is no universally reliable propagation time: it depends on cached TTL values, resolver behavior and the record being changed.
5. Confirm the A record and remove conflicting records
In the authoritative DNS zone, check that the domain’s A record points to the new server’s IP address. Check the www hostname as well; it may use a CNAME or its own A record. Remove stale records that still point to the old host when they conflict with the intended setup.
Common mistakes include editing a DNS zone that is not authoritative, leaving two A records from different hosts, or updating the root domain while leaving www unchanged. Record the intended value before deleting anything so you can restore it if necessary.
6. Keep the old host online while you test
Do not remove the domain from the old hosting account immediately after changing DNS. During the transition, some visitors can still be sent there. Keeping it active gives those visitors a working response and lets you compare the old and new installations.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsA WordPress.org forum report described a fatal error after the old host’s domain was removed before the migrated backup had been tested. That is an individual troubleshooting report, not a universal failure rate, but it illustrates the risk of taking down the fallback too early. Decommission the old account only after the new site works through its real domain from several networks and the migration is backed up.
7. Check WordPress’s own URL settings
Once DNS reaches the new server, sign in to WordPress and open Settings > General. Check both:
- WordPress Address (URL): the address where the WordPress core files are installed.
- Site Address (URL): the public address visitors should use.
Both values should use the final domain and the intended protocol. An old staging hostname, an accidental subdomain, or a mismatch between http and https can cause redirects, login loops or asset failures after the DNS problem itself is fixed.
If you cannot reach the dashboard, inspect the equivalent URL values in the site’s configuration or database using the tools supplied by your host, and make a backup before editing. Exact recovery methods differ by hosting stack, so avoid changing database values blindly.
Free tools Windows power users keep installed
One-click scans. No signup required.
8. Review domain mapping, cache and SSL layers
Managed WordPress setups, multisite installations and domain-mapping plugins can route a request to a different site even when DNS is correct. Temporarily review or disable migration-related domain-mapping rules, caching layers and redirect plugins, then test again.
Also verify that the new host has a certificate covering the root domain and www name you actually use. A certificate problem normally produces a security warning rather than “Server Not Found,” but an HTTPS redirect to an unconfigured hostname can make the failure appear connected to the move.
How to read the result of each test
Only your computer fails
Return to the hosts file and local cache. Check the address your computer resolves after the flush and compare it with the new server address shown by an independent network. If the values differ, the problem is local; changing WordPress will not correct it.
Rank #4
Every network reaches the old site
The public delegation is still sending traffic to the old infrastructure. Verify nameservers at the registrar, then inspect the authoritative A or CNAME record. Do not delete the old installation until the new address is visible from multiple networks.
Every network fails to find the domain
Check for missing or incorrect nameservers, an empty DNS zone, an expired domain, or an A record that was never created. Ask the new host for the exact address and required DNS record type, then compare it with the authoritative zone rather than with a cached lookup.
DNS is correct but WordPress redirects or shows a blank site
The request is now reaching the server, so move beyond DNS. Check the two WordPress URL fields, domain-mapping rules, cache configuration, SSL coverage and the web server’s document root. A blank page or PHP fatal error indicates an application or server configuration problem, not a name-resolution failure.
Prepare the next migration before changing DNS
Preview the new server privately
Before public DNS changes, add a temporary hosts-file entry that maps the domain to the new server’s IP. Test the homepage, login, media files, forms, administrative screens and any subdomains. Remove the entry after testing so it cannot mask public-DNS mistakes later.
Lower TTL ahead of the move
DNS TTL controls how long resolvers may reuse an answer. Lowering it before a planned migration can make later changes refresh sooner, but it cannot instantly invalidate caches that already hold a longer previous value. The appropriate lead time and TTL depend on your DNS provider; the evidence available here does not establish a single number that applies to every migration.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Use a staged cutover
- Back up the old WordPress files and database.
- Restore the backup on the new host and test it privately.
- Confirm the new server, certificate and WordPress URLs use the final domain.
- Change the authoritative nameservers or DNS records.
- Monitor the site from multiple networks while leaving the old host online.
- Remove temporary hosts-file entries and disable migration-only redirects or plugins.
- After traffic consistently reaches the new host and backups are confirmed, retire the old hosting account.
What not to assume about propagation time
Search summaries sometimes quote a four-to-48-hour window for nameserver changes, but that figure is not tied to a verifiable source here and should not be used as a promise. Some users see a change quickly; others continue receiving an old answer until a resolver’s cached TTL expires. Judge progress by independent DNS checks and real browser tests, not by a fixed countdown.
If the domain remains unreachable after public DNS consistently shows the new address, stop waiting for propagation and inspect the hosts file, local resolver, web-server virtual host, WordPress URL settings and SSL or redirect rules. Those layers can fail after DNS has already converged.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
