If you’ve ever migrated a domain to a new server and you’ve received errors in your browser about not being able to resolve the domain (“DNS not found”) then you’ve experienced a propagation issue.
What is happening is that your ISP hasn’t been told about the new record you’ve created or it’s using cached information which is pointing to an old server.
This is a big problem for sites with a lot of traffic is you don’t want half your visitors seeing the old site and the other half seeing your new one.
This is especially important for ecommerce sites because you want to avoid handling orders from both the old and new site. So how can we mitigate this issue?
Where is your staging site?
Before you read on, I want to highlight that if your staging site and live site are on the same server, this article isn’t relevant to you.
In this case all you need to do is to change the document root path to where the new staging site is being stored. All your visitors will see the new site the moment you update your configuration and restart the web server.
If your staging and live sites are on different servers, keep reading..
Let’s assume you have your staging site at http://www2.yourcompany.com and you’ve had it up and running for a few weeks or more. It’s safe to assume that it will resolve for everyone because it has had time to propagate.
Let’s also assume that the URLs on the new site have probably changed somewhat as you assumed it would be a good time to roll out more SEO friendly URLs and you’ve implemented 301 redirects to handle the old site’s URLs.
Tip: Read this tutorial on implementing 301 redirects on your new site.
When you make the DNS changes to make the new site live, be sure your new site has DNS A records for both “www” and “www2″. We need both to be in play.
You’ll then need to implement some redirections should anyone see your old site because the new details haven’t propagated to their ISP.
Just to re-iterate, all of the below 302 temporary redirections should only be implemented on your old site and not on your new site where 301 redirections should be in place for only URLs that changed.
Case 1: URLs that have changed
You can basically copy your 301 rules from your new site but make them 302 and absolute URLs via .htaccess.
The end result should be something like www.yourcompany.com/category-15 302 redirecting to www2.yourcompany.com/lcd-tvs
Case 2: URLs that haven’t changed
For all the URLs which remain unchanged, we will need to redirect them to www2.
RewriteRule (.*) http://www2.yourcompany.com/$1 [L,R=302]Avoiding duplicate content issues on www2
Because we have both www and www2 in play, we need to ensure search engine robots don’t start indexing www2 URLs.
The quickest way to fix this is to implement the rel canonical tag for every URL.
e.g. both www.yourcompany.com/lcd-tvs and www2.yourcompany.com/lcd-tvs should output
Note: With all the redirections being put in place, be careful not to create 301 redirection loops.
Cleaning up: Decommissioning www2
Once you’re confident no one is landing on your old site, you need to fix the canonical issues you’ve created by having www2 as an alias.
RewriteCond %{HTTP_HOST} ^www2\.yourcompany\.com [NC]
RewriteRule (.*) http://www.yourcompany.com/$1 [L,R=301]A good way to check is looking at the old site’s web server logs to see if there’s been any activity.
Troubleshooting: Issues with SSL certificates
If your site has certain pages on SSL, then this method will cause SSL certificates to complain about not matching the domain for visitors who are accessing ‘www2′.
The upshot is that forms asking for personal/payment information should be the only URLs using SSL, so not everyone will see the errors. Furthermore, it may be a lesser evil than having to deal with orders from your legacy site.