Flight log / Transmission 043

Mobile landing pages for paid search: a field guide

Your landing page gets approved on a 27-inch monitor and visited on a 6-inch phone. Google's own target for a good load is 2.5 seconds to the largest element on screen, and plenty of paid pages miss it on the device that carries most of their clicks.

Mobile isn't a version of the page anymore. For a lot of paid search accounts it is the page, because it's where the click happens. Yet the review process for most landing pages still runs on a laptop: a design file, a staging link, a quick scroll, approved.

This field guide covers what changes on a phone, the speed numbers Google publishes, the layout rules that matter for paid traffic, a manual audit you can run with your own phone, and how to read the mobile gap in your account without over-reacting with bids.

What is a mobile landing page?

A mobile landing page is the page a phone user sees after clicking your ad, built and checked for a small screen first. For most advertisers it is not a separate site or a separate URL. It's the same responsive page, judged by how it behaves at phone width, on a phone connection, under a thumb.

Google Ads Help is direct about the setup: a responsive website that adjusts to a user's device is, in its words, "the best way" to handle smaller screens. Two separate pages mean two pages to keep accurate, and in paid search the second one is usually the one that drifts.

What changes on mobile isn't the message. It's the order, the space and the patience. A desktop visitor sees the headline, the proof and the form side by side. A phone visitor sees one thing at a time, in the order you stacked it.

Why does the mobile page matter so much in paid search?

Because the gap between mobile and desktop is usually a page problem dressed up as an audience problem. The pattern that shows up in most B2B accounts: mobile takes a large share of clicks, converts at a lower rate, and gets blamed for "low intent" before anyone opens the page on a phone.

Here is what that gap looks like in a hypothetical B2B software account. Same ads, same keywords, same page. The only difference is the device.

Read the illustrative chart from top to bottom. Mobile visitors scroll about as much as desktop visitors. They just don't arrive at the form as often, and once they start it, fewer finish. That's two fixable problems: the form is buried too deep in the stack, and it's harder to complete with a thumb. Neither is solved by a bid adjustment.

The money side of the same hypothetical account makes the cost obvious. Mobile takes most of the spend and returns a minority of the conversions.

You can pull the real version of this chart from your own account by segmenting campaigns by device. If the two bars for mobile are far apart, the page is the first suspect.

How fast does a mobile landing page need to be?

Google publishes the targets. Per web.dev, a page passes Core Web Vitals when, at the 75th percentile of page loads, it hits all three of these:

Two details matter for paid pages. First, web.dev says the same thresholds apply to mobile and desktop, but it recommends measuring the 75th percentile segmented by device, so your mobile number has to pass on its own. Second, INP replaced First Input Delay as a Core Web Vital in March 2024. If your page was tuned against the old metric, re-check it: a form that lags on every tap fails INP even when it loads fast.

Why it matters for conversion: Google Ads Help says that in retail, a 1-second delay on mobile "can impact mobile conversions by up to 20 percent." That figure comes from Google's retail data and is several years old, so treat it as a direction, not a forecast for a B2B form. The shape is what to remember. The curve below is illustrative, not from a real account, but it's the shape most teams find when they plot their own data.

The usual mobile speed offenders on paid pages are not mysterious:

• A hero image or video sized for desktop. Serve a smaller file at phone width. An autoplay background video is rarely worth its weight on a cellular connection.
• Third-party scripts loaded first. Chat widgets, heatmaps and extra tags all compete with the headline. Load what the visitor needs to read and act, then the rest.
• Web fonts that block text. If the headline waits on a font file, LCP waits too.
• Late-loading banners and cookie bars. Anything that pushes the page down after it appears adds layout shift, and on a phone it often moves the button just as someone taps it.

What should be on the first mobile screen?

On a phone the first screen is small, so it has to carry the three things a paid visitor checks before deciding to stay: am I in the right place, what do I get, and what do I tap. That means:

1. A headline that matches the search. The same words the ad used. On mobile there's no sidebar to rescue a vague headline. See the message match guide for the full set of layers.
2. One line on the offer. Trial length, what the download is, or what the call covers. Keep it to a line or two at phone width.
3. The primary button, visible without scrolling. Or a clear cue that the form is right below. We cover the tradeoffs in above the fold.

What usually needs to move down or go away on mobile: the full navigation menu, the logo bar, a large decorative image, and any pop-up. Google Ads Help recommends avoiding pop-ups or other features that interfere with navigation, and on a 6-inch screen a pop-up is the whole page.

