Showing posts with label mobile-friendly. Show all posts
Showing posts with label mobile-friendly. Show all posts

Tuesday, January 31, 2017

Introducing the Mobile-Friendly Test API

With so many users on mobile devices, having a mobile-friendly web is important to us all. The Mobile-Friendly Test is a great way to check individual pages manually. We're happy to announce that this test is now available via API as well.

The Mobile-Friendly Test API lets you test URLs using automated tools. For example, you could use it to monitor important pages in your website in order to prevent accidental regressions in templates that you use. The API method runs all tests, and returns the same information - including a list of the blocked URLs - as the manual test. The documentation includes simple samples to help get you started quickly.

We hope this API makes it easier to check your pages for mobile-friendliness and to get any such issues resolved faster. We'd love to hear how you use the API -- leave us a comment here, and feel free to link to any code or implementation that you've set up! As always, if you have any questions, feel free to drop by our webmaster help forum.


Wednesday, November 9, 2016

Building Indexable Progressive Web Apps

Progressive Web Apps (PWAs) are taking advantage of new technologies to bring the best of mobile sites and native applications to users -- and they’re one of the most exciting new ideas on the web. But to truly have an impact, it's important that they’re indexable and linkable. Every recommendation presented in this article is an existing best practice for indexability -- regardless of whether you're building a Progressive Web App or a simple static website. Nonetheless, we have collated these best practices to provide a checklist to guide you:

Make Your Content Crawlable

Why? Historically, websites would always generate or render their HTML on the server which is the simplest way to ensure your content is directly linkable. Web applications popularised the concept of client-side rendering in which content is updated dynamically on the page as the users navigates without requiring the page to be reloaded.

The modern approach is hybrid rendering, in which server-side rendering is used when a user navigates directly to a URL and client-side rendering is used after the initial page load for subsequent navigation and asynchronous requests.

Our server-side PWA sample demonstrates pure server-side rendering, while our hybrid PWA sample demonstrates the combined approach.

If you are unfamiliar with the server-side and client-side rendering terminology, check out these articles on the web read here and here.

Best Practice:

Use server-side or hybrid rendering so users receive the content in the initial payload of their web request.

Always ensure your URLs are independently accessible:

https://www.example.com/product/25/

The above should deep link to that particular resource.

If you can’t support server-side or hybrid rendering for your Progressive Web App and you decide to use client-side rendering, we recommend using the Google Search Console “Fetch as Google tool” to verify your content successfully renders for our search crawler.

Don’t:

Don't redirect users accessing deep links back to your web app's homepage.

Additionally, serving an error page to users instead of deep linking should also be avoided.


Provide Clean URLs

