Mobile SEO Checklist: Make Your Site Work Where Your Readers Are

Google indexes the mobile version of your site, full stop — and most of your readers are holding phones. If your pages pinch-zoom, stutter, or hide buttons under thumbs, you’re losing rankings and readers at the same time. This checklist walks through responsive basics, tap targets, and phone-speed fixes in the order that pays off fastest.

Updated August 2026 · 14 min read

Last year I ran a mobile audit on a small recipe blog that had plateaued at around 12,000 visits a month. The content was genuinely good — better than half the sites outranking it. But on a phone, the ingredient list sat in a two-column layout that required pinch-zooming, the “Jump to Recipe” button was 20 pixels tall and flush against an affiliate disclosure link, and the hero photo was a 2.4 MB JPEG that took six seconds to paint on cellular. We changed nothing about the writing. Three months after fixing the mobile experience, the same posts were up 40% in organic traffic. The content didn’t get better. It just became readable where readers actually were.

That’s the whole argument for mobile SEO in one story. This isn’t a niche sub-discipline anymore — since Google completed its switch to mobile-first indexing, the phone version of your site is your site as far as rankings are concerned. What follows is the checklist I run on every site I touch, ordered so the high-impact, low-effort fixes come first.

Why Mobile Is the Audit That Matters Most

Mobile-first indexing means Google crawls and indexes your site with a smartphone user-agent, and whatever that crawler sees — or fails to see — is what determines your rankings, even for people searching on desktop. If your mobile template hides a paragraph, a table, or a block of internal links that your desktop version shows, Google may never index that content at all.

The user side is just as blunt. Depending on the niche, 55 to 75 percent of organic visits to content sites arrive on phones, and how-to queries skew even higher because people search the moment the problem appears — standing in a hardware store aisle, lying in bed. A reader on a laptop will tolerate a slightly awkward layout. A reader on a phone hits the back button in four seconds and picks the next result. That pogo-stick behavior is a ranking problem disguised as a design problem.

Google’s own SEO starter guide treats mobile-friendliness as table stakes rather than an advanced optimization. Treat it the same way: this checklist isn’t polish, it’s plumbing.

Step One: The Five-Minute Reality Check

Before you touch a line of CSS, do the embarrassingly simple thing most site owners skip: open your five most important pages on an actual phone. Not a browser’s device emulator — a real phone, on cellular, not your office Wi-Fi.

Here’s what I look for in those five minutes:

• Pinch test. If I have to pinch-zoom to read body text, the viewport or font sizing is broken. Automatic fail.
• Thumb test. Can I reach the main navigation, the search icon, and the primary button with my right thumb while holding the phone one-handed? If I’m stretching or using a second hand, the layout is desktop-first.
• Load feel. Time from tap to readable content. Over about three seconds on LTE and real readers are leaving, whatever the lab tools say.
• Horizontal scroll. Swipe left and right. If the page wobbles sideways, some element — usually a table, an embedded video, or a fixed-width image — is overflowing the viewport.
• Tap accuracy. Try tapping the smallest link on the page, fast, like a distracted person would. If I hit the neighboring link twice in a row, the tap targets are too tight.

Write down every failure. This list, not an automated score, is your real audit. Then confirm it with data: in Google Search Console, the Core Web Vitals report splits mobile and desktop, and the mobile numbers are the ones that count. If you haven’t set that up yet, our Search Console walkthrough covers the basics in about twenty minutes.

Responsive Basics That Actually Break Sites

Responsive design has been standard advice for over a decade, so it’s tempting to assume your theme handles it. In practice, three specific things break on otherwise “responsive” sites.

The viewport meta tag

Every page needs <meta name="viewport" content="width=device-width, initial-scale=1"> in the head. Without it, mobile browsers render the page at a desktop width (usually 980 CSS pixels) and zoom out, which is why text looks microscopic. Most themes include this, but I’ve seen it stripped by caching plugins, missing from custom page templates, and duplicated with conflicting values. View-source on your phone-rendered page and check it’s there, once, with sane values. The mechanics are documented in MDN’s viewport meta reference if you want the details.

Fixed-width elements that overflow

A fluid grid doesn’t help if one element inside it has a hard pixel width. The usual suspects: tables with six columns, embedded iframes (YouTube, forms, maps), images with an inline width="900", and ad units. The fix is almost always one CSS rule — max-width: 100%; height: auto; for images and media, and a horizontal scroll wrapper for genuinely wide tables. If the page passes your swipe test from step one, you’re clean here.

Hover-only interactions

Dropdown menus that open on hover, tooltips that reveal critical information, image captions that only appear when a mouse moves over them — none of these exist on a touchscreen. Any navigation or content that depends on hover needs a tap equivalent. This one is sneaky because it never shows up in automated tools; you only catch it by tapping around on a real device.

Mobile-first indexing means the phone version of your page isn’t a special edition. It’s the only edition Google reads.

Tap Targets: The Most Ignored Ranking-Adjacent Fix

A tap target is anything a finger is supposed to hit: links, buttons, menu items, form fields, checkboxes. Get the sizing wrong and two bad things happen — users mis-tap and bounce, and Search Console flags “Clickable elements too close together” in the Page Experience report.

