Mobile SEO checklist: 24 checks for a mobile-first Google

A mobile SEO checklist makes sure the version of your site a phone sees is complete, crawlable, usable and fast, because that is the version Google indexes and ranks. Since July 2024 Google crawls practically every site with its smartphone crawler, so a page that is broken, thinner or slower on mobile is broken, thinner or slower in search. Below are 24 checks in six groups, each with how to test it for free, followed by a routine for a mobile SEO audit. It is part of our guide to technical SEO.

Quick answer

• Access: Googlebot Smartphone must be able to fetch the page and its CSS, JavaScript and images, with no noindex on the mobile version.
• Parity: the mobile page carries the same main content, headings, links, structured data, title and description as desktop.
• Layout: a correct viewport tag, no sideways scrolling, body text of about 16 px, and zoom left enabled.
• Taps and pop-ups: tap targets at least 24 × 24 px (48 × 48 px is more comfortable), and no full-screen pop-up hiding the content on arrival.
• Speed: LCP under 2.5 s, INP under 200 ms and CLS under 0.1 for mobile visitors, at the 75th percentile.
• Audit: Search Console URL Inspection shows what Googlebot Smartphone got; the getReport mobile-friendly test and SEO audit check the rest.

Why mobile SEO means "the SEO of your site"

Google moved to mobile-first indexing over several years and finished the switch on 5 July 2024. From that date, the small set of sites still crawled with the desktop crawler moved to Googlebot Smartphone, and Google said that sites whose content is not accessible at all on a mobile device would no longer be indexable. There is no separate mobile index: the mobile version is the index.

That changes what "mobile SEO" means. It is not a set of extras for phones. If the phone version lacks a paragraph, a link or a block of structured data, Google does not know it exists. The background, including how Google treats separate m-dot sites and content in tabs, is in mobile-first indexing: what Google reads on your mobile pages. This page is the checklist you run.

Google also retired Search Console's Mobile Usability report and its Mobile-Friendly Test on 1 December 2023, pointing people to Lighthouse instead. Mobile usability still matters, Google said at the time; you just have to test it with other tools now.

1. Can Googlebot Smartphone reach the page?

1. The page returns HTTP 200 to a phone user agent. Some servers, firewalls and bot protections treat unknown mobile user agents differently. Test with URL Inspection → Test live URL, which fetches as Googlebot Smartphone.
2. robots.txt does not block CSS, JavaScript or images. Google renders the page like a browser; blocked resources can leave it with a broken, empty-looking layout.
3. No noindex on the mobile version. On responsive sites the mobile and desktop HTML are the same. On dynamic serving or m-dot sites, the robots meta tags must match.
4. Content does not depend on actions Googlebot does not take. Googlebot does not click, scroll or type. Content that loads only after a tap on "Load more" or a scroll event may never be seen; lazy-loaded content should load when it enters the viewport.

2. Does the mobile page have the same content as desktop?

5. Same main content. The text, product details and reviews that matter for ranking are present on mobile. Content in accordions or tabs is fine as long as it is in the HTML.
6. Same headings. The H1 and the heading structure match.
7. Same internal links. Menus may collapse, but the links in them must exist in the mobile HTML. Footer links removed "to save space" disappear from Google's view of your site.
8. Same structured data. Product, Article, Breadcrumb and other schema must be on the mobile version, with the URLs updated for m-dot sites.
9. Same title and meta description, and the same Open Graph tags.
10. Same images, with alt text and crawlable src URLs, at a quality that is still useful on a phone.

If your site is responsive, with one HTML for every screen, checks 5–10 are passed by design, unless JavaScript adds or removes content per screen size. That is why responsive design is the safe choice. For separate m-dot sites, the desktop page needs rel="alternate" pointing to the mobile URL and the mobile page a canonical pointing back to desktop.

3. Does the layout work on a phone?

11. Viewport tag present and correct: <meta name="viewport" content="width=device-width, initial-scale=1">. Without it, phones draw the page at about 980 px wide and shrink it.
12. No horizontal scrolling at 360 px. A single fixed-width table, image or embed can widen the whole page.
13. Readable text. Body text around 16 px; nothing essential under 12 px.
14. Zoom not disabled. Never add maximum-scale=1 or user-scalable=no; they fail WCAG and help nobody.

4. Can people tap and read without fighting the page?

15. Tap targets at least 24 × 24 CSS px, the WCAG 2.2 minimum, or with enough space around them. 48 × 48 px is the more comfortable size many design guides use for primary buttons.
16. No intrusive interstitials. Google's page experience guidance names pop-ups that cover the main content right after arriving from search, and standalone interstitials the visitor must dismiss first, as a poor experience. Cookie banners, age checks and small, easily dismissed banners are acceptable.
17. Forms work on a phone: the right type on inputs (email, tel, number) brings up the right keyboard, and labels stay visible.
18. Sticky headers and chat widgets do not cover content or the buttons people need.

