Skip to content

Easier Site Migrations: Avoiding DNS Problems with the hosts File

Over this past month, I’ve needed to migrate quite a few WordPress sites from one host to another. I can say with confidence: it’s still not my favorite process. There’s nothing that should be complex about it, but somehow there are enough moving parts that it’s never simple, and you feel on edge throughout. If you’ve ever put together a chair from Ikea, you’ll know what I’m talking about.

DIY fail chair

Today, we’ll be looking at a specific source of complications in a WordPress site migration: Domain Name System (DNS) records. We’ll talk in depth about potential DNS pitfalls in a WordPress site migration, and introduce a very helpful way to step around many of them: the hosts file.

DNS: A Quick Rundown

DNS is a massive set of recorded associations between domain names and IP addresses.

To understand DNS, it’s helpful to reflect on a couple of things:

  1. Every location on the internet is specified by a numeric IP address that looks something like this: Your web browser, FTP client, etc., all ultimately rely on IP addresses to know which server to request information from.
  2. But humans aren’t so good at remembering 12-digit numeric strings. They’re a lot better at remembering names, like, which is why domain names exist.

So we have two sets of address information on the internet: a big list of human-readable domain names, and a big list of computer-readable IP addresses.

So what is DNS? DNS is a massive set of recorded associations between domain names and IP addresses. “ is at” is a single DNS record—domain-name/IP address associations—of which there are millions and millions.

When you enter a domain name into your browser, your request is sent to a nameserver: a computer whose job is to store DNS records. When it gets your request, the nameserver looks up its record for the domain you’ve given it, finds the IP address it has on file for that domain, and sends you there. That’s how you get to the actual web server that’s storing the resources you’ve requested.

How DNS Can Get Tricky During a WordPress Site Migration

You can’t point your domain to the target site because you’re not sure it works properly; and you can’t test whether it works properly because it has no domain name.

If you’re migrating a WordPress site from one host to another, DNS generally presents the following conundrum: You want to view, work with, and make changes to the new site on the new hosting (the “target site”), but that site doesn’t have a domain name associated with it. In other words, you can only view the target site at, because still points to your old site on your old hosting.

When you access the target site by IP, it’s probably mostly broken: depending on how you’ve done the migration, your links across the site will probably look like—but points, of course, back to the old site on the old hosting. The target site’s resources are actually at links looking like, since the target site has no domain name pointing to it.

You can use a tool like searchreplacedb2 to go into the database on the target site and rewrite every instance of to, which should give you a working target site. From experience, though, this is the kind of change that can be a big headache to undo later. If you write your find-replace rules wrong, you can, for example, miss instances of in the database—which, for one site, caused me to rewrite all of the site’s email addresses from to the very broken email@

To summarize, you’ve got a Catch-22: You don’t want to point your domain to the target site because you’re not sure it works properly; and you can’t test whether the target site works properly because it has no domain name.

It Gets Worse: DNS Propagation and Caching

DNS records have to propagate: all nameservers throughout the world have to be told that a particular domain now points to a new IP address.

Okay, we’ve got a problem. But can’t we just point our domain to the new site really quickly to see if everything’s okay, and then point it back if it’s not?

Here’s where I tell you that DNS records aren’t stored on one single computer. That would be a very big computer, and if someone ever unplugged it the whole internet would break. On the contrary, they’re stored on an immense hierarchy of nameservers that looks something like this:

  1. “Authoritative” nameservers that answer occasional questions from other nameservers
  2. Intermediate nameservers scattered into zones throughout the world that take their cues from nameservers higher up the chain
  3. Nameservers kept by your internet service provider (ISP) that take their cues from intermediate nameservers, and that actually direct your requests

Each of these nameservers caches its information: rather than trying to constantly update every single record, it assumes that the records it has are good until someone tells it otherwise. It’ll also dump any record that’s older than a certain age; this maximum age is given by a setting called time-to-live (TTL) that varies server-to-server, but is a few hours or less for most nameservers.

This is why DNS records have to propagate: all nameservers throughout the world have to be told that a particular domain now points to a new IP address. Until that happens, some nameservers will know about the new IP address, and some won’t, and people will be seeing different versions of the site. And in particular, if your nameserver hasn’t updated its record, you can’t see the new site.

ISP Badness

Because of relatively short TTLs on most nameservers, DNS propagation usually takes a few hours or less—which is already a significant headache, since “Show the world a perhaps-broken site, that you can’t see is broken, for half a day” isn’t the greatest proposition for a site someone actually cares about.

