Mobile SEO Checklist

A mobile SEO checklist is a set of checks that confirm the mobile version of a site can be crawled, rendered, indexed, and used on a phone, in that order. Since Google finished the move to mobile-first indexing, the mobile version is the one in the index, and whatever Googlebot Smartphone fetches at your URL is the document Google ranks, on desktop too.

That changes what the checklist is for. Most lists on this query still read like a 2016 mobile-friendly audit: responsive layout, viewport tag, font size, load time. Those items are here too, further down, after a harder question, which is whether the page Googlebot Smartphone receives contains everything you think it does. A site can pass every layout check and still hand Google 60% of its content, and nothing in Lighthouse will say so.

The list below runs in audit order. If you only have time for the first four sections, do those.

Mobile-first indexing

Google announced the transition complete on 31 October 2023. The last exception ended on 5 July 2024, when the small set of sites still crawled with desktop Googlebot was moved to the smartphone crawler. Google also said at that point that a site whose content is not accessible on a mobile device would no longer be indexable. So “mobile-first” stopped being a status a site is in or out of.

The mobile HTML is the indexed HTML. Ranking signals such as titles, headings, internal links, and structured data are read from it, including for desktop searches. There is one index. Desktop Googlebot still makes a small share of requests, which Google describes as occasional verification crawling, and you can see the split in Search Console under Settings → Crawl stats → By Googlebot type. On a healthy site the Smartphone line dominates; if Desktop is anywhere near parity two years after the cutover, the server is treating the two user agents differently.

“Mobile version” here means what the smartphone crawler receives. A person on a phone sees something else more often than designers expect. The crawler fetches with a US IP address by default, sends no Accept-Language header, holds no cookies from a previous request, and renders each URL from a clean state. A geo-redirect, a language gate, or a consent wall that decides what to show based on any of those will decide it for Google too. Content that is in the DOM but collapsed in an accordion counts. Content that loads only after a tap does not.

The old diagnostics went with it. The one place that still tells you which crawler fetched a page is URL Inspection, under “Crawled as”.

Mobile content parity checklist

Parity is the core check, and most of the rest of this list is about the ways it breaks.

The rule is simple to state: the mobile page must carry the same primary content, headings, links, images, video, metadata, robots directives, and structured data as the desktop page. Google’s own guidance says the mobile version needs to be as complete as the desktop version. I read that with one qualification from my own audits: a footer link or two missing on mobile has never cost a site anything I could measure, while a missing H2 block or a menu level has, so the diff below weights the main content over the chrome. What makes parity hard is that it breaks per template. The homepage is fine, the category page dropped its filter links, the article page trimmed the FAQ, and a site-wide check averages the three into a pass.

Which mechanism did the hiding matters more than which block is missing. Content hidden with CSS is in the HTML and is indexed: Elementor’s elementor-hidden-mobile, Dawn’s small-hide class on Shopify, any display: none inside a media query. Content removed by a template condition is not in the HTML: a Liquid {% if %} on a section, a WordPress block with a device rule that resolves server-side, a React component that only mounts above a breakpoint. In the page builder the two settings sit next to each other and look the same.

The tool for this is URL Inspection → View crawled page → HTML, compared against a crawl run with the Googlebot Smartphone user agent and JavaScript rendering on. Compare counts first, then read the diffs where the counts move, per template type:

• Body text. Word count of the rendered mobile HTML against the desktop crawl. A custom extraction on main (or whatever wraps the article) is more useful than the whole-page count, because navigation and footer noise hides the gap.
• Headings. Mobile redesigns often keep the visual hierarchy and lose the tags: an H2 becomes a styled div. Check that H1–H3 are the same elements, not just the same text.
• Internal links. Count a[href] inside the main content and inside the navigation separately. The three usual casualties are the footer, “related” blocks, and the second level of navigation. If the hamburger menu is built on tap, the links may not exist in the crawled HTML at all.
• Images and video. Same src, same alt, same embeds. Google Images indexes from the mobile version, so an image dropped on mobile drops from Images. Images inside collapsed tabs are indexed as long as the img element is in the DOM; images inside a tab that mounts on click are not.
• Metadata and directives. Title, meta description, robots meta, canonical, hreflang. A mobile-only noindex left over from staging is the one I find most often.
• Structured data. Same JSON-LD blocks, covered in its own section below.

