This pdf is useful for those who would like to make their website mobile friendly. School of Digital Marketing has carved a niche in the field of digital marketing training.

1. Mobile
Search
Engine
Optimization

2. 253
Mobile SEO:
Let's make sure your site shows up in search results. In these sections, learn to configure your site
for multiple devices, help search engines understand your configuration, and avoid common
mistakes along the way.
Choose your mobile configuration
First, learn what it means to go mobile and do it using one of three configuration methods.
Understand different devices
Understand key points in going mobile
Select your mobile configuration
Frequently asked questions
Understand different devices:
Mobile: In this document, “mobile” or “mobile devices” refers to smartphones, such as devices
running Android, iPhone, or Windows Phone. Mobile browsers are similar to desktop
browsers in that they can render a broad set of the HTML5 specification, although their
screen size is smaller and in almost all cases their default orientation is vertical.
Tablets: We consider tablets as devices in their own class, so when we speak of mobile
devices, we generally do not include tablets in the definition. Tablets tend to have larger
screens, which mean that, unless you offer tablet-optimized content, you can assume that
users expect to see your site as it would look on a desktop browser rather than on a
smartphone browser.
Multimedia phones: These are phones with browsers that are able to render pages coded to
meet XHTML standards, support HTML5 Mark-up, JavaScript/ECMAscript but might not
support some of the extension APIs in the HTML5 standard. This generally describes the
browser in most 3G-ready phones that are not smartphones.
Feature phones: On these phones, browsers lack the capability to render normal desktop
webpages coded using standard HTML. This includes browsers that render only cHTML
(iMode), WML, XHTML-MP, etc.
Note: Our recommendations are geared toward smartphones, but we encourage multimedia
and feature phones site owners to follow the same advice where they feel appropriate.
2. Understand key points in going mobile:
No matter which configuration you choose, take note of these key points.
Signal to Google when a page is formatted for mobile (or has an equivalent page that’s
formatted for mobile). This helps Google accurately serve mobile searchers your content in
search results. More information in Signal your mobile configuration to Google Search.
Keep resources crawlable. Do not use robots.txt to block search engines from accessing critical files
on your site that help render the page (including ads). If Googlebot doesn’t have

3. 254
access to a page’s resources, such as CSS, JavaScript, or images, we may not detect that it’s
built to display and work well on a mobile browser. In other words, we may not detect that
the page is “mobile-friendly,” and therefore not properly serve it to mobile searchers.
Avoid common mistakes that frustrate mobile visitors, such as featuring unplayable videos
(e.g., Flash video as the page’s significant content). Mobile pages that provide a poor
searcher experience can be demoted in rankings or displayed with a warning in mobile
search results. More information in Common mistakes section.
Select your mobile configuration:
Google recognizes three different configurations for building mobile sites.
Here’s a chart comparing the three methods:
Configuration Does my URL stay the same? Does my HTML stay the same?
Responsive Web Design Yes Yes
Dynamic Serving Yes No
Separate URLs No No
Responsive web design: Serves the same HTML code on the same URL regardless of the
users’ device (desktop, tablet, mobile, non-visual browser), but can render the display
differently (i.e., “respond”) based on the screen size. Responsive design is Google’s
recommended design pattern.
Dynamic serving: Uses the same URL regardless of device, but generates a different version of
HTML for different device types based on what the server knows about the user’s browser.
Separate URLs: Serves different code to each device, and on separate URLs. This configuration tries
to detect the users’ device, then redirects to the appropriate page using
HTTP redirects] along with the Vary HTTP header.
Google does not favor any particular URL format as long as the page(s) and all page assets
are accessible to all Googlebot user-agents.
Frequently asked questions:
I have a separate mobile website on m.example.com, while my desktop site is at
www.example.com. What should I do with mobile pages on m.example.com that don’t have
an equivalent desktop page on www.example.com?
It’s fine to have a mobile-only page without a desktop equivalent (just make sure these pages
don’t include a rel=”canonical” to a non-corresponding desktop version). Please be aware
that mobile-only pages will need to build a reputation on their own (i.e., contain unique
content, be well-linked from other pages on your site or the web) because they will not
receive shared indexing signals from an existing desktop version of the page.


