Decoration Circle
Advanced SEO Textbook
5

Mobile SEO

The world of Search has shifted to mobile. In this chapter, we leave no stone un-turned as we show you the best practices of how to optimise the mobile version of your website.

Topic Details
Clock icon Time: 70
Difficulty Hard

Simply put, mobile has changed the world. Pretty much everything you could do on a computer, you can now do in that small device in your pocket. According to Google, “the number of smartphones has surpassed the number of personal computers” in many countries. For that reason alone, having a mobile-friendly website is one of the cornerstones of your online search presence.

As is the case for most websites, the number of organic searches (and visits) from mobile devices has now surpassed desktop, so if your website isn’t mobile-friendly, you really should
head over to Google’s Mobile Friendly Test now to check if your website is considered as being mobile-friendly.

If it is, great. If not, we’ve got you covered.

In this chapter, we’ll cover the basics of mobile SEO, highlighting its importance and impact on SEO, before diving into some advanced technical SEO concepts and strategies to help get your website in shape for Google Mobile Search. We’ll look at the various mobile configurations you can choose as well as how you can optimise the performance of your mobile website using AMP and PWA to optimise your website’s performance before diving into mobile-first indexing.

The Fundamentals of Mobile SEO

What is Mobile SEO?

Mobile SEO is the practice of providing users on smartphones and tablets with the best possible experience on the mobile version of your website. At its core, mobile optimisation is all about performance – for users, it’s about ensuring that your site’s resources load quickly – and for search engines, it’s about making these resources easily accessible to search engine crawlers.

Why is Mobile SEO Important?

The convenience and portability of smartphones has meant that finding information on the web has never been quicker – regardless of whether you’re at home or out and about, you’re more likely to pull out your mobile phone to perform a search query.

In fact, according to a study by Google in 2013, “77% of mobile searches occur at home or at work”. This is interesting, considering most homes will have a personal computer present.

With search behaviour shifting away from desktop, it’s more important than ever before that you’re providing users with the best possible experience when they access your website using a mobile device.

A website that isn’t optimised for mobile users can be extremely frustrating from a UX and performance perspective. More often than not, a site that isn’t mobile-friendly requires the user to pinch or zoom to read content or may take too long to load – this can result in users abandoning the site completely and having a negative impression of your business.

Therefore, regardless of whether you’re a content publisher, a local business, or an eCommerce website – mobile optimisation is critical for business.

If you still need some convincing, here’s a short (but hopefully impactful) list of statistics that highlight the importance of mobile optimisation.

1. 60% of Google searches are done via mobile devices. (Source)

2. 51% of smartphone users have discovered a new company or product when searching on their smartphone device. (Source)

3. 87% of mobile users use search engines at least once a day. (Source)

4. 40% of mobile website visitors will leave your site if it takes more than 3 seconds to load. (Source)

To top things off, as of 2015, Google has switched to a mobile-first index. We’ll explore this in much more detail later on, but essentially, it means that Google’s crawlers are now indexing the mobile versions of websites as opposed to desktop.

How Does Google Define “Mobile”?

This may sound like a silly question, but it’s worth understanding the distinction between the various types of devices.

  • Mobile – Whenever Google refers to “mobile” or mobile devices, it’s referring to smartphones i.e. devices that run on operating systems like Android or iPhone.
  • Tablets – Google places tablets “in their own class”. In other words, according to Google, tablets are not considered a “mobile device”. This is because tablets “tend to have larger screens, which means 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”.

Google also lists two other devices (Multimedia phones and feature phones), however the main point to take note of is:

Mobile = Smartphones

Mobile != Tablets

Choosing A Mobile Configuration

Imagine having to navigate the same website on your computer and smartphone without any adjustments. On the latter, you would have to move the site in every direction and resize it constantly to read the content. This is definitely not a pleasant user experience.

When it comes to building your mobile website, there are three main techniques that allow you to handle the various screen types and sizes for mobile devices and provide a different experience for mobile searchers.