The working standard is simple. Apple recommends 44 × 44 points; Google’s material guidelines say 48 × 48 density-independent pixels; WCAG 2.2 requires a minimum of 24 × 24 CSS pixels as an absolute floor. In practice, I aim for 44 pixels minimum with at least 8 pixels of space between adjacent targets. On a typical phone, 44 pixels is roughly the size of a fingertip — which is exactly the point.

Where sites fail most often:

• Inline links in dense text. A link at the end of every line of a paragraph is fine on desktop and a mis-tap machine on mobile. Space them out or convert dense link lists into a proper list with padded <li> elements.
• Footer and sidebar link lists. Font-size 12px, line-height 1.2, stacked links — classic offenders. Bump line-height to at least 1.6 or add vertical padding.
• Icon-only buttons. A 16-pixel hamburger icon is not a 16-pixel tap target. Wrap it in a button with padding so the tappable area is 44 pixels even if the glyph is small.
• Pagination “1 2 3 … 47”. Tiny digits, zero spacing. Either enlarge them or replace with big “Previous / Next” buttons, which are also better for readers.
• Cookie banners and sticky bars. The “Accept” button is frequently half-covered by a sticky header on small screens. Test the banner itself on a phone.

Readability: Fonts, Contrast, and Line Length on Small Screens

Nobody links to a page they couldn’t stand to read. Hard-to-read pages get shorter dwell time, fewer shares, and more back-button exits.

The baseline rules I enforce: body text at 16 pixels minimum (never 14, and 15 is a gray area), line-height between 1.5 and 1.8, and line length around 50 to 70 characters. On a phone that last one mostly takes care of itself, but on tablets in landscape it doesn’t — cap your content column with a max-width rather than letting paragraphs stretch across the full screen.