Why? Fragment identifiers (#user/24601/ or #!user/24601/) were an effective workaround for browsers to AJAX new content from a server without reloading the page. This design is known as client-side rendering.

However, the fragment identifier syntax isn’t compatible with some web tools, frameworks and protocols such as Facebook’s Open Graph protocol.

The History API enables us to update the URL without fragment identifiers while still fetching resources asynchronously and therefore avoiding page reloads -- it’s the best of both worlds. The AJAX crawling scheme (with its #! / escaped-fragment URLs) made sense at its time, but is now no longer recommended.

Our hybrid PWA and client-side PWA samples demonstrate the History API.

Best Practice:

Provide clean URLs without fragment identifiers (# or #!) such as:

https://www.example.com/product/25/

If using client-side or hybrid rendering be sure to support browser navigation with the History API.

Avoid:

Using the #! URL structure to drive unique URLs is discouraged:

https://www.example.com/#!product/25/

It was introduced as a workaround before the advent of the History API. It is considered a separate pattern to the purely # URL structure.

Don’t:

Using the # URL structure without the accompanying ! symbol is unsupported:

https://www.example.com/#product/25/

This URL structure is already a concept in the web and relates to deep linking into content on a particular page.


Specify Canonical URLs

Why? The best way to eliminate confusion for indexing when the same content is available under multiple URLs (be it the same or different domains) is to mark one page as the canonical, and all other pages that duplicate that content to refer to it.

Best Practice:

Include the following tag across all pages mirroring a particular piece of content:

<link rel="canonical" href="https://www.example.com/your-url/" />

If you are supporting Accelerated Mobile Pages be sure to correctly use its counterpart rel=”amphtml” instruction as well.

Avoid:

Avoid purposely duplicating content across multiple URLs and not using the rel="canonical" link element.

For example, the rel="canonical" link element can reduce ambiguity for URLs with tracking parameters.

Don’t:

Avoid creating conflicting canonical references between your pages.


Design for Multiple Devices

Why? It’s important that all your users get the best experience possible when viewing your website, regardless of their device.

Make your site responsive in its design -- fonts, margins, paddings, buttons and general design of your site should scale dynamically based on screen resolutions and device viewports.

Small images scaled up for desktop or tablet devices give a poor experience. Conversely, super high resolution images take a long time to download on mobile phones and may impact mobile scroll performance.

Read more UX for PWAs here.

Best Practice:

Use “srcset” attribute to fetch different resolution images for different density screens to avoid downloading images larger than the device’s screen is capable of displaying.

Scale your font size and line height to ensure your text is legible no matter the size of the device. Similarly ensure the padding and margins of elements also scale sensibly.

Test various screen resolutions using the Chrome Developer Tool’s Device Mode feature and Mobile Friendly Test tool.

Don’t:

Don't show different content to users than you show to Google. If you use redirects or user agent detection (a.k.a. browser sniffing or dynamic serving) to alter the design of your site for different devices it’s important that the content itself remains the same.

Use the Search Console “Fetch as Google” tool to verify the content fetched by Google matches the content a user sees.

For usability reasons, avoid using fixed-size fonts.


Develop Iteratively

Why? One of the safest paths to take when adding features to a web application is to make changes iteratively. If you add features one at a time you can observe the impact of each individual change.

Alternatively many developers prefer to view their progressive web application as an opportunity to overhaul their mobile site in one fell swoop -- developing the new web app in an isolated environment and swapping it with their existing mobile site once ready.

When developing features iteratively try to break the changes into separate pieces. For example, if you intend to move from server-side rendering to hybrid rendering then tackle that as a single iteration -- rather than in combination with other features.

Both approaches have their own pros and cons. Iterating reduces the complexity of dealing with search indexability as the transition is continuous. However, iterating might result in a slower development process and potentially a less innovative overhaul if development is not starting from scratch.

In either case, the most sensitive areas to keep an eye on are your canonical URLs and your site’s robots.txt configuration.

Best Practice:

Iterate on your website incrementally by adding new features piece by piece.

For example, if don’t support HTTPS yet then start by migrating to a secure site.

Avoid:

If you’ve developed your progressive web app in an isolated environment, then avoid launching it without checking the rel-canonical links and robots.txt are setup appropriately.

Ensure your rel-canonical links point to the real site and that your robots.txt configuration allows crawlers to crawl your new site.

Don’t:

It’s logical to prevent crawlers from indexing your in-development site before launch but don’t forget to unblock crawlers from accessing your new site when you launch.


Use Progressive Enhancement

Why? Wherever possible it’s important to detect browser features before using them. Feature detection is also better than testing for browsers that you believe support a given feature.

A common bad practice in the past was to enable or disable features by testing which browser the user had. However, as browsers are constantly evolving with features this technique is strongly discouraged.

Service Worker is a relatively new technology and it’s important to not break compatibility in the pursuit of progress -- it's a perfect example of when to use progressive enhancement.

Best Practice:

Before registering a Service Worker check for the availability of its API:

if ('serviceWorker' in navigator) {
...

Use per API detection method for all your website’s features.

Don’t:

Never use the browser’s user agent to enable or disable features in your web app. Always check whether the feature’s API is available and gracefully degrade if unavailable.

Avoid updating or launching your site without testing across multiple browsers! Check your site analytics to learn which browsers are most popular among your user base.


Test with Search Console

Why? It’s important to understand how Google Search views your site’s content. You can use Search Console to fetch individual URLs from your site and see how Google Search views them using the “Crawl > Fetch as Google“ feature. Search Console will process your JavaScript and render the page when that option is selected; otherwise only the raw HTML response is shown

Google Search Console also analyses the content on your page in a variety of ways including detecting the presence of Structured Data, Rich Cards, Sitelinks & Accelerated Mobile Pages.

Best Practice:

Monitor your site using Search Console and explore its features including “Fetch as Google”.

Provide a Sitemap via Search Console “Crawl > Sitemaps” It can be an effective way to ensure Google Search is aware of all your site’s pages.


Annotate with Schema.org structured data

Why? Schema.org structured data is a flexible vocabulary for summarizing the most important parts of your page as machine-processable data. This can be as general as simply saying that a page is a NewsArticle, or as specific as detailing the location, band name, venue and ticket vendor for a touring band, or summarizing the ingredients and steps for a recipe.

The use of this metadata may not make sense for every page on your web application but it’s recommended where it’s sensible. Google extracts it after the page is rendered.

There are a variety of data types including “NewsArticle”, “Recipe” & “Product” to name a few. Explore all the supported data types here.

Best Practice:

Verify that your Schema.org meta data is correct using Google’s Structured Data Testing Tool.

Check that the data you provided is appearing and there are no errors present.

Don’t:

Avoid using a data type that doesn’t match your page’s actual content. For example don’t use “Recipe” for a T-Shirt you’re selling -- use “Product” instead.


Annotate with Open Graph & Twitter Cards

Why? In addition to the Schema.org metadata it can be helpful to add support for Facebook’s Open Graph protocol and Twitter rich cards as well.

These metadata formats improve the user experience when your content is shared on their corresponding social networks.

If your existing site or web application utilises these formats it’s important to ensure they are included in your progressive web application as well for optimal virality.

Best Practice:

Test your Open Graph markup with the Facebook Object Debugger Tool.

Familiarise yourself with Twitter’s metadata format.

Don’t:

Don’t forget to include these formats if your existing site supports them.


Test with Multiple Browsers

Why? Clearly from a user perspective it’s important that a website behaviors the same across all browsers. While the experience might adapt for different screen sizes we all expect a mobile site to work the same on similarly sized devices whether it’s an iPhone or an Android mobile phone.

While the web can be perceived as fragmented due to number of browsers in use around the world, this variety and competition is part of what makes the web such an innovative platform. Thankfully, web standards have never been more mature than they are now and modern tools enable developers to build rich, cross browser compatible websites with confidence.

Best Practice:

Use cross browser testing tools such as BrowserStack.com, Browserling.com or BrowserShots.org to ensure your PWA is cross browser compatible.


Measure Page Load Performance

Why? The faster a website loads for a user the better their user experience will be. Optimizing for page speed is already a well known focus in web development but sometimes when developing a new version of a site the necessary optimizations are not considered a high priority.

When developing a progressive web application we recommend measuring the performance of your page load speed and optimizing before launching the site for the best results.

Best Practice:

Use tools such as Page Speed Insights and Web Page Test to measure the page load performance of your site. While Googlebot has a bit more patience in rendering, research has shown that 40% of consumers will leave a page that takes longer than three seconds to load..

Read more about our web page performance recommendations and the critical rendering path here.

Don’t:

Avoid leaving optimization as a post-launch step. If your website’s content loads quickly before migrating to a new progressive web application then it’s important to not regress in your optimizations.


We hope that the above checklist is useful and provides the right guidance to help you develop your Progressive Web Applications with indexability in mind.

As you get started, be sure to check out our Progressive Web App indexability samples that demonstrate server-side, client-side and hybrid rendering. As always, if you have any questions, please reach out on our Webmaster Forums.


Friday, November 4, 2016

Mobile-first Indexing

Mobile-first Indexing

Today, most people are searching on Google using a mobile device. However, our ranking systems still typically look at the desktop version of a page’s content to evaluate its relevance to the user. This can cause issues when the mobile page has less content than the desktop page because our algorithms are not evaluating the actual page that is seen by a mobile searcher.

To make our results more useful, we’ve begun experiments to make our index mobile-first. Although our search index will continue to be a single index of websites and apps, our algorithms will eventually primarily use the mobile version of a site’s content to rank pages from that site, to understand structured data, and to show snippets from those pages in our results. Of course, while our index will be built from mobile documents, we're going to continue to build a great search experience for all users, whether they come from mobile or desktop devices.

We understand this is an important shift in our indexing and it’s one we take seriously. We’ll continue to carefully experiment over the coming months on a small scale and we’ll ramp up this change when we’re confident that we have a great user experience. Though we’re only beginning this process, here are a few recommendations to help webmasters prepare as we move towards a more mobile-focused index.

  • If you have a responsive site or a dynamic serving site where the primary content and markup is equivalent across mobile and desktop, you shouldn’t have to change anything.
  • If you have a site configuration where the primary content and markup is different across mobile and desktop, you should consider making some changes to your site.
    • Make sure to serve structured markup for both the desktop and mobile version.

      Sites can verify the equivalence of their structured markup across desktop and mobile by typing the URLs of both versions into the Structured Data Testing Tool and comparing the output.

      When adding structured data to a mobile site, avoid adding large amounts of markup that isn’t relevant to the specific information content of each document.
    • Use the robots.txt testing tool to verify that your mobile version is accessible to Googlebot.
    • Sites do not have to make changes to their canonical links; we’ll continue to use these links as guides to serve the appropriate results to a user searching on desktop or mobile.
  • If you are a site owner who has only verified their desktop site in Search Console, please add and verify your mobile version.
  • If you only have a desktop site, we'll continue to index your desktop site just fine, even if we're using a mobile user agent to view your site.

    If you are building a mobile version of your site, keep in mind that a functional desktop-oriented site can be better than a broken or incomplete mobile version of the site. It's better for you to build up your mobile site and launch it when ready.  

If you have any questions, feel free to contact us via the Webmaster forums or our public events. We anticipate this change will take some time and we’ll update you as we make progress on migrating our systems.


Wednesday, September 21, 2016

8 tips to AMPlify your clients

Here is our list of the top 8 things to consider when helping your clients AMPlify their websites (and staying ahead of their curiosity!) after our announcement to expand support for Accelerated Mobile Pages.

  1. Getting started can be simple

If a site uses a popular Content Management System (CMS), getting AMP pages up and running is as straightforward as installing a plug-in. Sites that use custom HTML or that are built from scratch will require additional development resources.

  1. Not all types of sites are suitable

AMP is great for all types of static web content such as news, recipes, movie listings, product pages, reviews, videos, blogs and more. AMP is less useful for single-page apps that are heavy on dynamic or interactive features, such as route mapping, email or social networks.

  1. You don’t have to #AMPlify the whole site

Add AMP to a client's existing site progressively by starting with simple, static content pages like articles, products, or blog posts. These are the “leaf” pages that users access through platforms and search results, and could be simple changes that also bring the benefits of AMP to the website. This approach allows you to keep the homepage and other “browser” pages that might require advanced, non-AMP dynamic functionality.

If you're creating a new, content-heavy website from scratch, consider building the whole site with AMP from the start. To begin with, check out the getting started guidelines.

  1. The AMP Project is open source and still evolving

If a site's use case is not supported in the AMP format yet, consider filing a feature request on GitHub, or you could even design a component yourself.

  1. AMP pages might need to meet additional requirements to show up in certain places

In order to appear in Google’s search results, AMP pages need only be valid AMP HTML. Some products integrating AMP might have further requirements than the AMP validation. For example, you'll need to mark up your AMP pages as Article markup with Structured Data to make them eligible for the Google Top Stories section.

  1. There is no ranking change on Search

Whether a page or site has valid and eligible AMP pages has no bearing on the site’s ranking on the Search results page. The difference is that web results that have AMP versions will be labeled with an icon.

  1. AMP on Google is expanding globally

AMP search results on Google will be rolling out worldwide when it launches in the coming weeks. The Top Stories carousel which shows newsy and fresh AMP content is already available in a number of countries and languages.

  1. Help is on hand

There’s a whole host of useful resources that will help if you have any questions:

Webmasters Help Forum: Ask questions about AMP and Google’s implementation of AMP
Stack Overflow: Ask technical questions about AMP
GitHub: Submit a feature request or contribute

What are your top tips to #AMPlify pages? Let us know in the comments below or on our Google Webmasters Google+ page. Or as usual, if you have any questions or need help, feel free to post in our Webmasters Help Forum.

Friday, September 16, 2016

How can Google Search Console help you AMPlify your site?

If you have recently implemented Accelerated Mobile Pages on your site, it’s a great time to check which of your AMP pages Google has found and indexed by using Search Console.

Search Console is a free service that helps you monitor and maintain your site's presence in Google Search, including any Accelerated Mobile Pages. You don't have to sign up for Search Console for your AMP pages to be included in Google Search results, but doing so can help you understand which of your AMP pages are eligible to show in search results.

To get started with Search Console, create a free account or sign in here and validate the ownership of your sites.

Once you have your site set up on Search Console, open the Accelerated Mobile Pages report under Search Appearance > Accelerated Mobile Pages to see which AMP pages Google has found and indexed on your site, as shown here:

The report lists AMP-related issues for AMP pages that are not indexed, so that you can identify and address them.

Search Console also lets you monitor the performance of your AMP pages on Google Search in the Search Analytics report. This report tells you which queries show your AMP pages in Search results, lets you compare how their metrics stack against your other results and see how the visibility of your AMP pages has changed over time.

To view your AMP page metrics, such as clicks or impressions, select Search Appearance > Search Analytics > Filter by AMP.

(Note: if you’ve only just created your Search Console account or set up your AMP pages and they have not been detected yet, remember that Google crawls pages only periodically. You can wait for the scheduled regular recrawl, or you can request a recrawl.)

Have you been using Search Console to monitor your AMP pages? Give us feedback in the comments below or on our Google Webmasters Google+ page. Or as usual, if you have any questions or need help, feel free to post in our Webmasters Help Forum.

UPDATE: To help ensure that your AMP implementation is working as expected, Search Console now has an enhanced AMP testing tool.

Tuesday, May 17, 2016

A new mobile friendly testing tool

Mobile is close to our heart - we love seeing more and more sites make their content available in useful & accessible ways for mobile users. To help keep the ball rolling, we've now launched a new Mobile Friendly Test.

The new tool is linked from Search Console's mobile usability report or available directly at https://search.google.com/search-console/mobile-friendly

The updated tool provides us with room to continue to improve on its functionality, and over time, we expect it to replace the previous Mobile Friendly Test. Additionally, of course this tool also works well on your smartphone, if you need to double-check something there!

We'd like to invite you to take it for a spin, try your website and other sites that you're curious about! Let us know how you like it - either here in the comments or in our webmaster help forums.

Wednesday, March 16, 2016

Continuing to make the web more mobile friendly

Continuing to make the web more mobile friendly

Getting good, relevant answers when you search shouldn’t depend on what device you’re using. You should get the best answer possible, whether you’re on a phone, desktop or tablet. Last year, we started using mobile-friendliness as a ranking signal on mobile searches. Today we’re announcing that beginning in May, we’ll start rolling out an update to mobile search results that increases the effect of the ranking signal to help our users find even more pages that are relevant and mobile-friendly.

If you've already made your site mobile-friendly, you will not be impacted by this update. If you need support with your mobile-friendly site, we recommend checking out the Mobile-Friendly Test and the Webmaster Mobile Guide, both of which provide guidance on how to improve your mobile site. And remember, the intent of the search query is still a very strong signal — so even if a page with high quality content is not mobile-friendly, it could still rank well if it has great, relevant content.

If you have any questions, please go to the Webmaster help forum.

Tuesday, September 1, 2015

Mobile-friendly web pages using app banners

When it comes to search on mobile devices, users should get the most relevant answers, no matter if the answer lives in an app or a web page. We’ve recently made it easier for users to find and discover apps and mobile-friendly web pages. However, sometimes a user may tap on a search result on a mobile device and see an app install interstitial that hides a significant amount of content and prompts the user to install an app. Our analysis shows that it is not a good search experience and can be frustrating for users because they are expecting to see the content of the web page.

Starting today, we’ll be updating the Mobile-Friendly Test to indicate that sites should avoid showing app install interstitials that hide a significant amount of content on the transition from the search result page. The Mobile Usability report in Search Console will show webmasters the number of pages across their site that have this issue.

After November 1, mobile web pages that show an app install interstitial that hides a significant amount of content on the transition from the search result page will no longer be considered mobile-friendly. This does not affect other types of interstitials. As an alternative to app install interstitials, browsers provide ways to promote an app that are more user-friendly.


App install interstitials that hide a significant amount of content provide a bad search experience

App install banners are less intrusive and preferred

App install banners are supported by Safari (as Smart Banners) and Chrome (as Native App Install Banners). Banners provide a consistent user interface for promoting an app and provide the user with the ability to control their browsing experience. Webmasters can also use their own implementations of app install banners as long as they don’t block searchers from viewing the page’s content.

If you have any questions, we’re always happy to chat in the Webmaster Central Forum.

Posted by Daniel Bathgate, Software Engineer, Google Search.

Tuesday, April 21, 2015

FAQs about the April 21st mobile-friendly update

We’d like to share answers to your frequently asked questions. For background, in February, we announced that the mobile-friendly update will boost the rankings of mobile-friendly pages -- pages that are legible and usable on mobile devices -- in mobile search results worldwide. (Conversely, pages designed for only large screens may see a significant decrease in rankings in mobile search results.) To get us all on the same page, here are the most frequently asked questions:

General FAQs


1. Will desktop and/or tablet ranking also be affected by this change?

No, this update has no effect on searches from tablets or desktops. It affects searches from mobile devices across all languages and locations.


2. Is it a page-level or site-level mobile ranking boost? 

It’s a page-level change. For instance, if ten of your site’s pages are mobile-friendly, but the rest of your pages aren’t, only the ten mobile-friendly pages can be positively impacted.


3. How do I know if Google thinks a page on my site is mobile-friendly?

Individual pages can be tested for “mobile-friendliness” using the Mobile-Friendly Test.

Screen Shot 2015-04-08 at 5.41.16 PM.png
Test individual URLs in real-time with the Mobile-Friendly Test.

To review site-level information on mobile-friendliness, check out the Mobile Usability report in Webmaster Tools. This feature’s data is based on the last time we crawled and indexed your site’s pages.

Screen Shot 2015-04-08 at 5.39.24 PM.png
Mobile Usability in Webmaster Tools provides a snapshot of your entire site’s mobile-friendliness.



4. Unfortunately, my mobile-friendly pages won’t be ready until after April 21st. How long before they can be considered mobile-friendly in ranking?

We determine whether a page is mobile-friendly every time it’s crawled and indexed -- you don’t have to wait for another update. Once a page is mobile-friendly, you can wait for Googlebot for smartphones to naturally (re-)crawl and index the page or you can expedite processing by using Fetch as Google with Submit to Index in Webmaster Tools. For a large volume of URLs, consider submitting a sitemap. In the sitemap, if your mobile content uses pre-existing URLs (such as with Responsive Web Design or dynamic serving), also include the lastmod tag.


5. Since the mobile ranking change rolls out on April 21st, if I see no drop in traffic on April 22nd, does that mean that my site’s rankings aren't impacted?

You won't be able to definitively determine whether your site’s rankings are impacted by the mobile-friendly update by April 22nd. While we begin rolling out the mobile-friendly update on April 21st, it’ll be a week or so before it makes its way to all pages in the index. 


6. I have a great mobile site, but the Mobile-Friendly Test tells me that my pages aren't mobile-friendly. Why?

If a page is designed to work well on mobile devices, but it’s not passing the Mobile-Friendly Test, the most common reason is that Googlebot for smartphones is blocked from crawling resources, like CSS and JavaScript, that are critical for determining whether the page is legible and usable on a mobile device (i.e., whether it’s mobile-friendly). To remedy:
  1. Check if the Mobile-Friendly Test shows blocked resources (often accompanied with a partially rendered image).
  2. Allow Googlebot to crawl the necessary files.
  3. Double-check that your page passes the Mobile-Friendly Test.
  4. Use Fetch as Google with Submit to Index and submit your updated robots.txt to Google to expedite the re-processing of the updated page (or just wait for Google to naturally re-crawl and index).
Screen Shot 2015-04-08 at 8.27.58 PM.png
The most common reason why a mobile page fails the Mobile-Friendly Test is that Googlebot for smartphones is blocked from crawling resources, like CSS and JavaScript, that are crucial for understanding the page’s mobile-friendliness. 


To reiterate, we recommend that site owners allow Googlebot to crawl all resources for a page (including CSS, JavaScript, and images), so that we can properly render, index, and in this case, assess whether the page is mobile-friendly.


7. What if I link to a site that’s not mobile-friendly?

Your page can still be “mobile-friendly” even if it links to a page that’s not mobile-friendly, such as a page designed for larger screens, like desktops. It’s not the best experience for mobile visitors to go from a mobile-friendly page to a desktop-only page, but hopefully as more sites become mobile-friendly, this will become less of a problem.


8. Does Google give a stronger mobile-friendly ranking to pages using Responsive Web Design (which uses the same URL and the same HTML for the desktop and mobile versions) vs. hosting a separate mobile site (like www for desktop and m.example.com for mobile)?

No, mobile-friendliness is assessed the same, whether you use responsive web design (RWD), separate mobile URLs, or dynamic serving for your configuration. If your site uses separate mobile URLs or dynamic serving, we recommend reviewing the Mobile SEO guide to make sure Google is properly crawling and indexing your mobile pages.


9. Will my site / page disappear on mobile search results if it's not mobile-friendly?

While the mobile-friendly change is important, we still use a variety of signals to rank search results. The intent of the search query is still a very strong signal -- so even if a page with high quality content is not mobile-friendly, it could still rank high if it has great content for the query.


Specialized FAQs


10. What if my audience is desktop only? Then there’s no reason to have a mobile site, right?

Not exactly. Statistics show that more people are going “mobile only” -- either because they never had a desktop or because they won’t replace their existing desktop. Additionally, a non-mobile-friendly site may not see many mobile visitors precisely for that reason. 

The mobile-friendly update will apply to mobile searches conducted across all sites, regardless of the site’s target audiences’ language, region, or proportion of mobile to desktop traffic.


11. I have pages showing mobile usability errors because they embed a YouTube video. What can I do?

We suggest paying close attention to how the YouTube video is embedded. If you are using the “old-style” <object> embeds in the mobile page, convert to <iframe> embeds for broader compatibility. YouTube now uses the HTML5 player on the web by default, so it’s mobile-friendly to embed videos using the <iframe> tags from the “share” feature on the watch page or from the YouTube iFrame API. If you have a more complex integration, that should also be mobile-friendly, since it’ll instruct the device to use the device’s native support. 

For Flash content from sites other than YouTube, check if there is an equivalent HTML5 embed tag or code snippet to avoid using proprietary plugins.


12. Is there a clear standard for sizing tap targets?

Yes, we suggest a minimum of 7mm width/height for primary tap targets and a minimum margin of 5mm between secondary tap targets. The average width of an adult's finger pad is 10mm, and these dimensions can provide a usable interface while making good use of screen real estate.


13. To become mobile-friendly quickly, we’re thinking of creating a very stripped down version of our site (separate mobile pages) until our new responsive site is complete. Do you foresee any problems with this?

First, keep in mind that we support three mobile configurations and that your website doesn't have to be responsive to be mobile-friendly. In response to your question, please be cautious about creating a “stripped down” version of your site. While the page may be formatted for mobile, if it doesn’t allow your visitors to easily complete their common tasks or have an overall smooth workflow, it may become frustrating to your visitors and perhaps not worth the effort. Should a temporary mobile site be created, once the RWD is live, be sure to move the site properly. For example, update all links so they no longer reference the separate mobile URLs and 301 redirect mobile URLs to their corresponding RWD version.

Recommendations


If you’re totally new to building a mobile-friendly site, it’s not too late! Check out our Getting Started guide in the Mobile-Friendly Websites documentation.

Screen Shot 2015-04-08 at 8.53.30 PM.png
Get started on your mobile site at https://developers.google.com/webmasters/mobile-sites/.


If you already have a mobile site, investigate the Mobile Usability report in Webmaster Tools to make sure that Google detects your site’s pages as mobile-friendly. 

Still more questions? Please ask below or check out the Mobile Websites section of the Webmaster Forum


Rolling out the mobile-friendly update

As we noted earlier this year, today’s the day we begin globally rolling out our mobile-friendly update. We’re boosting the ranking of mobile-friendly pages on mobile search results. Now searchers can more easily find high-quality and relevant results where text is readable without tapping or zooming, tap targets are spaced appropriately, and the page avoids unplayable content or horizontal scrolling.

Screen Shot 2015-04-07 at 2.20.01 AM.png
April 21st’s mobile-friendly update boosts mobile search rankings for pages that are legible and usable on mobile devices.

This update:
  • Affects only search rankings on mobile devices
  • Affects search results in all languages globally 
  • Applies to individual pages, not entire websites

While the mobile-friendly change is important, we still use a variety of signals to rank search results. The intent of the search query is still a very strong signal -- so even if a page with high quality content is not mobile-friendly, it could still rank high if it has great content for the query. 

To check if your site is mobile-friendly, you can examine individual pages with the Mobile-Friendly Test or check the status of your entire site through the Mobile Usability report in Webmaster Tools. If your site’s pages aren’t mobile-friendly, there may be a significant decrease in mobile traffic from Google Search. But have no fear, once your site becomes mobile-friendly, we will automatically re-process (i.e., crawl and index) your pages.  You can also expedite the process by using Fetch as Google with Submit to Index, and then your pages can be treated as mobile-friendly in ranking.