{"id":1990,"date":"2017-12-18T08:32:30","date_gmt":"2017-12-18T12:32:30","guid":{"rendered":"https:\/\/www.gsqi.com\/marketing-blog\/?p=1990"},"modified":"2017-12-23T11:53:43","modified_gmt":"2017-12-23T15:53:43","slug":"mobile-problems-with-google-mobile-first-index-looming","status":"publish","type":"post","link":"https:\/\/www.gsqi.com\/marketing-blog\/mobile-problems-with-google-mobile-first-index-looming\/","title":{"rendered":"From m-dot to m-not. Real-world examples of mobile SEO problems with Google’s mobile-first index looming"},"content":{"rendered":"

\"Mobile
\nIn October of 2016,\u00a0Google announced<\/a>\u00a0its plan to move to a mobile-first index.\u00a0Gary Illyes first explained this at Pubcon and then Google officially published a blog post<\/a> covering the subject. It\u2019s an important move and a 180 for search. Until now, Google has used the desktop URLs and content for ranking purposes, even for mobile rankings. That\u2019s not optimal given the surge in smartphones and mobile usage, so they decided to make a switch.<\/p>\n

With the mobile-first index, Google will instead use the mobile URLs and content for ranking purposes. Therefore, it\u2019s critically important that site owners have their ducks in a row from a mobile standpoint (across several areas).<\/p>\n

Tough(er) for m-dots
\n<\/strong>The move to a mobile-first index can be especially concerning for sites using separate mobile URLs (like m-dot subdomains). And that\u2019s one of the reasons Google has been pushing responsive design as the cleanest approach for handling mobile. When using responsive design, the same HTML is delivered to all users, including structured data, hreflang tags and so on. CSS is used to change the rendering of the page based on viewport size. Since the same HTML is delivered for both desktop and mobile users, the move to a mobile-first index shouldn\u2019t impact sites using responsive design at all.<\/p>\n

But when using separate mobile URLs, you have a completely different set of pages. And those URLs could very well contain scaled-down content, a different internal navigation, no structured data, the wrong hreflang tags (or no hreflang tags) and so on. And that\u2019s a dangerous situation with the mobile-first index rolling out. You also need to use the correct technical SEO setup to signal the relationship between desktop and mobile URLs.<\/p>\n

Here is the difference between using separate mobile URLs and responsive design, from\u00a0Google\u2019s support docs<\/a>:
\n\"The<\/p>\n

Google\u2019s John Mueller and Gary Illyes have both explained that having equivalent content on your mobile URLs is extremely important when preparing for the mobile-first index. In addition, other elements such as structured data and hreflang tags must also be present on your mobile URLs. You don\u2019t want to be in a situation where your site moves to the mobile-first index and only half the content is being used for ranking purposes.<\/p>\n

And recently, Google even explained that some sites have already\u00a0moved to the mobile-first index<\/a>! So yes, we are very close to seeing Google move more and more sites to mobile-first. Needless to say, site owners started to freak out a little.<\/p>\n

\"Jerry<\/p>\n

Over the past several months, there have been many questions about how the mobile-first index will work, the types of problems that need to be rectified, and how Google will treat certain situations. There\u2019s a lot of confusion, that\u2019s for sure. Below, I\u2019ll take you through some real-world mobile problems that I have uncovered while helping companies prepare for the mobile-first index. Let\u2019s jump in.<\/p>\n

Risky m-dot setups cause mobile-first problems
\n<\/strong>Since Google\u2019s announcement about the mobile-first index, I\u2019ve been helping a number of large-scale websites prepare. These are companies that either have separate mobile URLs (like m-dot subdomains) or are using dynamic serving, which provides different HTML and CSS based on user-agent. (Note:<\/strong>\u00a0Dynamic serving is only a problem if there are significant gaps between the desktop page and mobile version. But there can still be problems, so keep an eye out.)<\/p>\n

While helping these companies dig into their specific mobile setup, I have uncovered some very interesting problems. Therefore, I thought it would be valuable to share some of those problems so you can better prepare your own sites for the move to a mobile-first index. You never know, you or your client might be facing similar issues. And if you are, I recommend tackling those issues\u00a0now<\/em>, before the switch to m-first happens.<\/p>\n

Botched bidirectional annotations = bad signals
\n<\/strong>The first problem I\u2019ll cover relates to the fundamental mobile setup a site should be employing when using separate mobile URLs. That\u2019s where the desktop URL should contain rel alternate pointing to the mobile URL, and then the mobile URL should contain rel canonical pointing to the desktop URL.<\/p>\n

These bidirectional annotations signal the relationship between desktop and mobile URLs to Google. And this can help Google surface the correct URLs in the search results based on device, consolidate indexing properties across the URLs and so on. Google\u2019s\u00a0support documentation<\/a>\u00a0fully explains how to set this up.<\/p>\n

\"Bidirectional
\nDuring a recent audit, I noticed a few alarming things. First, there were many pages indexed on the m-dot subdomain. That shouldn\u2019t be the case. If Google is properly canonicalizing the mobile URLs, then they shouldn\u2019t be indexed. Note, there will always be\u00a0some<\/em>\u00a0indexation of mobile URLs showing in Google Search Console (GSC), but you shouldn\u2019t see a large percentage of URLs indexed there. For the company I was helping, I saw over 170K mobile URLs indexed, and it was rising!<\/p>\n

Second, mobile URLs were ranking on desktop. If you\u2019re not familiar with this situation, it\u2019s important to understand that this shouldn\u2019t be happening. I saw over 57K clicks and over 1.2M impressions when checking the search analytics reporting for the m-dot (and filtering by desktop).
\n\"Mobile<\/p>\n

It\u2019s also important to know that if mobile URLs are ranking in desktop search, that\u2019s a clear sign there are technical problems with the mobile setup. Google’s John Mueller mentioned this on Twitter recently:<\/p>\n

\"Google's<\/p>\n

After digging in, I could see that the desktop pages contained self-referencing\u00a0canonical tags (a good thing), but rel canonical was botched.\u00a0The tags were using\u00a0relative<\/em>\u00a0URLs rather than absolute, and since the URLs weren\u2019t entered correctly, they created excessively long and concatenated URLs that led to 404s. Rel alternate was set up properly on the desktop URLs pointing to the correct mobile urls, but rel canonical wasn\u2019t correct on those desktop urls.<\/p>\n

Note: You can use relative URLs, but they must be entered correctly or Google may ignore rel canonical. Google even mentioned this issue in a blog post covering\u00a0common problems<\/a>\u00a0when using the canonical tag. Here\u2019s a graphic from the post illustrating the problem. The first line is incorrect and will append the domain name to a url that already<\/em> has the domain name in it:<\/p>\n

\"Relative<\/p>\n

And here is how the urls were breaking. Notice the url example that 404s and how the domain name was incorrectly appended to the url:<\/p>\n

\"Botched<\/p>\n

Rel canonical was implemented correctly on the mobile pages, so the mobile URLs were correctly indicating the desktop URLs as the canonical version. However, since rel canonical was botched on desktop, the setup wasn\u2019t working correctly. This led to over 170K mobile URLs getting indexed \u2014 and that\u2019s why the mobile URLs were ranking on desktop search. Google was apparently seeing them just the way they would see other standard desktop URLs.<\/p>\n

In addition, if Google doesn\u2019t understand the relationship between desktop URLs and mobile URLs, the site could be diluting its efforts from an SEO standpoint. Google would not be consolidating indexing properties across each set of URLs (the desktop and mobile URLs). That could lead to weaker pages SEO-wise, weaker rankings, less organic search traffic and more. Not good, to say the least.<\/p>\n

I immediately sent my findings to my client, and the fix was implemented very quickly (within two days). And you can already see desktop clicks and impressions dropping on the m-dot in Google Search Console (when filtering by desktop).<\/p>\n

\"Traffic<\/p>\n

Double canonicals (header and HTML)
\n<\/strong>Another problem I surfaced that could cause serious problems overall (but especially with the mobile-first index looming) related to how a site was publishing rel canonical. I\u2019ve written before about the power \u2014 and\u00a0danger<\/em>\u00a0\u2014 of using the x-robots-tag<\/a>. Using this tag, you can publish directives and rel links via the header response rather than in the HTML.<\/p>\n

It\u2019s powerful since it scales very well (it\u2019s not in the HTML of each document). The danger is that it\u2019s invisible to the naked eye. And when you can\u2019t readily see the directives or rel links, there\u2019s always a chance they could be wrong. And when they\u2019re wrong on large and complex sites, they can wreak havoc on your SEO.<\/p>\n

While recently auditing a site with separate mobile URLs, I surfaced rel canonical being published via\u00a0both<\/strong>\u00a0the HTML and the header response. So each page contained rel canonical twice. Since rel canonical is just a hint and\u00a0not<\/em>\u00a0a directive, Google can ignore the canonical URL tag if it sees multiple tags (or if it just believes the site owner messed up). Therefore, when a site is using separate mobile URLs, the bidirectional annotations are critically important (as mentioned earlier). And you don\u2019t want to publish multiple canonical tags across your URLs, including on your mobile URLs.<\/p>\n

\"Double<\/p>\n

I sent this information along to my client, and their dev team is working on removing rel canonical via the header response. Once that\u2019s completed, the company will be confident they are signaling to Google the correct relationship between desktop and mobile URLs. It\u2019s better to rely on one hint versus multiple hints that possibly send mixed signals. Beware.<\/p>\n

Pagination not set up correctly, especially on mobile.
\n<\/strong>Since I help a lot of large-scale sites, I\u2019m often auditing and dealing with large amounts of pagination. It\u2019s one area I\u2019ve found to be extremely confusing for many site owners, SEOs and developers.\u00a0Actually, I was surfacing so many similar pagination problems that I decided to write a thorough blog post detailing the correct setup for pagination<\/a>, including how to set up sorting and filtering parameters. You can read that post if you need help with setting up your own pagination.<\/p>\n

\"Setting<\/p>\n

Well, during a recent audit of a site using separate mobile URLs, I noticed the pagination wasn\u2019t set up properly, especially across the mobile URLs. Remember, the desktop URLs should contain rel alternate pointing to the mobile URLs, and the mobile URLs should contain rel canonical pointing to the desktop URLs. That\u2019s on a one-to-one basis.<\/p>\n

Therefore, each page of the pagination should contain self-referencing canonical tags. And the mobile URLs should contain rel canonical pointing to the desktop component pages. In other words, page two on mobile should point to page two on desktop, page three on mobile should point to page three on desktop, and so on.<\/p>\n

The mobile URLs did contain rel canonical, but they were all pointing to page one on desktop. The desktop URLs were correctly set up with self-referencing canonical tags along with rel next\/prev, but the mobile component pages were all being canonicalized to page one on desktop.<\/p>\n

Needless to say, this is not the proper setup. And when the switch is made to the mobile-first index, Google would not index any of the content on the mobile component pages. Instead, only page one would be indexed. That\u2019s not what this site wants based on their categories and articles, and it could lead to ranking problems (since content beyond page one would not be indexed at all.)<\/p>\n

Don\u2019t simply canonicalize\u00a0component pages to page one in the pagination. That\u2019s not the correct setup!
\n<\/strong>\"Incorrectly<\/p>\n

I sent my findings along, and the pagination code was fixed pretty quickly. Now the desktop and mobile pages all use rel canonical properly, along with rel next\/prev.<\/p>\n

Bonus: Rel alternate for mobile delivered via the header response. What?!
\n<\/strong>This problem is pretty sinister, since it\u2019s easy for a company to falsely believe it\u2019s correct across all of their desktop urls. During an audit of a site using separate mobile URLs, I noticed that rel alternate was being delivered via the header response (for connecting the desktop URL with the mobile URL). That\u2019s different from delivering rel alternate via the HTML, which most sites have in place.<\/p>\n

An example of rel alternate being delivered via the header response on a site with over 600K pages indexed:
\n\"Rel
\nIf you\u2019re scratching your head now wondering why you haven\u2019t heard much of this before, it\u2019s because Google doesn\u2019t support<\/strong> that method! So if you are delivering rel alternate via the header response to connect desktop URLs with their mobile counterparts, then you should change that as soon as possible. Instead, rel alternate should be delivered in the HTML or via XML sitemaps as documented in Google\u2019s support center<\/a>:<\/p>\n

\"Two<\/p>\n

Quick tips based on helping a number of sites with separate mobile URLs:
\n<\/strong>As you can see, there are a number of mobile issues that can cause problems when sites get switched over to the mobile-first index (and those issues could even be causing problems now). Although I covered several important problems, I didn\u2019t even cover content mismatch issues, missing structured data, hreflang problems, etc.<\/p>\n

That\u2019s why I recommend site owners take a hard look at their mobile setup now<\/strong>, before they get switched over to the mobile-first index. By identifying potential problems in the short-term, you can resolve them before they cause even bigger problems down the line.<\/p>\n

Here are some quick tips based on helping a number of companies prepare:<\/strong><\/p>\n