Mobile SEO: How Google's Smartphone Crawler Reads Your Site, and the Gaps That Cost Rankings

Google reviews your site on a phone, and has for years

Google calls it mobile-first indexing: it uses the mobile version of a page, crawled with its smartphone agent, for indexing and ranking. The project began in 2016. On October 31, 2023, Google's Search Central blog announced the move was complete for every site that works on a phone. A June 2024 post set the last date: after July 5, 2024, even the few holdouts would be crawled with mobile Googlebot.

The same post carries the sentence every owner of an old site should read twice: if a site's content "is not accessible at all with a mobile device, it will no longer be indexable." Note the wording. A plain desktop layout that still loads on a phone is not thrown out. Google's mobile-first indexing documentation says a mobile version is not required to appear in results, and in the next breath calls one "very strongly recommended."

So mobile SEO is no longer a separate discipline with its own checklist and its own invoice. It is ordinary SEO, performed on the version of the site most owners look at least. Our technical SEO guide covers the crawl and index basics; this page covers what changes when the reader holds a phone.

Content parity: what a trimmed phone template quietly deletes

Google's documentation is direct: the mobile site should contain the same content as the desktop site, because indexing comes from the mobile version. If the phone version carries less on purpose, Google warns of possible traffic loss. Design can differ. Accordions and tabs are acceptable as long as the content inside them is equivalent. What fails is content that does not exist in the phone version at all, or that loads only when someone swipes, clicks or types, which Google says it will not do.

Links belong on the same list as a matter of practice. A desktop mega menu with forty service links that collapses to six on a phone has removed thirty-four paths Google could have followed. Check the phone menu and footer against the desktop ones. For pictures, our image SEO guide covers alt text and formats, and schema markup covers the structured data that must travel with the page.

Responsive, dynamic serving or an m-dot site: Google has a favorite

There are three ways to serve phones, and Google's documentation names all three. Responsive design sends the same HTML at the same URL to every device and lets the layout adapt. Dynamic serving keeps one URL but sends different HTML depending on the device, which requires a Vary: user-agent header. Separate URLs put the phone version at its own address, usually m.example.com. Google's verdict: "Google recommends Responsive Web Design because it's the easiest design pattern to implement and maintain."

With a responsive site, parity is automatic: the content and metadata are the same because there is only one copy. That is the real SEO argument, more than any ranking bonus. The design case for responsive layouts is already made in our guide to making a website mobile friendly, and the mechanism is explained in what responsive design is.

If you still run an m-dot site

