How to Make a Website Mobile-Friendly

To make a website mobile-friendly, give the browser a device-width viewport, replace fixed-width layouts with flexible ones, make media fit its container, and use CSS media queries only where the content needs a different arrangement. Then check reading, navigation, forms, and touch controls at narrow widths, including a 320 CSS-pixel equivalent width for ordinary horizontally read content.

Responsive design is usually the simplest approach: keep the same URL and HTML while CSS adapts the presentation. Google recommends it as the easiest configuration to implement and maintain. A mobile-friendly page should preserve its primary content and work without forcing readers to scroll sideways to read ordinary text.

1. Find what breaks on a phone

Start with the page as it exists. Resize the browser or use a device emulator, then inspect real pages with their actual content. Look for:

Fixed-width containers or tables that extend beyond the viewport.
Columns that become too narrow to read instead of stacking.
Images, videos, or code blocks wider than their containers.
Navigation that overlaps, clips links, or is hard to open.
Small text, cramped line spacing, and long unbroken strings.
Buttons and form controls that are difficult to tap or use.
Content hidden behind hover behavior or interactions unavailable on touch.

Fix the underlying layout and content constraints rather than shrinking the whole desktop page. A page that technically fits but makes text tiny or controls awkward is not comfortable to use.

2. Add the viewport declaration

Put this element inside the document’s <head>:

<meta name="viewport" content="width=device-width, initial-scale=1">

width=device-width tells the browser to use the device’s width as the layout viewport. initial-scale=1 sets the initial zoom. Without this declaration, some mobile browsers may lay out the page on a wider virtual canvas and scale it down, making desktop-sized content appear tiny.

Do not disable user zoom with user-scalable=no or a restrictive maximum scale. Readers need to be able to enlarge content.

3. Build a flexible layout

Replace fixed page and column widths with widths that can shrink, grow, wrap, or stack. Set a readable maximum width for long text, while letting the container use the available space on small screens.

* {
  box-sizing: border-box;
}

body {
  margin: 0;
  font: 1rem/1.5 system-ui, sans-serif;
}

.page {
  width: min(100% - 2rem, 72rem);
  margin-inline: auto;
}

.columns {
  display: grid;
  grid-template-columns: minmax(0, 2fr) minmax(14rem, 1fr);
  gap: 2rem;
}

main,
aside {
  min-width: 0;
}

img,
video,
svg {
  max-width: 100%;
  height: auto;
}

@media (max-width: 48rem) {
  .columns {
    grid-template-columns: 1fr;
  }
}

The minmax(0, ...) and min-width: 0 rules help grid children shrink below their content’s intrinsic width. The example breakpoint is only a starting point: choose breakpoints when your content stops working, not because a device is labeled “phone” or “tablet.”

Let content wrap and overflow safely

Long URLs, identifiers, and code lines can cause overflow even in a flexible layout. Allow text to wrap where appropriate, and provide a scrollable region for content that must remain two-dimensional, such as a data table or code sample.

.prose {
  overflow-wrap: anywhere;
}

.table-scroll,
.code-scroll {
  max-width: 100%;
  overflow-x: auto;
}

.table-scroll table {
  min-width: 36rem;
}

Use horizontal scrolling only for the specific region whose content needs it. Do not make the entire page scroll sideways to read ordinary paragraphs.

4. Adapt layout with content-led breakpoints

Media queries let CSS change presentation when the viewport or user preference changes. A layout might stack a sidebar below the article when two columns become cramped, simplify a navigation row, or adjust spacing. There is no universal breakpoint that makes every design work.

/* Base styles work at narrow widths first. */
.site-nav {
  display: flex;
  flex-wrap: wrap;
  gap: 0.75rem 1rem;
}

@media (min-width: 50rem) {
  .site-nav {
    align-items: center;
    justify-content: space-between;
  }
}

@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    scroll-behavior: auto !important;
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
  }
}

Keep the default layout usable at narrow widths, then add wider-screen enhancements. Test where navigation wraps, labels collide, or columns become too tight. If the page only works after a large fixed breakpoint, reconsider the layout itself.

5. Make text and controls comfortable to use

Use text that remains readable without pinch-zooming. Relative units such as rem make it easier to respect browser text settings. A line height around 1.5 is a practical starting point for body text; Digital.gov cites guidance of at least the browser’s default line height, approximately 1.2, as a readability baseline. Neither number alone proves that text is accessible.

Make interactive targets large and well spaced. WCAG 2.1 Success Criterion 2.5.5 (Level AAA) specifies a 44 by 44 CSS-pixel target, with stated exceptions; it is not a blanket requirement that every link be that size. Digital.gov separately cites Android guidance of at least 48 CSS pixels in width or height and 32 CSS pixels between targets. Treat these as distinct pieces of guidance, and check whether adjacent controls can be activated accurately.

button,
input,
select,
textarea {
  font: inherit;
}

button,
input,
select {
  min-height: 2.75rem;
}

button,
a.button {
  padding: 0.65rem 0.9rem;
}

.form-row {
  display: grid;
  gap: 0.4rem;
  margin-block: 1rem;
}

input,
select,
textarea {
  max-width: 100%;
}

Check that labels remain visible, keyboard focus is clear, errors are understandable, and controls do not become clipped when text is enlarged.

6. Choose a mobile configuration that fits your site

