Mobile SEO: Making Your Site Work on Phones

I audit websites for a living, and the conversation that repeats most often goes like this: the site looks immaculate on a laptop, the owner is proud of it, and their rankings have been drifting sideways for a year.

Then I open it on a phone. A section of the copy is hidden behind a tab that only loads on click, the main heading has been shrunk to fit, and the two most important links sit close enough together that a thumb has to guess. Nothing is broken in the sense a developer would report. It simply does not work for the person doing the searching.

After 13 years of this, I can tell you that mobile SEO is mostly boring, structural work. Google indexes the mobile version of your pages, so anything that only exists on desktop effectively does not exist, and the rest is about whether a person can read and tap your site without a fight.

Mobile-first indexing in plain English

What Google crawls and what it uses

The phrase sounds technical and the meaning is simple. Google does not keep a desktop copy and a mobile copy and choose between them. It crawls with a smartphone agent and uses what it finds. Google Search Central's guidance on mobile-first indexing states that "Google uses the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking."

One crawl, one version, and the version it uses is the one a customer sees on a phone. That is the whole concept, and it explains a large share of the ranking problems I diagnose.

Why desktop-only content stops counting

The practical consequence is stated in the same place and it is blunt. Per the same Google guidance, "Only the content shown on the mobile site is used for indexing." If a paragraph, a specification table or a set of frequently asked questions exists on desktop and not on mobile, it is invisible to the system that decides what your page is about.

Most businesses have never checked this. They assume the responsive theme serves the same content to everyone, because it usually does. It is the hidden blocks, the components that load on interaction and the section that was dropped for space that cause the problem.

Content parity is the fix that matters most

Accordions, tabs and hidden sections

Google's own wording covers the difference between hiding content and withholding it. Where a mobile page carries less than the desktop equivalent, its recommendation is to bring them into line: "If your mobile site has less content than your desktop site, consider updating your mobile site so that its primary content is equivalent to your desktop site."

An accordion or a tab is fine, as long as the content is present in the HTML and the user simply expands it. Content that only arrives after a tap, loaded by a script on demand, is a different situation, because the crawler does not interact with the page. When in doubt, view the rendered page and search it for the text you expect to be there.

Titles, meta descriptions and structured data on both versions

Parity applies to more than body copy. The page title, the meta description, the heading structure and any structured data should be identical on both versions. A pattern I still find is a mobile theme that outputs a shortened title or omits the schema entirely, which quietly removes the markup you added for search and for other systems that read it.

Check the rendered HTML for a phone user agent rather than assuming the template behaves. If the schema is missing there, it is missing as far as indexing is concerned.

The viewport meta tag and why it matters

What width equals device width actually does

The viewport meta tag tells a phone how wide to treat the page. Setting the width to the device width and the initial scale to one is what makes a responsive design behave as designed, and every current theme ships with it by default.

Where it is missing or wrong, the consequences are immediate. Chrome's documentation on the Lighthouse viewport audit notes that "Without a viewport meta tag, mobile devices render pages at typical desktop screen widths and then scale the pages down, making them difficult to read." A desktop-width page shrunk to a phone screen is technically responsive and practically unusable.

What happens to a page without it

The user zooms and pinches, or leaves. On a page where someone is meant to read three paragraphs of explanation or compare two prices, that friction costs conversions before it costs rankings.

Treat the check as documented guidance rather than a scorecard. Lighthouse's viewport check has been folded into a broader mobile viewport insight in recent versions, so use it as a signal that something is worth reading on your site, not as a number that decides your position in search. If the tag is missing on a custom build, adding it is one line in the head of the template.

Tap targets, buttons and forms

The 48 pixel rule of thumb

A tap target is anything a person is meant to press: a link, a button, a checkbox, a menu item. Too small and the tap lands on the wrong thing, or nothing at all. Chrome's Lighthouse guidance on tap targets gives a workable reference point, stating that "Tap targets that are 48 px by 48 px never fail the audit."

That is a documented check rather than a ranking factor, and it is still a good working standard, because it comes from observing how thumbs actually land on glass. Keep interactive elements at least 48 pixels in both directions and leave space between them.

Spacing and the small icon problem

The worst offenders are almost always icon-only links. Social icons in a footer, a close button on a popup, a phone icon next to an address. They get sized to look neat rather than to be pressed, and they sit in a cluster where a thumb cannot separate them.

Forms have their own version of the problem. Fields that are too short, labels that disappear once typing starts, a submit button that sits directly under a field so a mistimed tap is easy. Test every form on a phone with one hand before you look at anything else on the page.

Mobile page experience beyond speed

Interstitials, ads and readability

The things that make a phone experience feel bad are mostly not speed. A popup that covers the content the moment the page loads, an ad that shifts everything down as it arrives, body text set at fourteen pixels with a light weight on a white background, or a cookie banner that occupies the bottom third of the screen for the whole visit.

Readability matters more than most owners expect. Long paragraphs without breaks, tables that require horizontal scrolling, and images with text baked in are all mobile problems that cost you readers even when the page loads instantly.

What Google says is and is not a ranking signal

Be careful how this is framed, because the topic attracts more certainty than the evidence supports. Google's guidance on page experience in search results states plainly that "There is no single signal. Our core ranking systems look at a range of signals that align with overall page experience." The same page adds that "Beyond Core Web Vitals, other page experience aspects don't directly help your website rank higher in search results."