They are: Separate URLs, Dynamic Serving and Responsive Web Design.

Separate URLs

Although Google still supports this method, it’s not one that is recommended. For that reason, we won’t go into a lot of detail, but for the context of this chapter, it’s worth knowing.

With this method, which is also referred to as the “m” configuration, both the desktop and mobile versions of the website have different URLs.

For example, you may have the following configuration:

Desktop – example.com

Mobile – m.example.com

As long as the pages are accessible to Googlebot, Google doesn’t mind which URL format you use.

When separate URLs are used, the website tries to detect the user’s device and then redirects them to the most optimised version of the page for that particular device.

Google still supports this method, as long as you clearly define the relationship between the desktop and mobile versions of the website.

In order to help Google’s algorithm understand this distinction, you should use the following bi-directional annotations:

  • On the desktop URL, add a rel=”alternate” tag pointing to the corresponding mobile page. This helps Googlebot discover the location of your site’s mobile pages.
  • On the mobile page, add a rel=”canonical” tag pointing to the corresponding desktop URL.

You can find more information on how to do this here.

However, one of the main reasons why separate URLs aren’t advisable is because “it’s difficult to implement and maintain”.

You will need multiple URLs for every page on your website, not to mention, each desktop page must have the rel=”alternate” tag and each mobile page must have the rel=”canonical” tag to be implemented.

Not only does this take a lot of time (especially if you have a large website), it also makes it easier for mistakes to occur – i.e. you may forget to add one of the annotations etc.

Dynamic Serving

With Dynamic Serving, the URLs remain the same regardless of what device is being used, but the content that is served is different. In this case, the server generates and sends a different version of HTML and CSS depending on whether the user is accessing the site on mobile, tablet or desktop.

When adopting this method, Google recommends that the web server is configured to send a hint requesting Googlebot to crawl the smartphone version of the page. This is because the altered HTML is not immediately apparent and the mobile content would be “hidden” when crawled by Googlebot’s desktop user agent.

In order to allow Google to crawl your website, add the Vary HTTP header to your website. This is what it would look like:

HTTP/1.1 200 OK
Content-Type: text/html
Vary: User-Agent
Content-Length: 5710
(... rest of HTTP response headers...)

Implementing the above code “helps Googlebot discover your mobile-optimized content faster”.

Essentially, the Vary header tells the web browser that the contents will “vary” depending on the user agent that requests the web page – in other words, the content is dynamic.

Although dynamic serving is a step up from separate URLs, it still has some drawbacks.

The main reason why dynamically serving your web pages is not advised, is because of user-agent “sniffing”, which is generally an erroneous technique.

User-agent sniffing is the process of detecting which device is being used to make the request. In order for this to work properly, the server needs to have a list of user-agent strings (which can be difficult to maintain and update) that it can match against.

Likewise, dynamic serving can also lead to a mismatch of user-agents i.e. showing mobile users the desktop version of the website.

Responsive Web Design

The third and final method is Responsive Web Design (or RWD) – this is the method recommended by Google, so we’ll take a much more detailed look at how you should implement it for your website.

What is RWD?

With a responsive setup, the website automatically adapts to the size of the screen of the device being used. The server maintains the same HTML code to all devices whilst CSS is used to alter the rendering of the web page depending on the device.

The Benefits of RWD

Here are the many benefits of using RWD:

A Single URL

RWD eliminates the need for creating different versions of the same site only to adjust them to different devices. Likewise, having a single URL makes it much easier for users to share and link to, and also eliminates any duplicate content issues.

Improved User Experience

The content served on the device is clear and easy to read, providing a much better user experience than using separate URLs or dynamic serving.

Reduces Bounce Rate

Better usability helps users navigate a site without difficulties. As a result, users are likely to spend more time on your website (a lower bounce rate), which sends a clear signal to Google that the site makes users happy by giving them a good experience.

Improved Conversions

It is also worth mentioning that the more time users spend on the website, the higher probability that they will convert i.e. subscribe to your newsletter or place an order.

