Forum Moderators: mack
1. Put up a temporary index.html page at the new host
2. Get the other parts of the site uploaded without being linked to from that page.
3. Put in a robots.txt file excluding robots from the new site until the site is moved.
4. When it's all working properly at the new host:
4a. Put a "moved" notice on your ISP site pointing to the index page at your new host. Avoid getting caught with duplicate content at both.
4b. Get the index page up at the new site
4c. Remove the robots.text exclusion
4d. Contact those who link to you to change their links to the new URL. Search engines will find you through the links.
4e. If you have an ODP listing for the old URL, submit a change when it's all working properly.
If you slip out of search engines temporarily, don't panic. You'll get back in. Don't even ask how long that will take, the only one that's predictable is Google, and that can take 60 days.
GB
Suppose I have a website at www.mysite.tld, on a server with IP address 192.168.55.20. Either I, my ISP, my hosting provider, or my registrar, depending on the service agreements I have, maintains the "authoritative" DNS servers for this domain. Suppose I have three people who want to visit the site. One of them is me, another is my father at home several states away, and the third is an old college friend in yet another state.
For the sake of this example, we'll pretend that my computer is configured to use the same DNS server that is authoritative for mysite.tld. (call it ns.mysite.tld - though this is certainly not required. The name could be anything.) I type [mysite.tld...] into my browser. The browser then consults the DNS server. The DNS server in this case is authoritative, so it doesn't have to ask any further to determine that www.mysite.tld means 192.168.55.20, and it tells the browser so. The browser then asks 192.168.55.20 for the web page. If I then click on a link to another page on the same site, the process is repeated.
Now that I know things work, I call up my father and ask him to take a look. He types the same thing into his browser, but he has his system configured to use his ISP's DNS server (call it ns.dadsisp.tld). His browser asks ns.dadsisp.tld what the IP address for www.mysite.tld is. Since ns.dadsisp.tld is *not* authoritative for mysite.tld, it asks one of the 'root' name servers for the answer. The 'root' nameserver doesn't know either, but it knows who is authoritative for .tld, and referrs ns.dadsisp.tld to that server (often, especially for .com, the 'root' servers are also the top-level doman authoritative servers, but not necessarily.), which then referrs ns.dadsisp.tld to ns.mysite.tld, which reports that www.mysite.tld means 192.168.55.20. It also includes a timeout value for how long this inoformation should be cached (say 4 days), and ns.dadsisp.com remembers what the answer was. Now, when Dad clicks on a link to another page on my site, his browser asks ns.dadsisp.tld the same question again. Since the it hasn't been four days since the last time someone asked ns.dadsisp.tld that same question, it just answers without checking.
The next day I decide that I want to move the site from 192.168.55.20 to a different server, 192.168.128.3. I make the change in the authoritative records on ns.mysite.tld, and replace the site on 192.168.55.20 with a page that says "we've moved to a new IP". This time I'm a little nervous about the change, so instead of just calling Dad to make sure it works, I call Dad and my friend in another state.
When I look, my browser again asks ns.mysite.tld for the IP address, and since ns.mysite.tld is authoritative, it knows the new IP, and sends me to the site on its new server at 192.168.128.3.
When my friend looks, her browser asks ns.friendsisp.tld for the IP address. Ns.friendsisp.tld has never been asked for this before, so it goes through the same steps that ns.dadsisp.tld did yesterday. Since those steps culminate in asking ns.mysite.tld, she gets the new answer, 192.168.128.3.
When Dad looks, though, his browser asks ns.dadsisp.tld again. Ns.dadsisp.tld knows that someone asked it that question just yesterday, and that the timeout was four days. Since it has checked more recently than the timeout value, it skips the other steps and tells Dad's browser that www.mysite.tld means 192.168.55.20. Dad gets the "we've moved to a new IP" page. Oops. Dad will keep getting that page for the next 3 days, too, until ns.dadsisp.tld expires the answer from its cache and goes through the whole set of inquiries and referrals again.
This caching is generally a good thing. Even with caching in place, the root name servers handle a phenomenal number of requests per second. Without it DNS just plain wouldn't be practical. However, it does make changing DNS information slow, which is particularly fristrating when you are setting up DNS for the first few times and aren't absolutely certain you'll get it right. When I have the control, which so far has been most of the time, I set the timeouts short while I'm initially configuring a domain, and then longer once I think I've got a stable configuration. The only way to be sure you have a smooth transition, though, is to leave an indentical copy of the site on the old server (at the old IP) until longer than the longest timeout affected by the change.
The domain name is "you" for as long as it's registered to you. It has to live at an address, which is an IP number, just like you live someplace, either individually in a one-family home with a unique IP number or shared like in an apartment building - virtual, name-based hosting where it's divided up among different tenants.
The DNS is like the post office, having an address to send the mail - only in this case it's the domain name being sent to an IP number (nameserver) instead of a letter being sent to a building. When you make the nameserver designation with the registrar, the message gets sent across the internet with the "address" - the IP number you gave as your web address.
It's not a direct line, like sending mail door to door in a mail truck. It's like follow-the-dots with way-stations along the way (hubs, routers - techie type stuff) that have to record the location of the address the domain name goes to.
When that's all done and it fully "resolves", the server where your site is hosted is the address of that domain name. When someone types in the domain name, there's a connection established with the "apartment" or web space you rent, browsers then can connect the name with the address, and your site will come up. Until then, when it's typed in, it will give a 404 error - not found, or dnserror. That can happen for up to 72 hours.
A redirected domain name doesn't work this way, it doesn't really "live" at your web address, which is where the problems come in with the same site showing up at two different places - because it is.
When you've been typing in Holly's domain name it wasn't the domain name that showed in the brower address bar, it's been the www.her-isp.com/~username/ that shows in the browser. The ISP URL was listed with Google, with back- links, but the domain name wasn't getting listed.
And thanks, BTW. You gave some information I've been wondering about, so everyone's got what they need now. :)
I realize that you took a lot of time to explain this to me, and I really appreciate it.
