How to Make a Website Mobile Friendly

A site that only behaves on a desktop is a site with a hidden leak

Most teams discover the problem the same way. Someone opens the company site on a phone during a meeting, pinches to zoom on a price table, taps the wrong link twice, and quietly closes the tab. Nobody files a bug, because technically nothing is broken. The pages load, the content is there, the logo is in the right place. What is broken is the assumption underneath: that a layout built for one screen width will gracefully shrink to every other width. It will not. Knowing how to make a website mobile friendly is less about shrinking a design and more about building a layout that can be rebuilt by the browser at any width.

This guide walks through the parts that actually produce a mobile friendly site — fluid layout, breakpoints, touch ergonomics, performance budget, content parity and verification — in the order a build should tackle them. It is written for people who have to decide and pay for the work, not only for the people who write the CSS.

Responsive web design in one sentence: proportion instead of pixels

The foundation of responsive web design fits into a single rule: define widths as relationships, not as fixed numbers. A column pinned to a fixed pixel width will overflow every screen narrower than that number. The same column described as a share of the available space, with an upper limit, fits everywhere and still avoids uncomfortably long lines on a wide monitor.

In day-to-day markup this becomes a handful of habits. Containers do not get fixed heights, so they can grow when the text inside them grows. Side-by-side blocks are built with flexbox or grid, because both collapse into a single column with one rule instead of a rewrite. Images get a maximum width tied to their container, so an oversized asset cannot push the page sideways. Those three habits remove a large share of mobile defects before anyone has seen the site on a phone.

One prerequisite sits above all of them: the viewport meta tag. Without it, a browser renders the page at desktop width and scales the whole thing down. The site looks mobile friendly in a screenshot and is unusable in the hand, because every paragraph needs a zoom gesture. No amount of fluid CSS works until that tag is present.

Breakpoints belong to your content, not to a device list

It is tempting to pick breakpoints from a list of popular phone and tablet widths. That list changes every year; the behaviour of your content does not. A more durable method is to drag the browser window slowly from wide to narrow and watch for the exact width where the layout becomes ugly — a navigation bar that no longer fits, a heading that breaks into three lines, a comparison table that stops being readable. That width is your breakpoint, and it is specific to your page.

This approach also keeps the number of breakpoints low. Most business sites are served well by two or three: single column, two columns, full layout. A stylesheet with a dozen thresholds becomes a set of rules that contradict each other, and the person maintaining it six months later cannot tell which rule is deliberate. Few breakpoints in the right place beat many breakpoints in approximately the right place.

Designing for thumbs: tap target size and reach

A mouse pointer can hit a single pixel. A fingertip cannot. Good mobile friendly website design treats that as a layout constraint rather than a detail. Platform guidelines from both Google and Apple recommend a comfortable minimum for interactive elements plus clear spacing between them, and the practical translation is straightforward: inline links do not sit shoulder to shoulder inside a paragraph, an icon button gets a touch area larger than its visible box, and a destructive action is never the same size and colour as the confirming one right next to it.

Reach is the second constraint. When a phone is held in one hand, the top corners are the hardest region to touch. Pinning the primary action to the very top of a long page forces the user to shift their grip every time they want to use it. Repeating the call to action at natural points in the content flow works better than one button parked above the fold.

The third constraint is hover. On a touch screen, hover does not exist. A navigation menu that opens on hover turns into a two-tap puzzle: the first tap opens the submenu, the second follows the link, and nobody explains this to the visitor. Any navigation with a second level needs an explicit expand-and-collapse behaviour on mobile rather than an inherited desktop interaction.

Core Web Vitals on mobile are a separate budget

The same page can be fast on a laptop wired to office fibre and slow on a phone on a patchy mobile connection. Two limits stack: bandwidth and processing power. A phone does not merely download the same JavaScript bundle, it also parses and executes it more slowly. That is why speed on a mobile friendly site is not a rounding error on desktop speed — it is a budget you have to track on its own, and why Core Web Vitals are reported separately for mobile.

Three line items usually dominate that budget:

• Images. Serving an asset several times wider than the space it occupies on screen is the single most common waste on mobile. Using a modern format and offering different files for different screen widths produces a noticeable gain on most sites without touching a line of application code.
• Web fonts. Every additional family and weight is another request and another wait. Limiting weights and making sure text stays visible while a font loads removes the blank-page moment where the layout has arrived but the words have not.
• Third-party scripts. A chat widget, a heatmap recorder, two analytics tags and a few social embeds are each small. Their sum is frequently heavier than everything the site itself ships. Asking which of them anyone actually reads reports from tends to pay better than another round of code optimisation.

Layout stability deserves its own mention. When an image or embed has no reserved space, the page jumps as things load and the visitor taps the wrong element. Declaring dimensions up front prevents it. If you want the performance side broken down cause by cause, our article on why your website is slow continues where this section stops.

