Chapter 17: Mobile SEO — Mobile-First Indexing, Responsive Design, and the Reality That Most Search Happens on Phones

"Your customer is standing in a cold basement at nine at night, staring at a furnace that won't light, holding the only computer they own in one hand. That is not an edge case. That is the search." — [constructed teaching line]

Overview

Here is a question that quietly decides whether a great deal of technical SEO effort pays off or is wasted: when Google reads your site, which version of it is Google actually reading? Most site owners have never asked. They built the site on a laptop, they review it on a laptop, and they assume Google sees the same thing they do. It does not. Google has looked at your site, for years now, as a phone.

This is not a stylistic preference on Google's part. It is a response to where search actually happens. Google publicly reported back in 2015 that mobile searches had surpassed desktop searches in the United States and several other countries — and the mobile share has only grown since. For whole categories of query, and above all for the local, urgent, "I need this fixed now" searches that a home-services company lives on, the searcher is not at a desk. They are in a driveway, a basement, a parking lot, a hallway with a flooded floor, tapping a small glowing rectangle with a cold thumb. If your page makes that person pinch-to-zoom, hunt for a phone number they cannot tap, or wait eight seconds on a weak signal, you have lost them — and you have lost them to whoever's page was built for the device they were actually holding.

So this chapter is about two linked realities. The first is technical: mobile-first indexing, Google's policy of crawling, indexing, and ranking the mobile version of your pages. If content is missing from your mobile version, it is, for ranking purposes, missing from the web. The second is human: the phone is a small screen held by a distracted, hurried, thumb-driven person, and a page that ignores that fact converts poorly no matter how it ranks. The good news is that these two problems have largely the same solution, and it is not exotic. It is a well-built responsive site with nothing hidden, tappable targets, legible text, no pop-up ambushes, decent speed, and — for a local business — a phone number a person can call with one tap. We advance two of the book's themes here at once: theme 4 (technical SEO is the foundation the rest builds on) and theme 2 (intent is everything — and mobile intent has a texture of its own).

In this chapter, you will learn to:

• Explain mobile-first indexing precisely, and why "there are two indexes" is a myth.
• Choose the right mobile configuration and say why responsive design is the safe default.
• Hunt down content-parity gaps between your desktop and mobile versions.
• Fix the core mobile-usability problems with free tools — and know which Google tools no longer exist.
• Make a phone number tappable, and understand why that one change can matter more than anything else on the page for a local business.
• Judge AMP (Accelerated Mobile Pages) for what it now is: a faded requirement, not a live necessity.

Learning Paths

This chapter is close to the center of gravity for the 🏪 Local Business track — §17.6 (local + mobile, click-to-call) is written for you, and parity plus tap targets are where your leads leak away. 📝 Content Creator: weight §17.3 (don't hide your article's content on mobile) and §17.4 (readable text, tappable in-article links). 🛒 E-Commerce: §17.4 (tap targets and interstitials on product pages) and §17.5 (mobile speed on catalog pages) are your money sections; a mistimed pop-up on mobile is a conversion and a ranking problem. 🔧 Developer: §17.2 (responsive vs. dynamic serving vs. separate URLs), §17.3 (implementing parity), and the viewport mechanics in §17.4 are your chapter within the chapter. 📊 Strategist: internalize §17.1 (what mobile-first indexing changes about how you think) and the AMP decision in §17.7 — knowing when not to adopt a Google-specific technology is a senior judgment.

17.1 Mobile-first indexing: what it really means

Let us define the term carefully, because it is one of the most misunderstood phrases in SEO, and half the confusion comes from people guessing at it from the name.

Mobile-first indexing means that Google predominantly uses the mobile version of a page's content for indexing and ranking. When Googlebot comes to crawl your site, it comes primarily as Googlebot Smartphone — a crawler that identifies itself as a mobile device and fetches the page the way a phone would. Whatever Google finds in that mobile fetch is what goes into the index. Whatever it doesn't find there — content, images, structured data, links — is at risk of never being counted at all.

Read that twice, because the practical consequence is severe and non-obvious. It is not that Google gives mobile pages a bonus. It is that the mobile version has become the source of record. Your desktop site could be a masterpiece; if your mobile version is a stripped-down shadow of it, Google is largely blind to the difference between them — it is looking at the shadow.

🔎 How Search Sees It There is exactly one index. Picture Google's index as a single vast library, and picture the smartphone-Googlebot as the only librarian still filing new books. When it fetches your page, it does so from a data center, declaring a mobile user-agent, and it renders the page at a phone-sized viewport — running your JavaScript and applying your CSS as a mobile browser would (rendering itself works the same way we described in Chapter 1; the difference is the device profile). The finished mobile page is what gets read, understood, and stored. So the operative question for every page you own is brutally simple: load it on a real phone. Is everything that matters actually there? If a paragraph, a review star, a LocalBusiness block, or a set of internal links appears on your desktop layout but not on your phone, Google is filing the version without them.