Mobile crawlability checklist

Crawlability on mobile fails in two ways. Either the crawler can’t reach the page, or it reaches the page and can’t fetch what the page needs to render, and the second is the one I find more often, because nothing in Search Console says “blocked stylesheet” in so many words. A robots.txt that disallows /assets/, /static/, a theme folder, or an image CDN path stops Googlebot from loading CSS, JS, and images. The HTML arrives, the render is broken, and Google’s understanding of the page is whatever survives. Google warns specifically that blocking CSS interferes with rendering and blocking images removes them from Google Images.

The checks:

• Fetch robots.txt and list every disallowed path. For each one, ask whether a stylesheet, script, font, or image lives there.
• Confirm the mobile user agent isn’t filtered. Googlebot Smartphone identifies as Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) ... Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html). Bot-management rules and CDN firewalls sometimes treat the mobile string differently from the desktop one, and a JavaScript challenge page returns 200 with no content, which is worse than a 403. Test with curl -A "<the string>" -I and with URL Inspection’s live test.
• HTTP 200 on the mobile fetch, not a redirect to a different URL, not a 403 from a WAF, not a 5xx under load.
• HTML under 15 MB. Googlebot stops reading past that point. The limit is per file, so external CSS and JS have their own budget, but inlined base64 images on mobile templates can push the HTML itself there.
• Server logs. Filter by the Googlebot Smartphone string and verify the requests really come from Google: reverse DNS resolving to googlebot.com or google.com, or a match against the published googlebot.json IP ranges. If desktop Googlebot still dominates your logs, something on your side is serving it a different site.
• XML sitemap lists the canonical URLs and nothing else. Separate mobile URLs do not belong in it.

Mobile indexability checklist

A page can be crawlable and still not make the index, or make it under a URL you didn’t choose. Google’s technical requirements are minimal: Googlebot is not blocked, the page returns 200, and the page has indexable content. Most mobile indexability failures are a mobile template quietly violating one of the three.

• noindex on the mobile template only. Grep the rendered mobile HTML for noindex, and check the HTTP header X-Robots-Tag too. CDN edge rules that add the header to a path pattern are invisible in the HTML.
• Canonical. A responsive page should self-canonicalize. A canonical pointing at a desktop URL from a mobile URL is correct only in a separate-URL setup, and there it must be paired with rel="alternate" on the desktop side.
• Soft 404. Mobile templates that show “no results” or an empty state with a 200 status get classified as soft 404 and dropped. Category pages with mobile-only filtering are the usual source, and the classification runs on the rendered page, so a JavaScript “nothing found” message triggers it too.
• Redirects. Faulty redirects (every mobile request sent to the homepage), chains through an old m-dot, and redirect loops between mobile and desktop URLs.
• URL Inspection. Confirm “Crawled as: Googlebot smartphone”, “Indexing allowed: Yes”, and that the Google-selected canonical matches the user-declared one.

When the canonicals differ, the Pages report names it, and four statuses are where mobile indexability problems surface first:

Mobile rendering and JavaScript checklist

Googlebot renders pages with an evergreen Chromium, so JavaScript by itself is fine. Content that depends on a user event isn’t, because the crawler doesn’t produce user events. It doesn’t scroll, tap, type, or swipe.

Rendering also runs on a separate queue from crawling; Google said at I/O 2019 the median wait was about five seconds and the long tail minutes, which is fine for indexing and irrelevant for the checks below.

Open URL Inspection, run the live test, read the rendered HTML and the screenshot, and open “Page resources” under More info: every stylesheet or script listed with “Other error” or “Blocked by robots.txt” is a resource the renderer went without. Then do the same in a crawler with rendering on. If a block of content is on the page when you open it on a phone and absent from the rendered HTML, it isn’t indexed, whatever the design says.

Viewport meta tag settings