Typography, forms and tables on a narrow screen

Reading distance is shorter on a phone, but so is patience. Shrinking body text below its desktop size is usually the wrong instinct; leaving it the same is safer. Form fields carry a specific trap: when the input font size falls under a certain threshold, mobile Safari zooms the page in as soon as the field is focused, and the visitor finishes typing on a page that has silently shifted. Keeping input text large enough switches that behaviour off.

Line length is the next decision. Removing side padding entirely glues text to the edge of the screen and makes long passages tiring. A modest, consistent gutter measurably improves how readable the same paragraph feels. Heading hierarchy matters more here than on desktop as well: on a large screen the eye scans the structure at a glance, while on a phone it only ever sees one screenful, and subheadings are the only signal telling the reader where they are.

Tables are the hard case. A four-column pricing table cannot simply be narrowed. Two mobile friendly approaches work: make the table itself horizontally scrollable inside its container, or redraw each row as a standalone card below a breakpoint. The second costs more to build and earns it back on tables that drive a purchasing decision.

Mobile first indexing: what a search engine actually reads

Google evaluates pages using the mobile version of the site. The practical consequence of mobile first indexing is blunt: content that exists on desktop but is hidden on mobile is largely invisible for ranking purposes. Descriptions trimmed to save vertical space, product specifications collapsed away, internal links shown only in a desktop sidebar — each of those quietly removes signals.

So mobile SEO is not a separate discipline bolted onto the project. It is the requirement that the mobile version of a page is complete: same structured data, same headings, same meta descriptions, same internal linking. A page cut down for small screens serves a partial experience to the visitor and a partial document to the crawler. We covered the structural side of that as a checklist in SEO friendly web design, and the ongoing technical and visibility work is described on our SEO service page.

Templates, page builders and the maintenance bill

Commercial templates are plentiful and most of them genuinely ship a fluid layout. For a brochure site with a predictable structure, a template is a reasonable starting point. The trouble rarely comes from the template itself; it comes from what gets stacked on top. Each page builder and plugin brings its own stylesheet and its own script, and after a year the mobile layout is the sum of rules that override one another in an order nobody chose deliberately.

Custom development gives you weight control from day one: only the code in use is shipped, breakpoints follow the content, and every third-party script is a decision rather than a default. When comparing the two, the honest comparison is not build cost against build cost but two years of maintenance and performance against each other. If you want an approximate figure, our price calculator produces one, and the scope of the work is set out on the web and software development page.

Building a separate mobile site on its own address — the old m-dot approach — is no longer defensible for a new project. Two versions mean two maintenance streams, content that drifts apart, and redirect rules that fail quietly. One address, one set of content, a mobile friendly layout that reorganises itself by width: that is the settled answer.

Testing before launch: emulator, real device, throttled network

The device emulator in a browser is a good first pass and a poor last one. It does not reproduce touch behaviour, font rendering or network latency. A workable order is: verify breakpoints by narrowing the window in developer tools, then browse the site with real taps on at least one Android and one iOS device, then throttle the connection in developer tools and watch how the page arrives on a weak link.

Measurement comes after that. Lighthouse and PageSpeed Insights produce a distinct mobile score with distinct recommendations, and reading the desktop score while assuming mobile is the most common shortcut in this whole process. Search Console reports something different again: field data from real visits rather than a lab run. When the lab result and the field data disagree, the field data is the one describing your actual visitors.

How to Make a Website Mobile Friendly: A Pre-Launch Checklist

• The viewport meta tag is present and no page scrolls sideways at any width.
• Breakpoints were chosen where the layout breaks, not from a list of device models.
• Interactive elements meet a comfortable tap target size and are spaced apart; no menu depends on hover.
• Images are served close to their displayed size, with dimensions declared in advance.
• Focusing a form field does not cause the page to zoom.
• Nothing available on desktop is hidden from the mobile version.
• Scores were read on the mobile tab and confirmed by hand on a real device.

Retrofit or rebuild?

If you already have a working site, the decision turns on one question: is the existing layout fluid, or is it nailed to fixed widths? With a fluid foundation, making the site mobile friendly is contained work — correct the breakpoints, resize the images, enlarge the touch targets. That is a short engagement, and it preserves your content, your URLs and your rankings exactly as they are.

With a fixed-width foundation, every fix breaks the next one. Rebuilding the layout is then both cheaper and more durable than patching it. What must survive a rebuild is not the design but the address structure and the content: if URLs are going to change, plan the redirects before the build rather than after it, or you will gain mobile usability and lose visibility in the same week.

The short version of how to make a website mobile friendly is that no single technique does it. Six decisions do: a layout expressed in proportions, breakpoints derived from your own content, an interface usable with a thumb, a performance budget kept separately for mobile, full content parity between versions, and verification on hardware someone actually holds. Get those six right and the site does not merely look acceptable on a phone — it works there.