Some history, honestly told, because the timeline is often mangled. Google announced it was experimenting with mobile-first indexing in 2016, began rolling it out to sites gradually from 2018, and by late 2023 stated that the migration was effectively complete for the entire web — at which point it retired the public timeline and the "which sites are still on desktop" tracking altogether. A tiny number of sites that genuinely do not work on mobile at all may still be crawled by the desktop crawler as a fallback, but for practical purposes, assume your site is mobile-first indexed. It is. This is not a change coming someday. It happened, and you are living in the world after it.

🚫 SEO Myth: "There's a separate mobile index, and a separate mobile ranking I optimize on its own." No. There is one index and one core ranking system. Mobile-first indexing describes which version of your page Google reads to build that single index — the mobile one — not a parallel universe with its own rules. Two related confusions travel with this myth. The first: "so desktop doesn't matter anymore." Desktop matters enormously to the humans who use it; it is simply no longer the version Google indexes from. The second: "mobile-first means being mobile-friendly is now a giant ranking boost." It is not a giant boost. Mobile-friendliness is a real but modest page-experience consideration (it rides alongside Core Web Vitals, which we weighed honestly in Chapter 16). What mobile-first indexing changes is more fundamental and less glamorous than a ranking lever: it changes what content Google can see in the first place. A page cannot rank on content Google never indexed because that content lived only on the desktop layout.

That distinction — between a ranking factor and a visibility prerequisite — is worth holding onto. Most of this chapter is not about earning a boost. It is about not accidentally hiding your own content from the search engine, and not repelling the human once they arrive.

⚖️ Evidence Check Claim: "Google indexes the mobile version of your site." Where does this sit? — Confirmed by Google: This is Tier-1, straight from Google's own documentation and repeated public statements about mobile-first indexing. Googlebot Smartphone as the primary crawler is confirmed. This is as solid as SEO facts get. — The honest caveats: (1) "Predominantly" is Google's own hedge — it uses the mobile version as the basis, but this does not mean desktop content is actively penalized or ignored in every conceivable case; it means you cannot rely on desktop-only content being seen. (2) Mobile-first indexing being confirmed tells you nothing about how much any given mobile-usability signal moves rankings — that is a separate, murkier question we treat with the same skepticism we brought to Core Web Vitals. Confirmed that Google reads the mobile version; unconfirmed and probably modest how much "mobile-friendliness" as a signal reranks results. Hold both.

17.2 Responsive vs. separate mobile: why responsive wins

If the mobile version is what Google reads, the next question is architectural: how should you produce a mobile version at all? Historically, Google documented three ways a site can serve mobile users, and the choice among them has real SEO consequences.

FIGURE 17.1 — THREE WAYS TO SERVE A PHONE                    [schematic — not to scale]

  (1) RESPONSIVE DESIGN            (2) DYNAMIC SERVING           (3) SEPARATE URLs
      one URL, one HTML                one URL, two HTMLs             two URLs
      CSS adapts to screen             server sniffs the device       desktop + m-dot

   example.com/heater              example.com/heater            example.com/heater
        │                               │                          │        │
   ┌────┴────┐                     server checks                 desktop   redirect
   │ same    │                     user-agent, sends…            HTML      to…
   │ HTML;   │                      ┌──────────┴──────────┐                 │
   │ layout  │                   desktop HTML         mobile HTML     m.example.com/heater
   │ reflows │                   (to laptops)         (to phones)          (separate mobile HTML)
   └─────────┘
     ✅ Google's recommended default    ⚠️ workable, error-prone     ⚠️ legacy, parity-prone