The viewport tag is one line, and it is the difference between a page rendering at a phone’s width and rendering at 980 CSS pixels and being shrunk to fit. 980 is the fallback layout width mobile Chrome and Safari both use when no viewport is declared.

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

width=device-width matches the layout viewport to the screen. initial-scale=1 sets the starting zoom. That is the whole recommendation, and the trouble comes from what people add to it. maximum-scale=1 and user-scalable=no both block pinch-zoom; they fail the meta-viewport accessibility audit, and iOS Safari has ignored them since iOS 10 anyway, so they cost a failed audit and gain nothing. A fixed width=320 made sense for one phone in 2010.

Optional keys that are legitimate: viewport-fit=cover if the layout needs to extend behind a notch, and interactive-widget=resizes-content (Chrome 108 and later) if the on-screen keyboard should shrink the layout instead of overlaying it.

One update for anyone running old audit scripts: in Lighthouse 12 (May 2024) the viewport and font-size audits were moved out of the SEO category into Best Practices, on the grounds that they are no longer priorities for Google Search. The tag still matters, because without it the page is unreadable on the user side; it just stopped being scored as SEO.

Responsive design, dynamic serving, and separate mobile URLs

Google supports three configurations and recommends one.

Responsive is the recommendation because it removes the parity problem by construction: there is one document. Dynamic serving and m-dot sites can be indexed correctly, but every check in the parity section has to be run twice, and the annotation pairs have to be right on every URL. Google has been explicit that separate mobile URLs cause problems in mobile-first indexing that responsive sites don’t have.

Dynamic serving has one failure that is specific to it and easy to miss. CDNs cache by URL, and most of them either strip Vary: User-Agent or normalize the user agent to a handful of buckets before the cache key. If Googlebot Smartphone lands in the desktop bucket, it is served the desktop HTML from cache, and every parity check you run from a phone passes while the index holds the wrong document. The test is a curl with the Googlebot Smartphone string against the CDN hostname, not the origin.

If you are building new, there is no case for an m-dot in 2026. If you already have one, the question is how to leave it.

Mobile SEO after a site migration

Migrations break mobile SEO in two shapes, one loud and one quiet.

The loud one is the m-dot to responsive move. Each mobile URL needs a 301 to its exact responsive counterpart, not to the homepage and not to the category. A host-level rewrite from m.example.com/$1 to example.com/$1 only works if the paths were identical, and on older m-dots they often weren’t (/p/123 on mobile against /product/blue-widget on desktop), so the mapping ends up as a table, one row per URL. The rel="alternate" annotations come off the desktop pages, the mobile hreflang entries come out of the hreflang sets, the m-dot drops out of the sitemap, and the old host keeps redirecting for at least a year, which is Google’s stated minimum for a site move, and longer if external links still point at it. Skip the per-URL mapping and the mobile URLs go to soft 404, taking whatever equity they had with them.

The quiet one is a redesign on the same URLs. Nothing redirects, so nothing looks broken. What changes is the mobile template. The new theme hides the specs block on small screens with a template condition instead of CSS. The new framework hydrates a menu that used to be static HTML. A “delay JavaScript” optimization ships turned on and pushes INP past 200 ms on mid-range phones. A noindex left on the mobile layout from staging goes live with the theme.

The check after any migration is the parity diff from section two, run on the first crawl after launch and again after Google has recrawled the templates. Then Search Console → Performance → Compare mode, last 28 days against the previous 28, with Device as the dimension. If mobile clicks fall while desktop holds, the migration touched the mobile document, and the list above is where to look. Watch the Pages report in the same window: a rising Soft 404 or “Duplicate, Google chose different canonical” count is the same story from the index side.

Mobile Core Web Vitals checklist

The thresholds are unchanged: LCP at or under 2.5 seconds, INP at or under 200 milliseconds, CLS at or under 0.1, measured at the 75th percentile of real Chrome sessions over a rolling 28-day window. INP replaced FID on 12 March 2024, and any list that still names FID predates that.

