Skip to content

Mobile-First Indexing

By Matthew Edgar · Last Updated: December 14, 2023

Google typically crawls and evaluates the mobile version of a website first and uses what is found on the mobile website to decide where to rank the website in search results. This is referred to as mobile-first indexing.

This is not mobile-only indexing. Google will still crawl the desktop version of the website. In some cases, Google may even crawl the desktop version of the website more frequently than the mobile version of the website. Whatever is found on the desktop website can also influence what is ranked in search results.

What Device Does Google Use to Crawl Your Website?

You can find out which device Google is using to crawl your website in Google’s Search Console’s Crawl Stats report. To access the Crawl Stats report, click on Settings and then click Open Report next to Crawl Stats. Once on the Crawl Stats report, you’ll see a table that says “By Googlebot type”. The first screenshot shows an example of a website where Google primarily crawls via the Desktop bot and the second screenshot below shows an example where Google primarily crawls via the Smartphone bot.

Google Crawl Stats Googlebot Type report, desktop bot first
Google Crawl Stats Googlebot Type report, smartphone bot first

Mobile Equivalency

The most important consideration for mobile-first indexing is the equivalency between the desktop and mobile websites: does your mobile and desktop website share the same content and serve the same general purpose?

You want to make sure that if Google only crawls one version of the website, Google will be able to correctly understand what your website is about and will be able to find the important content that exists on your website.

Keep in mind this isn’t all about Google. Human visitors want to see the same content too—if people visit a website from both their phone and desktop devices, they expect to find the same information regardless of the device used.

Equivalency of Main Content

The biggest problems arise when the main content is hidden from view on one device. That includes hiding important text, images, videos, or other features. Google needs to see this important content on mobile and on desktop devices to determine where to rank your website. If Google’s robots can’t see this content on one device or another, they might miss key content and might not include your website in relevant search results, leading to a loss of traffic.

This is not to say all content must match. There will be some natural differences between the desktop and mobile versions of a website. It is common practice to remove some content from the mobile website that is present on the desktop website. This is fine so long as what gets hidden is only unessential content. For example, it makes sense to hide decorative images on the mobile website; those decorative images might help the desktop website’s design but crowd out the content on mobile devices.

Concerns When Removing Main Content

In some cases, parts of the main content are removed from the mobile version of the website altogether so that the remaining content can more easily fit on the mobile screen. This is risky because the removed main content may be important for Google to fully understand the page (and might be important for visitors as well). Instead of removing this key content, decide how to position these elements so robots and humans, regardless of the device used, can find them.

The best example is the website’s main navigation. While the main navigation can easily be displayed prominently on the desktop website, it needs to be hidden from view on the mobile version of the website until a hamburger icon is clicked. So long as it is the same (equivalent) content presented in different ways, you can still maintain equivalency between devices.

Concerns When Hiding Main Content

In other cases, the content is present on mobile devices but hidden from view by default. This is acceptable so long as Google can still fetch the main content. For example, some content might be hidden on mobile websites until people click a “Read More” link, click on tabs, or expand accordions.

If you are using these types of techniques, there are two important steps to make sure Google can easily find this content:

  1. The content should still be present in the server-side rendered code or in the client-side code rendered on load. Google can’t click on a tab or expand an accordion to view the content. (Learn more about JavaScript and SEO.)
  2. There should be an obvious link to show this content (like a read more link, tab headers, arrows on the accordion, etc.) so that Google knows that human visitors will be able to see this content as well.

Images

Images can be an important part of a webpage’s main content. As a result, main content images need to be present on both the mobile and desktop versions of the website.

Typically, though, images need to be sized differently on mobile devices. That is acceptable so long as the image conveys the same information and is displayed at an appropriate quality for the given device. The image shouldn’t get blurry on larger screens and the image shouldn’t be too large where it doesn’t fit well on a mobile screen.

For responsive images, Google’s recommendation is to use the <picture> element or to include a srcset attribute in the <img> tag along with a fallback image in the src attribute. This allows you to consistently show the same image and use the same img tag across all devices. This also means you only need to establish a single alt text that can apply to each image listed in src and srcset.

Here is an example of a responsive <img> tag that would show the image equivalently across devices.

<img srcset="example-320w.jpg 320w,
       example-480w.jpg 480w,
       example-800w.jpg 800w"
   sizes="(max-width: 320px) 280px,
      (max-width: 480px) 440px,
      800px"
   src="example-800w.jpg" alt="this is a responsive image">

To break this down:

  • This srcset attribute in this code presents two pieces of information: the image’s file name and the size of the image. For example, there is an image with the file name example-320w.jpg and it has a width of 320 pixels (320w). This code presents three images at three different sizes: 320 pixels wide, 480 pixels wide, and 800 pixels wide.
  • The sizes attribute tells the browser where to use each of these thee images. The first line says (max-width: 320px) 280px. This tells the browser that if the viewport is up to 320 pixels wide, the image displayed will have a width of 280 pixels.

When a browser loads this HTML, it looks at the srcset and sizes attributes to determine the most appropriate image to download based on the device’s screen resolution and viewport size. If the sizes specified do not match, or if the browser does not support srcset, it will use the image specified in the src attribute. (Google will typically use the image provided in the src attribute for indexing.)

Equivalency Beyond Main Content