Low Maintenance

Considering that RWD doesn’t require different versions of HTML or the need for multiple URLs, maintenance is no longer an issue.

Easy to Detect

As long as Googlebot user agents aren’t blocked and are allowed to crawl the web page (along with the CSS, JavaScript and images), then its algorithms should automatically be able to detect the configuration.

Improved Page Load Speed

As we’ve seen previously in this module, page load time is one of the ranking factors that Google uses to determine rank. Nobody likes waiting ages for a site to load, when there are tens of other high quality places providing relevant content and delivering answers on the web quickly. With RWD, there is no need for any redirection to enable users to view content that is optimised for their device, this drastically reduces the load time.

Saves Crawl Budget and Improves Crawl Efficiency

Responsive web pages only need to be crawled once by a single Googlebot user agent, rather than having to crawl multiple versions of the same web page with different user agents. This improves the efficiency of how Google crawls your website and can also indirectly help Google index more of your site’s content.

Google Recommends It

Responsive web design is recommended by Google “because it’s the easiest design pattern to implement and maintain”.

How Responsive Web Design Works

Responsive web pages are made of elements that adjust (in size, shape, and place) themselves according to the width of the screen. The screen size is determined by the elements using CSS media queries.

Here are some example:

On a smaller screen, the elements are displayed in a 3 x 3 grid:

If the screen is wider, the elements spread out:

And stack for screens that are narrow:

It is also common practice to remove or reshuffle additional elements as the screen gets smaller. This is because websites displayed on mobiles often may not have room or browser memory in comparison to those on a desktop screen.

How to Implement RWD

The meta name=”viewport” Tag

Adding the meta name=”viewport” tag to the head of your documents tells web browsers that the web page adapts to all devices.

Here’s what the code looks like:

<meta name="viewport" content="width=device-width, initial-scale=1.0">

The tag instructs the web browser on how to adjust the dimensions of the pages based on the width of the device.

Without this tag, mobile browsers will use the default rendering of a desktop screen (this is usually about 980px but varies from device to device). To compensate for this, mobile browsers will increase the font size and scale the content to try and fit the screen or, only displaying the parts of the content that fit within the screen.

This potentially creates inconsistencies within the layout and overall appearance of the web page – which leads to the users having to pinch-to-zoom or double-tap in order to view the desired content.

This example graphic from Google shows how a web page is rendered on a mobile device without (left) and with (right) the tag:

To ensure that your images are also responsive, Google recommends including the <picture> element.

JavaScript Configurations

Using JavaScript to alter the rendering and behaviour of your website on various devices requires careful consideration. Below, we have outlined three Google-approved JavaScript implementations for building your mobile-friendly website.

1. Adaptive JavaScript: this alters the behaviour or rendering of the site when Javascript is executed.

2. Combined Detection: different content is served to different devices by a server-side detection of device capabilities and Javascript on the website.

3. Dynamically-Served JavaScript: whilst the HTML remains the same, different JavaScript code is served dynamically depending on the device’s user-agent.

Optimising For Performance

Mobile SEO is all about optimising for performance. The bottom line is the faster your mobile site loads, the higher chance you’ll have of ranking. This is because a faster loading site improves the user experience.

In this section, we’ll discuss two different methods on how you can create a mobile-friendly website that is optimised for performance.

They are Accelerate Mobile Pages (AMP) and Progressive Web Apps (PWA).

Accelerated Mobile Pages

What is AMP?

Accelerated Mobile Pages or (AMP) are stripped down versions of web pages that are designed to improve load speed on mobile devices. AMP is a free open-source project that is heavily backed by Google and other search engines like Bing and Baidu. The aim of AMP is to drastically improve page load speeds for mobile users by stripping away elements from desktop versions of web pages that may impact load time.

How AMP Works

There are three core elements that make up how the AMP framework works:

AMP HTML: The HTML code for AMP pages is extended with custom AMP properties – web developers can serve AMP pages by adding the rel=amphtml tag to the HTML code.