Google describes three broad ways to serve mobile pages. The right choice depends on the existing application and how much infrastructure you can change.

Configuration	How it works	Considerations
Responsive design	One URL and HTML document; CSS adapts the presentation.	Usually easiest to implement and maintain. Keep content and resources available across widths.
Dynamic serving	One URL, but the server returns different HTML based on the device.	Requires reliable device variation and careful caching. Check that mobile and desktop versions expose equivalent primary content and metadata.
Separate mobile URLs	Different URLs serve desktop and mobile pages.	Requires URL mapping and ongoing content consistency. Check that links, metadata, and primary content correspond between versions.

If you use a CMS and cannot change the current theme, look for a responsive theme for that CMS. Verify its output with your own pages and content; a theme’s label does not establish that every page or plugin behaves well on a phone.

7. Check reflow, content, and search access

For ordinary horizontally read content, W3C’s WCAG 2.1 Reflow understanding guidance uses an equivalent viewport width of 320 CSS pixels. At that width, check that paragraphs reflow without requiring horizontal scrolling to read lines. Some content, such as a data table or diagram, may need two-dimensional layout; keep any necessary horizontal scrolling confined to that content.

Check at a narrow viewport and at a wider phone or small tablet width.
Zoom in and confirm that text and controls remain usable.
Try keyboard navigation and touch interaction; do not rely on hover alone.
Check images, embeds, dialogs, menus, tables, and forms with real content.
If search visibility matters, ensure important mobile content and resources are accessible to Google and that core content remains equivalent across implementations.

Google’s mobile-first indexing guidance says important mobile content and resources should be accessible, and advises against hiding primary content behind interactions Google will not perform to load it. A redesign does not guarantee a ranking change; the practical goal here is to keep the content available and usable.

8. Validate the finished pages

Review representative page types rather than just the home page: an article, a page with a form, a product or pricing page, and any page with tables, embeds, or complex navigation. Check them in browsers and on representative devices where possible. PageSpeed Insights can be one input for page diagnostics, but an automated score does not prove that a page is usable or accessible.

Viewport: the page uses the device width and remains zoomable.
Layout: ordinary content fits and reflows; no accidental page-wide horizontal scrolling.
Media: images and video fit their containers; necessary tables scroll within their own region.
Reading: text size, line length, contrast, and spacing remain comfortable.
Interaction: menus, buttons, links, and forms work with touch and keyboard.
Content: mobile visitors and crawlers can access the important information and resources.

9. Common problems and fixes

Problem	Likely cause	Fix
The whole page looks tiny on a phone.	Missing viewport declaration or a desktop-sized fixed layout.	Add the viewport element, then replace fixed container widths with flexible sizing.
The page scrolls sideways.	Fixed widths, oversized media, long unbroken strings, or a wide table.	Find the overflowing element; constrain media, allow text wrapping, and place necessary wide content in a local scroll container.
Columns are cramped.	The layout keeps desktop columns at every width.	Use a content-led media query to stack or rearrange the columns.
The menu is clipped or hard to tap.	Rigid navigation, too many links in one row, or small touch targets.	Allow links to wrap or use a tested compact navigation pattern; make controls comfortably sized and spaced.
Images break the layout.	Intrinsic image dimensions exceed the content column.	Apply `max-width: 100%` and appropriate height behavior; inspect embedded media separately.
Mobile search results lack important content.	Mobile HTML hides core information, resources are inaccessible, or separate versions drift.	Make primary content accessible on mobile and keep equivalent content across device-specific implementations.
A responsive theme still has broken pages.	Plugins, custom widgets, tables, or page-specific CSS impose their own widths.	Inspect the actual rendered pages and fix the component causing overflow; do not rely on the theme name alone.

10. Performance, reliability, and maintenance

Responsive CSS can adapt presentation without serving separate page versions, which reduces the number of layouts and content copies to maintain. It does not automatically make a page fast: large images, scripts, fonts, and third-party embeds still consume time and data. Serve appropriately sized media and avoid loading resources the page does not need.

Test after changes to shared components, themes, plugins, or content templates. A layout that works for short headings may fail for a long translation, an unusually wide image, or a validation message. Use flexible constraints and test representative edge cases rather than depending on one viewport screenshot.

11. Or skip the browser setup

To inspect a rendered page without building your own screenshot browser flow, use ScreenshotNeo, a website screenshot API and MCP server. The one-call request below captures a URL as an image; see the API documentation for the available parameters.

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://example.com \
  -o mobile-review.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.com"},
    timeout=90,
)
r.raise_for_status()
open("mobile-review.webp", "wb").write(r.content)

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.com'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const image = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('mobile-review.webp', image));

Cookie banners, popups, and chat widgets are removed before the shot. Bot checks, blank pages, and failed loads are never billed. An MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000.

Frequently asked questions

Do I need a separate mobile website?

Usually not. Responsive design keeps one URL and document while CSS adapts the presentation, and Google recommends it as the easiest configuration to implement and maintain. Existing systems may require a different serving model.

What is the right mobile breakpoint?

There is no universal breakpoint. Add one where your content or controls stop working comfortably, then confirm the layout on both sides of that width.

Does passing an automated check mean the site is mobile-friendly?

No. Automated tools can help identify issues, but also inspect content, interaction, zoom, reflow, and representative devices manually.