Along with ensuring the main content is equivalent between the mobile and desktop versions of your website, you also want to make sure that any signals being sent to Google are also equivalent. This includes:

  • Status code
  • Title tag
  • Meta description tags
  • Meta robots tags
  • Canonical tags
  • Hreflang tags
  • Schema / structured data
  • Images (captions and alt text)
  • Videos

Test Equivalency on Your Website

The best way to test the equivalency of your website’s content between devices is to load your website on multiple devices. While you can load your website on a regular smartphone, testing equivalency is often made easier by emulating a mobile device on a desktop browser. That way you can view the mobile version of the website’s code more easily to check that title tags, canonical tags, meta tags, schema, and more are the same across devices.

You can emulate a mobile device using Google Chrome’s DevTools. Under the more tools dropdown, select Network Conditions.

Under Network Conditions, you can choose a different user agent to load the website. There are default choices to load the website as Googlebot Desktop or Googlebot Smartphone.

Google Chrome Developer Tools - Network Conditions

Load the website with these two user agents and review the website that is returned. Once loaded, review the content to ensure the websites that the main content returned for these user agents are equivalent. As well, inspect the code to make sure that all tags present on one device are present on the other.

Types of Mobile Support

Responsive Websites

The most common way of creating a mobile website is with a responsive design. With a responsive design, your website’s design code (CSS and JavaScript) determines how to transform the page’s layout to fit on larger or smaller screens. With a responsive design, you only have one set of HTML code, but the CSS and JavaScript code adapts the HTML code to different size screens.

The advantage of a responsive design is that you can keep your mobile and desktop websites equivalent more easily. It is the same content and HTML, just sized differently.

The hardest part of responsive design is determining how your design should scale from large to small screens. As an example, a desktop design might include a left sidebar and then a larger right column containing the main content. Instead of being hidden from view, the mobile version swaps the columns for a single column with the left sidebar stacked on top of the main content. This becomes frustrating for visitors as the content they came looking for on the page—in this case, the main content—is beneath the sidebar content on mobile devices and it requires excessive scrolling to reach.

To avoid these problems, be sure to review each page of the mobile version of your website’s design and check that key content is nearest the top of the page and generally easy to access. If the responsive design accidentally placed something on top of that key content, work with your designer and developer to fix it.

You can determine what mobile sizes your responsive website should support by reviewing GA4’s screen resolution reports and tracking browser sizes in GA4.

Mobile-Dedicated Websites

While less commonly used, another option is to create a mobile-dedicated website. This creates multiple sets of code: one for the mobile version of the website and another for the desktop version of the website.

There are two types of mobile-dedicated websites:

  • Dynamic Serving. With dynamic serving, the same URLs are used for mobile and desktop websites, but the HTML is different across devices. When a visitor requests a page, the web server detects what device a visitor is using and returns the appropriate HTML.
  • Separate Domain. With a separate domain, both the URLs and HTML code are different between mobile and desktop devices. When a visitor requests a page, the web server detects what device is being used and routes the visitor to the appropriate URL. Note that you’ll sometimes see this type of dedicated site referred to as an “m-dot website” as many companies place this at an “m” subdomain (as in, m.elementive.com).

Equivalency Concerns

Unlike responsive websites, which have a single set of HTML code, mobile-dedicated websites have different sets of HTML code. When people or robots request a mobile-dedicated website, they are shown the specific mobile version of the website. When people or robots request a desktop-dedicated website, they are shown the desktop version of the website.

Given that these are different websites, with different sets of code, mobile-dedicated websites can present more issues with equivalency. Depending on the exact configuration, the code, content, images, and design can be somewhat different or completely different from that shown on the desktop website. In extreme cases, some pages might not even be available on the mobile website even though those pages are available on the desktop website.

If you are using a mobile-dedicated website, make sure that the main content delivered to each version of the website is equivalent following the guidelines discussed above. That includes making sure that additional tags provided for robots are equivalent as well. The easiest answer is for both versions of the website to rely on the same content management system but use different templates in how that main content is presented.

URL Differences

For mobile-dedicated websites using separate URLs, there is also a  duplicate content concern. Let’s say, as an example, that your desktop website’s about page is domain.com/about and the mobile website’s about page is m.domain.com/about. If the content is equivalent between the two pages (as it should be!), it will seem like you have created two duplicate pages.

To avoid the risks of duplicate content, you want to use an “alternate” element. In the example above, that alternate element would look like this on the desktop website:

<link rel="alternate" href="http://m.domain.com/about">

On the mobile page, you would place a canonical element referencing the desktop version of the page. This tells robots, like Google’s search robot, that the desktop version is the official version of the page.

<link rel="canonical" href="http://www.domain.com/about">

Need Help?

If you need help with mobile-first indexing, and making sure your website is equivalent between devices, contact me today. You can also learn more about mobile SEO considerations in my book, Tech SEO Guide.

Resources

You may also like

How to Check HTTP Response Status Codes

Every page on every website returns an HTTP response status code. How do you check the status code for your website’s pages? What tools can you use to test status codes? What do the status codes mean?

Noindex vs. Nofollow vs. Disallow

Are you confused about the difference between noindex, nofollow and disallow commands? All three are powerful tools to use to improve a website’s organic search performance, but each has unique situations where they are appropriate to apply.

How to Use a Headless Browser

Learn what a headless browser is, why you should use a headless browser and how to launch a headless browser on your own computer.