Mobile fails first. Same page, same code, and the phone build of CrUX is red while desktop is green, because a mid-range Android on a cell connection has a fraction of the CPU and a multiple of the latency. If you optimize against the desktop numbers you will pass desktop and keep failing where the traffic is. Across the web, roughly six in ten origins have good mobile LCP according to CrUX-based HTTP Archive reporting, and the gap to desktop has been there every year the metric has existed.

Search Console groups URLs. The Core Web Vitals report assigns status to a group of similar URLs by the worst metric in the group, so a slow header script or a third-party widget on one template turns hundreds of URLs red at once. Fixes on individual pages don’t move the status; the template does.

Since Chrome 112, images with very low entropy (under 0.05 bits per pixel: gradients, solid placeholders, blurred LQIP) are not LCP candidates, so a placeholder strategy that “passed” on older Chrome no longer does. And INP counts clicks, taps, and key presses, not scrolls or hovers, and reports roughly the worst interaction with outlier trimming per fifty; the field INP itself is in the CrUX section of PageSpeed Insights and in the Search Console report.

Boundary: Google says Core Web Vitals are used by its ranking systems and also that they don’t override relevance. Treat them as a thing that can hold a page back. I have not seen them push one forward, and I have looked.

Mobile images and video checklist

• srcset and sizes on content images, with a source close to the mobile rendered width. sizes="(max-width: 600px) 100vw, 600px" is the shape; the wrong sizes value makes the browser pick the largest candidate, which is why srcset alone often changes nothing. A 2,000-pixel desktop hero served to a 390-pixel viewport is the single most common mobile LCP failure.
• Explicit width and height attributes, or CSS aspect-ratio, on every image, so the browser reserves space before the file arrives.
• WebP or AVIF with a fallback. WebP is universal; AVIF has been in Safari since 16.4, so the <picture> fallback is for edge cases, not for Googlebot.
• loading="lazy" on images below the fold and never on the LCP image. decoding="async" on the rest.
• Same images on mobile and desktop, same alt. This is a parity item as much as a performance one.
• Video: a poster image, the embed present in the rendered HTML, and VideoObject structured data with name, thumbnailUrl, and uploadDate at minimum. Google’s video indexing now requires the video to be the main content of the page to count as a video page; a clip embedded halfway down an article gets a “video isn’t the main content” note in the Video pages report rather than a video result.

Mobile UX checklist

Google folds mobile usability into “page experience” alongside Core Web Vitals, HTTPS, and interstitials. The items below are the ones with a measurable definition or a documented Google position.

Tap target size

The accessibility minimum, from WCAG 2.2 Success Criterion 2.5.8, is 24 by 24 CSS pixels. The comfortable target in Google’s Material guidance is 48 by 48 dp with about 8 pixels of spacing; Apple’s Human Interface Guidelines say 44 by 44 points. Lighthouse 12 replaced its old SEO tap-targets audit with a target-size audit under Accessibility, which is where it now lives, and the new audit checks the 24-pixel minimum, not the 48-pixel comfort level. The elements that fail in practice are inline text links stacked in footers, icon buttons without padding, and pagination controls. The fix is padding; a larger icon changes nothing if the hit area stays the same.

Font size and readability

16 CSS pixels for body text is the working baseline, and on iOS there is a second reason for it: Safari auto-zooms the page when a form field with a font size under 16 pixels receives focus, which is the “page jumps when I tap the search box” complaint. Below about 12 pixels, text needs zoom, and if you’ve disabled zoom in the viewport tag it needs squinting. Keep line length short on narrow screens and line height around 1.5.

Lighthouse 13, released in October 2025, removed the font-size audit entirely, and Google’s explanation was that it isn’t a current search signal. It still decides whether people read the page.

Interstitials and pop-ups

Google’s page experience guidance lists intrusive interstitials as a negative signal: full-screen overlays on entry from search, pop-ups that cover the main content, and standalone interstitials the user has to dismiss. App-install interstitials have been penalized on their own since November 2015; the general case followed in January 2017. Exceptions are documented: legal notices such as cookie and age gates, login walls for gated content, and banners that use a reasonable amount of screen.

The signal applies to the transition from a search result to the page, so an exit-intent pop-up on the second page of a session is outside the signal. A sticky CTA that covers a third of a phone screen is inside it, however it’s labeled in the design file.

