Mobile SEO optimisation: parity first, speed second, layout third

Mobile SEO optimisation starts with parity, because Google indexes the mobile version of your pages. Whatever is missing from your mobile HTML is missing from the index, so the first job is to confirm that your mobile pages contain the same content, headings, links, images, structured data and metadata as the desktop ones. Only then do speed and layout matter, and in that order: fix what the mobile crawler cannot see, then make the page load and respond quickly on a mid range phone, then fix the tapping, reading and interrupting problems that cost you the conversion after the click.

Most mobile SEO problems are not design problems. They are content that exists on desktop and quietly does not exist on mobile, usually because a component collapses, defers or never renders.

Mobile first indexing, stated plainly

Google crawls and indexes the web with a smartphone agent, which it documents in its guidance on mobile first indexing. Three consequences follow, and they are the whole basis of the work.

• Content only present on desktop is not indexed.
• Structured data, titles, meta descriptions and canonical tags must be present on the mobile pages.
• Links that only exist in a desktop navigation do not pass anything, because the crawler never sees them.

A responsive site built from one HTML document satisfies most of this by design, which is why responsive remains the recommended setup. Sites that serve different markup by device, or still run a separate mobile subdomain, need the parity audit below every time they ship.

The parity audit, which takes an hour

1. Fetch the page as a smartphone. Use the URL Inspection tool in Search Console and read the rendered HTML it returns, not your browser view.
2. Compare text. Copy the rendered mobile text and the desktop text into two files and diff them. Missing paragraphs, missing tables and missing product specifications are the common findings.
3. Compare headings. Count h1 and h2 elements on both. Mobile templates frequently demote headings to plain text inside accordions.
4. Compare links. List every internal link in both renders. A collapsed mobile menu that builds its links only after a tap is the classic cause of orphaned pages.
5. Compare structured data. Run both through the Rich Results Test. Markup injected by a desktop only script disappears on mobile.
6. Compare images. Check that mobile images have the same alt text and are not swapped for decorative placeholders.
7. Compare metadata. Title, meta description, canonical, hreflang and robots meta tags, on the mobile render.

Content inside accordions and tabs is fine. Google indexes content that is in the HTML even when it is hidden behind a tap, so collapsing long sections on mobile is good design, not an SEO problem. The problem is content that is not in the HTML at all.

Speed and responsiveness on a real phone

Test on a mid range Android device on a mobile network, not on your own handset over office wifi. Then work through the three metrics Google reports as Core Web Vitals, which feed the page experience signals.

Metric	What it measures	The usual mobile cause
LCP	How long the largest visible element takes to appear	An oversized hero image, a slow server response, or fonts and scripts blocking the render
INP	How quickly the page responds to a tap	Heavy JavaScript on the main thread, usually third party tags
CLS	How much the layout jumps while loading	Images and ads without reserved dimensions, and late loading banners

Practical order of work, which handles most mobile sites:

• Serve correctly sized, modern format images with explicit width and height attributes.
• Reserve space for every ad slot, banner and embed before it loads.
• Audit third party scripts and remove the ones nobody can name an owner for. This is usually the largest single win on INP.
• Defer non critical JavaScript and inline only the CSS needed for the first screen.
• Preload the font used in the headline and the hero image, and nothing else.
• Measure field data in the Core Web Vitals report in Search Console, because that reflects real visitors rather than a single test. PageSpeed Insights gives you both the lab test and the field data side by side.

The layout problems that cost conversions

• Intrusive interstitials. A full screen pop up that covers the content when somebody arrives from search is a poor experience and a known risk. Delay prompts until a second page view or a scroll, and keep cookie notices compact.
• Tap targets. Buttons and links big enough to hit with a thumb, with space around them. Test the booking or buy button with one hand on a crowded train.
• Readable text without zooming. Set the viewport meta tag correctly and never disable user scaling.
• Forms built for phones. Correct input types so the right keyboard appears, autocomplete attributes filled in, address lookup rather than six separate fields, and a visible phone number as an alternative to the form.
• Sticky elements that eat the screen. A sticky header plus a sticky promo bar plus a chat bubble leaves very little page on a small phone.
• Tables and code blocks. Allow horizontal scroll inside the element rather than shrinking the font or letting the whole page scroll sideways.

Mobile results look different, so plan for them

The same query returns a different first screen on a phone. Local results, people also ask blocks, shopping carousels, video units and an AI Overview take more of the visible area than they do on desktop, which means position four on mobile can sit well below the fold.

• Check your important queries on an actual phone and note what sits above you.
• For local intent, the Business Profile does more work than the website on mobile, so keep hours, services and photographs current.
• Write titles that still make sense when truncated to around half their desktop length.
• Answer the question in the first paragraph, because mobile readers decide in a sentence.

This page covers mobile optimisation for organic search. For a deeper treatment of the performance metrics themselves, Core Web Vitals deserves its own guide, and app indexing is a separate subject again.

Asked and answered: Mobile SEO optimisation

Do I still need a separate mobile site?

Responsive design on a single set of URLs is the simplest setup to maintain and the one Google recommends. If you already run a separate mobile subdomain, keep the annotations correct and run the parity audit on every release, and plan the move to responsive when the next redesign comes round.

Does hiding content behind an accordion on mobile hurt rankings?

No. Content that is present in the HTML is indexed whether or not it is visible before a tap. Collapsing long sections is a good way to keep a mobile page readable while still giving search engines everything.

How fast does a mobile page need to be?

Aim to pass all three Core Web Vitals in the field data for the majority of your visits, and treat the slowest template as the priority rather than the site average. One slow product template can account for most of a site's failing URLs.

Is a different page for mobile and desktop ever right?

Serving a different layout is normal and fine. Serving different content is where sites get into trouble, because the mobile version is the one that gets indexed. Keep the words, links and markup identical and vary only the presentation.

What is the quickest mobile win on most sites?

Removing unused third party scripts, then compressing the hero image. Those two changes together usually move LCP and INP more than any amount of template tuning, and neither one needs a design decision.

The reader that is never on a phone

Mobile first indexing asks whether Google sees the same content on the phone as on a desktop. An assistant is neither. It reads the text of your page as it was fetched, and then writes its own version for the person who asked, on whatever device they happen to hold.

So the test that matters here is what the reply contains. Ask an assistant a question your page answers and see whether your content, a rival's or neither shaped the reply. AI Knows Us reports which sources each answer used.