On a Google Hangout back in June, John Mueller, Webmaster Trends Analyst at Google, was asked how it’s best to handle a migration from a mobile domain to a responsive website. His recommendation? Do it before the mobile-first index is released as it makes the migration process much easier and quicker.

Let’s do a quick recap of what the mobile-first index is. This way you get a better sense of the potential issues that might arise if you choose to migrate from a mobile domain to a responsive website after the mobile-first index is released.

We’ve covered this topic in detail in “The Web Designer’s Guide to Google’s Mobile-First Index” but following are some key points to consider.

Google currently indexes websites based on their desktop version. When a user runs a search on Google from their mobile device, Google uses the signals from the desktop URL to check for a mobile version of that website.

Here are the 3 most common ways in which this is done:

• Google uses the same desktop URL but the content of the page that is taken into consideration is the one set for mobile by the presence of the @media query if the page is responsive.
• Google uses the same URL but looks at the content in the files that are served for mobile devices if the website is adaptive.
• Google uses a different URL altogether if the desktop page signals that a different URL for mobile exists through the usage of the rel="alternate" tag if the website uses a m-dot.

Once the mobile-first index is released, Google will look directly at the mobile version of a site in order to find and index URLs. This also means that it will use the desktop version only when a mobile one is not found.

Why even consider a migration?

To best answer this question, let’s look at how things work now from Google’s perspective in terms of a migration for both separate mobile websites and responsive sites. And then we’ll compare that to how they’ll work after the release of the mobile-first index.

Ok, so say you now have a separate mobile website – m.example.com – as well as a desktop site – www.example.com. Your desktop URLs are currently seen as your main URLs (canonical) while your mobile URLs are seen as alternates that should be used for mobile searches alone.

That’s why a mobile website should point their canonical tags to the desktop version, and the desktop URLs should signal that the mobile version of the URLs exists by using the rel="alternate" tag.

You can learn more about having separate URLs for mobile and desktop from Google’s documentation.

So if you’re planning to do the migration soon, you’re in luck as redirecting your mobile pages to your desktop ones won’t be seen as a migration. That’s because the URLs that Google considers canonical, your desktop ones, will stay in place and not suffer any redirects.

But after Google releases the mobile-first index, your mobile URLs will be seen as your main URLs. This means that redirecting your mobile subdomain to a cleaner URL would require Google to reindex everything since you’re moving your canonical URLs to a new location. Google will look at it as a migration, so it will take it longer to realise it’s a full move.

You can read all about site moves with URL changes in Google’s documentation.

Why should you go responsive anyway?

Here are our top Pros and Cons for migrating your m-dot to a responsive website. Take it all in and based on your business’ priorities, you can decide what’s the best course of action for you and your website:

Pros

1. All backlink signals can be better consolidated

If you have two URLs for the same page, one for desktop and one for mobile, they can both earn you backlinks. Normally the signals should be consolidated by using the correct canonical tags.

In other words, both URL versions should point to the same canonical URL. But even so, there are issues that can arise:

• No canonical tags at all
• Not all pages are correctly canonicalised
• Pages with parameters that don’t change the content are not correctly canonicalised to the clean URLs
• More than one canonical tag is used so it’s up to Google to decide which canonical URL to choose.
• Google just ignores the canonical tag as that’s more of a suggestion and not a directive.

With a responsive website, although the page adapts to the device, there’s just one URL that gets served. So all signals will always point to one page only.

2. Easier to update

When you want to update your website, you still have two different pages with two different URLs. That means you’ll need to make changes to both pages, mobile and desktop. But when you have a responsive site, that’s one less thing to worry about since you’ll only need to make changes to just one HTML file.

3. More content

m-dot pages tend to have less content than desktop pages. And it’s obvious why.

But here’s the problem: currently Google doesn’t give the same weight to content hidden in tabs or expandable content as it does to visible content. So there’s no point in adding anything else on your m-dot page other than visible content.

But with the mobile-first index, every piece of content on your site is taken into consideration for ranking purposes, whether hidden or not. So if you don’t add that extra content to your m-dot pages you’ll be missing out as your competitors who have responsive websites will be ranked for all the content found on their pages.

4. Better UX

With m-dot sites you need to implement redirects from the desktop to the mobile version. Why? Because when the browser that makes the request seems like a mobile browser or if the screen size of the device making the request hints that a mobile phone is being used, then the user needs to be redirected to the mobile version of your site.

But what happens when the browser doesn’t send any user-agent data? With privacy concerns on the rise, chances are this will happen often.

And what if you decide to add a new page on your desktop website but forget to create its counterpart on the m-dot site? There’s no redirect in place or, even worse, the redirect takes the user to a 404 page.

Whichever the situation, it translates to bad user experience.

With responsive design, you can avoid such issues as you don’t need any redirects so there’s no possibility of getting them wrong.

Plus, you’re being consistent in terms of branding and navigation, which is something users appreciate.

5. Easier to adopt new Google advances

Want to add hreflang tags for internationalisation? What about support for Accelerated Mobile Pages (AMP)? Perhaps you’re looking at introducing structured data with the aim of improving your site’s appearance in search results? Even if you’re not planning to implement any of these things right now, the chances are you’ll at least consider them in the near future. Switching to a responsive website means it will be easier for you to make these (and other) changes in the future.

Cons

1. Speed

Pages on m-dot sites tend to have less content. They also tend to keep design elements and images to a minimum, which makes them load faster.

With responsive websites, the same resources you serve on desktop are downloaded for mobile too. That means a responsive website will require more work in terms of optimising its loading times.