• Point the mobile page's rel="canonical" to the desktop URL, and add a rel="alternate" link from desktop to mobile with a media attribute, as Google's documentation shows. Our canonical tags guide explains the signals.
• Give every desktop page an equivalent mobile page. Redirecting many desktop URLs to the mobile home page drops them all from the index.
• Return the same status on both. A desktop page that loads while its mobile twin errors will be missing from Google.
• Keep fragments (#) out of mobile URLs, use the same robots.txt rules, and make hreflang point mobile to mobile and desktop to desktop.
• Verify both versions in Search Console, and make sure the mobile host can handle a higher crawl rate.

Every item on that list is a way to break SEO that a responsive site cannot suffer. When we find an m-dot site still running, retiring it with proper redirects is usually cheaper than maintaining it for another year.

Pop-ups, ad stacks and the first screen Googlebot sees

Google's page on intrusive interstitials defines them as elements that "obstruct users' view of the content, usually for promotional purposes." It asks sites not to cover the entire page and not to redirect visitors to a separate page for consent or input. The stated risk is concrete: intrusive dialogs make content hard for search engines to understand, "which may lead to poor search performance." Google's page experience self-assessment asks the same question in plain words: do your pages avoid intrusive interstitials?

The mobile-first documentation adds that sites should follow the Better Ads Standards on phones, noting that ads at the top of a page can take too much room on a small screen. The Coalition for Better Ads lists mobile pop-up ads, prestitial ads, ad density above 30%, auto-playing video with sound, full-screen scrollover ads and large sticky ads among the experiences that fall short. A local business rarely runs display ads, but its chat widget, cookie banner and promo bar can stack up the same way.

Tap targets and type: the report Google retired, the question it kept

Owners still ask us to "run the mobile-friendly test." It is gone. Google retired the Mobile-Friendly Test and the Search Console Mobile Usability report on December 1, 2023. Plenty of SEO checklists still tell readers to open a report that no longer exists, which is a fair test of when the checklist was last read by anyone.

Retiring the report did not retire the question. Google's page experience guidance still asks whether your content displays well on mobile devices, and says Chrome's Lighthouse can identify improvements, including mobile usability. It is also careful about weight: Core Web Vitals are the part of page experience it says ranking systems use, and the other aspects do not directly lift rankings, though they make a site more satisfying to use. Read that as: a cramped phone layout costs you callers first and rankings second.

• Viewport. One meta tag tells the phone to render at its own width. Without it, the page arrives as a shrunken desktop. Our meta tags guide shows the line.
• Tap targets. Google's web.dev guidance suggests touch targets of around 48 device-independent pixels, spaced about 8 pixels apart. Its article dates from 2020, and the number still matches how thumbs work.
• Readable text. If a visitor has to pinch to read a price, the page fails the page experience question whatever its rankings say.
• Content that fits. Nothing should scroll sideways. A wide pricing table belongs in a scrolling container or stacked into cards.

Font sizes, button placement, the call bar and forms that a thumb can fill are design work, and our guide to mobile website design best practices covers them in full. The SEO point is shorter: Google wants to send searchers to pages they can use, and it now checks on a phone.

Speed on a phone is scored separately from speed on a desk

The Core Web Vitals report in Search Console splits every result into mobile and desktop, each with its own status. It draws on real visits from Chrome users over the last 28 days, groups similar pages together, and rates a group by its worst metric, so good loading with a jumpy layout still reads Poor. New or low-traffic sites may see "No data available" because there are not enough real visits to measure.

That split matters because phones are where sites fail. A page that scores well on office broadband can stall on a mid-range phone over a cellular connection, with less processing power to run the same scripts. Google says Core Web Vitals are used by its ranking systems and that good scores do not guarantee top rankings. The thresholds for LCP, INP and CLS are in our technical SEO guide, and the methods for meeting them are in how to improve Core Web Vitals.

Images and third-party scripts are the usual weight. If the fix list runs past what a plugin can do, our site speed and Core Web Vitals work takes it on, and the page speed statistics page collects the published research on what slow pages cost.

The one-hour mobile SEO audit, using only free tools

You need a verified Google Search Console property, a desktop browser, your own phone and an hour. Pick five pages: the home page, your two best service or product pages, a location page and the contact page.

1. 1

   Ask Google how it crawled the page

   Run each URL through URL Inspection. The crawl details show whether Google crawled it as a smartphone or a desktop. For a site that works on phones, expect smartphone.

2. 2

   Look at what Googlebot rendered

   Run a live test, then view the tested page. Check the screenshot and the HTML for your key paragraphs, prices, reviews and service areas. Anything missing there is missing from Google.

3. 3

   Compare the two versions side by side

   Open the page on a desktop and on your phone. List every section, link and image the phone version lacks or hides behind an interaction. That list is your parity backlog.

4. 4

   Check the head on both

   View source on each version and confirm the title, description, canonical and robots tags match. A noindex on one version only is an emergency.

5. 5

   Open Core Web Vitals, mobile tab

   Note which URL groups are Poor or Need improvement and which metric drags each one down.

6. 6

   Split Performance by device

   In the Performance report, open the Devices tab and compare clicks, CTR and average position for mobile against desktop. A large gap on the same pages is a clue worth chasing.

7. 7

   Walk it like a customer

   Wi-Fi off, one thumb. Close every pop-up you meet and count the taps it took. Tap the phone number and the main button.

If the device split shows phones clicking far less than desktops on the same queries, our guide to click-through rate explains how to read that number and what changes it. If the rendered HTML is missing text that appears in your browser, the problem is scripts, and JavaScript SEO is the next read.

When the phone version needs a template, not a tweak

Most of what this audit finds falls into two piles. The first is fixable in place: a missing viewport tag, a pop-up plugin to switch off, alt text to copy across, a robots tag to correct, a reviews widget to render on load. The second is structural: an m-dot site, a theme that builds a separate, thinner phone layout, or a fixed-width design that no amount of CSS will rescue. The first pile is an afternoon. The second is a rebuild, and it is cheaper to admit that early.

For the first pile, mobile responsive fixes are quoted as fixed-price repairs, and the free site audit checks mobile, speed signals, SEO, security and content and emails a report listing what to fix. For the second, every site DataCram builds is responsive by construction: one URL, one copy of the content, the same HTML on every screen, rendered on the server so the text is there before any script runs. Custom builds start at $1,750, and the free mockup shows your home page designed for a phone before you commit to anything.

Mobile work is also part of every DataCram SEO program, because there is no longer any other kind of SEO to do. For the full map of where mobile fits beside titles, links and content, start at the SEO guide, and for how much of search now happens on a phone, see our mobile statistics.