Navigation, forms, and overflow

Horizontal scrolling on a mobile page is a layout bug, usually a fixed-width table, an image without max-width: 100%, or an element with a negative margin. overflow-x: hidden on body hides the symptom and leaves the cause; the quick check is document.documentElement.scrollWidth > window.innerWidth in the console, then walk the DOM to find the element that’s wider than the viewport. Wrap wide content in its own scroll container.

Forms: use type="email", type="tel", inputmode="numeric", autocomplete, and enterkeyhint so the right keyboard and the right return key appear. Navigation links should exist in the HTML whether or not the menu is open.

Mobile structured data checklist

A mobile template that drops or trims the JSON-LD, or loads it inside a component that never renders for the crawler, is the failure here. Google’s position is that markup present on desktop has to be present on mobile, for the same reason as everything above: the mobile version is what gets indexed.

• Same JSON-LD blocks on mobile and desktop: Product, Offer, AggregateRating, BreadcrumbList, Article, Organization, LocalBusiness, VideoObject, whichever apply.
• JSON-LD in the initial HTML or in the rendered DOM, not inside a lazy-loaded block. JSON-LD injected through Google Tag Manager is rendered and does work, but it inherits every risk in the rendering section and it disappears the day someone pauses the container.
• Rich Results Test defaults to the smartphone crawler. Run it as smartphone, then compare with a desktop run if you have any doubt.
• Prices, availability, and ratings in the markup must match what the mobile page shows. Mobile templates that hide the rating widget while keeping AggregateRating in the markup are a policy problem: Google issues a “Structured data issue” manual action for markup that describes content the user can’t see.
• Merchant listing eligibility needs Offer with price, priceCurrency, and availability on the mobile product page, not only in the feed.

Mobile local SEO checklist

Most local searches happen on a phone, and most of them are decided outside the organic listing, in the map pack. The mobile-specific items are short: a Google Business Profile that is complete and matches the site’s NAP, LocalBusiness schema on the location pages on mobile, click-to-call links (tel:), and a map that loads without blocking the page, since an embedded Maps iframe is routinely the heaviest third party on a location page and belongs below the fold with loading="lazy". And location pages that survive the parity check, because hours and address are the sections most often hidden on small screens. Everything else about local SEO belongs to a local SEO checklist.

AMP and progressive web apps

AMP has not been required for the Top Stories carousel since the page experience update in June 2021, and the lightning-bolt badge went with it. If you still run AMP pages, the checks are the same as any paired setup: the AMP page carries rel="canonical" to the original, the original carries rel="amphtml", the AMP page passes validation, and the content matches. Search Console’s AMP report shows validation errors per URL. If you are deciding whether to keep AMP: for most sites a fast responsive page does the same job with one document instead of two, and removing AMP is a migration, with a 301 from every AMP URL to its canonical.

Progressive Web Apps are indexed like any other site: the content has to be in the rendered HTML, the manifest doesn’t help indexing, and service workers are ignored by the crawler, which also means a PWA’s offline shell is never what Google sees. Lighthouse dropped its PWA category in version 12, so installability is no longer scored there. Treat a PWA as a JavaScript site and run the rendering section.

How to test mobile SEO

Each tool answers one question, and the usual mistake is asking Lighthouse whether a page is indexed.

The Mobile-Friendly Test URL now redirects to Lighthouse documentation, and the Search Console Mobile Usability report is gone; both were retired in December 2023. Lighthouse changed shape too: version 12.7 (June 2025) switched to insight-based audits by default, and version 13 (October 2025) removed the legacy audit IDs, so render-blocking-resources, uses-rel-preload, and offscreen-images are gone and their replacements are grouped insights with different names. Any dashboard or CI check keyed to the old IDs needs re-mapping before its numbers mean anything.

Without coding: everything in the first column can be checked by someone who doesn’t write code. Fixing most of the second half of this list requires a developer.

Mobile SEO problems that cause ranking drops