2. Complete redesign

Designing a mobile website based on an existing desktop site can lead to a lot of issues. Ideally, you should design the mobile version first and then expand that into a desktop site. When it comes to a responsive website, this might mean more hours spent on designing it.

3. Bad UX

This may seem like it’s in contradiction with the “Better UX” section in the pros list. But it’s not. While a responsive website can offer an overall better UX, in some situations the experience for users can be a less pleasant one.

Here’s what we mean by that:

With responsive websites you’ll need to hide certain parts of your desktop page when serving it on mobile. That’s so you don’t create a mobile page that requires a lot of scrolling. If a user runs a search on Google and finds your page relevant but then can’t see that information on the page by just browsing, they might leave the website. It might not even matter if the information they’re looking for is actually available under a “read more” type button that expands into a section.

There are ways to avoid these types of situations such as making sure visible content is relevant for the hidden content so the user can easily guess that the information they want can be found in a hidden section. Ideally you should look at heat or click maps to see how your users interact with your page when using mobile devices. This allows you to better understand potential UX issues and ways to fix them.

Want to migrate now? Here’s a handy cheat sheet to help you

If you’ve already been planning a migration from your m-dot to a responsive site or if the information above has convinced you that it’s the right move for you, then you should consider taking the necessary steps before the mobile-first index is released. This way you can prevent any loss in organic visibility as a result of reindexation.

Google hasn’t given an exact date for the release of the mobile-first index. Gary Illyes, Google Webmaster Trends Analyst, said that they want to make sure they’re not going to hurt websites and they’re willing to work on it as long as it takes, even 5 years if necessary. However, in a recent interview he mentioned they’re aiming to have the mobile-first index released in early to mid 2018.

Even though you might have lots of time to get ready for the big change, we don’t recommend doing the migration at the last minute. Take your time to do it right and follow the steps below.

Before the migration

1. Compile a list of all your m-dot URLs

Do a crawl and also check to see what Google has indexed with a site:m.example.com type search. Check what mobile pages your visitors have seen through your analytics platform for both organic and paid search.

2. Compile a list of all your desktop URLs

You’ll need the list of destination URLs, the final URLs that you want to use for your responsive website. If your mobile subdomain mirrors your desktop site perfectly, you can implement a redirect rule similar to m.example.com* 301 to www.example.com/*. This way you won’t have to bother with URL mapping. But do this only if the page URLs are identical on both your m-dot and desktop sites.

3. Map URLs

Create a list of all m-dot URLs and where they should redirect to on the desktop site. Try to match the pairs as much as possible in terms of relevancy. Don’t send all m-dot URLs to one page on your desktop site. Also make sure you don’t have any duplicates in the m-dot URL list. Ideally, you should be able to do 1:1 pairing if you’ve created a mobile version of every desktop page.

4. Get stats

It’s a good practice to benchmark the performance of your current m-dot site so you can check and see if your responsive website performs as well as the m-dot subdomain did. At the very least, take a closer look at mobile traffic and conversions, keyword ranks and page speed for your most important pages.

It’s migration time

When you’re ready to make the move, follow these steps:

1. Remove temporary redirects

If you’ve correctly set up your m-dot website to work with your desktop one, this means you’ve had temporary redirects (302) in place to take users from the desktop to the mobile site when the appropriate user-agent was detected.

Now you’ll need to remove all the 302 redirects from www.example.com/ to m.example.com.

2. Add permanent redirects

Using the URL mapping from above, implement permanent redirects (301) from m.example.com to www.example.com as you won’t need to ever use those URLs if your www.example.com website is responsive.

3. Crawl your responsive site

See if you have any m-dot links on your www.example.com website. This is in case you’ve hard-coded mobile URLs that will now redirect and make pages load slower. Update them to the www. version.

See if you have any redirect chains (two steps or more for an URL to get a 200 OK status) or any redirect loops (the 200 OK status is never achieved).

Check if previous 200 OK pages are now 404 and also keep an eye out in the Search Console for new 404 showing up.

After the migration

1. Remove old sitemaps and rel="alternate"

To help Google find the changes, it’s good to keep the old m-dot sitemap live a few weeks after the migration (if such a sitemap exists). You can also keep the rel="alternate" tags in the code of your desktop pages to ensure Google can find and crawl the old m-dot URLs and see the permanent redirects. There’s no point in keeping these up forever though as they’re wasting your crawl budget.

A few weeks to a couple of months after the migration you should remove the old m-dot sitemap and/or the rel="alternate" tags.

2. Update all online properties

Check all the accounts you have that use URLs from your website and replace any m-dot URLs with the corresponding www’s. Be sure to check your AdWords or other paid accounts and make the necessary URL changes.

3. Compare the performance of the new website

In terms of speed, you should be able to collect stats for your desktop site as you’re developing it to be responsive.

For keyword ranks, you will need to wait for about four weeks though. That should give Google plenty of time to completely understand the changes. But do keep in mind that his timeframe can vary depending on how big your website is.

Now, while fluctuations are very common in the SERPs, if you see a dramatic loss of ranks across most pages then something has probably gone wrong.

Also check to see if you’re getting the same amount of organic traffic from mobile users as you did before. Take seasonality into account as well as you’re benchmarking against data collected at least a month prior to the migration.

 

We hope you found this useful and not just for you but also for your clients who might require more information (and probably some hand-holding) while they make the decision to move to a responsive site from a m-dot. Hopefully this guide will also help make the migration process a lot easier for you.