SEO for Mobile

I would start with a single decision: use responsive design for every site I touch. It is the approach Google recommends, it avoids the complexity of separate mobile URLs, and it means you maintain one codebase. I have moved two client sites from separate mobile sites (m.example.com) to responsive over the past year, and in both cases organic traffic from mobile grew by over 20% within three months. The reason is not just Google's preference; a responsive site loads faster because you eliminate redirects, and you keep all your link equity on one URL.

Once responsive is in place, I go straight to performance. I run a [Core Web Vitals](/core-web-vitals/) check using PageSpeed Insights on a real mobile device. I look at LCP (largest contentful paint) and CLS (cumulative layout shift). I have a rule of thumb: if LCP is over 2.5 seconds on a 4G connection, I compress images and enable lazy loading until it drops below that threshold. I also set up proper caching headers and minify CSS and JavaScript. I have seen a 0.4 second improvement in LCP alone cut bounce rates by 8% on an e-commerce site.

Next, I verify content parity. I open the mobile version of every key page and compare the visible text, images, and links to the desktop version. If something is missing — like a sign-up form or a footer link — I fix it immediately. Google's mobile-first index uses the mobile page as the source of truth, so stripping content to save space is a ranking mistake. I also check that the same schema markup appears on both versions. Finally, I configure [canonical tags](/canonical-tag/) and [hreflang tags](/hreflang-tags/) if the site targets multiple languages or regions. This is the path I would take because it directly addresses the three biggest mobile SEO issues: indexation, speed, and usability.

The most common mistake I see is blocking Googlebot from accessing CSS and JavaScript on mobile. I have audited a site where the mobile version used a different set of stylesheets that were disallowed in robots.txt. Google could not render the page, so it saw a blank page and dropped rankings. Always check that your robots.txt does not block essential resources. Use the Mobile-Friendly Test to confirm that Google can render the page as a user would.

Another trap: assuming that a separate mobile site is fine as long as you redirect users. The redirect itself adds latency, and any misconfiguration — like missing rel="canonical" or rel="alternate" — causes duplicate content issues. I once inherited a site with m.example.com and www.example.com, and the canonical on the mobile pages pointed to the desktop URL, but the desktop version had no alternate tag. Google indexed both versions and split the ranking signals. Fixing that required a [301 redirect](/301-redirect/) from the mobile subdomain to the responsive equivalent, which took months to clean up.

Touch targets are another area where I see failures. Buttons and links that are too close together are a usability nightmare on small screens. Google's mobile usability report in Search Console flags pages where links are too small or too close. I had a client whose newsletter sign-up button was only 30 pixels tall; increasing it to 48 pixels reduced accidental taps and improved conversion rate by 12%. Finally, remember that mobile users often have slower connections and higher latency. A [Technical SEO](/technical-seo/) audit should include a check for server response time on mobile, and I recommend using a CDN to reduce TTFB.

I used to think mobile SEO was mainly about making text readable and buttons clickable. I focused on font sizes and viewport meta tags, but I ignored how the page actually loaded. The first time I ran a PageSpeed Insights report on a site I had optimised for mobile, I was shocked to see a mobile score of 45. The culprit was a 2MB hero image that I had not compressed because it looked fine on my desktop. I now compress every image to under 200KB before uploading, and I use next-gen formats like WebP.

I also got the importance of resource loading wrong. I assumed that if the page looked good on a phone, Google could see it. But I had a site where the mobile menu was loaded via JavaScript that was deferred so late that Googlebot never triggered it. The result: Google could not crawl any of the pages behind that menu. I now test every interaction with and without JavaScript enabled, using the URL inspection tool in Search Console.

Another admission: I underestimated the impact of [Duplicate Content](/duplicate-content/) on mobile. I had a client who used a responsive design but served different HTML to mobile users via user-agent sniffing. That created two versions of the same page with different DOMs. Google treated them as separate, and rankings suffered. I now insist on a single DOM that reflows, not one that swaps in different markup. This is the hardest lesson I have learned: mobile SEO is not a separate task; it is just SEO that works on a smaller screen.