AMP JavaScript: AMP Javascript enables browsers to fetch the required resources and render the stripped down AMP HTML pages quickly. This also prevents third-party JavaScript from blocking the rendering of the web page.

AMP Cache: This is an optimised content delivery network that is specifically designed to cache pages and immediately adapt them to AMP code. The majority of AMP pages are served via Google’s own AMP Cache which provides a better (and faster) experience for mobile users because all AMP documents (and their resources i.e. HTML, CSS, JS) are stored here.

What Are the Benefits of AMP?

Drastically Improves Load Time

The core benefit of AMP is that it dramatically speeds up the load time for mobile pages. Whilst AMP in itself is not a ranking factor, how fast your web pages load is a ranking signal for Google Search. A study conducted by Google in 2018 suggests that the bounce rate increases by 90% when a page’s load speed increases from 1 second to 5 seconds.

Improved Server Performance

As a result of the stripped down resources, AMP reduces the strain on your servers. This is especially the case if your website receives the majority of its traffic from mobile devices.

AMP Icon Displayed in the SERPs

On mobile search, Google displays the AMP icon which helps users identify pages that support AMP – it tells them that these pages will load quickly and smoothly and is designed to increase CTR. See an example below of the icon displayed in the search results page below.

AMP-only Search Results Features

By implementing AMP, you open up a few opportunities for how your web pages appear in the search results. For example, if you have a recipe blog using AMP, Google may display your web pages on Host carousels that appear at the top of the mobile search results page.

Below is an example provided by Google:

There are several other SERP Features that are specifically applied to AMP pages, you can find them here.

When Should You Adopt AMP?

Despite the fact that AMP is heavily favoured by Google and offers super fast load speeds, adopting this method may not be the best solution for your website, as there are a few drawbacks.

Limited Tracking

Although this is an issue that is improving over time, tracking data for AMP pages on Google Analytics (GA) is fairly limited and presents the need to separately configure AMP pages so that they can be tracked in conjunction with your main domain in GA. Google has provided documentation on how to add AMP analytics and as mentioned, it’s not as big of an issue as it used to be.

Limited Page Functionality

The biggest drawback of AMP is the limitations it puts on how the UX elements of your webpage appear. With AMP, you’re essentially sacrificing performance for aesthetics – this is because a lot of the CSS that appears on your desktop page will have been stripped away. This means that you’re not only missing out on images not being rendered, but AMP only allows one ad placement tag per page and blocks popups. As a result, users visiting the AMP version of a page are likely having a different experience of your website.

There’s no denying the tangible benefits that AMP can present, but whether it should adopt this method really depends on your needs. AMP is certainly useful for content publishers who want to capitalise on the AMP-specific search features, however, the time and resources required to implement AMP may not always be cost-effective.

Likewise, if the reason to adopt AMP is purely to speed up your web pages, it’s worth noting that more often than not, sticking with a responsive design and optimising the speed of your pages across your website via other methods works well enough in most cases.

Google’s SEO Recommendations for AMP

If you’ve decided that AMP is right for you, here are some recommendations on how to go about enhancing your AMP content. To learn more about creating an AMP page, head here.

1. Ensure that users are able to “experience the same content and complete the same actions on AMP pages as on the corresponding canonical pages”.Follow Google’s guidelines on creating AMP pages here.

2. Ensure that your AMP page is validated. Pages that contain invalid AMP will not be considered for the AMP-specific SERP features that we discussed earlier.

3. Add structured data to your AMP pages – remember to use the same markup for the both the AMP and canonical versions of the page.

4. Ensure that your AMP pages follow the AMP HTML specification.

5. The URL scheme that you use should make sense to the user. For example, if your canonical page is example.com/cake-recipe then the AMP version should be hosted on a URL like amp.example.com/cake-recipe

6. Ensure that your AMP pages are not blocked by your robots.txt file.

These are the main recommendations that Google provinces, but you can find a full list of suggestions on how best to enhance your AMP content here.

Progressive Web Apps