Contrast is the silent killer. Light gray text (say, #999 on white) looks elegant on a desktop monitor and is genuinely unreadable on a phone in sunlight. Aim for a contrast ratio of at least 4.5:1 for body text, which in practice means copy darker than #767676 on white. Check your link color too: if links are distinguished only by a subtle color shift, mobile readers can’t find them. Underlines are unfashionable and effective.

One more trap: text inside images. If your headings, comparison charts, or coupon codes are baked into graphics, they’re unreadable on a 375-pixel-wide screen and invisible to Google. Real text always wins. (The same principle applies to the images themselves — our guide to image SEO covers sizing, formats, and alt text in detail.)

Speed on Phones: What Actually Slows You Down

Desktop speed problems and mobile speed problems are different animals. A phone on LTE deals with higher latency per request, a weaker CPU for parsing JavaScript, and a smaller memory budget. A page that feels snappy on your MacBook can be genuinely sluggish on a three-year-old Android.

When I profile slow mobile pages, the same four causes account for nearly everything:

1. Oversized images. The single most common offender. A 1200-pixel-wide photo exported straight from a camera is often 1.5 to 3 MB; the same image resized to 800 pixels, compressed, and served as WebP is 60 to 120 KB. Multiply by six images per article and you’ve cut load time in half with one afternoon of work. Use responsive srcset markup so phones don’t download desktop-sized files.

2. JavaScript bloat. Every slider, pop-up plugin, social widget, and animation library ships JavaScript that the phone’s CPU has to parse before the page becomes interactive. I regularly see small blogs pushing 1 MB or more of scripts. Audit ruthlessly: if a plugin’s feature isn’t earning its keep, remove it. Defer everything non-critical.

3. Web fonts. Three custom font families in four weights each can add 300 KB and, worse, block text rendering while they download. Use one or two families, subset them, and set font-display: swap so text appears immediately in a fallback font.

4. Render-blocking third parties. Ad scripts, chat widgets, heatmap tools, and A/B testing tags that load synchronously in the head. Everything third-party should load async or after the main content. If a script must block rendering, ask whether it must exist at all.

None of this requires guessing. Run your key templates through PageSpeed Insights on the mobile tab, and treat the lab data as a map to the biggest item, not a score to obsess over. For the fix-by-fix details, our Core Web Vitals fix guide goes deeper on each metric.

Core Web Vitals Through a Mobile Lens

Google’s Core Web Vitals — LCP (Largest Contentful Paint), INP (Interaction to Next Paint), and CLS (Cumulative Layout Shift) — are measured on real users’ devices, and the mobile thresholds are where most sites fail. The targets haven’t changed: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1, each at the 75th percentile of your actual visitors. Google documents how these feed into search on its Core Web Vitals and Search page.

On mobile specifically, the three metrics tend to trace back to predictable causes:

• Slow LCP → hero image or server response. The largest element is almost always the top image or heading block. Compress it, preload it, and stop lazy-loading the above-the-fold image (lazy-loading should start below the fold).
• Bad INP → heavy JavaScript on tap. If menus or buttons feel laggy on a phone, long JavaScript tasks are blocking the main thread. Split or defer the scripts; remove the page-builder effects you forgot you installed.
• High CLS → things jumping as they load. Ads, embeds, and images without declared dimensions push text around while the reader is mid-sentence. Always set width and height (or aspect-ratio) on images and reserve fixed space for ad slots and embeds.

One realistic expectation: vitals are a modest ranking signal, not a magic lever. Fixing them removes a drag on rankings and makes the site feel instant to humans. Chase green field data for your real visitors, not a perfect 100 in lab tools.

Pop-Ups and Interstitials: Know Where the Line Is

Intrusive interstitials on mobile have been explicitly discouraged by Google since 2017, and the policy hasn’t loosened. A full-screen newsletter pop-up that covers the content the moment someone arrives from search is the canonical violation — it can earn a ranking penalty and, in my experience, converts terribly on phones anyway because the close button is a 12-pixel ×.

Generally acceptable: slim banners that use a small fraction of the screen, legally required notices like cookie consent and age verification, and paywall or login dialogs on gated content. Risky: anything blocking the main content on arrival, pop-ups that are hard to dismiss on a small screen, and stacked sequences (cookie banner, then newsletter modal, then app-install prompt — yes, real sites do this).

The mobile-safe pattern I recommend: delay any promotional overlay until the reader has engaged — scrolled 50 percent, spent 45 seconds, or reached the end of the article — and make it a dismissible banner rather than a full-screen takeover. You’ll keep the conversions that matter and lose the penalty risk.

Content Parity and the Mobile Crawl

This is the technical item most checklists skip, and the one that can quietly cost you the most. Because Google indexes the mobile version, anything missing from your mobile rendering is missing from your rankings. Verify parity in four places:

Main content. Some themes “simplify” mobile by hiding sidebars — fine — but occasionally they also hide author bios, related-posts blocks, or even parts of the article inside collapsed sections. Content in accordions and tabs is indexed, but content absent from mobile HTML is not. Compare the mobile and desktop source of a key page and confirm the substance matches.

Internal links. If your desktop sidebar carries contextual links and your mobile template drops that block entirely, you’ve weakened your internal linking for the only version Google reads. Move important links into the article body where they belong.

Structured data. Your JSON-LD schema must be present in the mobile HTML too. If you use a plugin or template that injects schema only in the desktop view, rich results will silently disappear. Test a mobile-rendered URL in the Rich Results Test, which uses the smartphone crawler by default.

Metadata and robots rules. Titles, meta descriptions, canonical tags, and robots directives should be identical across versions. A stray noindex in a mobile-only template is rare but catastrophic — I’ve seen exactly one, and it took the site three months to recover.

The Full Mobile SEO Checklist

Everything above, condensed into the list I actually work through. Run it per template (home, article, category, landing page), not just per site — one broken template is enough.

• Viewport tag present. One meta viewport tag with width=device-width on every template.
• No horizontal scroll. Swipe test passes; no fixed-width images, tables, or embeds overflow.
• Base font ≥ 16px. Body text readable without zoom; line-height 1.5–1.8; contrast ≥ 4.5:1.
• Tap targets ≥ 44px. Buttons, menu items, and links padded with 8px+ separation; no mis-taps in real use.
• No hover-only content. Every menu, tooltip, and caption reachable by tap.
• Hero image optimized. Above-the-fold image compressed, modern format, not lazy-loaded; total image weight per page under ~400 KB where possible.
• JavaScript dieted. Non-critical scripts deferred; page interactive quickly on a mid-range phone over LTE.
• Vitals green on mobile field data. LCP < 2.5s, INP < 200ms, CLS < 0.1 at the 75th percentile.
• No intrusive interstitials. Promos are delayed, dismissible banners; only legal notices may block content.
• Content parity confirmed. Mobile HTML carries the full article, internal links, schema, and metadata.
• Search Console clean. No mobile usability errors, no “clickable elements too close together,” vitals report trending green.
• Real-device spot check. A human tapped through the five most important pages on an actual phone this quarter.

Putting It in Order: What to Fix First

If your audit turned up a long list, don’t try to fix everything in one weekend. The order that pays back fastest, based on what I’ve seen move traffic on real sites: first, anything that breaks reading entirely — viewport issues, microscopic fonts, horizontal scroll — because those drive instant bounces. Second, the hero image and the worst JavaScript, because speed affects every visitor on every page. Third, tap targets and interstitials, usually a few hours of CSS. Fourth, the parity and structured-data checks, which are verification rather than renovation.

Then set a reminder. Mobile templates drift — a plugin update adds a pop-up, a new embed overflows, a theme update shrinks your buttons. A fifteen-minute phone walk-through once a quarter catches the rot before Search Console does. The sites that win on mobile aren’t the ones that fixed it once; they’re the ones that treat the phone as the primary screen and the desktop as the edge case. For your readers, it already is.

Sources: Google Search Central documentation on mobile-first indexing, the SEO starter guide, and Core Web Vitals (developers.google.com/search); MDN Web Docs on the viewport meta tag. Targets cited — 44px tap targets, 2.5s LCP, 200ms INP, 0.1 CLS — reflect platform and Google guidance current as of August 2026. Re-test quarterly; template updates are where mobile regressions hide.