4. 255
Is it okay if I have some pages using responsive design and others using dynamic serving?

Yes, it’s fine to use more than one configuration for your site. Just check that on a page-level
basis, each provides the right indications to search engines (e.g., the responsive page has the
@media only screen and (max-width: 600px) {...} information and the dynamic serving page
uses the Vary: HTTP header). Or, if you’re using a hybrid of responsive design (e.g.,
responsive but with images dynamically served), we still consider that responsive since the
page is nearly the same – keep the markup @media only screen and (max-width: 600px) {...}
and forego the Vary HTTP header if it’s included specifically for Google. If you’re using
responsive images, include the <picture> element.
I have both a mobile website and a native app. Any advice?
Yes, first, build your mobile website and native apps with “deep linking capability” or URIs that
provide pointers to specific areas of content (vs. a Flash ball that’s only accessible from the
start screen). Deep links and URIs provide more acquisition possibilities for your business
through Search or social sharing. Second, see App Indexing for Google Search for more
information on driving more traffic to your native app from Google Search.

With App Indexing for Google Search, native app "pages" are potentially accessible to
searchers.
Signal your configuration to search engines
Make sure search engines like Google can understand your mobile site setup.
Responsive Web Design:
Dynamic Serving
Separate URLs
Responsive Web Design:
Responsive web design (RWD) is a setup where the server always sends the same HTML
code to all devices and CSS is used to alter the rendering of the page on the device.
Google’s algorithms should be able to automatically detect this setup if all Googlebot user
agents are allowed to crawl the page and its assets (CSS, JavaScript, and images).
Responsive design serves all devices with the same code that adjusts for screen size.
To signal to browsers that your page will adapt to all devices, add a meta tag to the head of
the document:
<Meta name="viewport" content="width=device-width, initial-scale=1.0">
The meta viewport tag gives the browser instructions on how to adjust the dimensions
and scaling of the page to the width of the device. When the meta viewport element is
absent, mobile browsers default to rendering the page at a desktop screen width (usually
about 980px, though this varies across devices). Mobile browsers then try to make the
content look better by increasing font sizes and either scaling the content to fit the screen
or showing only the part of the content that fits within the screen.
For users, this means that font sizes may have an inconsistent appearance, and users may
have to double-tap or pinch-to-zoom in order to be able to see and interact with the

5. 256
content. For Google, we might not judge a page as mobile-friendly because it requires this
kind (or type) of interaction on a mobile device.
On the left is a page without a meta viewport specified — the mobile browser therefore
assumes desktop width and scales the page to fit the screen, making the content hard to
read. On the right is the same page with a viewport specified that matches the device width
— the mobile browser doesn't scale the page and the content is
readable. For responsive images, include the <picture> element.
As a general rule, if your site works in a recent browser such as Google Chrome or
Apple Mobile Safari, it would work with our algorithms.
Why responsive design:
We recommend using responsive web design because it:
Makes it easier for users to share and link to your content with a single URL.
Helps Google’s algorithms accurately assign indexing properties to the page rather than
needing to signal the existence of corresponding desktop/mobile pages.
Requires less engineering time to maintain multiple pages for the same content.
Reduces the possibility of the common mistakes that affect mobile sites.
Requires no redirection for users to have a device-optimized view, which reduces load time.
Also, user agent-based redirection is error-prone and can degrade your site’s user
experience (see “Pitfalls when detecting user agents” section for details).
6. Saves resources when Googlebot crawls your site. For responsive web design pages, a single
Googlebot user agent only needs to crawl your page once, rather than crawling multiple
times with different Googlebot user agents to retrieve all versions of the content. This
improvement in crawling efficiency can indirectly help Google index more of your site’s
content and keep it appropriately fresh.
Remember:
Be sure not to block the crawling of any page assets (CSS, JavaScript, and images) for any
Googlebot using robots.txt or other methods. Being able to fully access these external
files will help our algorithms detect your site's responsive web design configuration and
treat it appropriately.
JavaScript:
One part of building mobile-friendly sites that requires careful consideration is the use of
JavaScript to alter the rendering and behaviour of the site on different devices. Typical
uses of JavaScript include deciding which ad or which image resolution variant to show in
the page.
This section describes different approaches to using JavaScript and how they relate to
Google’s recommendation of using responsive web design.
Common configurations