Now here’s where your ISP (Comcast, Time Warner, or whomever provides your internet connection) comes into play. ISPs may not have the most thoughtfully configured nameservers, and in my experience the time-to-live on an ISP’s nameservers can be way too long: 24 or 48 hours or more. This means you’ll be seeing the old site basically forever, as long as you still use the same internet connection—even once your phone (with its different ISP) is properly showing you the new site.

You can switch things up by moving to a coffee shop or connecting through your phone’s hotspot capability, but those are sketchy solutions, and ones you shouldn’t have to count on.

Okay, We’re Done with the Bad News

That’s a lot about how DNS can mess you up, but I wanted to paint a picture so you know where DNS issues can lead, and so that if you do get turned around by DNS you at least know how you’re turned around. Hopefully these confusions are feeling familiar if you’ve migrated a site before.

With all the bad news out of the way, let’s talk about a better solution for testing a new site prior to redirecting a domain name: your computer’s hosts file.

Using hosts to Test Sites with No Domains

It turns out your computer can act as its own nameserver.

It turns out your computer can act as its own nameserver: you can manually map IP addresses to domain names, just for your own computer, using your computer’s hosts file.

This file is mercifully similar across Windows machines and Macs. The only key difference is its location on your computer: on Windows machines, it’s at C:\Windows\System32\drivers\etc\hosts, and on Macs it’s at /etc/hosts. In either case, the file has no file extension—it’s not hosts.txt, for example, but just hosts.

Working with hosts

Once you’ve found the file, you need to open it with a text editor, which could be something simple and preinstalled like Windows’s Notepad, or, preferably, an actual code editor like Sublime Text.

Once you’ve got it open it looks like this:


How you use it is mercifully simple: you just enter the IP address of the target site—the IP associated with your new hosting account—and the domain you want it to point to on your computer. In the image above you can see the example for its hosting account’s IP is, and I wanted to browse at that address prior to actually making any DNS changes to the domain. (Note that all the lines that begin with # are commented-out: the first line that does something is line 19.)

The syntax looks like:

with each record on a new line. Once you’ve edited the file as needed, simply save it in your text editor and close the file.

What this Gets You

You can browse and edit the new site at its target domain, while the rest of the world still sees the old site.

With hosts record changes, you can browse and edit the target site—the site on the new hosting—at its normal domain (, while the rest of the world still sees the old site you’re about to switch from when it visits that domain.

This means no database rewrites: any links on the new site will work properly. You can edit the site just as you would if it were already live. Then, when you do redirect the domain to the new hosting account’s DNS records, and those changes propagate, the rest of the world will see what you already see on your computer.

Checking if the Site Propagated

Of course, with hosts, there’s always the danger that you’re the only one seeing the new site. You can check the progress of DNS propagation by browsing the domain on your phone. It’s also quite easy to remove the hosts record you created and then test whether you see the new site or the old site. This is the best long-term, since in general you want to see what the rest of the world sees for debugging purposes.

hosts is Awesome!

I hope we’ve shown how big a headache DNS stuff can be in a WordPress site migration—and how you can route around a lot of that unwanted complexity with the hosts file. Got any questions or thoughts about hosts or DNS? Let’s hear ’em in the comments below!

Yay! 🎉 You made it to the end of the article!
Fred Meyer

1 Comment
Most Voted
Newest Oldest
Inline Feedbacks
View all comments
May 25, 2016 2:48 pm

Thanks for the update on searchreplacedb2!

Or start the conversation in our Facebook group for WordPress professionals. Find answers, share tips, and get help from other WordPress experts. Join now (it’s free)!

Would love your thoughts, please comment.x

Most Searched Articles

Best JavaScript Libraries and Frameworks: Try These 14 in 2024

In this post, we look at the best JavaScript libraries and frameworks to try out this year. Why? Well, with JavaScript being available in every web browser, this makes it the most accessible programming language of ...

20 Best Free WordPress Themes for 2024 (Responsive, Mobile-Ready, Beautiful)

If you're looking for only the best free WordPress themes in the market for this year, then you're in the right place. We have more than enough such themes for you right ...

12 Best WordPress Hosting Providers of 2024 Compared and Tested

Looking for the best WordPress hosting that you can actually afford? We did the testing for you. Here are 10+ best hosts on the market ...

Handpicked Articles

How to Make a WordPress Website: Ultimate Guide for All Users – Beginners, Intermediate, Advanced

Many people wonder how to make a WordPress website. They’ve heard about WordPress, its incredible popularity, excellent features and designs, and now they want to join the pack and build a WordPress website of their own. So, where does one get ...

How to Start an Ecommerce Business: Ultimate Guide for 2024

Is this going to be the year you learn how to start an eCommerce business from scratch? You’re certainly in the right place! This guide will give you a roadmap to getting from 0 to a fully functional eCommerce business. ...