Although mobile search has eclipsed desktop search, the sad truth is that not enough websites are optimised for mobile with speed and usability remaining poor. This is why developers at Google created Progressive Web Apps or PWAs.

What Are Progressive Web Apps?

According to the official definition from the Google team, Progressive Web Apps (PWA) are mobile web applications that are “built and enhanced with modern APIs to deliver native-like capabilities, reliability, and installability while reaching anyone, anywhere, on any device with a single codebase.”

Google’s Alex Russell (one of the leading software engineers of the project) described them quite eloquently as blurring the lines “between Web content and apps”.

PWAs look, feel and work the same way as a native mobile app on your smartphone – this means that features like push notifications, offline accessibility (and more) can be enabled.

How Progressive Web Apps Work

Progressive Web Apps are encountered by users within a web browser just like they would with a normal mobile website. The difference with PWAs, is that the user will be prompted to install the web app on the device should they wish to do so. In this case, the application will be installed and downloaded in the same way that a native app from the Apple App store or Google Play Store would be.

Let’s take a closer look at how they work.

There are three main technologies which entail how PWAs work: web app manifest file, service workers and application shell model.

Web App Manifest File

The Web App Manifest is a JSON (JavaScript Object Notation) file that specifies how the web browser should behave when it’s installed by the user on their mobile (or desktop) device.

A typical manifest file should contain:

  • The application name
  • Icons that the app should use
  • The URL that should be opened when the app is launched

Here’s an example of what a manifest file should look like:

{
  "short_name": "Chocolate Cake",
  "name": "Chocolate Cake Recipe",
  "description": "Delicious chocolate cake recipe.",
  "icons": [
    {
      "src": "/images/icons-192.png",
      "type": "image/png",
      "sizes": "192x192"
    },
    {
      "src": "/images/icons-512.png",
      "type": "image/png",
      "sizes": "512x512"
    }
  ],
  "start_url": "/?source=pwa",
  "background_color": "#3367D6",
  "display": "standalone",
  "scope": "/",
  "theme_color": "#3367D6"
}

Once you have created the JSON file, insert the following line of code to the <head> section of your index.html file:

<link rel="manifest" href="/manifest.json">

Google has provided more information about the web app manifest file here.

Service Workers

Service workers are what provide the offline capabilities for progressive web apps. A service worker is a JavaScript file that runs in the background independent to the browser and separate from the web page.

One of the core features of service workers is the ability to enable push notifications and background sync. However, the main function of a service worker is to intercept and handle network requests which includes retrieving and storing resources in the cache when needed.

What this means, is that when users aren’t connected to the Internet, data from previous sessions can be shown by the PWA to the user and once the user is back online, the latest data can be retrieved almost instantaneously.

This allows for a much improved user experience as the number of network requests made by the user (to the server) is considerably reduced.

To find out more about how to implement service workers, head here.

Application Shell Model

The application shell model (also referred to as the app shell architecture), enables PWAs to reliably and instantly load on users’ devices.

The application shell is composed of the minimum HTML, CSS and JavaScript resources required for the PWA to function and is commonly achieved by using a JavaScript framework (which we will discuss later) like React or Angular.

This has the effect of ensuring fast load times as the shell’s files are cached on the user’s first visit to the web page, which allows for instantaneous load times on repeat visits. Whenever the user visits the web page again, only the necessary content that is needed from the network is loaded, everything else is taken from the cache.

Google recommends that the app shell model should:

  • Load fast
  • Use as little data as possible
  • Use static assets from a local cache
  • Separate content from navigation
  • Retrieve and display page-specific content (HTML, JSON, etc.)
  • Optionally, cache dynamic content

This way, you’re improving the user’s experience (by ensuring fast load speeds) whilst saving resources (by reducing the number of requests made to the server and caching the basic elements of your web page).

Find out more about this technology here.

What Are the Benefits of Progressive Web Apps?

