Several of our clients have gone through the rebranding process, including but not limited to the migration of a website from one domain to another. This change is inherently high-risk – especially for well-established websites with a lot of domain authority and history, as well as content that tends to rank and perform well in the search engines. It can be a precarious and risky change, so it is imperative to do your due diligence, consider every angle you can think of, and take your time if you can.
The purpose of this article is to provide an easy-to-understand guide to migrating a website from one domain to another. Many of the principles addressed in this article can apply not just to domain migrations, but also to other major or high-risk changes such as redesigns, server migrations, changes in content management system, and more.
These changes are high-impact and should be handled with time and care. No one website is exactly the same, and the impact and considerations may be different from one site to another. This guide is quite thorough, but if you are not experienced in this kind of transition, please consult a professional who can help you sort through all the information, make recommendations on the best ways to proceed, and get into the trenches to help you map out all the details and keep a handle on the moving parts.
Before Migrating Domains
What exactly is going to be changing?
Ideally, high-risk and high-magnitude changes like migrating an entire site from one domain to another should be done in isolation, not in combination with other major variables like design changes or server changes. The very first thing you should do is ask yourself these questions to ensure that a domain migration really is all that’s happening:
- Will the main top level domain (TLD) change?
- Will the content management system (CMS) change?
- Will the front-end design change?
- Will any page content, multimedia and/or meta tags change or be removed?
- Will the information architecture and/or page URL paths change?
- Will the server/hosting change?
Think hard about everything you anticipate that could possibly change during the domain migration process. For example, if you must change content management systems or servers, you should do it several weeks in advance so you can monitor closely, troubleshoot and stabilize this change first. As another example, major changes to the internal site architecture such as the global navigation, footer navigation, important home page links, or otherwise, should be avoided if at all possible. One final example – avoid changing content, title tags, H1 tags, multimedia on the pages, especially for your most important and highest trafficked pages, if you can.
The goal is to change as little as possible so you can minimize the margin of error from juggling multiple changes, and isolate the change variable so you can accurately identify positive or negative impacts to rankings or traffic, and quickly get to the bottom of any problems should they arise.
With a change this big, temporary rankings and traffic declines are likely as the search engines begin crawling through your 301 redirects and updating your index. It is difficult to predict how much and how long, because it’s different for everyone. Many companies elect to do these changes during their slowest traffic times to keep the risk to a minimum – however if that period falls around holidays like Thanksgiving and Christmas, I advise against this because holiday traffic can cloud your view of potential issues from the migration.
Acquire the Online Assets for the New Brand
First and foremost, decide on your new domain name. Register the domain for 5 to 10 years, which can be a subtle signal of longevity for the domain. This step assumes you have already done research on your new domain’s age, authority, backlink profile, and any current content or past owners (if applicable).
Register social media accounts, if necessary. Some social media usernames and vanity URLs can be changed relatively easily, like Twitter and LinkedIn. Some can be changed, but are tricky and convoluted – like Google+ and YouTube. Others may require starting from scratch. At this stage, you are securing, setting up and optimizing these profiles (if new). Changing old profiles over to new profiles with the new website address can happen later in the process after you flip the switch, or you could update social media profiles and links from your website to your profiles well before the final site migration if you like. Also, check out Michael King’s article “How to Maintain Social Shares After a Migration” if preserving those social media share metrics for displaying on the pages is important to you.
If you are planning to set up a new Google Analytics UA for this new property, do that at this stage, and get it installed right away to start collecting data.
Don’t forget to get access to and control of your Google+ Local, Bing Local, Yahoo Maps, Yelp, FourSquare and any other local listings if you don’t already. Otherwise, get your login information handy. You’ll need to be able to update these quickly once you make the switch.
Create & Map a Complete List of Page URLs & Content Sections
As mentioned above, ideally the paths to each individual page will not be changing outside of the TLD. But I still advise doing a complete export of all URLs on the site. A database-side export will be the most complete, but I find all methodologies a little imperfect and incomplete. So in addition to the database export, I also run Screaming Frog and Xenu Link Sleuth crawls, export a list of all URLs that have received at least one landing on the last year or so from Analytics, and dump all the data into one fat Excel spreadsheet, format the columns for consistency, then use Excel’s “Deduplicate” data validation function to get the absolute most complete list possible. Include a column for the server response code you get for each page (i.e. 200 = OK, 301 = redirected, 404 = broken).
This export allows you to get a big picture view of all the main sections of content that you should be monitoring and testing closely after the change. When you migrate the site from the old domain to the new one, you can use this list as a spot-checking tool to make sure all pages are accessible exactly where they should be. Don’t forget to take inventory of multimedia content objects like images, videos, audio files, PDFs and other downloads, etc. Now is a great time to clean up any 404 errors, temporary 302 redirects, URL normalization issues, or other errors or warnings you’re showing in Google Webmaster Tools or Moz Analytics, by the way.
If you are changing page URLs – again I advise against this during a domain migration that is already high-impact – this document can also serve as a mapping tool for you to make sure every old URL has a new home, or a plan to remove the page and redirect it to something else. If any traffic-driving pages will be lost in the migration, it is critical to anticipate this and have a strategy to permanently 301 redirect those pages. Be clear about what new pages will be added, what pages will be eliminated (and 301 redirected), and what pages should be untouched in the migration – and map all old URLs to new URLs if applicable. This is not a change to be taken lightly. Please consult a professional if you are unsure.
Collect Data and Establish Baselines
You need to have a clear understanding of where your site stands and how it behaves prior to the change. Below are some recommendations for areas to familiarize yourself with, and some data to pull in advance. You may have others specific to your site that I’ve not listed below. These are all items that should be monitored closely after the change, as well. Once again, please consult a professional who can help you establish reliable baselines and guide you to other metrics you should monitor before and after the change.
- Use Google Webmaster Tools and Bing Webmaster Tools to identify your most linked to pages throughout the site. Make sure this does not change after the domain migration. Be especially aware of the internal linking structure from the homepage and other top pages.
- Use Google Analytics or your web analytics platform of choice to get a complete understanding of your top content on the site, and how it performs. Test and monitor this content especially closely during and after the domain migration. To mitigate the potential traffic losses, this may require extra linkbuilding or social media support immediately after the change.
- Use tools like MajesticSEO, Google Webmaster Tools, Google Analytics and Open Site Explorer to figure out what your most important, high authority and highest traffic referring backlinks are, and the social shares to that top content. Begin organizing contact information to contact the appropriate people to get those links updated to the ones on your new domain if possible.
- Get a feel for your pages indexed. You can get a vague idea between site:domain.com searches in Google and Google Webmaster Tools “Index Status” section. Look at your “Crawl Stats” while you’re in there.
- Check your home page’s Google PageRank and page authority, as well as your overall domain authority. Open Site Explorer can help here, too.
- Ensure that your most important keywords are being rank tracked well in advance of the migration. I use Moz Analytics, for example. You’ll want to keep an eye on the long-term trending of your keyword rankings.
Completely Back-Up the Site
This should go without saying – and you should already be doing this regularly, even without a domain migration in play. Things can and do go wrong with large, complicated changes like this. Do not make the mistake of not having a complete, reliable backup of your site. Things can and do go wrong, and you may need this safety net. Double up or triple up as a failsafe if you need to.
Create an Awesome 404 Page
Some 404s during a migration like this are to be an anticipated. Don’t underestimate the power of an awesome 404 page. Make sure you have an eloquent, easy-to-understand 404 page that helps guide users to other valuable content on your site should they encounter it, so you don’t frustrate and lose the user. Include a clear message, link to top content, and include a site search function if applicable.
Do the Migration to a Dev Site First
Get a dev or staging site that is nofollowed and noindexed using meta robots, disallows search bot crawling in your robots.txt file, and is also password protected. You could even specify that you would only allow certain IP addresses to access this dev site – like your business’s IP address and your SEO consultant’s IP address, for example. Copy your site over to this dev site on the new domain and test from top to bottom. Use your list of top content and internal links pulled from the “Data & Baselines” step above as a guide to testing what is most important – but don’t let that limit you. Be thorough! See my “Test Everything” section below for more. Once you are confident that the migration to a dev site is successful, deploy the changes to the live version of the site and test like crazy again.
During the Domain Migration
If you have the luxury of running the old site and new site in tandem, it can soften the potential blow to rankings and traffic many domain migrations have, and can also give you more time to test and work out the kinks for a more seamless transition. Make sure your robots.txt file and meta robots tags aren’t disallowing search bots from crawling your site when you move on to this phase.
Many specialists recommend canonicalizing pages on the old domain to pages on the new domain using the rel=canonical tag before committing to the final 301 redirects. The biggest pro to this approach is that it’s a gentler step between just pulling the plug on your old domain, and can be a good intermediate step before the final 301 redirects if your new domain has no domain authority. So all the ranking content can still exist where it is, but it can help point search engines in the right direction toward the new site, without causing duplicate content issues in the search engines. This may add more time to your transition timeline, but it will likely be worth it if you need to buy time to build content, links, social signals to your new domain.
Google has said that they use the rel=canonical tag “as a hint and not an absolute directive,” but it should be fairly reliable. It is not a good permanent substitute for proper sitewide server-side redirects from the old domain to the new. This is only a brief and temporary step to ease the transition between one site and another. I do not recommend this for all sites, as permanent 301 redirects are the ultimate preferred method and are supported by all search engines.
Set Up Analytics Platforms
You need accurate, reliable data to ensure your changes are going smoothly. If you are using various web analytics platforms like Google Analytics, Moz Analytics, HubSpot, Bing & Google Webmaster Tools, etc., be sure they are all set up and working properly first thing.
There are several routes you can take with Google Analytics, each with their pros and cons. Here are the top two I consider:
- Run the same Google Analytics script on both the old and new sites. You may wish to create a Custom Report to show the full URL, not just the URI after the main part of the domain. The upside to this is that you don’t have to interrupt your current Google Analytics flow, you have all historical data in one place for easy comparisons and research in the future, minimize confusion about content performance in the future, and you save the miniscule amount of time it takes to setup and install a new GA account. The downside to this is that there is some work required to set up the full URL capture, and you must be sure to annotate all changes clearly to avoid confusion in the future. If you choose this route, this is a must-read tutorial on how to get the full URLs in Google Analytics on Search Engine Land by Annie “Annielytics” Cushing.
- Run the old Google Analytics script on the old site, and a new Analytics script with an all-new UA on the new site. Keep access to the old Analytics script for comparisons and historical data, and the new domain will get an all-new Analytics script for a fresh start. One upside to this is a fresh start with a clean Analytics slate if you’ve had irreparable data damage to the prior Analytics accounts (like using filters on your only property profile, instead of keeping one completely untainted data set). Another pro is that you can easily see when traffic begins to drop off of the old domain and starts to climb on the new domain, so you know when to pull the plug on the old site. The biggest downside to this is that you will have extra work to do when you need to make comparisons against historical data because it will be in a separate account.
Build Out Content on the New Domain
Once the new domain is up and running, your team can begin creating unique, useful content for readers to begin consuming. This content can help build the relevance and authority of the new domain and position it within your space, and it could also start generating social media shares and backlinks. This can be especially helpful if you have a long timeline for the domain migration to allow you to build up visibility, credibility and authority for the new site.
Begin Notifying Current Customers & Website Visitors
If possible and if the rebranding is not a huge secret, take advantage of your current website, e-mail marketing, social media platforms, etc. to start warning current customers and website visitors ahead of time that the change is coming. One client of mine had an awesome idea to start referring to their brand as “BrandName (formerly OldBrandName)” throughout the content on their existing website to start signaling the change. This may also involve doing a press release to announce the change and where the new website will be, doing an e-mail drop to current customers, including a reminder on the customer login screen, notifying people repeatedly via social media, and so on. Anything you can do to give your users and visitors a heads up that change is nigh leading up to the big day can be helpful to minimize confusion and traffic losses after the change.
Flipping the Switch
So how do you know when to flip the switch on the old site? To do away with the rel=canonical and switch over to permanent 301 redirects? Regardless of which Analytics method you chose above, monitor the traffic to the old domain and the new domain closely. Traffic to the old domain should continue to steadily drop, and ideally, traffic to the new domain will continue to rise. Give it time. When the majority of your traffic has started funneling to the new domain, pull the plug and 301 redirect all pages from the old domain to their corresponding pages on the new domain.
I sometimes even recommend deploying one section at a time if it’s manageable, so you can stabilize one section before moving onto the next. But a complete 301 redirect of the TLD at the DNS or .htaccess level can often more adequately capture all URIs from the old domain to the new with a MUCH smaller margin for error. My recommendation varies from client to client, and it really depends on the size and quantity of changes in play. Regardless of what method you choose, seek help if you’re at all uncertain about how to execute this step. This is the most common step where businesses go wrong and do lasting damage.
If any internal links are absolute instead of relative, make sure they’re updated to the new domain. If you are using the rel=canonical tag or permanent 301 redirects, start updating internal links to the correct URLs instead of forcing crawlers/traffic through the redirects or canonical tags.
Once the final transition is complete and 301 redirects are in place from the old site to the new site, you must notify Google and Bing Webmaster Tools that a change of address is happening, so they can update their indexes to reflect the change. Leave the old site’s XML sitemap live for a while after the migration so crawlers can still access it, follow the links therein through the 301 redirects, and start working the old URLs out of their indexes. A week or so should suffice. Then, run a fresh XML sitemap to include in your robots.txt file, and to submit to both Bing and Google Webmaster Tools, as well. I recommend adding an HTML sitemap to your root directory as well. (Excellent way to quickly check for broken links, too!)
After Migrating Site to New Domain
Use Google Analytics annotations or your internal changelog to document every single change. Seriously, no change is too small to document. Annotate the dates and times of each change throughout the process. This way you can spot issues quickly and isolate problems to quickly solve them if need be. But just like backing up your website, keeping an accurate changelog is something critical you should be doing anyway. So do it!
I encourage all my clients to draft a testing checklist, a living document that can grow and change with your site. I always recommend pairing it with a clear “go live” policy so the entire team understands the precise steps that will be taken to deploy and test major changes to the website. If you’re making a dramatic change like a domain migration, now is the perfect time to bust those out and follow them with the most meticulous care.
The go-live policy typically includes setting clear KPIs prior to making major changes, writing test cases for each change with step-by-step testing instructions before the project is implemented, executing changes on dev first before deploying to live, when changes will not be deployed (like Fridays, weekends, after 4 p.m., etc.) because they can’t be monitored closely, and so on. I encourage you to honor your go-live policy as closely as you can throughout the migration.
The testing checklist will vary from website to website, and brand to brand. But here are three key pointers I have that apply to anyone:
- Have people test who don’t work on your website all day. They are more likely to catch errors or odd website behavior than you.
- Don’t get too comfortable or take anything for granted. Don’t just test what should change – also test what should not change.
- Test as if something is definitely broken, with a truly critical eye. Encourage testers to think like a user, and try to break things.
For the sake of this domain migration, here are some of the items I would include on your testing checklist:
- Check for the scripts of all your web analytics tools to ensure they’re in place and collecting data.
- Check your robots.txt and .htaccess files, as well as meta robots tags on pages, to make sure nothing is being blocked from search engines accidentally.
- Cross reference your list old page URLs against the new site to ensure they work, and that content and meta tags haven’t changed. Check for page formatting issues, errors, broken images, broken links, etc.
- Clear your browser’s cache before testing. Check changes in all major browsers and on major device types. Be sure correct version of site is showing on desktop, tablet and mobile devices.
- Check all the top pages of your site, and be sure to check the top content in each and every main section of the site.
- Send through test leads or test sales. Try to break your forms, use values that won’t validate then fix them and resubmit, confirm leads or sales are being received by the appropriate parties after submission.
- Check 404s and any other crawl errors or warnings after making changes.
- Monitor your daily or weekly pacing for normal expected quantity of customer logins and new leads or sales.
This list should be elaborated upon and customized for your website and brand. Leave no stone unturned during the testing phase. You can’t be too careful or too thorough here. As always, consult a professional if you need help developing a testing plan and writing test cases!
Make sure all your public-facing profiles and communication tools, as well as your collateral materials, reflect the website change. Make sure your entire staff has updated their email signatures, that all your brand’s social media profiles have the new domain listed, that your clients and social media followers have been notified. (Moz, who did a rebrand from their original name of SEOmoz in 2013, even bought targeted ads on social media sites like Facebook to announce and remind people that they had rebranded – awesome idea!) Get business cards, printed materials, local listings, everything you can think of updated to reflect the domain change. You WILL miss some. Ask your staff to keep an eye out on the web for anything that has the old domain name.
I mentioned above that you should find out what your top backlinks are, especially the ones referring significant amounts of traffic to your website. While links do appear to pass value through 301 redirects, many theories suggest that not as much “link juice” or authority passes through a 301 redirect as would pass through a link straight to the correct domain. Contact the webmasters of those top links, and let them know about your rebrand and politely ask them to update them to the new URL. Remember, you are inconveniencing them and they’re doing you a huge favor by updating the link, and you don’t want to lose the link, so be very gracious and grateful!
Remember that login information you collected for your local listings like Google+ Local, Yahoo! Local, Yelp, etc.? Now is the time to get your brand name, website URL and contact information updated as quickly as possible on those local listings. This can take a few weeks to verify in some cases, so act fast.
There are no doubt other online assets that will need to be updated that you may miss initially. That’s ok, it’s going to happen – but be diligent and keep an eye out. Do lots of web searches for the old brand and domain to see what’s lurking for quite a while after flipping the switch. That list should become progressively smart over time.
Time to bust out everything from the “Data & Baselines” section and start monitoring regularly! Daily at first, then backing off to weekly should be fine after a week or two. It’s a ton to monitor, so consider divvying up the responsibilities and making certain people responsible for specific “beats.”
Look for big spikes in major errors, warnings, etc. in Google and Bing Webmaster Tools, Moz Analytics and any other platforms you may be using. Keep an eye on traffic volume, sources and landing pages. Keep spot-checking various permanent 301 redirects, and monitor 404 (Not Found) errors and fix as quickly as possible. Watch crawl rates and cache dates (in Google, search cache:yoursitedomain.com) to be sure your new content is getting crawled successfully.
Monitor your rankings to watch for major shifts or drops. With changes of this gravity, some rankings and traffic change are expected as the search engines begin to find and account for your 301 redirects and crawling those “new pages” (aka old pages with new addresses). The amount traffic will drop, and how long it will drop for, is tough to pin down – it’s different for everyone. Ideally all the painstaking care you took above, and the slow and steady migration you planned so meticulously, can help keep those dips to a minimum.
If you don’t start seeing your rankings and traffic climbing back up and returning to near-normal after a couple of weeks, start digging in. If you documented all your changes religiously, if you established your baselines and you’ve been monitoring constantly ever since, you shouldn’t be caught by surprise – but you should also have tons of valuable tools at your fingertips to find and fix potential issues.
Use the tools and resources available to you, stay organized and follow your best practices and checklists meticulously, and keep the communication frank, consistent and persistent on your team. If you have done your due diligence, taken your time, consulted professionals for guidance, and enlisted your whole team to pitch in and do their parts, you will be ready to take the plunge and proceed with confidence.
Once the change has been completed successfully, I’m sorry to say it’s not time to rest on your laurels. Your inbound marketing should be ramped up, your linkbuilding efforts should get extra attention and budget, and you need to keep spreading the word about the change to get the new site traction quickly.