Mobile-First Indexing Checklist: Make the Mobile Version Complete

With mobile-first indexing, Google uses the mobile version of your content for indexing and ranking, and it crawls with its smartphone crawler. If your mobile pages are a cut-down version of the desktop site, the cut-down version is what Google sees. Missing text, missing links, missing structured data or a stray noindex on mobile can all follow you into the index.

This guide gives you a practical mobile-first indexing checklist. You will compare your mobile and desktop pages, find content that exists on one but not the other, check the robots rules and metadata that must match, and test with Search Console. It is for site owners, developers and SEO leads, and especially for anyone who runs a separate mobile site, uses a theme that hides desktop content on small screens, or loads content only after a click.

At the end you will know which configuration you have, what must be equal across versions, and how to prove it.

Before you begin

You need access to the site's templates or CMS, a phone or the device toolbar in Chrome DevTools, and Search Console access for the property. If you run separate mobile URLs, verify both versions in Search Console, as Google recommends, because data can shift when your site is switched to mobile-first indexing.

Make a list of five to ten representative pages: home page, category page, a detail page, an article, a page with video and a page with structured data. Save a copy of the templates before you change them.

The aim here is parity and access, not a promise. Google's documentation says it is very strongly recommended to have a mobile version, but a mobile version is not required for inclusion in search. A complete mobile page does not promise ranking or indexing; it removes one reason for a problem.

Which setup do you have?

Google's documentation lists three mobile-friendly configurations.

Responsive design. The same HTML on the same URL for every device, with the display changing by screen size. Google says it recommends responsive design as the easiest pattern to implement and maintain.
Dynamic serving. The same URL for every device, but the server sends different HTML depending on the user agent, along with a Vary: user-agent header.
Separate URLs. Different HTML on different URLs, often an m. subdomain, with redirects based on the user agent.

Most of the parity warnings in the documentation apply to dynamic serving and separate URLs. With a responsive site, the content and metadata are the same in the HTML for all devices, so your main risk is content that is hidden, deferred or blocked on small screens. Work out which pattern you use first; it decides how much of the checklist you need.

Step-by-step instructions

Step 1: Compare the primary content

Open each sample page on desktop and on mobile. Compare the main text, headings, tables, product details, prices, downloads and any other information people come for. Google's guidance says the mobile site should have the same primary content as the desktop site, and that you can expect to lose traffic if it does not. If space is the problem, it suggests using accordions or tabs, not removing the content.

Pay attention to headings: use the same clear headings on both versions.

For a responsive site, compare what is in the HTML source, not only what is visible. Content collapsed into an accordion is normally fine because it is still in the page. Content that is removed from the HTML or loaded only after an action is a different case.

What success looks like: For each sample page you can state that all primary text, headings and data appear on mobile.

Step 2: Check that nothing waits for a tap or scroll

Google's guidance says not to lazy-load primary content behind user actions, because Google will not load content that requires swiping, clicking or typing. Test each page by loading it at phone width and not touching it. Is the main content present? Are there "load more" buttons or tabs that fetch their content only when clicked?

If so, change the implementation so that content loads when it is in the viewport, or put it in the HTML and hide it visually. Our guides on lazy loading images and infinite scroll explain safe approaches.

What success looks like: With no interaction, the primary content of each template is in the mobile page.

Step 3: Match robots rules and keep resources crawlable

Use the same robots meta tags on mobile and desktop, especially noindex and nofollow. A noindex that appears only on the mobile version is on Google's list of problems that can block mobile-first indexing. Also check the response headers, since a header can set the same directive.

Check robots.txt as well. Google says not to block mobile resources, because some resources use different URLs on mobile, and for most sites to use the same rules for both versions. Open your robots.txt and look for rules on paths used by the mobile version, such as a mobile subdomain or a /m/ folder. See robots.txt blocking search engines for diagnosis.

What success looks like: The robots meta tags, headers and robots.txt rules treat mobile and desktop pages the same way.

Step 4: Match metadata, structured data and links

Check these items on both versions.

Titles and meta descriptions should be equivalent. Missing titles or descriptions on mobile are listed among the common errors.
Structured data should be the same on both. Google says that if you must prioritise, start with Breadcrumb, Product and VideoObject. If you use separate URLs, structured data URLs on the mobile page must point to mobile URLs.
Internal links should be present on mobile. A mobile menu that drops sections or footer links can remove paths a crawler would follow. Compare the link lists, not just the look.
hreflang. On separate URLs, mobile pages should point to mobile alternates and desktop pages to desktop alternates.

A fast way to compare is to save the HTML of each version and look at the title, canonical, robots tag, JSON-LD and navigation. Test with the live test in Search Console's URL Inspection tool to see what Google gets; see Step 6.