Before blaming the mobile version for a drop, rule out the things that aren’t it: a site younger than a couple of months, a competitor with a much stronger link profile, or a SERP whose format changed. Then check the device split in Search Console. If mobile fell and desktop didn’t, work down this table.

Mobile SEO checklist for WordPress and Shopify

Two platform notes, because the same failures keep turning up under the same names.

WordPress

Page builders differ on what “hide on mobile” means. Elementor and Divi hide with CSS classes, so the block stays in the HTML; some block-visibility plugins remove it server-side. Check the rendered HTML, not the setting. Core has handled the two most common image mistakes since 5.9 and 6.3: it skips loading="lazy" on the first content image and adds fetchpriority="high" to the image it judges likely to be the LCP, so a lazy-loaded hero on a modern WordPress site is usually a theme or an image plugin overriding core. WP Rocket’s “Delay JavaScript execution” and “Remove Unused CSS”, and their equivalents in Perfmatters and LiteSpeed Cache, are the toggles to test individually against the rendered HTML and against field INP; each one can break a render or move INP by itself. Mobile menu plugins can duplicate every navigation link, which is harmless, or build the menu on tap, which is not.

Shopify

Liquid sections hidden on mobile through theme settings are removed from the HTML, so they fail parity; Dawn’s own small-hide and medium-hide classes are CSS and pass. Apps inject scripts through {{ content_for_header }}, which a theme can’t edit, and through app embeds, which can be switched off per app in the theme editor; the app embed list is where INP work on Shopify starts, and the admin’s Web performance dashboard shows the CrUX numbers for the store. Use image_url with a width parameter and image_tag with widths rather than the full upload. Product JSON-LD comes from the theme, so a theme change can drop Offer and AggregateRating without anyone noticing until the rich results go.

Where to start

If there is an 80/20 in this list, it is the first four sections: parity, blocked resources, indexability, rendering. They decide what Google has to work with; performance and UX only decide how that document competes once it exists. Most sites I look at have a passing Lighthouse score and a mobile template that is missing something. The score was the easy part.

There is no mobile version of the index. There is the index, and it was built from the mobile page.

Two things I’m not sure about. Whether Google still runs any desktop fetches for parity comparison after the 2024 cutover, and how long a fixed parity gap takes to reflect in rankings versus in the index. I have seen both take a week and both take a quarter.

Frequently asked questions

Is mobile SEO still important in 2026?

Since 2024 there is no non-mobile SEO for Google. The smartphone crawler builds the index, so everything called “SEO” runs on the mobile document, and what changed is what the phrase covers: viewport tags and font sizes moved into accessibility tooling, and what’s left is whether the crawler gets the whole page and whether real phones pass Core Web Vitals.

How do I check whether my site is indexed from the mobile version?

Search Console → URL Inspection on any URL, and read “Crawled as”. If it says Googlebot smartphone, the HTML under View crawled page is your indexed document.

What replaced Google’s Mobile-Friendly Test?

Nothing, one-for-one. Google retired it with the Search Console Mobile Usability report and the test API on 1 December 2023 and now points to Lighthouse. Lighthouse checks implementation details in the lab; PageSpeed Insights adds CrUX field data; URL Inspection shows the rendered mobile page for a property you own. Third-party “mobile-friendly checkers” are usually a wrapper around one of those three.

Does mobile SEO affect desktop rankings?

Yes. There is one index, built from the mobile page, so a heading that exists only on desktop is missing for both devices. Rankings can still differ between devices; the document doesn’t.

Can I work through this checklist without a developer?

The checks, yes. URL Inspection, the Pages report, the Core Web Vitals report, Rich Results Test, and a rendered crawl are all readable without code. Most of the fixes are template work: the parity gaps, the lazy-loading changes, the INP sources. Expect the audit to be yours and the ticket to be a developer’s, and expect the ticket to take longer than the audit did.

Prediction for 2027: the viewport tag, font size, and tap targets will be fully absorbed into accessibility tooling, and “mobile SEO” as a separate discipline will mean exactly one thing, which is whether the smartphone crawler gets the whole document. If you’d rather have that checked on your site than check it yourself, that’s our technical SEO audit.