Recently I developed a website for a client using one of my own spare domains which I use for these purposes. The intention was to migrate the WordPress site to his domain at the end – a process which I have successfully completed numerous times. Initially the client had his hosting at domain.com where there were a few problems with importing databases and them not being supported by the type of server implementation they had. Having created the site, I was ready to make it live and after the usual fiddling around exporting and reimporting the SQL databases, and doing a search/replace in them to change the domain name instances and altering settings in WordPress I came across two problems. The first took me a little while to figure out and was irritating. Pages would not display and ‘404 Not Found’ errors kept cropping up.
Broken Permalinks After Moving the Domain
What I discovered was that the permalinks in the WordPress (which were a custom structure) had not updated to the new domain name. It took 10 seconds to fix – simply set the permalinks in WordPress to a different setting and saved it, then changed it back again to my custom permalinks and everything picked up the correct domain name. It was an easy fix, just hard to find.
The next problem however was not so easy to sort out. Having repointed the nameservers to my Bluehost account from domain.com. the site was functioning for me after just an hour or so but for my client who was in Canada, it did not. It turned out that domain propagation was causing some odd effects.
Domain Propagation – The Bane of Developer-Client Relationships.
Domain propagation is a strange process. When a site moves from one domain name to another and nameservers are changed, the world has to be informed about the change. The way the Internet works is that when a domain name is registered, the domain itself is initially “in limbo” until a hosting account (on the same server as the domain or elswhere) is acquired and the nameserver (a way to point people to your domain server) made to point to your hosting server.
You can enter a somain into this useful site and check various aspects of DNS propagation:
Confusing? Yes it is a little. What makes it worse is that the site where the domain is registered does not necessarily have to be the host too. For example, if you purchase a domain at GoDaddy, you can “point” the nameservers to another server such as at HostGator where you have purchased a hosting account.
However, when a domain is moved from one server to another, things get a little wonky for a few days and this can look like the developer (or “The Internet”) is causing a problem that is preventing a site from being found. It is hard to explain to a client whaty is going on. What is worse, this problem can cause part of a site to appear mixed in with other parts that are out of date. The best soltuion is to not tell the client until propagation is complete but most in my experience are very much hands-on when it comes to checking out their new site – rightly so as they are paying for it to be built.
How does domain propagation cause issues?
The reason is that to keep the Internet running smoothly, the servers that deliver pages to your browser (i.e. at your ISP) keep a copy (cache) of pages locally to save time when you ask for them again. If you need to refresh a browser page, pressing F5 will refresh it from the nearest cache – on your local machine. If you clear your browser cache and hit F5, the browser will not find any locally cached pages information/images etc., so will request a copy from your ISP’s server. They too keep a page cache – one which you unfortunately cannot clear. The way the ISP cache is refreshed is a mechanism called TTL (Time To Live) which denotes the amount of lifespan a page in the cache will have before the server refreshes and gets a new copy from your host server where your site is stored. In our example that is HostGator. All Internet data has a TTL which is a simple self-destruct mechanism with a ticking clock countdown or a specific time – once the number of seconds in the TTL for a data packet reach zero or the specified time is reached the data is discarded. This is a hard-coded mechanism within the packets that make up the data sent and stored on networks and is not configurable remotely. It is used to maintain privacy and reduce wandering packets (where the destination cannot be reached, the TTL setting will destroy the packet to prevent network congestion).
This chain reaction of refreshing data gets broken when you change nameservers and move domains. What happens is that pages and the nameserver pointers are cached on servers across the world and when a refresh is requested, numerous problems become evident; the wrong page appears, menus may not work and images may be incorrectly displayed or missing – it depends on what has been cached and what is delivered as fresh data.
For a few days this is a pain as clients see a mish-mash of their site which can look a real mess. The TTL setting at most servers is measured in seconds and for a web page can be something in the order of 24 hours (86400 seconds) similarly for the caching of the nameserver which also has a TTL. If the server is in a foreign country, the effective TTL will most likely be in real terms even longer.Setting TTL at your host will make no difference to domain propagation as the caches in the servers along the route refresh. This process is automatic and can take a day or so regionally/nationally – several days internationally.
After the TTL expires for all existing pages and their components, the system gradually refreshes completely. This might take 3-4 days to complete everywhere around the globe. There is no way around the situation really so being patient and letting servers refresh is all you can do – remember to keep hitting CTRL F5 when you do look at a moved or new site so you get the local ISP’s latest copy .