A sticky call-to-action bar at the bottom of the screen is a reasonable fix for long pages, as long as it doesn't cover form fields or the cookie banner's buttons. Test it on the smallest phone you can find.

How do you design for thumbs and mobile keyboards?

Most mobile conversion loss happens in the last few taps. Two areas to check: targets and inputs.

Tap targets

WCAG 2.2 success criterion 2.5.8 sets a minimum target size of 24 by 24 CSS pixels at level AA. That's a floor, not a goal. web.dev's form guidance points to larger sizes for touch, and the primary button on a paid page should be easy to hit with a thumb, full width or close to it, with space around it so nobody taps the privacy link by accident.

Inputs and keyboards

The browser does a lot of work for you if the form asks it to. web.dev's guidance: use type="email" so phones show an email keyboard, type="tel" for a phone keypad, and visible labels instead of placeholder text. MDN documents the autocomplete values that let the phone fill in name, email, phone and company in one tap: name, email, tel, organization. Every field you can autofill is a field the visitor doesn't have to type.

Font size matters here too. web.dev suggests input text around 20px is about right on mobile. Small input text is hard to read and easy to mistype.

Field count matters more on mobile than anywhere else, because each field is a tap, a keyboard switch and a scroll. The companion piece on form optimization covers how to decide which fields stay.

How do you audit a mobile landing page by hand?

No lab required. You need your phone, a spreadsheet and the list of your top-spend ad groups.

1. Segment by device. In Google Ads, segment your top campaigns by device for the last 30 to 90 days. Note cost, clicks and conversion rate for mobile and desktop side by side.
2. Check the landing pages view. Google Ads Help describes a "Mobile-friendly click rate" column on the landing pages page, if your account still shows it. Anything under 100% means some mobile clicks reached a page Google didn't judge mobile-friendly.
3. Open each final URL on your phone, on cellular. Turn off Wi-Fi and use a private window. Count the seconds until you can read the headline.
4. Screenshot the first screen. Can you see the headline, the offer and the button? If any is missing, write down which.
5. Complete the form with your thumb. Check every keyboard, every autofill prompt and every error message. Submit it.
6. Check the speed numbers. Run the URL through Google's free page speed test and note whether real-user mobile data passes all three Core Web Vitals.
7. Rank fixes by mobile spend. The page with the biggest gap between mobile share of spend and mobile share of conversions goes first.

After a fix ships, watch the device split, not just the blended rate. In the hypothetical account below, a page rebuild that moved the form up and trimmed the hero image lifted mobile conversion rate within a few weeks while desktop stayed flat. That's the signature of a page fix rather than seasonality.

Should you cut mobile bids instead of fixing the page?

Sometimes, but rarely first. Google Ads Help lists device bid adjustments from -100% to +900% on strategies that support the full range, such as Maximize clicks. Most Smart Bidding strategies work differently: Target ROAS, Maximize conversions and Maximize conversion value only accept -100%, a full opt-out from the device, and Target CPA treats a device adjustment as an adjustment to the target rather than the bid.

So in a Smart Bidding account, "bid down mobile" usually means either telling the algorithm to accept a different CPA on phones or switching mobile off. Both hide the page problem instead of solving it. Fix the page, give the bid strategy a few weeks of new conversion data, then decide whether mobile still needs a different target.

The exception: if the offer genuinely doesn't work on a phone (a long technical evaluation, a product that requires a desktop install), a lower mobile target or a mobile-specific softer offer is a reasonable call. Make it on purpose, not by default.

Where this advice breaks down

• B2B conversions often finish on desktop. A buyer may find you on a phone and convert later on a laptop. Device-level conversion rates undercount mobile's role, so don't treat the mobile gap as pure waste.
• Passing Core Web Vitals doesn't guarantee conversions. A fast page with the wrong offer is a fast way to say no. Speed is the floor, not the payload.
• Lab tests aren't real users. A single speed test is one load on one simulated device. Real-user data at the 75th percentile is what web.dev's thresholds are built on, and low-traffic pages may not have enough of it.
• The retail speed stat is old and retail. Use it to justify looking, not to forecast revenue.
• Small samples lie. Mobile conversion rate on a page with 300 clicks a month will swing week to week. Look at 60 to 90 days before deciding a fix worked.

For the page fundamentals that apply on every device, see PPC landing page best practices.

FAQ