5. Is the page fast on a phone?

19. LCP under 2.5 seconds for mobile visitors, at the 75th percentile. Usually the hero image or the first heading.
20. INP under 200 ms. Phones have slower processors than laptops, so heavy JavaScript hurts more on mobile.
21. CLS under 0.1. Images without width and height, late ads and web fonts cause most shifts.
22. Images sized for phones, with srcset and sizes, so a 400-pixel-wide screen does not download a 2400-pixel photo.

Google's thresholds are measured on real users in the Chrome UX Report, which reports phone and desktop separately. A site that passes on desktop can fail on phones, and it is the phone result most of your visitors live with. Why your mobile and desktop scores differ explains the gap.

6. Mobile-specific extras

23. Separate mobile sites are configured correctly, if you have one: bidirectional rel="alternate" and canonical, the same URL mapping for every page, and redirects that send a phone to the matching mobile page, not the mobile home page. Dynamic serving (one URL, different HTML per device) should send Vary: User-Agent.
24. Titles and descriptions work at phone width. Google truncates by pixel width, and phones show less. Put the topic first in the title and the key point in the first 120 characters of the description.

AMP is not on the list. Google no longer requires AMP for Top Stories or any other feature; see whether to keep or remove AMP.

How to run a mobile SEO audit

A mobile SEO audit is this checklist applied to one page per template: home page, category or listing, product or service, article, and any landing page that gets search traffic. Templates repeat their problems on every page built from them, so five or six pages cover most sites.

1. Fetch as Google. In Search Console, run URL Inspection → Test live URL on each page. Check "Page fetch: successful", open View tested page, and compare the screenshot and the rendered HTML with what a visitor sees. Look for missing text, links and schema.
2. Check the layout and taps. Run each page through the mobile-friendly test below; it screenshots five widths and names the elements that overflow, the text that is too small and the tap targets that are too small.
3. Check parity with JavaScript. Run the JavaScript rendering check to see which content, links and tags appear only after scripts run on a phone profile.
4. Check the SEO basics with the SEO audit: indexability, canonical, robots, viewport, titles and links.
5. Check real-user speed for phones in the Core Web Vitals test, or in Search Console's Core Web Vitals report, which groups URLs by mobile and desktop.
6. Look at a phone. A real mid-range Android on mobile data finds things no tool does: a cookie banner that covers the "Add to cart" button, or a menu that needs two hands.

The mobile-friendly test resizes one loaded page to 360, 414, 768, 1024 and 1440 px rather than loading it on each device, which is close to, but not the same as, a real phone. For the fixes behind each finding, step by step, see how to make a website mobile-friendly. For the problems a mobile audit tends to turn up alongside the rest of technical SEO, see the most common technical SEO issues.

Common mistakes

• Testing on a laptop with a narrow window. It does not reproduce a phone's slower CPU, network or touch input. Use device emulation and throttling at least, and a real phone for the final check.
• Hiding content on mobile to "simplify" the page. Whatever is removed from the mobile HTML is removed from Google.
• A separate mobile menu with fewer links. It quietly removes internal links from the version Google crawls.
• Blocking /wp-content/ or /assets/ in robots.txt. Google renders a page without its styles and scripts, and the layout breaks.
• Full-screen newsletter pop-ups on arrival. They annoy visitors and are the kind of interstitial Google's guidance calls intrusive.
• Treating the desktop Lighthouse score as the result. Run it with the mobile profile, which is the default in PageSpeed Insights.

Questions people ask

What should a mobile SEO audit include?

A mobile SEO audit should check that Googlebot Smartphone can fetch the page and its resources, that the mobile HTML has the same content, links and structured data as desktop, and that the layout, text size and tap targets work on a small screen. Add mobile Core Web Vitals and pop-ups. Run it on one page per template, starting with the templates that get the most search traffic.

How do I see my page the way Googlebot Smartphone sees it?

Use URL Inspection in Google Search Console and click Test live URL. Google fetches the page with its smartphone crawler, renders it, and shows the screenshot, the rendered HTML and any resources it could not load. Compare the rendered HTML with the page a visitor sees on a phone, and look for missing text, links or structured data.

Do pop-ups on mobile hurt SEO?

Some do. Google's page experience guidance names pop-ups that cover the main content right after a visitor arrives from search, and interstitials that must be dismissed before reading, as intrusive. Cookie consent banners, age verification and small banners that leave most of the screen usable are acceptable. Show newsletter or offer pop-ups later, or as a slim banner instead.

Does a site need to be mobile-friendly to be indexed?

It needs to be accessible on a mobile device, which is a lower bar. Since July 2024 Google indexes only content it can reach with its smartphone crawler, so a site that does not load on phones at all will not be indexed. A desktop layout that loads on a phone is still indexed, but it will struggle to rank and convert against sites built for small screens.