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

> A mobile SEO checklist for the way Google indexes today: what Googlebot Smartphone must be able to fetch, content parity with desktop, viewport, text and tap targets, interstitials and mobile speed, with a free way to audit each check.

Updated 2026-09-26 · Technical SEO · HTML version: https://getreport.app/guides/mobile-seo-checklist

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](https://getreport.app/guides/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](https://getreport.app/tools/responsive-check) and [SEO audit](https://getreport.app/tools/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](https://getreport.app/guides/mobile-first-indexing). 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.

> **Check: robots.txt allows this page.** A Disallow rule stops search engines from crawling this page, so they cannot read its content or see any updates. The page can still appear in results as a bare URL with no description.
>
> 1. Remove or narrow the Disallow rule in robots.txt so this URL is allowed for all crawlers.
> 2. If the page should stay out of search, allow crawling and use a noindex tag instead; a blocked page cannot be de-indexed.

> **Check: The page is not set to noindex.** A noindex directive tells Google to drop this page from search results. Unless that is intended, every visit from search is lost.
>
> 1. Remove noindex from the robots meta tag and from the X-Robots-Tag header, unless the page should stay out of search.
> 2. In WordPress, untick Settings → Reading → "Discourage search engines" and check the page's SEO plugin settings.

## 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.

> **Check: The visible text is present without JavaScript.** Google renders JavaScript later and with a budget, so text that only appears after scripts run can be indexed late or not at all. Other search engines and link previews may never see it.
>
> 1. Serve the main content in the HTML (server-side rendering or static generation) and use JavaScript only to enhance it.
> 2. Check the difference in the technical detail; menus and widgets are fine, headlines and body copy are not.

## 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.

> **Check: Viewport meta tag is present.** Without a viewport tag, phones render the page at desktop width and shrink it. Google indexes the mobile version first, so this hurts rankings directly.
>
> 1. Add <meta name="viewport" content="width=device-width, initial-scale=1"> in <head>.

> **Check: The page fits every screen width from 360 to 1440 px.** When a page is wider than the phone, visitors have to pan left and right to read it, and Google indexes this mobile version, broken layout included. It is usually one fixed-width element.
>
> 1. Find the element named in the technical detail and give it max-width:100% instead of a fixed width.
> 2. Wrap wide tables in a container with overflow-x:auto, so only the table scrolls.
> 3. Let images and embeds shrink with max-width:100%; height:auto.

> **Check: Visitors can zoom the page on their phone.** Many people zoom web pages on their phone to read small text. A viewport tag with user-scalable=no or a low maximum-scale turns that off in Chrome on Android; only iOS Safari ignores it.
>
> 1. Change the viewport meta tag to <meta name="viewport" content="width=device-width, initial-scale=1">.
> 2. Remove user-scalable=no, and remove maximum-scale or set it to 5 or more; in WordPress this usually lives in the theme header or a mobile plugin.

## 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.

> **Check: Tap targets are at least 24×24 px.** Small links and buttons packed together cause mis-taps on phones, which means abandoned carts and wrong menu choices. WCAG 2.2 asks for at least 24×24 px or equivalent spacing.
>
> 1. Give links and buttons a minimum height of 24 px (44 px is comfortable) with padding rather than a bigger font.
> 2. Add space between neighbouring targets such as icon rows, pagination links and footer menus.

## 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](https://getreport.app/guides/mobile-vs-desktop-scores) explains the gap.

> **Check: Largest Contentful Paint.** LCP is when the biggest thing on screen — usually the hero image or headline — finishes loading. Visitors judge "is this site slow?" on it, and Google uses it for ranking.
>
> 1. Find the LCP element (named in your report) and make it lighter, earlier or both — a compressed WebP/AVIF, sized to the screen, without lazy loading.
> 2. Preload it with <link rel="preload" as="image"> or add fetchpriority="high" on the <img>.
> 3. Cut what comes before it — render-blocking CSS/JS and slow server responses push LCP back.

> **Check: Interaction to Next Paint.** INP measures how quickly the page reacts when someone taps or clicks. Lab tools cannot simulate it, so this comes from real Chrome users; slow responses feel like a frozen page.
>
> 1. Break up long JavaScript tasks and defer third-party scripts so the main thread is free when people interact.
> 2. Respond to input visually first (a pressed state, a spinner), then do the heavy work.
> 3. Reduce DOM size and avoid layout-heavy work inside click handlers.

> **Check: Cumulative Layout Shift.** CLS measures how much the page jumps around while loading — the button that moves just as someone taps it. It is one of Google's three Core Web Vitals.
>
> 1. Give every <img>, <video>, ad slot and embed explicit width and height (or aspect-ratio) so space is reserved before it loads.
> 2. Preload the main web font and use font-display optional, or swap with a size-adjusted fallback font, so text does not reflow.
> 3. Never insert banners or content above existing content after load.

## 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](https://getreport.app/guides/amp-keep-it-or-remove-it).

## 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.

> **Free tool:** [Mobile-friendly test and CSP generator](https://getreport.app/tools/responsive-check): Free mobile-friendly test to replace Google's retired one: screenshots at five widths, sideways scrolling, tiny text and tap targets, plus a CSP generator.

> **Free tool:** [JavaScript rendering checker: raw vs rendered HTML](https://getreport.app/tools/js-rendering-check): Free JavaScript rendering checker: compare raw HTML with the rendered page and see which text, links, tags and structured data appear only after scripts run.

> **Free tool:** [Free SEO checker and SEO audit for any page](https://getreport.app/tools/seo-audit): Free SEO audit of any page: titles, headings, canonical, robots.txt, sitemaps, indexability and broken links, each with a plain-language fix. No sign-up.

> **Free tool:** [Core Web Vitals test: check LCP, INP and CLS](https://getreport.app/tools/core-web-vitals): Free Core Web Vitals test: LCP, INP and CLS from real Chrome users next to the lab values, rated against Google's thresholds, with what to fix. No sign-up.

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](https://getreport.app/guides/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](https://getreport.app/guides/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.