Responsive design is a single set of pages — one URL, one HTML document per page — whose layout reflows to fit any screen using flexible CSS (Cascading Style Sheets, the language that controls a page's presentation). The phone and the laptop request the identical file; the page simply rearranges itself. Dynamic serving uses one URL but has the server detect the visitor's device and send different HTML to phones and to laptops. Separate URLs — the classic "m-dot" pattern, m.example.com — keeps an entirely separate mobile site at its own addresses, with desktop visitors redirected to the desktop version and mobile visitors to the mobile one.

Google's recommendation, stated plainly and for years, is responsive design. Here is why it wins, and — because every tactic in this book states its limits — where it does not save you.

Read the "parity risk" row as the heart of the matter. With responsive design, the mobile and desktop versions cannot fall out of sync on content, because there is only one HTML document — the very structure that mobile-first indexing rewards. With separate URLs, you are maintaining two websites that must be kept perfectly aligned forever, and in the real world they never are: someone updates a service description on the desktop site and forgets the m-dot, an editor adds a schema block to one and not the other, and slowly the mobile version — the version Google indexes — becomes the thinner, staler, less complete twin. That is why the industry has spent a decade migrating off m-dot sites and onto responsive ones, and why new sites almost never choose separate URLs.

🔗 Connection What responsive design can and cannot do. It can guarantee content parity for free and consolidate all your signals on one URL — a large, permanent win. It cannot, by itself, make your site fast (a responsive page can still be heavy and slow — that is Core Web Vitals, Chapter 16), and it cannot by itself make your site usable on a phone (you can be perfectly responsive and still have tap targets a thumb can't hit — that is §17.4). Responsive is the foundation, not the finish. And if you are on a legacy m-dot site today, moving to responsive is a site migration — the redirect discipline and monitoring of Chapter 21 apply in full; a botched m-dot-to-responsive move can lose traffic exactly like any other migration.

For our running project, this is one of the "problems you don't have" moments worth naming early. Rivertown's site runs on WordPress with a modern-ish theme, which means it is already responsive — one URL per page, layout reflowing on phones. That spares the team the entire m-dot migration headache. Their mobile problem is not architecture; it is everything that responsive design does not automatically fix — parity of what's shown, tap targets, an ambush pop-up, speed, and a phone number nobody can tap. Knowing that the architecture is sound tells you exactly where not to spend money, which is half of strategy.

17.3 Content parity: don't hide content on mobile

Content parity is the principle that your mobile version should contain the same primary content, and the same machine-readable signals, as your desktop version. Under mobile-first indexing it stops being a nicety and becomes a rule with teeth: if it isn't in the mobile version, Google may not index it, and you cannot rank on what isn't indexed.

The classic parity failures come in two flavors, and it is important to keep them separate because one is a real problem and the other is a myth that panics people needlessly.

The real failure is content that is genuinely absent from the mobile HTML. This happens most on separate m-dot sites and on older "adaptive" themes that shipped a deliberately trimmed mobile experience — the desktop page has a 1,500-word buying guide, a specifications table, a set of customer reviews, and a LocalBusiness schema block, and the mobile page, to "keep it clean," drops half of them. Every dropped element is invisible to the version Google indexes. The reviews you're proud of, the FAQ that earns a rich result, the internal links that pass authority to your other pages — if they live only on desktop, they are contributing nothing to your search visibility.

Google's own guidance for mobile-first indexing is a parity checklist, and it is worth carrying in your head as one:

Notice how many later chapters that table touches. Parity is not a topic beside the rest of technical SEO; it is the condition under which the rest of technical SEO counts. Your beautiful schema (Chapter 18) does nothing if it's desktop-only. Your careful internal linking (Chapter 15) passes no authority if those links only render on the laptop layout.

📄 Read the Report

text FIGURE 17.2 — "The mobile version is the thin version" [constructed teaching example] THE QUERY / PAGE A mid-size retailer's product page, compared desktop vs. mobile via each version's rendered HTML (View Source on desktop; URL Inspection's rendered HTML for the smartphone crawl). WHAT'S THERE Desktop: 1,400 words of description + specs, 38 customer reviews rendered in the HTML, Product + Review + FAQ schema, 12 internal links to related items. Mobile: 300-word description, reviews loaded only after a tap on "See reviews" that fetches them via JavaScript, Product schema only, 3 internal links. WHAT IT SHOWS The indexed (mobile) version is dramatically thinner: ~1,100 words, 35 reviews, the Review + FAQ schema, and 9 internal links are effectively absent from what Google reads. The page is competing on a fraction of its real substance. WHAT IT DOESN'T It doesn't prove the page would rank higher with parity restored — competitors and intent still decide that. It shows a self-inflicted handicap, not a promise. THE MOVE Make the mobile HTML carry the full description, the reviews, all the schema, and the internal links — present in the HTML, even if visually collapsed. Then re-inspect to confirm Google now sees them. THE LESSON Parity first, optimization second. You cannot out-optimize content the indexed version doesn't contain.

Now the myth, because it is the mirror image and it makes people do the wrong thing.

⚖️ Evidence Check Claim: "Content hidden behind tabs, accordions, or 'read more' expanders is penalized or discounted on mobile, so I must show everything expanded." This was once partly true and is now wrong — a perfect example of advice that outlived its facts. — The old world: Years ago, before mobile-first indexing, Google's representatives indicated that content hidden by default (in tabs or accordions) could be given less weight than visible content, on the reasoning that hidden content was less important to users. — What Google has since said (confirmed): Under mobile-first indexing, Google treats content that is in the HTML but visually collapsed behind tabs or accordions as fully indexed and normally weighted. The reasoning flipped with the device: on a phone, collapsing content into expanders is good, responsible UX — nobody wants an endless wall of text on a small screen — so Google does not punish it. The key word is in the HTML. Content that is present in the mobile HTML and merely hidden by CSS until tapped is fine. Content that is not in the HTML at all until a tap triggers a JavaScript fetch (as with the reviews in Figure 17.2) is the genuine risk. — The practical rule: Collapse for readability all you like. Just make sure the collapsed content actually ships in the mobile HTML, not fetched-on-demand. When in doubt, inspect the rendered HTML (Chapter 27's URL Inspection tool) and search it for the text you expect.

That one distinction — is the content in the HTML, or only fetched after a tap? — separates a smart, phone-friendly design from a self-inflicted parity wound, and it's the kind of thing worth being able to answer on reflex. Test yourself.

🔄 Check Your Understanding A developer says, "Our mobile page is clean — we tucked the long description and the reviews behind 'Show more' buttons so the page isn't cluttered." What is the one follow-up question that decides whether this is fine or a serious parity problem?

Answer

"Is that content in the mobile HTML from the start, or is it fetched by JavaScript only after the tap?" If the text ships in the HTML and is merely hidden by CSS until the tap, it's fine — Google indexes it at full weight on mobile. If the tap triggers a fresh JavaScript fetch and the content isn't in the HTML until then, Google may never see it, and you have a real parity problem. Same button, totally different SEO outcome — the difference is where the content lives, not whether it's visible by default.

17.4 Mobile UX: viewport, tap targets, text, and no ambushes

Parity gets your content indexed. Mobile user experience decides whether the human who arrives can actually use the page — and while the individual usability signals are modest ranking factors at most, they are enormous conversion factors, and a page people bounce off of in frustration is teaching Google something about its quality. Four things carry most of the weight.

The viewport. The single most important line of mobile HTML is the viewport meta tag — a tag that tells the browser how to size the page to the device's screen. It looks like this, and you should recognize it, not write it from scratch:

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

Here is what it does and why it matters. Without this tag, a mobile browser assumes the page was designed for a desktop and renders it at a wide desktop width, then shrinks the whole thing to fit the phone — leaving text microscopic and forcing the user to pinch-and-zoom to read anything. With it, the browser sizes the page to the device's actual width, so your responsive CSS can lay things out for a phone. A missing or misconfigured viewport tag is the most common single cause of a site being "not mobile-friendly," and on a WordPress site it is normally supplied by the theme — one more thing to confirm rather than assume.

FIGURE 17.3 — WHY THE VIEWPORT TAG EXISTS                    [schematic — not to scale]

  NO viewport tag                         WITH  width=device-width, initial-scale=1
  ┌───────────────┐                        ┌───────────────┐
  │ tiny  unreada │  ← desktop-width page   │  Readable     │  ← page sized to the phone;
  │ ble  text  sh │    crammed into the      │  text at a    │    responsive CSS lays it
  │ runk  to  fit │    phone; user must      │  normal size  │    out for the screen
  │ →pinch/zoom←  │    pinch-zoom to read    │  no zooming   │
  └───────────────┘                        └───────────────┘

Tap targets. A tap target is any element a user is meant to tap — a link, a button, a form field. On a mouse-driven desktop, a link can be tiny because a cursor is pixel-precise. A fingertip is not; it's a soft, roughly finger-width blob. When tap targets are too small or crowded too close together, users mis-tap: they hit the wrong link, they zoom by accident, they give up. Google's mobile guidance and the broader design consensus put a usable target at roughly 48 pixels in size with about 8 pixels of spacing between neighbors — enough that a thumb reliably hits what it aims at. Treat those as design guidance, not a precise ranking threshold; the point is that cramped, overlapping links are a real usability failure, most visible in navigation menus, "related links" clusters, and — critically for a local business — the phone number and the booking button.

Legible text. Body text should be readable without zooming — a base size in the neighborhood of 16 pixels is the common floor. Text that forces a pinch-to-zoom fails the same way a broken viewport does: it signals a page built for a screen the reader isn't using.

No intrusive interstitials. An interstitial is any overlay that comes between the visitor and the content — a pop-up, a modal, a full-screen promo, a "subscribe to our newsletter" or "download our app" takeover. Google announced, and since January 2017 has applied, a signal that can demote a page where an intrusive interstitial makes the main content hard to reach when a user arrives from search on mobile. The offenders are the aggressive ones: a pop-up that covers the main content immediately on arrival, a standalone full-screen unit the user must dismiss before reading, a layout that hides the content above the fold behind a promo. Reasonable, non-intrusive banners are fine, and — this matters — there are explicit exceptions for interstitials you are legally required to show (cookie-consent notices, age verification) and for login dialogs on genuinely gated, non-indexable content.

Here is the mobile-usability checklist in one place:

🛠️ Try It on Your Site Two free checks, five minutes. First, on a desktop browser, open one of your key pages, view the page source, and search it for viewport. If you don't find width=device-width, that's your highest-priority mobile fix. Second, open the page in Chrome, press F12 to open the developer tools, toggle the device-toolbar (the little phone/tablet icon) to view the page at a phone size, and run a Lighthouse report (the Lighthouse tab) with the "Mobile" device selected — it flags tiny tap targets, illegible font sizes, and viewport problems, and it's the same Lighthouse engine we met in Chapter 16. Poke your own navigation with the on-screen phone: can you hit the phone number and the menu items without missing?

You may notice a once-standard tool missing from that recommendation — the one every older tutorial tells you to use first. Its absence is not an oversight; it is the point.

⚖️ Evidence Check Claim: "I'll just run Google's Mobile-Friendly Test and the Mobile Usability report in Search Console." You'll be reaching for tools that no longer exist — and this is exactly the kind of stale advice this book exists to correct. — What happened (confirmed): In December 2023, Google retired the Mobile-Friendly Test tool, the Mobile-Friendly Test API, and the Mobile Usability report in Search Console. Google's stated reasoning was that being mobile-friendly is now table stakes — the tooling had aged, and "mobile usability" as a standalone report had outlived its usefulness now that essentially every site is mobile-first indexed. — What it does not mean: It does not mean mobile-friendliness stopped mattering to users, or that Google stopped reading the mobile version. It means Google stopped maintaining a dedicated report for it. — What to use instead (current): Lighthouse (in Chrome's developer tools) and Chrome's device-mode preview for the checks the old tool did; PageSpeed Insights (Chapter 16) for the speed side. The broader lesson is the durable one: SEO tooling changes under you constantly. Learn the underlying thing being measured — can a phone user read and use this page? — so you are never stranded when a specific tool disappears.

17.5 Mobile speed: the same vitals, on harder ground

We measured speed properly in Chapter 16 — Core Web Vitals (CWV): Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability, each with its "good" threshold, measured on real users (field data) and diagnosed in the lab. We will not re-teach any of that here. What this section adds is the reason mobile deserves its own paragraph in a speed conversation: the phone plays the same game on much harder ground.

Two forces make mobile the demanding case. First, networks: a phone may be on a strong home Wi-Fi connection or on a congested cellular signal in a parking garage, and you don't get to choose. Latency is higher and more variable than a wired desktop connection, so every extra kilobyte and every extra round-trip costs more — Time To First Byte (TTFB) and LCP both suffer on a weak signal. Second, processors: phone CPUs, especially mid-range and older ones, are weaker than laptop CPUs, so the JavaScript your page runs takes longer to execute on a phone — which is exactly why INP (a responsiveness metric driven heavily by main-thread work) tends to be worse on mobile than on desktop for the same page.

🔎 How Search Sees It This is why Google's field data leans mobile and why PageSpeed Insights reports mobile and desktop separately, with mobile almost always the worse — and more consequential — of the two. The Chrome User Experience Report (CrUX) that feeds the Core Web Vitals assessment is dominated by real mobile visits for most sites. So when you look at your numbers, the mobile column is not a pessimistic curiosity; it is the number closest to what Google is actually assessing. A page that scores well on desktop and poorly on mobile is, for ranking purposes, a page that scores poorly.

The discipline that follows is simple: judge your pages by their mobile numbers, not their flattering desktop ones. This chapter, though, is deliberately not where you fix those numbers — that machinery already has a home.

🔗 Connection The how of fixing all of this — right-sizing images (which overlaps Chapter 11's image work), deferring render-blocking resources, improving TTFB, reserving space to stop layout shift — lives in Chapter 16 (§16.6), and none of it changes on mobile; it just matters more. One continuity note for our project: the CWV measurement pass in Chapter 16 already put numbers on Rivertown's mobile pages — the homepage LCP around 4.1 seconds, the "AC repair" page near 4.8 seconds with an INP around 240 milliseconds and a CLS near 0.22, all worse than the good thresholds. Those are the pages a hurried, emergency searcher hits from a phone. This chapter doesn't re-fix them; it explains why, on a cold night on a weak signal, those seconds are the difference between a call and a bounce.

The honest weight, unchanged from Chapter 16: speed is a tiebreaker, a real but modest signal, not a magic ranking lever. A fast page that doesn't match intent still loses to a slower one that does. But speed's true payoff on mobile is less about the ranking nudge and more about the human: on the device where your most urgent, highest-converting searches happen, every second of delay is a share of customers who give up before your page ever loads.

17.6 Local + mobile: "near me," and the tap that becomes a phone call

Now we arrive at the section a home-services company should tape to the wall. For a local business, mobile SEO and local SEO are not two topics — they are the same customer, on the same device, in the same urgent moment. This is theme 2 (intent) at its sharpest: the intent behind a mobile "near me" search is not merely to learn something. It is to act — usually to call, sometimes to get directions, occasionally to book — and to do it in the next sixty seconds.

Consider the texture of the query. Someone types "emergency electrician near me" or "furnace repair Cedar Hills" into a phone at nine at night. They are not comparison-shopping across ten tabs. They have a dead furnace or a sparking outlet and a rising sense of dread. Google knows this — it is why the results for that search are dominated, on a phone, by the local pack (the map with three business listings) and why those listings carry a Call button. The winner of that moment is frequently not the best-written page. It is the business that shows up in the pack, looks legitimate at a glance, and lets the panicked person tap once to call a human.

FIGURE 17.4 — "furnace repair near me," on a phone           [constructed teaching example]
  THE QUERY / PAGE   "furnace repair near me" — typed on a phone at 9:14 p.m., location on.
  WHAT'S THERE       Top of screen: two Ads with tap-to-call. Then the LOCAL PACK — a small map
                     and three businesses, each with a star rating, "Open 24 hours," a distance,
                     and a prominent [ Call ] and [ Directions ] button. The ten organic blue
                     links begin only after the user scrolls past all of that.
  WHAT IT SHOWS      On mobile, for urgent local intent, the local pack owns the visible screen —
                     "the fold" is almost entirely map and call buttons. The organic listing you
                     worked so hard on is below the scroll. The click that matters is a CALL, not
                     a visit-and-read.
  WHAT IT DOESN'T    It doesn't tell you the pack ranking factors (proximity, relevance, prominence
                     — that's Chapter 25's subject) or guarantee a call converts. It shows where the
                     attention is, not how to win it end to end.
  THE MOVE           Two fronts: earn the local-pack spot (Chapter 25), AND make sure that when a
                     searcher does reach your site, the phone number is the most tappable thing on
                     the page — one tap, it dials. Never make an anxious person copy a number.
  THE LESSON         On mobile local search, the conversion is often a phone call, and the distance
                     between "interested" and "customer" is one tap. Engineer for that tap.

That tap has a name. Click-to-call is a phone number marked up as a tappable link so that tapping it on a phone starts a call. You have seen the pattern a thousand times; in HTML it is simply an anchor with a tel: link, and you should recognize it, not hand-code it:

<a href="tel:+15551234567">(555) 123-4567</a>

The failure this fixes is astonishingly common and astonishingly expensive. A great many small-business sites render their phone number as plain text or, worse, bake it into an image in the header. On a desktop, fine — the visitor reads it and dials their desk phone. On a phone, it is a small, un-tappable string that the anxious user must select, copy, switch apps, paste, and dial — five steps, each a chance to abandon. For a business whose customers are frequently mid-emergency, turning that number into a one-tap tel: link is plausibly the highest-return single change on the entire site, and it is not an SEO ranking trick at all — it is removing friction from the exact action the searcher came to perform.

A few adjacent moves belong to the same idea: keep the tappable number visible without scrolling (in the header, and often as a sticky bar on mobile); offer tap-to-directions (a maps link) and, where appropriate, tap-to-book; and — a point that reaches into local SEO — make sure the number on the site matches the number on your Google Business Profile and across the web, because name/address/phone (NAP) consistency is a real local signal.

🔗 Connection This section deliberately stops at the border of Chapter 25 (Local SEO), which owns the local pack, Google Business Profile (GBP), reviews, proximity, prominence, and NAP consistency — do not expect the ranking mechanics of the pack here; expect the mobile-usability half of the story. And when you want to know whether all these taps actually produce business, phone-call and form conversions are configured and measured in Chapter 28 (Google Analytics 4) — a tel: tap can be tracked as a conversion event, which is how you prove the click-to-call fix paid off rather than just believing it did.

The mental habit underneath all of this is to audit the page the way a hurried customer would use it — thumb-first, on a small screen, under stress — rather than the way you built it, mouse-first, on a big one. Try it on the plumber below.

🔄 Check Your Understanding A local plumber's site ranks decently and gets mobile traffic, but the owner complains that "traffic doesn't turn into calls." You look at the page on your phone. Name two mobile-specific things you would check first — before touching rankings or content.

Answer

(1) Is the phone number a tappable tel: link, visible without scrolling? If it's plain text or an image buried below the fold, mobile visitors have to work to call — the leak is at the conversion, not the ranking. (2) Is there an intrusive interstitial or a slow load getting in the way — a pop-up covering the content on arrival, or an 8-second load on a weak signal that loses people before they see the number? Both are mobile-usability problems that throttle calls regardless of how well the page ranks. Fix the tap and the friction before assuming you need more traffic.

17.7 AMP: what it was, and why it faded

No mobile-SEO chapter is complete without addressing the technology that dominated the conversation for half a decade and now sits, quietly, in decline. AMP — Accelerated Mobile Pages — is an open-source HTML framework Google introduced in 2015 for building very fast, lightweight mobile pages. AMP achieved its speed by constraining you: a restricted subset of HTML, no custom JavaScript (only AMP's own components), and — the crucial part — pages that could be cached and served by Google from Google's own infrastructure, so they loaded almost instantly when tapped from search.

For a few years, AMP came with a powerful carrot. To appear in the Top Stories carousel — the prime, image-topped news slot at the very top of many mobile SERPs — a page effectively had to be AMP. For publishers who depended on that placement, AMP was not optional; it was the price of the most valuable real estate in mobile news search. So they built it, often maintaining a second, AMP version of every article alongside the "real" one.

Then the carrot was removed. Here is the pivot, told with real, datable facts.

⚖️ Evidence Check Claim: "AMP is required for Top Stories / gives a ranking advantage." Once true in a narrow sense; now false. — Confirmed: With the Page Experience update (rolling out on mobile through 2021), Google removed the AMP requirement for the Top Stories carousel. Any page — AMP or not — became eligible for Top Stories as long as it met the news-content policies and provided a good page experience (Core Web Vitals and the rest). The lightning-bolt AMP badge was also retired from results. AMP's single biggest incentive evaporated, by Google's own announced change. — Confirmed: AMP was never itself a ranking factor. Its benefit was speed (a modest page-experience input) plus the now-removed Top Stories gate — not a direct boost. A fast non-AMP page competes on equal terms. — Contested / allegation (labeled as such): AMP also drew antitrust scrutiny; complaints in a multi-state case alleged that Google used AMP in ways that disadvantaged publishers' and competitors' advertising. Those are allegations in litigation, not established findings, and we present them as exactly that. What is not contested is the product reality: once Page Experience removed the requirement, the reason to build AMP for SEO was gone.

Why did AMP fade once the requirement lifted? Because the costs it had always carried were no longer worth paying:

Publishers had always chafed at AMP: the pages were served from Google-controlled URLs rather than their own domains, the constraints limited design, analytics, and monetization, and maintaining an AMP twin of every article was ongoing work. As long as Top Stories demanded it, they paid the tax. The moment Core Web Vitals offered a path to the same speed — and the same eligibility — on their own fast responsive pages, many major publishers dropped AMP, and new sites simply never adopted it.

🚫 SEO Myth: "You still need AMP to rank on mobile." You do not. This is one of the most common pieces of outdated advice still circulating, usually from articles written during AMP's peak and never updated. The facts: AMP is not a ranking factor; it is no longer required for Top Stories; and a well-built responsive site that passes Core Web Vitals is fast enough to compete without it. If you already run AMP and it works for you, there's no urgent need to rip it out — but building new AMP pages for SEO in the current era is chasing a requirement that no longer exists, at the cost of a second codebase and less control over your own pages. The durable lesson is bigger than AMP: be wary of pouring effort into any single-vendor, Google-specific format whose entire value rests on a search perk Google can revoke — as it revoked this one. Build fast, standards-based pages you own, and you never have to unwind a bet like this. (AMP the technology still exists and has niche uses in email and some ad tech; the point is narrowly about its faded role as an SEO necessity.)

That is the honest epitaph. AMP was a real answer to a real problem — the mobile web was genuinely too slow — imposed through a genuinely coercive incentive, and made largely redundant the moment Google shipped a neutral, standards-based way (Core Web Vitals) to measure the same thing. Learn it as history, and as a cautionary tale about building your house on rented land.

📈 The Strategy File

Rivertown's turn. Chapter 16 measured the site's speed and handed us a prioritized fix list for Core Web Vitals. This chapter adds the other half of the mobile picture — the usability and parity layer speed doesn't touch. Marisa Delgado has been saying for a year that "the website looks weird on my phone," and Tony keeps forwarding texts from customers who "couldn't find the number." Those aren't vague complaints; they're a mobile audit waiting to be written down. Here it is — diagnosis only, in keeping with the book's discipline: we name what's broken and where it gets fixed, and we do not get ahead of the local-SEO or schema work that later chapters own.

FIGURE 17.5 — "Rivertown's mobile audit"                       [the Strategy File]
  WHAT WE CHECKED            WHAT WE FOUND                      VERDICT / WHERE IT'S FIXED
  Configuration              Responsive (WordPress theme);      ✅ PASS — no m-dot migration
    (responsive/m-dot)         one URL per page                   needed. Good news; bank it.
  Viewport tag               Present (theme supplies it)         ✅ PASS — one problem they
                                                                   don't have.
  Content parity             Location-page "service area" list   ⚠️ FIX — restore to mobile HTML;
                               and the footer NAP block hidden      parity (this chapter). Schema
                               on mobile; no schema on any          plan itself → Ch 18.
                               version yet
  Click-to-call             Header phone number is an IMAGE,     🔴 FIX FIRST — convert to a
                               not tappable. Copy-paste on phone.   tel: link, sticky on mobile
                                                                    (this chapter). Highest ROI.
  Tap targets               Top-nav links + "Book Now" cramped;   ⚠️ FIX — enlarge/space targets
                               location-selector links overlap      (this chapter).
  Intrusive interstitial    "$50 off — join our list!" pop-up    ⚠️ FIX — remove/defer on mobile
                               covers content on mobile arrival     search arrival (this chapter).
                               (inherited plugin)                   Legal/consent notices exempt.
  Mobile speed              Homepage LCP ~4.1s; AC-repair page    ↪ DEFER — measured & queued in
                               ~4.8s / INP ~240ms / CLS ~0.22       Ch 16's fix list; harder on
                                                                    weak signals (this ch, §17.5).

Read the verdict column as a priority order. The click-to-call fix is first, and it isn't close: Rivertown is an emergency home-services business whose customers are, by definition, on phones in a hurry, and the site currently renders its phone number as an image — the single most self-defeating mobile decision a local business can make. Making that number a one-tap tel: link, visible without scrolling and sticky on mobile, is a few minutes of work that removes friction from the exact action every panicked "no heat" searcher is trying to take. The parity fixes come next, because content Google can't see on mobile can't help Rivertown rank — the hidden service-area lists and footer NAP need to ship in the mobile HTML. The interstitial (an inherited pop-up from the old "SEO guy's" plugin collection) is both a page-experience liability and a conversion killer on arrival. The tap-target cleanup is real but lower-stakes. And speed we hand back to Chapter 16's list, noting only that those slow seconds bite hardest on exactly the weak-signal, on-the-go connections Rivertown's customers use.

What this component does settle: it makes Rivertown's mobile site fully legible to the version of Google that actually indexes it, and it clears the friction between a mobile searcher and a phone call. What it does not settle, and we're honest about the boundary: it does not win the local pack (that's the Google Business Profile and reviews work of Chapter 25), it does not add the LocalBusiness/Service/FAQ schema the parity fix will eventually carry (that's Chapter 18), and it does not by itself make the pages fast (Chapter 16). It removes the mobile handicaps. Earning the mobile win is the rest of the book. We fold this audit into the growing Rivertown file; at the capstone in Chapter 40, it becomes the "mobile" rows of the full technical punch list.

Conclusion

We started with a question most site owners never think to ask — which version of my site does Google actually read? — and answered it plainly: the mobile one. Mobile-first indexing is not a future trend or a ranking bonus; it is the settled reality that the phone-shaped version of your page is the version that gets indexed and ranked, which makes content parity a prerequisite rather than a nicety. From there the chapter split cleanly in two. The machine half: use responsive design so parity comes for free, and make sure nothing that matters — content, schema, images, links — lives only on the desktop layout. The human half: a working viewport, tappable targets, readable text, no pop-up ambushes, tolerable speed on hard networks, and — for a local business above all — a phone number a frightened person can tap once to call.

We were honest about the limits throughout. Mobile-friendliness is a modest signal, not a lever that vaults you up the results. Speed is a tiebreaker we already sized honestly in Chapter 16. And AMP — the technology that once required your compliance — turned out to be a bet on rented land that Google itself made largely unnecessary, which is why "you still need AMP" belongs in the myth pile. The through-line is the one this whole part keeps returning to: technical SEO doesn't win the race, but it decides whether you're allowed to run it. A page Google can't fully see on mobile, or a person can't use on a phone, is a page that never gets the chance to be the best answer.

Next we turn from making your content visible to making its meaning explicit. In Chapter 18, we cover structured data and schema markup — the JSON-LD that tells Google not just what your page says but what it is, earns the rich results that lift click-through, and (for Rivertown) finally puts a LocalBusiness block on those five location pages. Remember the parity rule as you go: schema, like everything else, has to be on the version Google indexes.

→ Continue to Chapter 18: Structured Data and Schema Markup.

Key Terms

• Mobile-first indexing — Google's practice of predominantly using the mobile version of a page's content for indexing and ranking, crawled by Googlebot Smartphone; there is one index, built from the mobile version.
• Responsive design — a site configuration using one URL and one HTML document per page whose layout reflows to any screen via flexible CSS; Google's recommended default because it makes content parity automatic.
• Viewport — the visible area of a page on a device; the viewport <meta> tag (width=device-width, initial-scale=1) tells a mobile browser to size the page to the screen rather than shrinking a desktop-width page.
• Tap target — any element a user taps (link, button, field); needs to be large enough (~48px) and spaced enough (~8px) that a fingertip reliably hits it without mis-taps.
• Content parity — the principle that the mobile version must contain the same primary content, structured data, images, links, and metadata as the desktop version, because the mobile version is what Google indexes.
• Interstitial — an overlay (pop-up, modal, full-screen promo) between the visitor and the content; an intrusive interstitial on mobile search arrival can trigger a demotion, with exceptions for legally required notices and login dialogs.
• AMP (Accelerated Mobile Pages) — an open-source, constrained HTML framework (2015) for fast, Google-cacheable mobile pages; once required for the Top Stories carousel, it faded after the Page Experience update removed that requirement. Not a ranking factor.
• Click-to-call — a phone number marked up as a tappable tel: link so a phone user can start a call with one tap; the highest-leverage mobile fix for urgent local intent.

Spaced Review

Retrieval practice. Try each before revealing the answer. A few questions revisit earlier chapters (16, 14) on purpose — that's how it sticks.

1. Explain, in one or two sentences, what "mobile-first indexing" means — and correct the myth that it implies a separate mobile index.
2. A site tucks its product reviews and long description behind "Show more" buttons on mobile. When is that perfectly fine, and when is it a serious parity problem?
3. Why is turning a plain-text or image phone number into a tel: link plausibly the single highest-return change on a local emergency-services site's mobile pages?
4. (From Chapter 16.) Name the three Core Web Vitals and, in a phrase each, what they measure — and say why mobile scores tend to be worse than desktop for the same page.
5. (From Chapter 14.) A developer wants to keep a page out of Google and adds a Disallow line in robots.txt. Why can that fail to remove the page, and what actually keeps a page out of the index?