How to Audit Your Website for Mobile Responsiveness

UK adults now spend 77% of their online time on smartphones, according to Ofcom’s Online Nation 2025 report. If your site works well on a laptop but falls apart on a phone, you are failing the majority of the people who will ever land on it, and Google will treat that failure as a ranking problem, not just a design one.

This guide sets out a practical mobile responsiveness audit: what to check, which tools to use now that Google has retired its old testing tool, and how to read the results. It’s built for business owners, marketing managers, and in-house teams across Northern Ireland, Ireland, and the UK who need to know whether their site is genuinely mobile-ready, not just technically “mobile-friendly.” Running a mobile responsiveness audit properly means testing seven distinct areas, not just glancing at how the homepage looks on a phone.

The Post-Retirement Era: Why Google’s Mobile-Friendly Test Tool Is Gone

If your last mobile check involved pasting a URL into Google’s Mobile-Friendly Test, that check no longer exists. Google retired the Mobile-Friendly Test tool, its API, and the Mobile Usability report in Search Console in December 2023. Anyone still following an old guide that points to that tool will hit a dead link.

Google folded mobile usability checks into Lighthouse and Chrome DevTools instead, alongside PageSpeed Insights. This wasn’t a downgrade. It reflects that mobile usability is no longer a separate pass/fail check bolted onto a site; it’s built into the same performance and experience signals Google uses to judge the whole page. A complete website health audit now needs to test mobile responsiveness as one thread running through structure, speed, and accessibility checks, rather than as an isolated tick-box step.

Practically, this means running your mobile checks through:

• Chrome DevTools, using the device toolbar to emulate different screen sizes and the Lighthouse tab to run a mobile performance and accessibility report
• PageSpeed Insights, at pagespeed.web.dev, for field and lab data on real Core Web Vitals scores
• Google Search Console, which still reports Core Web Vitals by device, even though the standalone mobile usability report is gone

Beyond the Screenshot: Why Interaction to Next Paint Is the Metric That Matters Most

Most mobile audits stop at the visual layer: does the layout look right, do the images fit, does the menu collapse into a hamburger icon? That catches obvious breakages, but it misses the metric that increasingly separates sites that feel fast from sites that merely look fine in a screenshot.

Interaction to Next Paint (INP) replaced First Input Delay as a stable Core Web Vital in March 2024. It measures how long a page takes to visually respond after someone taps a button, opens a menu, or submits a form, not just how long the page took to load in the first place. A page can look perfectly responsive in a static screenshot and still fail INP badly, because the failure only shows up the moment a real visitor tries to interact with it on a mid-range phone processor.

This matters more on mobile than desktop because phones generally have far less processing headroom than the machine a developer tests on. Heavy JavaScript that runs invisibly on a desktop browser can noticeably delay a menu opening on a mobile handset, and that delay is exactly what INP is built to catch. ProfileTree’s guide to Core Web Vitals fixes for UK websites covers how LCP, CLS, and INP interact, and why they’re increasingly the difference between a page on position 4 and one buried on page two.

“A site can pass every visual check and still frustrate the person using it,” says Ciaran Connolly, founder of ProfileTree. “Responsiveness isn’t just about the layout rearranging correctly. It’s about whether the page actually responds when someone taps it, on the phone they’re actually using, on the connection they actually have.”

The 7-Step Mobile Responsiveness Audit Checklist

Work through these steps in order. Each one targets a specific failure mode that shows up repeatedly across SME websites, and together they form a complete mobile responsiveness audit rather than a partial visual check.

Step 1: Set Up Viewports and Prevent Horizontal Layout Bleed

Every responsive page needs a correctly configured viewport meta tag:

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

Without it, mobile browsers render the page at desktop width and shrink the whole thing down, forcing visitors to pinch and zoom just to read text. Check for horizontal scrolling on every template type (homepage, blog post, product or service page) by resizing the browser window gradually rather than testing only at fixed breakpoints. Layouts often break between the presets, not at them.

Step 2: Optimise Touch Target Sizing

Buttons and links sized for a mouse pointer are frequently too small for a finger. The widely used baseline is a minimum 44×44 pixel tap target, with enough spacing between adjacent elements that a visitor doesn’t accidentally tap the wrong one. This is one of the most common failures on sites that were designed desktop-first and only adapted for mobile afterwards.

Step 3: Implement Legible, Scalable Typography

Body text needs to be readable without a visitor having to zoom. Check that font sizes scale sensibly across breakpoints, that headings don’t overpower the screen on a phone, and that line length doesn’t stretch uncomfortably wide on larger tablets.

Step 4: Eliminate Cumulative Layout Shift on Mobile

