Redirects and User-Agent Detection

Automatic redirection

When a website is configured to serve desktop and mobile browsers using different URLs, webmasters may want to automatically redirect users to the URL that best serves them. If your website uses automatic redirection, be sure to treat all Googlebots just like any other user-agent and redirect them appropriately.

Correctly detecting user-agents

Detecting user-agents (sometimes called user-agent "sniffing") is generally an error-prone technique. There are many reasons why, but three kinds of failures are common:

  • User-agent detection depends on having a list of user-agent strings (or substrings) to match against. Such lists need constant maintenance and updating and will not match new user-agents. In reality, many such lists are not maintained appropriately and are stale, giving your users a bad experience.
  • When matching user-agents, it's common to mismatch, sometimes detecting a desktop user-agent as a mobile one or detecting a mobile user-agent as a desktop. Likewise, a common mistake for sites is to inadvertently treat tablet devices as smartphones. If you are detecting the user-agent of browsers accessing your site, be sure the detection looks for smartphone-specific strings (such as checking for both the words "Android" and "Mobile") as opposed to generic mobile strings (checking for just "Android"). Learn more.
  • Be very careful of cloaking when detecting user-agents. When detecting the user-agent, the site is detecting the device class or type by looking for the device name in the user-agent string; it should not be looking specifically for Googlebot. All Googlebot user-agents identify themselves as specific mobile devices, and you should treat these Googlebot user-agents exactly like you would treat these devices. For example, Googlebot for smartphones identifies itself as an iPhone and you should serve it the same response an iPhone user would get (redirect, optimized content, etc).

Supported redirection techniques

Googlebot supports the following two redirection implementations.

Using HTTP redirection

HTTP redirection is a commonly used to redirect clients to device-specific URLs. Usually, the redirection is done based on the user-agent in the HTTP request headers. It is important to keep the redirection consistent with the alternate URL specified in the page's link rel="alternate" tag or in the Sitemap.

For this purpose, it does not matter if the server redirects with an HTTP 301 or a 302 status code, but use of 302 is recommended whenever possible.

JavaScript redirects

If HTTP redirection is difficult to implement, you can use JavaScript to redirect users to the URLs pointed to by the link rel="alternate" tag. If you choose to use this technique, please be aware of the latency caused by the client side of redirection due to the need to first download the page, then parse and execute the JavaScript before triggering the redirect.

There are many approaches to implementing a JavaScript-based redirect. For example, you can use JavaScript to execute the media queries your site already uses in the link annotations on the page using the matchMedia() JavaScript function.

Bidirectional vs unidirectional redirects

Different websites implement different redirection policies. Some websites only redirect mobile users visiting a desktop page to the mobile page ("unidirectional" redirects), and some websites redirect both mobile and desktop users if they visit pages on, respectively, the desktop and mobile sites ("bidirectional" redirects).

For Googlebot, we do not have any preference and recommend that webmasters consider their users when deciding on their redirection policy. The most important thing is to serve correct and consistent redirects, i.e. redirect to the equivalent content on the desktop or mobile site. If your configuration is wrong, some users may not be able to see your content at all.

Also, we suggest giving users a way to override the redirect policy, i.e. allowing mobile users to view the desktop page and allowing desktop users to see the mobile page if they so choose.

Authentication required

You need to be signed in with Google+ to do that.

Signing you in...

Google Developers needs your permission to do that.