We’ve already discussed some of the main advantages of PWAs in previous sections, so here’s a condensed list on why PWAs are beneficial for mobile SEO:

  • Improved Load Speed – the ability to cache the skeleton code of a web page means pages load faster on repeat visits.
  • Push Notifications – service workers allow the user to receive push notifications, a great feature that makes native web applications user-friendly.
  • Offline Functionality – service workers enable users to access PWAs even when they aren’t connected to the Internet. PWAs can also run in the background by caching data about the user’s behaviour so that it’s presented to the user immediately when they’re back online.
  • Increased Functionality – PWAs also allow you to utilise hardware features like geolocation, the camera(s) and microphone as well as adapt to screen orientation. This provides a better user experience and allows for features that perhaps may not be easy to implement on a normal mobile website.
  • Efficiency – by caching the important resources, fewer requests are made by the browser to the server. This is especially useful when connections to the Internet are poor.

When Should You Adopt PWA?

One of the main drawbacks of PWAs is that they are considerably more expensive to build than AMPs which are easier, faster and cheaper to develop. Likewise, when it comes to discoverability by crawlers and page load speed, AMPs lead the way.

Progressive web apps pose several challenges when it comes to Google crawling and indexing web pages, so it’s incredibly important that you optimise the website correctly to ensure your pages are indexed. In fact, Google published an entire article on how to build indexable progressive web apps.

Likewise, although offline functionality is great for user experience, how are webmasters supposed to track “offline” visits on analytics? Built Visible have a great article that explores PWA tracking on GA.

Ultimately, to answer the question on whether or not you should adopt PWA? The answer is in the P – Progressive.

PWAs are the future of mobile. Even though Google continues to back AMP, progressive web apps offer benefits that apply to pretty much every single website.

Google’s SEO Checklist for Progressive Web Apps

Here are some recommendations from Google’s checklist on “what makes an app installable and usable by all users, regardless of size or input type”.

1. Ensure that your pages are responsive to any screen size (from tablets to smartphones).

2. Ensure that your pages pass Google’s mobile friendly test.

3. Ensure that your site loads quickly to avoid poor experience and user drop off.

4. Ensure that your PWA is accessible from all web browsers.

5. Provide a customised offline page to create a more seamless experience for the user.

6. Ensure that each URL has a unique, descriptive page title and meta description.

7. To avoid duplicate content issues, use rel=canonical when serving content from multiple URLs.