The honest reading is that speed work is worth doing because users feel it, not because it buys position. Treat the mobile experience as a conversion and retention issue first, and a ranking issue second.

Seeing your site the way Google does

The rendered page and URL Inspection

Use the URL Inspection tool on a live URL and read the rendered HTML it returns. That is the version the crawler is working with. Search that output for the words, headings, links and images you expect to be there, and take note of anything missing.

If a block of copy, a product table or a set of questions is absent from the rendered HTML, indexing will not see it either. That single check answers most of the questions I get about pages that refuse to rank for the terms written on them.

Checking robots and resources on mobile

Then confirm nothing is blocking the mobile crawl. Check that robots.txt does not exclude the paths you care about for mobile user agents, and that the CSS and JavaScript files the page needs are not blocked, because a page crawled without its styles or its data can render as something quite different from what you designed.

Finally, check for mobile-specific redirects that send smartphones to a different URL to the desktop. If that is happening, it is the mobile URL that has to carry the content, the title and the structured data, not the desktop one.

Mobile problems that are really content problems

Copy written for a wide screen

A paragraph designed for a 1400 pixel column reads badly at 390 pixels. Four-sentence paragraphs become walls, long parenthetical clauses lose the reader halfway through, and a comparison that worked as a sentence on desktop should be a table on a phone.

The fix is editorial rather than technical. Shorter paragraphs, one idea per sentence where the idea is doing real work, and the decision to present anything with more than two variables as a structured element rather than prose.

Tables, images and PDFs that fail on a phone

Wide comparison tables are the most common casualty. If your table has eight columns, it will not fit a phone without sideways scrolling, and people do not scroll sideways. Rebuild it as a stacked layout, or split it into the two or three comparisons that actually matter.

Images carrying text are the second casualty, because the text becomes unreadable and cannot be read by anything else either. PDFs are the third. A price list or a specification sheet published only as a PDF is a mobile problem, an accessibility problem and a measurement problem, and it should be a page.

A mobile SEO fix list for your top pages

Free fixes you can do this week

Start with your five highest value pages, which are usually the pages that produce enquiries rather than the pages that get the most traffic. On each one, open it on a phone and work through the same list: is the main heading readable without zooming, is every important element at least 48 pixels, is the unsubscribe or enquiry button obviously pressable, is any copy hidden that should be visible, does a table force sideways scrolling, and does the page load without a popup landing on top of it.

Then check the rendered HTML for those same five pages and search it for the phrases you expect indexing to see. Both checks are free, both take about half an hour per page, and between them they find most of what matters. The full sequence is set out in the technical SEO checklist, worked through in order.

What needs a developer and what it should cost

Some of the list you can fix yourself in the CMS: paragraph lengths, image sizes, the wording on buttons, an obvious alt text omission. Some of it needs a developer: a missing viewport tag in a custom template, content that only loads on interaction, a mobile redirect that serves a different URL, or structured data that the mobile theme strips out.

Ask for those as separate, specific items with a defined outcome, and test the rendered page yourself afterwards. A rebuild is rarely the answer for a mobile problem. I have seen a two line template change fix what a business had been quoted five figures to redesign, and I have also seen a rebuild that carried the same hidden content straight into the new theme. If a mobile problem has been misdiagnosed before, it is usually quicker to get a mobile problem diagnosed before rebuilding, and an SEO audit that checks how your site behaves on a phone will tell you where the content is disappearing. If you would rather have the checks run for you, you can ask for a mobile check on your top pages and get a prioritised list back.

Mobile SEO questions I get asked most

My site is responsive, so is mobile SEO done?

Responsive design solves the layout half of the problem, not all of it. You still need the mobile version to carry the same content, headings, structured data and metadata as the desktop version, because Google uses the mobile version when it indexes and ranks. Responsive sites with sections hidden on phones are the most common case I see.

Does content in an accordion or tab still count?

Yes, as long as it is in the HTML and not loaded only after a tap. Google warns that it will not load content that requires user interaction such as swiping, clicking or typing. Moving content into accordions or tabs to save space is fine. Loading it only when someone clicks is a risk, because indexing comes from the mobile page.

What viewport setting should I use?

The standard is a viewport meta tag with width set to device width and an initial scale of one, which is what every current theme sets by default. Without it, mobile devices render the page at a desktop width and shrink it, which makes text hard to read. If the setting is missing on a custom build, adding it is a one line fix in the head of the template.

How big should buttons and links be on a phone?

Lighthouse uses 48 pixels as its reference: tap targets that are 48 px by 48 px never fail its audit, and it also flags targets whose centre area overlaps another target. As a working rule, keep interactive elements at least 48 pixels in both directions and leave space between them, particularly for icon only links and social buttons.

Do I need to worry about speed as well?

Speed forms part of page experience, but be careful how you frame it. Google states there is no single page experience signal and that its ranking systems look at a range of signals, and that aspects beyond Core Web Vitals do not directly lift rankings. Treat speed work as removing something users genuinely feel, not as buying a ranking.

How can I tell whether Google can even see my mobile content?

Use the URL Inspection tool on the live URL, look at the rendered HTML it returns, and search that output for the words, headings, links and images you expect. If a block of copy or a product table is missing from the rendered HTML on a phone user agent, indexing will not see it either. Then confirm the page is not blocked for mobile user agents in robots.txt.