6. 257
Three popular implementations of JavaScript for mobile-friendly sites are:
JavaScript-adaptive: In this configuration, all devices are served the same HTML, CSS,
and JavaScript content. When the JavaScript is executed on the device, the rendering
or behaviour of the site is altered. If a website requires JavaScript, this is

Google’s recommended configuration.
Combined detection: In this implementation, the website uses both JavaScript and
server-side detection of device capabilities to serve different content to different
devices.

Dynamically-served JavaScript: In this configuration, all devices are served the same HTML, but
the JavaScript is served from a URL that dynamically serves different

JavaScript code depending on the device’s user-agent.
Let’s look at each of these configurations in detail.
JavaScript-adaptive:
In this configuration, a URL serves the same contents (HTML, CSS, JavaScript, an image) to all
devices. Only when the JavaScript is executed on the device is the rendering or behaviour of
the site altered. This is similar to how responsive web design, using CSS media queries,
works.
As an example, a page serves all devices the same HTML which includes a <script> element
that requests an external URL that serves the JavaScript. All devices requesting the
JavaScript’s URL get the same code. When executed, the JavaScript detects the device and
decides to alter something about the page, say to include a smartphone-friendly image or ad
code instead of the desktop alternatives.
This configuration is very closely related to responsive web design and our algorithms can
detect this setup automatically. Further, this configuration does not have a requirement for
the Vary HTTP header because the URLs of the page and its assets do not dynamically serve
content. Because of these advantages, if your website requires the use of JavaScript, this is
our recommended configuration.
Combined detection:
Combined detection is a setup where the server works in tandem with JavaScript on the
client to detect the device’s capabilities and alter the content being served.
For example, a site may choose to alter the rendering of the content based on whether the
device is a desktop or smartphone. In this case, the website can include JavaScript that
detects the screen dimensions, which are then sent to the server that updates or alters the
code sent to the device. Typically, the JavaScript stores the detected device capabilities in a
cookie that the server reads on subsequent visits from the same device.
Given that the server returns different HTML to different user-agents, combined detection
is considered a type of dynamic serving configuration. The details are described in full here,
but to briefly summarize them, the website should include the “Vary: User-agent” HTTP
response header when a URL that serves different HTML content to different user-agents is
requested.

7. 258
Dynamically-served JavaScript:
In this configuration, all devices are served the same HTML which includes a <script>
element to include an external JavaScript file that can have different content depending on
the requesting user-agent. That is, the JavaScript code is dynamically served.
In this case, we recommend that the JavaScript file be served with the “Vary: User-agent”
HTTP header. This is a signal to Internet caches and Googlebot that the JavaScript can be
different for different user agents, and is a signal for Googlebot to crawl the JavaScript
file using different Googlebot user-agents.
2. Dynamic Serving:
Dynamic serving is a setup where the server responds with different HTML (and CSS) on the
same URL depending on the user agent requesting the page.
As it is not immediately apparent in this setup that the site alters the HTML for mobile user
agents (the mobile content is “hidden” when crawled with a desktop user agent), we
recommend that the server send a hint to request that Googlebot for smartphones also
crawl the page, and thus discover the mobile content. This hint is implemented using the
Vary HTTP header.
The Vary HTTP header:
The Vary HTTP header has two important and useful implications:
It signals to caching servers used in ISPs and elsewhere that they should consider the
user agent when deciding whether to serve the page from cache or not. Without the
Vary HTTP header, a cache may mistakenly serve mobile users the cache of the
desktop HTML page or vice versa.