What success looks like: Titles, descriptions, structured data and key links are present and equivalent on mobile.

Step 5: Check images, video and ads

Google asks for high-quality images in supported formats, URLs that do not change on every page load, and the same alt text, titles, captions and file names on mobile. It also warns that using different image URLs on mobile may cause a temporary loss in image traffic while the new URLs build history, so keep the same URLs where you can. For video, avoid URLs that change on each load, use supported tags such as <video>, <embed> or <object>, place the video where mobile users can find it without lots of scrolling, and keep the same video structured data on both versions.

For ads, follow the Better Ads Standard that Google refers to: an ad that takes up too much of the top of a mobile page makes a poor experience. Ads that push main content off the first screen are a risk, but this is a user experience point, not a ranking promise.

If your images are heavy for phones, see responsive images for serving a size that fits.

What success looks like: The same images and video appear on both versions with the same descriptive text, and nothing important is pushed below a wall of ads.

Step 6: Test with Search Console and a phone

Open the URL Inspection tool in Search Console for a sample page. For an indexed page, the Page availability section shows a "Crawled as" value, which tells you whether a desktop or mobile crawler was used. A live test gives you a rendered screenshot, the HTML, headers, console messages and the resources loaded; Google's help page says the screenshot is available only in a live test. Compare the screenshot with what you see on your phone. If rendering looks different, the help page suggests blocked resources as a possible cause, and the "More info" list under the tested page shows the resource list. Use the live test guide to read it.

Then load the page on a real phone or with DevTools' device toolbar, once with a fast and once with a slow connection. Look for content that appears late, menus with missing links and tap targets that do not work.

What success looks like: The rendered HTML and screenshot show the content you expect, and the crawl type for the page is the mobile crawler.

Step 7: Extra checks for separate mobile URLs

If you run m.example.com, there is more to verify, all from Google's documentation.

Error status codes should match. If the mobile URL returns an error and desktop does not, the page can be missing from the index.
Do not use URL fragments on mobile URLs.
Do not redirect several desktop pages to one mobile page or to the mobile home page. Each desktop page should redirect to its mobile equivalent.
The desktop URL is canonical. The mobile page uses rel="canonical" to point at the desktop URL, and the desktop page points to itself and to the mobile URL with rel="alternate" and a media query:

<!-- On https://www.example.com/page -->
<link rel="canonical" href="https://www.example.com/page">
<link rel="alternate" media="only screen and (max-width: 640px)"
      href="https://m.example.com/page">

<!-- On https://m.example.com/page -->
<link rel="canonical" href="https://www.example.com/page">

Make sure the mobile server can cope with a possible increase in crawling. Check your hosting capacity and see HTTP 500 errors if it struggles.

What success looks like: Every desktop page has a matching mobile URL with matching status, and the annotations point both ways.

Final verification checklist

Common mistakes to avoid

Hiding content on mobile. Cutting text to save space removes it from Google's view of the page. Use accordions or tabs.
A noindex or nofollow only on the mobile version. It can keep pages out of the index. Compare robots tags on both.
Dropping structured data from the mobile template. Rich results depend on the markup Google sees. Keep it equal.
Blocking the mobile subdomain or folder in robots.txt. Crawlers need the mobile resources.
Lazy-loading main content behind a click. Google does not click. Load it with the page or on viewport entry.
Redirecting many desktop URLs to the mobile home page. Pages can drop from the index. Redirect each page to its matching mobile page.
Changing image URLs for mobile. Image traffic can dip while new URLs build history. Keep URLs stable.
Forgetting to verify both properties. With separate URLs, Google recommends verifying both versions in Search Console.

Frequently asked questions

Does mobile-first indexing mean desktop pages are ignored?

It means Google primarily uses the mobile version of the content for indexing and ranking. It does not remove desktop pages from your site, but what is only on desktop may not count.

Do I need a mobile version at all?

Google says it is very strongly recommended, but not required for a page to appear in search. A site without mobile pages can still be indexed, though its experience on phones may be poor.

Is responsive design the only acceptable setup?

No. Google lists dynamic serving and separate URLs as supported configurations, but recommends responsive design because it is the easiest to build and maintain.

What if my mobile site has less content because the layout is smaller?

Move the content into accordions, tabs or a collapsible section rather than deleting it. Keep it in the page so that the crawler sees it.

How do I know if my site is already on mobile-first indexing?

Search Console shows the crawler type used for a page in the URL Inspection tool under "Crawled as". Check a few key pages rather than relying on a single result.

Official references

Next step: See how Crawvix checks a website and capture a baseline once scanning opens. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.