'Moving an App to a New Domain (or to https)' by Firefield's Jeremy Sewell

Here's a great new post by Firefield's own Jeremy Sewell.

-----------------------------------------------------------------------------------------------

Moving an App to a New Domain (or to https)

Whether you have an impending lawsuit, a brilliant new branding idea, a late-night change of heart, or if you’re just running from Google bots, sometimes you need to change your apps’s domain.

                                                   Going a different way.

There are some things you should know and do before and after your move. Also, if you’re simply moving a site from http to https, you’re still changing domains in the eyes of search engines, so a lot of this still applies.

We’ve been through enough domain name changes for our clients, that we’ve developed a guide and we thought we’d share the details. While we’re often moving Ruby on Rails apps, the details here would apply to any web app.

If you’re moving a site to a new URL or simply changing from http to https, you need to make sure everything will continue to work seamlessly and that you don’t lose all current SEO.

Preparation

There are some things you should do well ahead of the move date to make sure that you are prepared.

Cleaning Up Links and Attachments

If you’re managing a production app, you’re probably also managing a development and/or staging environment, so probably all your links are versioned by environment, but you’d be surprised that a few hardcoded links always get included… find and destroy these. All links should be dynamically generated by the app based off configuration. Don’t forget to make sure emails generated and sent via your app also have dynamic links.

This can all be done prior to the move as the point is that it all works regardless of the domain.

While you should be able to make all the links in the code base dynamic, you also want to think about any links managed in a CMS. For example, say you have an admin interface to manage the items in your homepage carousel and part of this is putting in URLs to link to… these won’t change when you update environment, so make sure you have a plan for updating these, probably right after the switch over.

I know you’re probably thinking, we’ll just use 301 redirects for everything. Well, don’t do that. You should use 301 redirects as they are intended when you need to tell users (and search engines) content has moved permanently. You shouldn’t be linking to a 301 redirect, you know better.

Embeds and Integrations

Few apps don’t rely on outside services whether it’s sending emails, storing attachments, video players, etc, you should review them all and see if they are configured in any way by your domain. Each app, is different, but here are a few examples:

Mandrill — This email service (now just a Mailchimp add-on) requires that you verify your sending domain in a couple different ways, so this will need to be done for the new domain. You can probably do this ahead of time.

Typekit — If you want your cool fonts to keep appearing, you’ll need to make sure your kit has the new domain included in the settings.

Those are just a couple examples, but make sure you take a hard look at all outside services that could be affected and plan accordingly.

Prepare 301 Redirects

Back to the subject of 301 redirects, all domain traffic should be redirected to the non-www (and https if applicable) so that you end up with a URL like:https://appdomain.com (not https://appdomain.com orhttps://www.appdomain.com). We can probably fight about this, but I believe non-www is better as less is more. People will link to your www and non-www versions, so make sure you pick one and redirect the other. Not using SSL? Consider making your site secure with an SSL certificate. Now it’s supposed to be free and easy.

Canonical URL Metadata

Each page (that you want visible to search engines) should have this piece of metadata:

<link rel=”canonical” href=”https://appdomain.com/somepage" />

If you don’t have canonical metadata, add some and make sure that it is dynamically set just like other links.

Verify Domains with Google

If you’re not using Google’s Search Console, you should start as this will improve your SEO and deal with any issues (for Google at least, which owns about 70–80% of most organic links your app gets). You should verify your domain for the current URL and for the new URL. This will be important so you can tell Google about your domain change. If you’re changing from http to https, as far as Google is concerned, this is nearly the same as a full domain change

There are a bunch of different ways to verify.

Depending on how involved your Google Search Console settings are, you may want to look at URL Parameters, Geotargeting, Crawl Rate, and Disavowed Backlinks. More information on that can be found here.

Prepare a URL Mapping (If necessary)

This article is about changing the domain, but keeping the exact same app. If you are moving to a new app where content and URLs are different, you may need to prepare a URL mapping.

Prepare Code Update

You’re probably going to want to prepare a code update that will deploy after the name change and this will let you take care of a couple things that might be hardcoded. For example:

Sitemap
Depending on the size of your app, you probably use some method to create your site map such as a plugin or gem, and these usually have a base URL configuration. Make sure you update this. As soon as you make the change, you’ll want to deploy or generate this new site map.

Making the Move

Depending on the size of your app, you may stagger this or do it all at once. You probably want to make the move at a time when you know site traffic is low. You can review your analytics to pick the best time. We usually do this very late at night or very early in the morning.

Updates Robots.txt

On your old site, remove robots.txt directives. This allows bots to discover all redirects to the new site.

On the new site, make sure the robots.txt file allows crawling of URLs, images, css, js, and other assets you want search engines to index.

Confirm the Move

Once you confirm the move is complete, there are few things you should do immediately:

Tell Google About the Move

If you’re moving from http to https, you don’t need to do this, but if you’re actually moving to a different domain, you should use the Google Search Console to submit a “Change of Address”.

Updating Links you Control

It is best for SEO if other sites link directly to your actual domain and don’t rely on redirects, so if you have social profiles such as Facebook, Twitter, LinkedIn, Google +, make sure you update all the links to your new official domain. You should also do this for any ad campaigns. You can also reach out to any sites that link to you and ask them politely if they will update their links to your new site. This may be an ongoing project, but start with what you can control.

After the Move

You’re going to take a hit in terms of SEO immediately after the move, but this should build back up over time, and if you’re moving from http to https, hopefully surpass your previous SEO as Google weights secure sites higher.

You’ll want to monitor Google Analytics (or whatever you use) to make sure you’re seeing normal traffic and there don’t seem to be any issues. You should use Google Search Console to check the index status and to make sure there are no crawl errors.

And you’ve done it. Is there something we missed here? Please feel free to leave a comment to let us know.