# Mobile-friendly If your page is not usable on a phone, you will lose most visitors before they read a line. Google also indexes the mobile version first. Here is what mobile-friendly means now, how to check it, and what to fix. Updated 2026-09-14 · Source: https://porteur.ai/glossary/mobile-friendly ## What mobile-friendly means today Mobile-friendly means a page renders and works on a phone: readable text without zooming, tap targets far enough apart, no horizontal scrolling, no content wider than the screen, and no software the phone lacks. Google uses mobile-first indexing, so the mobile version is what gets indexed. Mobile usability also feeds into page experience. As of 2026, the old Mobile-Friendly Test and the Mobile Usability report in Search Console are retired. Use Lighthouse audits and the Core Web Vitals report by device to cover the same ground. Responsive design is the recommended setup. One codebase adapts to screen size with media queries, fluid layout, and flexible images. ## Why it matters for a small site Most of your visitors arrive on a phone. If /pricing needs pinching, they bounce and your support queue grows. You will also bury key content if the mobile version hides it or uses different copy than desktop. You do not need perfection. You do need no horizontal scroll, readable body text, buttons you can tap, and fast Core Web Vitals on mobile: LCP under 2.5 seconds, CLS under 0.1, INP under 200 ms. ## How to check mobile-friendliness now > Do not rely on the retired Mobile-Friendly Test or the old Mobile Usability report. They were removed in December 2023. - Open your page on a real phone. Check text size, tap targets, forms, and whether you can read and complete the main task without zooming. - Run PageSpeed Insights on your URL and switch to the mobile tab. Read Lighthouse audits for “Viewport not set”, “Content wider than screen”, “Tap targets not sized properly”, and font sizes. - In Search Console, open the Core Web Vitals report and filter for Mobile. Spot slow templates, like /blog/* or /product/*. - Test key pages behind login with an emulator or your device. Sign up, change a setting, and try your checkout. Bugs hide in flows, not just in the homepage. - Rotate the device and try an older small screen as well as a large one. Responsive breakpoints often miss the extremes. ## Fixes that move the needle 1. **Set the viewport** Add a responsive viewport meta tag: width=device-width, initial-scale=1. This lets the layout scale to the screen. 2. **Make the layout fluid** Use percentage widths and max-width. Avoid fixed pixel containers that force horizontal scrolling on small devices. 3. **Size text and tap targets** Use a base font size that is readable on small screens. Space interactive elements so fingers do not hit two at once. 4. **Use responsive images** Serve correct sizes with srcset and sizes. Constrain images and embeds so they never overflow the container. 5. **Keep mobile content complete** Do not hide key copy or links on mobile. The mobile version is what Google indexes and users see first. 6. **Ship fast mobile vitals** Optimise LCP elements on mobile, reduce render blocking, lazy load below the fold, and keep CLS stable as content loads. A fixed /guides/getting-started might change from a squeezed two-column layout to a single column with body text that reads well on small screens, larger buttons, and images that scale within the grid. ## Common traps to avoid - Using desktop-only popups that cover the screen on phones. - Shipping navigation that only works on hover, leaving no way to open submenus on touch. - Serving different content to mobile and desktop that changes meaning, which can confuse users and search. - Embedding third-party widgets that set fixed widths or inject styles that break the layout. - Relying on software a phone does not have, like legacy plugins, for critical content or controls. ## Questions ### What does mobile-friendly mean? It means a page works well on a phone: text is readable without zoom, buttons are easy to tap, no horizontal scroll, and nothing requires software the phone lacks. ### Is mobile-friendly the same as responsive design? Responsive design is the recommended way to achieve mobile-friendliness. It adapts one page to different screens. You could also serve dynamic content or separate URLs, but responsive keeps things simpler. ### How do I check if my site is mobile-friendly now the test is gone? Open your key pages on a phone, then run PageSpeed Insights and look at the mobile Lighthouse audits. In Search Console, use the Core Web Vitals report and filter for Mobile. Fix the audits and any slow templates. ### Does mobile-first indexing change my content? Google indexes the mobile version, so keep mobile content complete and consistent with desktop. Do not hide important copy or links only on large screens. ### What mobile metrics matter most? On mobile aim for LCP under 2.5 seconds, CLS under 0.1, and INP under 200 ms. These cover loading speed, layout stability, and responsiveness. ## Read next - [Mobile-first indexing](https://porteur.ai/glossary/mobile-first-indexing): Mobile-first indexing means Google uses your mobile page to crawl, index and rank. Here is what it hides on desktop-only pages and how to fix it. - [Core Web Vitals](https://porteur.ai/glossary/core-web-vitals): Core Web Vitals are Google’s three field speed and responsiveness metrics. See their thresholds, lab versus field, how to read them, and what to fix. - [The Core Web Vitals report in Search Console, page group by page group](https://porteur.ai/guides/search-console-core-web-vitals-report): Understand where the Core Web Vitals data comes from, how page groups work, what to fix by template, and how to move groups to Good. - [Mobile page speed: the version of your site that Google reads](https://porteur.ai/guides/mobile-page-speed): Run a mobile page speed test the way Google reads your site. See field vs lab, why phones are slower, the key fixes, and how to verify on a real device. - [How to read PageSpeed Insights: field data first, then the score](https://porteur.ai/guides/how-to-read-pagespeed-insights): Start with field data, not the score. Learn what Google uses, why scores vary, and how to turn a PageSpeed Insights run into a clear order of fixes. - [Lighthouse vs PageSpeed Insights: lab and field](https://porteur.ai/compare/lighthouse-vs-pagespeed-insights): Use Lighthouse for repeatable lab checks, PageSpeed Insights for real-user field data. See why scores differ and which to trust for fixes and reporting. Get a free check from your URL that reads your site and the searches around it in about thirty seconds and shows three findings you can ship next. Free check: https://porteur.ai/