8. Ensure that URLs are clean i.e. they should contain fragment identifiers such as the hash symbol (#).

9. If you are also supporting AMP ensure that you use its counterpart rel=”amphtml” instruction as well.

10. Ensure any required web pages aren’t blocked by robots.txt.

11. Ensure your URLs are independently accessible.

12. Use Google Search Console “Fetch as Google tool” to verify your content is successfully rendered by Google’s crawlers.

13. Include structured data from Schema.org in your PWA to increase crawlability.

For further information on the best practices for PWAs head here, and to ensure that your pages are indexable by Google, head over here.

Mobile-First Indexing

After a year and a half of experimentation and careful testing, Google announced its decision to start moving away from its desktop-based index and to a mobile-first index in March 2018.

In this section, you will learn what mobile-first indexing is and what it entails for your website. We will finish by highlighting some of the best practices to ensure that your website is well optimised for MFI.

What Is Mobile-First Indexing?

Mobile-first Indexing refers to Google using the mobile version of a website’s content as the primary version for indexing and ranking as opposed to the desktop version. Google predominantly used the desktop version of web pages when evaluating its ability to rank for a query, however, since the majority of searches are now made with a mobile device, Googlebot predominantly crawls and indexes content with its smartphone user agent. This specialised version of Googlebot is able to render web page content as if it were being viewed from a smartphone or other mobile device.

How Mobile-First Indexing Impacts SEO

There are several ways that mobile-first indexing impacts SEO, but a common misconception about MFI is that it will improve your search presence. According to Google, “being indexed this way has no ranking advantage and that it “operates independently from our mobile-friendly assessment”. This means that desktop versions of a web page can still outrank a mobile page in the search results.

Although the shift to a mobile-first index doesn’t affect the rankings directly, it does impact how you approach optimising your website so that it is mobile-friendly.

From an SEO perspective, the key factors to consider when developing a mobile friendly website is if the mobile version of your web pages are quick enough and whether the mobile version offers the same features and fulfills the same user intention as the desktop version.

These are all topics that we have covered in the rest of the mobile SEO chapter.

FAQs About Mobile-First Indexing

There are many misconceptions about what mobile-first indexing entails. Below we have answered some of the most pressing questions when it comes to MFI.

Why Move to A Mobile-First Index?

Since 2016, searches made on mobile devices (remember, this includes tablets too) have eclipsed desktop. Consequently since Google wants to maintain its position as the best search engine, it had to adapt its crawler to meet the new shift in user behaviour.

Why Is There A Need to Adapt the Crawler?

Having decided to move to a mobile-first index, Google also had to adapt the way web content is crawled and rendered. This is because most modern websites are built with design solutions which adapt based on the device that the user is viewing the content on. Website owners also want to provide the best experience to their audience and as we’ve seen in our Choosing a Mobile Configuration and Optimising for Performance section, this cannot be achieved via a desktop view of a site on a smartphone device.

With that in mind, mobile versions of sites often encounter their own issues like buttons / links being too close together resulting in the inevitable “fat finger slip”. In addition to this resources like images or videos may appear fine on the desktop version of the site however on the mobile version they might look misplaced or even be broken.

Seeing and understanding these errors is important for Google to make an accurate assessment of the site and determine if it truly is the best result for a user search, particularly on mobile devices.

What if I Don’t Have A Mobile Website?

Although Google is pushing for webmasters to optimise for mobile, if your website does not adapt at all to mobile devices or you do not have a mobile version of a particular web page then Google will consider the desktop version as the primary version “even if we’re using a mobile user agent to view your site”.

In addition Google will begin to rank websites from the signals it gets from the mobile version of the site, not the desktop version. This means that desktop performance in the SERPs could also suffer if the site is not mobile friendly.

In short, you should really work on building a mobile version of your site if you don’t already have one.

How Does Mobile-First Indexing Differ From Desktop?

One misconception is that Google’s mobile-first index is separate from its desktop index. This is not the case. Google’s Danny Sullivan confirmed that Google only has a single index and that all rankings (for both mobile and desktop search) will “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”.

The difference between mobile and desktop indexing is purely the fact that Google is now placing more emphasis on assessing a website’s ability to rank for a keyword based on the mobile version.

So for example, if the desktop version of a web page has a section of content that is not present on the mobile version of the same page, Google will still proceed to index the mobile version – hence the phrase “mobile-first indexing”. As a result, you should ensure that both the desktop and mobile versions of your web pages include the same content.

Has My Website Been Migrated to Mobile-First Indexing?

As of July 1st 2019, Google has enabled mobile-first indexing for all new websites, with no option to opt-in or opt-out.

In March 2020, Google outlined its plans to transition all websites to its mobile-first index in September 2020.

You will receive a notification from Google (like the below) when your website has been migrated to mobile-first indexing via Google Search Console.

When your website has been switched over, you will see a significant increase in crawl rate from Googlebot’s smartphone agent.

Apart from this message, you can quickly check to see if your web pages have been shifted to mobile-first indexing via Google Search Console.

Navigate to the “Coverage” report in the left-side navigation of GSC. If the “Primary Crawler” is set to “Smartphone”, then the mobile version of your web pages have been indexed.

What If My Mobile and Desktop Pages Have Different Content?

If the mobile version of your web pages do not contain content that would normally be shown to users on desktop, then this is an issue because it means that the content simply won’t be indexed by Google. If Google is unable to crawl and index this content, then there is no chance of it ranking.

Google wants the mobile version of your web pages to be representative of your desktop pages so that both mobile and desktop users are served the same (or very similar) content. As a result you should not remove key page assets like videos or other visual elements from the mobile version.

A solution to this is to hide content and other assets in expandable menus or sections to ensure that your web pages are mobile friendly. In fact, Google’s Gary Illyes said that this practice is given more weight as it improves the experience for mobile users.

Will My Website Be Crawled More Often?

As mentioned before, during the early stages of when your website has been switched to MFI, your website will be crawled more frequently by Google’s smartphone agent to ensure that all of the pages on your website are reindexed. However this is only temporary. After this transition stage, Google have confirmed that your crawl rate will remain mostly the same.

Best Practices for Mobile-First Indexing

Below we have listed the best practices as outlined by Google to ensure that both mobile and desktop users have the best experience.

1. Ensure that Googlebot can access and render your content – This can be achieved by Google’s Mobile Friendliness test linked above

2. Ensure that the content on the mobile and desktop versions of your website is the same.

3. If you have implemented structured data on the desktop version, ensure that it is also available on the mobile version.

4. Place the same metadata (such as page titles, headings and meta descriptions) for both versions of a page.

5. Check that the visual components such as images and videos on the mobile versions of your web pages follow best practices.

Mobile SEO Best Practices and Common Mistakes

Outside of the techniques that we discussed previously (AMP, PWA, RWD, MFI etc), there are several important things to consider when optimising your website for mobile devices.

Blocked Resources

Ensure that important resources such as JavaScript, CSS, and Image files can be accessed by Google. Otherwise, Googlebot will be unable to render and index your web pages properly.

1. The URL Inspection tool on Google Search Console shows you how Google views your web pages, so if it is unable to access your JS, CSS and image files, it won’t be able to determine whether or not your website is mobile-friendly.

2. Check that these resources aren’t blocked on your robots.txt file.

3. Test your web pages to see if they are mobile-friendly.

Redirects

Regardless of whether or not you have separate URLs for mobile and desktop (remember, this is not recommended), ensure that mobile users that arrive on a desktop URL, are redirected to the most appropriate mobile URL instead of just the homepage, which would be incorrect and provides a poor experience.

Minimising the number of redirects is advised as although a 301 redirect is better for user experience than returning a 404 error, having lots of redirects increases the page load speed, which as we already know, hinders user experience and your chances of ranking.

Mobile-Only 404s

A common mistake webmasters tend to make is returning a 404 error page when mobile users try to access a URL that is fine on desktop. In order to provide users with the best experience, Google recommends that you redirect mobile users to the most relevant page instead of serving a 404 error.

Avoid Interstitials or Pop Ups

Google penalises websites that use large pop-ups or interstitials that partially or completely cover the contents of the page as they drastically disrupt the user’s experience. Interstitials are usually used to promote newsletters, sign-up forms or ads. Instead, use a simple (smaller) banner which doesn’t impede on the experience.

Cross Linking

Ensure that desktop URLs don’t link to irrelevant mobile versions of your web pages and vice versa. This coincides with the solution to redirects i.e. instead of redirecting to the most relevant page, ensure that all pages link to the most relevant page.

Viewport Settings

Pages should specify the viewport using the viewport tag. This is because visitors will access your website from a host of different devices, each with different screen sizes. The viewport ensures that the browser adjusts the page’s dimension and scaling based on the device being used. Here is a helpful guide from Google on how to set your viewport correctly.

Slow Mobile Pages

Although techniques like AMP and PWAs are designed to increase page speed for mobile, there are several other ways to fix slow mobile pages.

1. Optimise images – instead of loading high resolution images, scale your images to the correct size so that they are smaller using tools like ImageOptim.

2. Minify Resources – reducing the number of requests the browser makes to the server impacts page speed. Minifying your JavaScript and CSS files is one solution for this. Minifying essentially means that you’re concatenating these resources together so that they have a smaller weight when a request is made by the browser.

Legibility

A simple UX factor is legibility. Ensure that the content on your mobile website is easy to read for users so that they aren’t forced to pinch-to-zoom. When setting your viewport, you should also configure the font sizes so that they scale accordingly within the viewport.