How to Make a Website Mobile Friendly

What a mobile friendly site has to pass

A mobile friendly site fits the screen without sideways scrolling, keeps body text at 16 pixels or more, spaces tap targets at least 48 pixels apart, and loads its main content in under 2.5 seconds on a mid-range phone.

• No horizontal scroll at 360 pixels wide, the width of a common budget Android screen.
• Body text at 16 pixels or more, line height around 1.5, headings at 24 pixels and up.
• Buttons and menu links at least 48 by 48 pixels, with 8 pixels of space between them.
• LCP under 2.5 seconds, CLS under 0.1 and INP under 200 milliseconds, measured on mobile.

Google indexes the mobile rendering of a page first. If a section is hidden on small screens to tidy the layout, that section is also missing from what Google reads. Core Web Vitals come from mobile field data, so a fast desktop score can still fail the check that matters.

Fix it in this order

Work top to bottom. Each step takes minutes on a normal WordPress site, and the early steps fix what visitors notice first.

1. Open the site on a phone at 360 pixels wide. Note the first thing that breaks: sideways scroll, tiny text, a menu that will not open, or a slow hero. That note is the work order.
2. Confirm the viewport tag is in the head: <meta name="viewport" content="width=device-width, initial-scale=1">. In WordPress the theme prints it. If it is missing, change the theme rather than patching a template.
3. In WordPress, open Appearance, then Themes, and activate a responsive block theme or a theme such as Astra, GeneratePress or Kadence. Preview before publishing, and check a long post and a table, not just the home page.
4. Replace fixed pixel widths in custom CSS with percentages or max-width. A container set to 1200 pixels is what forces the sideways scroll every phone shows.
5. Resize images to their display width and export WebP or AVIF. Keep the hero eager and preloaded, and let everything below the fold lazy-load.
6. Set form inputs to a 16-pixel font, cut the fields to the ones you actually read, and add autocomplete for name, email and phone.
7. Reload on the phone and repeat the checks. It worked when the page has no sideways scroll, the menu opens with a thumb, and the mobile LCP reads under 2.5 seconds.

Fix the layout problems phones expose

Five failures account for most broken mobile layouts. Match the symptom, make the one change, then reload.

A wide table is worth fixing rather than hiding. Wrapping it keeps every row readable by swipe, while display none removes the data from the phone entirely.

Make text, taps and forms usable with a thumb

A thumb is not a mouse pointer. Body text at 16 pixels or more, tap targets at least 48 by 48 pixels, and 8 pixels between links stop the mis-taps that send a visitor back to search.

Form fields have their own rule: an input with a font size below 16 pixels makes iOS Safari zoom the page when the field gets focus, and the visitor has to pinch back out. Set the input font to 16 pixels and the zoom stops.

• One column on phones, two from 768 pixels, the desktop grid from 1024 pixels and above.
• Short forms: name, email, message. Every extra required field costs completions.
• Correct keyboards with inputmode="tel" and autocomplete="email", so typing does not fight the phone.
• Menu links stacked with space, not squeezed into a footer row of eight cities.
• Text left-aligned, not centred, for anything longer than a headline.

Cut the weight that mobile networks punish

Mobile speed is a weight problem before it is a code problem. Every extra 100 KB is visible on a 4G connection, and a 2 MB hero image is the usual culprit.

• Hero image: resize, export WebP or AVIF, load it eagerly and preload it. This image is usually the LCP element.
• Everything below the fold: loading="lazy", including the in-post images.
• Fonts: two families at most, font-display: swap, subset to the characters you use.
• JavaScript: defer it, and remove third-party widgets nobody reads, such as a heatmap, a second chat box and a fourth analytics tag.
• Hosting: a cached HTML page and compressed assets do more for a phone than any CSS tweak.

Targets are LCP under 2.5 seconds, CLS under 0.1 and INP under 200 milliseconds on a mid-range Android phone over 4G. The speed guide covers each lever in depth.

Test the result on a real phone

Emulation catches layout, not touch. Test in the browser first, then on the phone you actually carry.

• Chrome DevTools: press F12, click the device toolbar icon, choose Pixel 7 or iPhone 14, then reload.
• Lighthouse: open the Lighthouse tab, choose Mobile, run the audit, and read LCP, CLS and INP rather than the single score.
• PageSpeed Insights: paste the live URL. The field data is real visitors; the lab data is one test run on a simulated phone.
• Real phone: open the URL over mobile data, not office Wi-Fi, then use the menu, a form and the checkout with one thumb.

You know it worked when the page fits at 360 pixels, the text is readable without zooming, every tap lands first time, and the mobile LCP is under 2.5 seconds.

When the fix does not stick

If the layout still breaks after the change, something is serving or overriding the old CSS. Check these in order before you edit the theme again.

• Cache: clear the WordPress cache plugin, the host cache and the CDN, then reload in a private window.
• Plugin CSS: deactivate plugins one at a time, or run Health Check to test with them all off.
• Theme custom CSS: open Appearance, then Customize, then Additional CSS, and look for a fixed width.
• Child theme: an old override in the child theme beats the parent theme's fix.
• Page builder: a section saved with fixed padding or a fixed column width keeps that width on every screen.

Get the mobile build done for you

WebJi® builds mobile-first WordPress sites and repairs existing ones, with the theme, images, fonts and forms handled in one pass. WordPress hosting starts at ₹400 a month or ₹3,000 a year, before 18% GST.

If the site needs more than a theme change, the speed optimization team works on Core Web Vitals directly, and the design team rebuilds the pages that break on a phone. Both are quoted by email before payment. Write to support@webji.services, which answers in Hindi and English 24/7 with an average first reply under 60 minutes.