A mobile SEO audit checks whether your site gives mobile users and Googlebot a fast, usable, crawlable experience. Since Google switched to mobile-first indexing, what the mobile version of your site looks like to the crawler is what determines your rankings across all devices — not the desktop version. If the mobile experience is thin, slow, or blocked, the rankings reflect that regardless of how good the desktop site looks.

Page Speed and Core Web Vitals on Mobile

Speed is the first thing I check in a mobile SEO audit. Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP) all have explicit thresholds Google uses when assessing page experience. On mobile, LCP is particularly unforgiving because images that load fine on a fast desktop connection can time out on a throttled 4G connection. I use PageSpeed Insights and the Chrome User Experience Report (CrUX) to get real-world field data from actual users, not just lab scores from a simulated environment — lab and field numbers often diverge significantly.

  • LCP should be under 2.5 seconds at the 75th percentile in field data. Images sized for desktop and served without responsive srcset attributes are a common cause of slow LCP on mobile.
  • CLS should stay below 0.1. Ads, embeds, and lazy-loaded images that shift layout as they load are the usual culprits.
  • INP (replaced FID in March 2024) measures responsiveness to user input. Heavy JavaScript that blocks the main thread degrades INP on lower-end mobile devices.
  • Check Time to First Byte (TTFB) separately — slow server response time kills everything downstream regardless of how well the front end is optimized.

Crawlability and Mobile Configuration

Google crawls your site primarily with a mobile user-agent. If your robots.txt or server-side redirect logic blocks Googlebot-Smartphone, or if your site serves a stripped-down mobile version that omits content present on desktop, you have a crawlability problem that directly affects what gets indexed. I audit the mobile configuration type — responsive design, dynamic serving, or a separate m-dot subdomain — and verify the implementation does not create content gaps or duplicate canonicalization issues.

  • Confirm robots.txt does not block the CSS or JavaScript files needed to render the mobile view. If Googlebot cannot load those resources, it renders a broken page and may miss your content.
  • Check that hreflang tags on m-dot setups correctly point to their desktop counterparts, and that the desktop pages return the reciprocal annotation. A one-sided hreflang implementation is the same as none.
  • Use Google Search Console's URL Inspection tool with the mobile user-agent to see what Googlebot actually renders — not what you see in a browser emulator. Rendered HTML and actual mobile browser output can differ.
  • Look for interstitials or app install banners that cover more than 20% of the viewport on mobile. Google explicitly demotes pages with intrusive interstitials in mobile search results.

A correctly configured robots.txt that allows mobile crawling looks like this:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

# Do NOT disallow /wp-content/themes/ or /wp-content/plugins/
# Blocking these prevents Googlebot from rendering CSS and JS
Sitemap: https://example.com/sitemap.xml

A common mistake is adding Disallow: /*.js or Disallow: /*.css rules that block the render-critical resources Googlebot needs to see your mobile layout.

Usability and Tap Target Sizing

Google's mobile usability report in Search Console flags the most common issues, but it is not exhaustive. I manually check tap target size — buttons and links should be at least 48×48 CSS pixels with adequate spacing between them. Body text below 16px is often flagged as too small to read without zooming, which is also a usability signal. The viewport meta tag should be set correctly:

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

Sites that set a fixed width or disable user scaling with user-scalable=no fail both usability and accessibility standards. Google can and does demote pages with these configurations in mobile search results.

  • Audit navigation menus for mobile. Hamburger menus that do not open, or that are too small to tap reliably, are surprisingly common on sites that look fine in desktop view.
  • Check form fields: using the correct input type attributes triggers the right mobile keyboard. type='tel' opens a numeric keypad; type='email' opens a keyboard with @ readily available. Wrong input types create friction for mobile users filling out contact or lead forms.
  • Test on actual physical devices where possible, not only in browser emulation. Emulation in Chrome DevTools misses some rendering behavior, particularly around font rendering and touch event handling on lower-end Android devices.

Structured Data and Mobile Rendering

Structured data needs to be present in the mobile-rendered HTML, not injected only by scripts that load after Googlebot stops waiting. JavaScript-rendered schema is technically supported, but Google does not guarantee it will be processed, and timing issues are common. I check that schema markup appears in the rendered DOM when using a mobile user-agent — particularly for Product, Article, and LocalBusiness schemas where rich results have direct visibility impact in mobile SERPs.

The Rich Results Test at search.google.com/test/rich-results lets you test specific URLs and see which rich result types are detected. Run it with the mobile user-agent toggle enabled and compare the output to what you see in desktop testing. Discrepancies usually point to a JavaScript rendering issue.

Common Mobile SEO Audit Mistakes

  • Relying only on Search Console mobile usability data: It reports issues Google has already encountered. New issues from recent deploys will not appear there immediately.
  • Assuming responsive design means no mobile issues: Responsive design handles layout, not performance. A responsive site can still have slow LCP, oversized images, and render-blocking JavaScript.
  • Ignoring the mobile experience for JavaScript-heavy sites: Single-page applications and JavaScript frameworks often produce different rendered output on mobile Googlebot than on desktop. Always verify with URL Inspection.
  • Checking Core Web Vitals only in lab mode: PageSpeed Insights lab scores and real-user CrUX field data measure different things. A site can pass lab tests and still have poor field CWV due to user device mix and connection variability.

How Mobile SEO Fits a Full Technical Audit

Mobile is one layer of a broader technical health picture. Fixing mobile performance without also addressing indexation issues, canonical conflicts, and redirect chains leaves potential ranking gains on the table. A website audit covers the complete picture — mobile is part of that, not a separate track. You should also review your broken link audit alongside mobile work, since 404s hurt both crawl efficiency and user experience on every device. For the technical foundations, what is technical SEO and the technical SEO audit overview are good starting points.

How Often to Run a Mobile SEO Audit

Mobile SEO is not a one-time task. Google updates its mobile crawler, PageSpeed Insights lab environment, and Core Web Vitals thresholds periodically. Site deploys, plugin updates, and CMS upgrades routinely introduce new mobile issues — shifted viewports, accidentally blocked resources, regressed LCP from newly added images. A mobile audit check should be part of your post-deploy QA process, not just an annual item. At minimum, re-run PageSpeed Insights, the Rich Results Test, and Google Search Console URL Inspection against your top landing pages any time a significant change goes to production. For sites on a CMS like WordPress with frequent plugin updates, a monthly mobile health check catches regressions before they accumulate into a larger ranking problem.

The most common pattern I see is a site that passed a mobile audit 18 months ago but has quietly accumulated issues since then — a new slider plugin that adds layout shift, a font-loading change that delays LCP, a server migration that added 200ms to TTFB. None of these individually would trigger a manual audit, but together they push the site out of Good CWV range and suppress rankings. Regular light checks prevent that drift.