Cumulative Layout Shift (CLS) tracks how much content jumps around as a page loads, most commonly when images or ads load without reserved space and push text down mid-read. This is often worse on mobile because slower connections widen the gap between when text appears and when late-loading images catch up. Reserve explicit width and height attributes for images and embeds so the browser can allocate space before the asset arrives.

Step 5: Audit Resource-Heavy Assets and Media Loading

Serving a desktop-sized hero image to a phone wastes bandwidth and slows load time on mobile data. Check that images are compressed, served in modern formats, and lazy-loaded where appropriate, and that video embeds maintain their aspect ratio rather than being cropped or overflowing their container. ProfileTree’s guide to optimising website speed and the accompanying GTmetrix scoring guide both go into more depth on diagnosing exactly which assets are costing you the most load time.

Step 6: Audit Content Parity Between Desktop and Mobile

Hiding content on mobile to save space is a common shortcut, but it has a cost beyond the visible user experience. If content, internal links, or structured data are stripped out or hidden behind interactions on the mobile version, Google’s mobile-first indexing means it may effectively see less of your page than a desktop visitor does. ProfileTree’s mobile-optimised website guide covers why content parity between desktop and mobile is now a ranking issue rather than a purely cosmetic one, since mobile-first indexing means the mobile version is what Google actually evaluates.

Step 7: Check WCAG 2.2 and Accessibility Compliance

Mobile usability and accessibility overlap more than most audits acknowledge. Touch target sizing, text-scaling without loss of function, and colour contrast are all covered by the Web Content Accessibility Guidelines (WCAG), currently at version 2.2. For UK organisations, the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations require WCAG 2.1 Level AA compliance from public sector sites, and private UK and Irish businesses trading into the EU should be aware of the European Accessibility Act’s requirements for digital services.

This isn’t a substitute for legal advice specific to your business, but it’s worth treating as part of the audit rather than a separate exercise. ProfileTree’s step-by-step accessibility audit guide and its overview of legal requirements for website accessibility both walk through what to check and why it matters commercially as well as legally.

Executing the Audit: Tooling and Scaled Workflows

The seven checks above work at any scale, but the tooling changes depending on whether you’re checking a single landing page or an entire site.

Manual Diagnosis via Chrome DevTools and Lighthouse

For a single page, open Chrome DevTools, toggle the device toolbar to emulate a mobile viewport, then run a Lighthouse report with the “Mobile” device setting selected. This surfaces viewport issues, tap target failures, CLS, and INP data in a single report, and it’s free, built into the browser, and doesn’t require installing anything.

Scaled Audits Using Screaming Frog

Checking one page manually is fine for a spot check. Checking an entire site with hundreds of URLs is not something to do by hand. Screaming Frog SEO Spider, connected to the PageSpeed Insights API, can crawl a full sitemap and flag viewport configuration errors, missing alt text, and slow-loading templates at scale, which is the only realistic way to audit mobile responsiveness across a site of any size, rather than page by page. For a broader walkthrough of what a full-site technical review should cover beyond mobile alone, see ProfileTree’s UK framework for website analysis.

Mobile Auditing Tools at a Glance

Getting the Fix Built: When to Bring in a Web Design and Development Team

An audit tells you what’s wrong. Fixing it is usually where SME teams stall, particularly when the issues sit below the surface, in template code, image pipelines, or JavaScript that a content editor can’t touch. This is where responsive web design and website development work becomes a practical next step rather than a sales pitch: touch target and viewport fixes usually need a developer, CLS fixes often mean rebuilding how images and embeds are loaded, and INP issues typically mean restructuring how JavaScript executes rather than tweaking CSS.

For sites where mobile speed keeps slipping between audits, ongoing website hosting and management that includes performance monitoring catches regressions before they show up in Search Console months later. And because a lot of what breaks mobile responsiveness is hidden inside marketing decisions, not just code, teams juggling content marketing updates alongside a redesign benefit from checking content parity as part of that process rather than after launch.

Where an internal team wants to run these checks themselves on an ongoing basis rather than relying on an external audit each time, digital training that covers Lighthouse and Search Console interpretation is often a smaller investment than a repeat consultancy engagement, and it’s an area where AI-assisted workflows are starting to help teams triage large lists of audit findings faster than manual review allows.

Summary Checklist and Next Steps

A genuine mobile responsiveness audit covers seven things: viewport configuration, touch target sizing, scalable typography, layout stability, media loading, content parity, and accessibility compliance, checked with Lighthouse, PageSpeed Insights, and Search Console rather than a retired single-URL tool. Run it page by page for a spot check, or at scale with Screaming Frog for a full-site review. Where the audit turns up fixes that sit in code rather than content, that’s the point to bring in development support rather than trying to patch the symptoms through the CMS.

FAQs