What “Mobile-Friendly” Means
A mobile-friendly site is one a person can read and use on a phone without pinching, zooming or scrolling sideways. Many visitors reach websites on small screens, so a page that only works on a desktop loses part of its audience. The usual solution is responsive design: one set of pages whose layout adapts to the width of the screen, rather than a separate “mobile site.”
This guide assumes you already have a site and want to improve it. It works whether you edit the code yourself or adjust a theme or builder’s settings; where you use a builder, look for equivalent options.
Step 1: Set the Viewport
Without instructions, a phone browser pretends the screen is much wider than it is and shrinks the page to fit. The fix is one line in the <head> of each page:
<meta name="viewport" content="width=device-width, initial-scale=1">
This tells the browser to use the real screen width. Without it, none of the other changes below will behave as intended. Do not disable zooming; some people need it.
Step 2: Use a Flexible Layout
Fixed widths measured in pixels are the main reason pages break on phones. Replace them with widths that adapt.
- Let content containers take a percentage of the screen, with a maximum width so lines do not become too long on large monitors.
- Use modern layout tools such as flexbox and grid, which can rearrange items automatically.
- Avoid text or images that are wider than the screen. A simple rule such as
img { max-width: 100%; height: auto; }stops images from overflowing. - Design for the narrow screen first, then add rules for wider screens. Writing styles this way tends to produce simpler, cleaner code.
Use media queries to change the layout at certain widths. For instance, a three-column row can become a single column on narrow screens:
.columns { display: flex; gap: 1rem; flex-wrap: wrap; }
.columns > * { flex: 1 1 100%; }
@media (min-width: 700px) {
.columns > * { flex: 1 1 0; }
}
Choose breakpoints where your content starts to look wrong, not at the sizes of particular devices, since device sizes vary widely.
Step 3: Make Text Readable
Body text on a phone generally needs to be at least about 16 pixels (or 1rem) to be comfortable without zooming. Keep line length moderate, leave generous space between lines, and keep strong contrast between text and background. Use relative units such as rem so that people who have set larger text in their device settings get the benefit.
Write short paragraphs and clear headings. Walls of text are tiring on a small screen, and the same editing habits that help writers of a knowledge base help here.
Step 4: Size Tap Targets Properly
A fingertip is much less precise than a mouse pointer. Buttons and links that are fine on a desktop can be nearly impossible to hit on a phone.
- Make buttons and links at least roughly 44 to 48 pixels tall and wide, a commonly cited range in accessibility guidance.
- Leave space between neighboring links so a tap does not hit the wrong one.
- Use a compact menu, often a “hamburger” button that opens a list, for long navigation bars, but make the button clearly labeled and large.
- Avoid actions that rely on hovering, since touch screens have no hover.
- Use the right input types in forms, such as
type="email"ortype="tel", so the phone shows a suitable keyboard, and keep forms short.
Step 5: Lighten Images and Media
Phones are often on slower or metered connections, so heavy pages can be slow and costly for visitors. Network latency and limited bandwidth both matter more on mobile.
- Compress images and avoid uploading a photo much larger than it will be displayed.
- Use the
srcsetattribute to let the browser choose a smaller image file on a small screen. - Load images below the first screen lazily, with
loading="lazy". - Give images width and height attributes so the page does not jump around as they load.
- Avoid autoplaying video and large background videos.
- Be careful with tables and charts. A wide table can sit in a container that scrolls sideways, and a complex chart may need a simpler version on phones, which is a common issue with interactive dashboards.
Also remove scripts and fonts you do not need. Each extra file takes time to download.
Step 6: Test Properly
Resizing a desktop browser window is a good start, and most browsers include a device mode in their developer tools that simulates phone screens. However, simulation misses real-world behavior, so also try the site on actual phones if you can, including an older one. Check:
- the page in both portrait and landscape
- whether any content is cut off or requires sideways scrolling
- whether forms, menus and buttons can be used comfortably with a thumb
- how fast the page loads on a mobile connection rather than office Wi-Fi
- whether text remains readable in bright light and at larger text settings
Free tools from search engines and browser developers can report issues such as small text or tap targets that are too close together. Treat their scores as hints rather than goals in themselves. A methodical approach, changing one thing at a time, makes problems easier to isolate, similar to a good troubleshooting method.
Step 7: Keep Checking
Every new page, plugin or banner can undo earlier work. Preview new content on a phone before publishing it, particularly pop-ups, which can cover the whole screen and be hard to close. Search engines generally evaluate the mobile version of a page, so a poor phone experience may affect how well the site performs in search, and sites that depend on digital marketing for visitors have more reason to care. Results vary, and no change guarantees higher rankings, but a site that is easy to use rarely hurts.
Secure connections matter as well. Serving pages over HTTPS, supported by data encryption, protects visitors on public Wi-Fi and is expected by modern browsers.
A Short Checklist
- Viewport meta tag present on every page
- No fixed-width layouts that force sideways scrolling
- Body text about 16 pixels or larger
- Tap targets large and well spaced
- Images compressed and responsive
- Forms short, with suitable input types
- Tested on at least one real phone