It helps Googlebot discover your mobile-optimized content faster, as a valid Vary
HTTP header is one of the signals we may use to crawl URLs that serve mobile-
optimized content.

The Vary HTTP header is part of the server’s response to a request, like this:
GET /page-1 HTTP/1.1
Host: www.example.com
(...rest of HTTP request headers...)
HTTP/1.1 200 OK
Content-Type: text/html
Vary: User-Agent
Content-Length: 5710
(... rest of HTTP response headers...)
The Vary header tells the browser that the contents of the response will vary depending on
the user agent that requests the page. If your server already uses the Vary HTTP header, you
can add “User-Agent” to the list that’s already served.

8. 259
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.).
Separate URLs:
In this configuration, each desktop URL has an equivalent different URL serving mobile-
optimized content.
A common setup would be pages on www.example.com serving desktop users with
corresponding pages served on m.example.com for mobile users. Google does not favor any
particular URL format as long as they are all accessible for all Googlebot user-agents.
Annotations for desktop and mobile URLs:
To help our algorithms understand separate mobile URLs, we recommend using
the following annotations:
On the desktop page, add a special link rel=”alternate” tag pointing to the
corresponding mobile URL. This helps Googlebot discover the location of your site’s
mobile pages.
On the mobile page, add a link rel=”canonical” tag pointing to the corresponding
desktop URL.
We support two methods to have this annotation: in the HTML of the pages themselves
and in sitemaps. For example, suppose that the desktop URL is http://example.com/page-1
and the corresponding mobile URL is http://m.example.com/page-1. The annotations in
this example would be as follows:

9. 260
Annotation in the HTML:
On the desktop page (http://www.example.com/page-1), add:
<link rel="alternate" media="only screen and (max-width: 640px)"
href="http://m.example.com/page-1" >
and on the mobile page (http://m.example.com/page-1), the required annotation should be:
<link rel="canonical" href="http://www.example.com/page-1" >
This rel=”canonical” tag on the mobile URL pointing to the desktop page is
required. Annotation in sitemaps
We support including the rel=”alternate” annotation for the desktop pages in sitemaps
like this:
<? xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:xhtml="http://www.w3.org/1999/xhtml">
<url>
<loc>http://www.example.com/page-1/</loc>
<xhtml: link
rel="alternate"
media="only screen and (max-width: 640px)"
href="http://m.example.com/page-1" />
</url>
</urlset>
The required rel=”canonical” tag on the mobile URL should still be added to the
mobile page’s HTML.
Annotation in detail:
Notice the attributes of the link tag on the desktop page:
The rel=”alternate” attribute signals that this tag specifies an alternative URL to
the desktop page.
The media attribute’s value is a CSS media query string that specifies the media
features describing when Google should use the alternative URL. In this case, we’re
using a media query that’s typically used to target mobile devices.
The href attribute specifies the location of the alternative URL, namely the page on
m.example.com.
This two-way (“bidirectional”) annotation helps Googlebot discover your content and helps our
algorithms understand the relationship between your desktop and mobile pages and treat
them accordingly. When you use different URLs to serve the same content in different formats,
the annotation tells Google’s algorithms that those two URLs have equivalent content and
should be treated as one entity instead of two entities. If the desktop and mobile version of the
page are treated as separate entities, both desktop and mobile URLs can be shown in desktop
search results, and their ranking may be lower than if Google

10. 261
understood their relationship. Furthermore, please note some of the common mistakes
in this configuration:
When using rel=”alternate” and rel=”canonical” markup, maintain a 1-to-1 ratio
between the mobile page and the corresponding desktop page. In particular, avoid
annotating many desktop pages referring to a single mobile page (or vice versa).

Double-check your redirects – make sure that desktop pages don’t inadvertently redirect to
a single, unrelated mobile page.

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.
Supported redirection techniques:
Googlebot supports the following two redirection implementations:
HTTP redirects

JavaScript redirects

Using HTTP redirects:
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
codes, 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 match Media () 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

11. 262
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.
Avoid common mistakes:
Avoid common mistakes we often see on mobile websites.
Blocked JavaScript, CSS and image files:
Unplayable content
Faulty redirects
Mobile-only 404s
App download interstitials
Irrelevant cross-links
Slow mobile pages
Blocked JavaScript, CSS and image files:
For optimal rendering and indexing, always allow Googlebot access to the JavaScript, CSS,
and image files used by your website so that Googlebot can see your site like an average
user. If your site’s robots.txt file disallows crawling of these assets, it directly harms how well
our algorithms render and index your content. This can result in suboptimal rankings.
Recommended actions:
Make sure that Googlebot can crawl your JavaScript, CSS and image files by using
the “Fetch as Google” feature in Google Webmaster Tools. It will allow you to see
exactly how Googlebot sees and renders your content, and it will help you identify
and fix a number of indexing issues on your site.

Check and test your robots.txt in Google Webmaster Tools.

Test your mobile pages with the Mobile-Friendly Test to see if our systems detect your
website as compatible for mobile users.

If you use separate URLs for your mobile pages, make sure to test both the mobile
and the desktop URLs, so you can confirm that the redirect is recognized and
crawlable.


Unplayable content:
Some types of videos or content are not playable on mobile devices, such as license-
constrained media or experiences that require Flash or other players that are not broadly
supported on mobile devices. Unplayable content, when featured on a page of any
website can be very frustrating for users.
When users visit a page with content not supported on a mobile device, they will see an
error message similar to the one below:
This provides users with a poor mobile experience!

12. 263
Instead of using a proprietary video player or putting content in unsupported formats, we
recommend using HTML5 standard tags to include videos or animations.
For animated content rendered using Flash or other multimedia players, consider using
HTML5 animations that work across all web browsers. Google Web Designer makes it easy
to create these animations in HTML5.
Recommended actions:
Use HTML5 standards for animations to provide a good experience to all your users.

Use video-embedding that’s playable on all devices.

Consider having the transcript of the video available. This will make your site accessible to people
who use assistive browsing technologies or who have browsers that cannot play a proprietary
video format.


For more details, read about video best practices on Google’s Web Fundamentals.
3. Faulty redirects:
If you have separate mobile URLs, you must redirect mobile users on each desktop URL to
the appropriate mobile URL. Redirecting to other pages (such as always to the homepage)
would be incorrect.
Examples:
Your desktop site’s server is configured to redirect mobile users to the mobile site’s homepage,
regardless of which URL they originally requested, even if the mobile site has the equivalent
page to the redirecting desktop page.
Your desktop site’s URLs are dynamically generated with URL parameters that don’t map well to
the equivalent mobile URL. For example, a user who is looking for a train timetable on a
specific date on the desktop site will be frustrated if they are redirected to the general
timetable search page on the mobile site. We recommend that you configure the redirection
correctly if you do have an equivalent mobile URL so that users end up on the page they
were looking for.

Your desktop site redirects some mobile devices but not others. For example, a site may redirect
only Android users to the mobile site and not redirect iPhone or Windows Phone users.

Recommended actions:
Use Webmaster Tools. If you’re a verified user, we’ll send you a message if we detect that any
of your site’s pages are redirecting smartphone users to the homepage. We’ll also show
you any faulty redirects we detect in the Smartphone Crawl Errors section of Webmaster
Tools. Use the example URLs we provide in Webmaster Tools as a starting point to debug
exactly where the problem is with your server configuration.



Set up your server so that it redirects smartphone users to the equivalent URL on your smartphone site.


13. 264
If a page on your site doesn’t have a smartphone equivalent, keep users on the desktop page,
rather than redirecting them to the smartphone site’s homepage. Doing nothing is better
than doing something wrong in this case.


Try using responsive web design, which serves the same content for desktop and smartphone
users.

4. Mobile-only 404s:
Some sites serve content to desktop users accessing a URL but show an error page to
mobile users.
To ensure the best user experience, if you recognize a user is visiting a desktop page from a
mobile device and you have an equivalent mobile page at a different URL, redirect them to
that URL instead of serving a 404 or a soft 404 page. Also make sure that the mobile-friendly
page itself is not an error page.
Recommended actions:
Use Webmaster Tools. If you’re a verified user for the site, we’ll send you a notification in the Message
Center.

If you have a smartphone site on a separate URL, set up your server so that it redirects smartphone
users to the equivalent URL on your smartphone site.

If you use Dynamic serving, Ensure your user-agent detection is correctly configured.

If a page on your site doesn’t have a smartphone equivalent, keep users on the desktop page.
Showing the content the user was looking for is a much better experience than showing an
error page.

Use responsive web design when possible. This configuration allows you to serve the same content to users,
whatever the device they use.


Check the Crawl Errors report in Webmaster Tools; the Smartphone tab will show a list of detected URLs
that return smartphone-only 404 errors.

5. App download interstitials:
Many webmasters promote their business’ native apps to their mobile website visitors. If
not done with care, this can cause indexing issues, and disrupt the visitor’s usage of the site.
Recommended actions:
Use a simple banner to promote your app in line with the page’s content. This banner can be implemented
using:

The native browser and operating system support such as Smart App Banners for Safari.

An HTML banner or image, similar to a typical small advert, that links to the correct app store for
download.

6. Irrelevant cross-links:
A common practice when a website serves users on separate mobile URLs is to have links to
the desktop-optimized version, and likewise a link from the desktop page to the mobile

14. 265
page. A common error is to have links point to an irrelevant page such as having the
mobile pages link to the desktop site’s homepage.
Recommended action:
Check your links to make sure that they point to the correct equivalent page.
7. Slow mobile pages:
It is very important to make sure your mobile site loads quickly. Users can become
very frustrated if they have to wait a long time to see your content.
Recommended action:
Use Google Page Speed Insights to discover if your page has any issues that can slow your
pages down, focusing on the “Speed” sub-section. Try to address the issues marked as
“Should Fix.”
Configure for other devices:
Configure your site to also be friendly on tablets and feature phones.
Tablets:
When thinking about how to configure your website for mobile users, it’s common to think about
visitors using tablet devices to access your site. Although we do not have specific recommendations
for building search engine friendly tablet-optimized websites, there are some tips for building
websites that serve desktop, smartphone and tablet users.
Responsive web design:
As for smartphone-optimized sites, our recommendation is to use responsive web design. This
means that your website serves the same HTML code to all devices along with different CSS style
rules to optimize the site’s interface on desktops, smartphones, and tablets.
If your website uses responsive web design, test it on a variety of tablets to make sure it renders
correctly as, just like for smartphones, there are a variety of tablet sizes and screen resolutions.
Device-specific content:
A website can return different pages (different HTML, CSS, JavaScript, etc) for different devices.
These pages can be served on the same URL (a configuration called dynamic serving) or on
separate dedicated URLs. Learn more about correctly detecting devices and user-agents.
If your website has different pages to serve desktop and smartphone users and does not have
tablet-specific pages, in our experience tablet users usually expect to see your desktop site rather
than the site’s smartphone pages.
If your website has tablet-optimized sites, these guidelines can help you configure your site:

15. 266
Dynamic serving: Here the same URLs serves desktop, smartphone, and tablet users by serving
different HTML (and CSS) depending on the user-agent. As described in our smartphone website
recommendations, we strongly suggest using the Vary HTTP header.
Separate tablet-dedicated URLs: In this case, we strongly suggest you allow Googlebot to crawl the
tablet URLs and use a rel=”canonical” on each tablet URL to point to the equivalent desktop URL.
Feature Phones:
Our recommendation for sites serving smartphone users is to use responsive web design if possible.
However, since feature phones do not have the capability to follow CSS media queries, webmasters
wishing to serve feature phones would need to configure their sites to either use dynamic serving
or separate URLs to serve the feature phone content.
This page demonstrates how to implement each of these configurations.
Dynamic Serving:
Configuring your server to dynamically serve feature phone optimized contents on the same
URL that serves other devices uses the same implementation as when serving smartphones.
To summarize: The server should include the “Vary: User-Agent” HTTP response header, and
you should also be aware of the common pitfalls when detecting user-agents
Separate URLs:
Webmasters have three supported configurations when serving desktop, smartphone, and feature
phone users on different URLs. These configurations use the annotations we’ve previously described
for building feature phone and smartphone optimized sites.
Dedicated URLs configuration:
In this configuration, the setup would be like this:
http://www.example.com/page-1 serves desktop users

http://m.example.com/page-1 serves smartphone users

http://phone.example.com/page-1 serves feature phone users

In this configuration, we recommend to add the following annotations to help our algorithms
understand the relationship between the equivalent pages targeting different devices:
On www.example.com/page-1 add:
<link rel="alternate" media="only screen and (max-width: 640px)"
href="http://m.example.com/page-1" />
<link rel="alternate" media="handheld" href="http://phone.example.com/page-1" />
On m.example.com/page-1 add:

16. 267
<link rel="canonical" href="http://www.example.com/page-1" />
On phone.example.com/page-1 add:
<link rel="canonical" href="http://www.example.com/page-1" />
Desktop and all-mobile URLs configuration:
In this configuration, a website would serve desktop devices on one URL and all mobiles, i.e. both
smartphones and feature phones, on a separate URL. For example:
http://www.example.com/page-1 serves desktop users

http://m.example.com/page-1 serves both smartphone and feature phone users

In this case, the annotation on http://www.example.com/page-1 would be:
<link rel="alternate" media="only screen and (max-width: 640px)"
href="http://m.example.com/page-1" />
<link rel="alternate" media="handheld" href="http://m.example.com/page-1" />
On the m.example.com site, include:
<link rel="canonical" href="http://www.example.com/page-1" />
This rel=”canonical” needs to be included on all pages regardless if they are feature phone pages or
smartphone pages.
The server should include the HTTP Vary: User-Agent header in its response. This sends a signal to
Internet caches and Googlebot that the server’s response may differ depending on the user-
agent. Mobile Googlebot will use this signal for crawling.
Separate feature phone URLs configuration:
In this configuration, a website serves desktops and smartphones on one URL using responsive
web design or dynamic serving, and feature phones on a separate URL. For example:
http://www.example.com/page-1 serves desktop and smartphone users

http://m.example.com/page-1 serves feature phone users

In this case, the annotation on http://www.example.com/page-1 would be:
<link rel="alternate" media="handheld" href="http://m.example.com/page-1" />
And on http://m.example.com/page-1 would be:
<link rel="canonical" href="http://www.example.com/page-1" />
Note that if http://www.example.com/page-1 uses dynamic serving, it would need to follow our
recommendations for this configuration.

17. 268
Redirects and the HTTP Vary header
Please note that if your site automatically redirects mobile visitors coming to the desktop site to the
mobile site, or vice versa, please be sure to configure your server to include the Vary HTTP header as
described on this page.
Sitemaps:
Our recommendations for using feature phone sitemaps, and sitemaps for smartphone
alternate URLs remain unchanged.