A responsive website adapts one layout to every screen, from a 320px phone to a 4K monitor. Most sites today are built “responsive”, but many still break in small ways that cost visitors, conversions and rankings. Since July 2024, Google crawls and ranks every site using its smartphone crawler, so a broken mobile layout is no longer a design problem only. It is an SEO problem too.
This guide covers the 12 responsive design mistakes we find most often when auditing client sites, with a fix and a test for each one. If you’d rather have someone check your site for you, our web development team runs responsive audits as part of every rebuild.
The 12 mistakes at a glance
- Designing desktop-first and squeezing the layout down to mobile.
- A missing or restrictive viewport meta tag that breaks scaling or blocks zoom.
- Fixed pixel widths that cause sideways scrolling.
- Breakpoints based on devices instead of where your content breaks.
- Relying only on media queries when a component needs container queries.
- Images that don’t adapt: no srcset, no dimensions, or a lazy-loaded hero image.
- Hiding content on mobile, which Google may then ignore.
- Tap targets that are too small and menus that only open on hover.
- Text that doesn’t scale: fixed font sizes, tiny body text, endless line lengths.
- Mobile viewport bugs: 100vh overflow, oversized sticky headers, keyboards covering forms.
- Tables, forms and embeds that overflow the screen.
- Ignoring performance and real-device testing, so Core Web Vitals fail on real phones.
Quick reference
| Mistake | What Users Notice | Fix | How to Test |
|---|---|---|---|
| Desktop-First Design | Cramped, cluttered mobile pages. | Design the smallest screen first. | Review the mobile layout before desktop. |
| Bad Viewport Tag | Tiny, zoomed-out pages or pinch-zoom restrictions. | width=device-width, initial-scale=1 |
View the page source. |
| Fixed Widths | Horizontal scrolling on mobile screens. | max-width: 100%, min(), andminmax(). |
Resize the browser to 320px. |
| Device Breakpoints | Layouts break on intermediate screen sizes. | Use content-based breakpoints in em. |
Drag the browser window slowly from narrow to wide. |
| Media Queries Only | Cards look wrong in sidebars or grids. | Use container queries. | Place the component in a narrow column. |
| Non-Adaptive Images | Slow loading and content shifting. | srcset, sizes, and explicitwidth/height attributes. |
Test with PageSpeed Insights for LCP and CLS. |
| Hidden Mobile Content | Missing information on phones. | Collapse content instead of hiding it. | Compare mobile and desktop content. |
| Small Tap Targets | Mis-taps and menus that won’t open. | Provide targets of at least 24 × 24px, ideally 44 × 44px. |
Use the site one-handed on a phone. |
| Non-Scaling Text | Squinting or zooming to read text. | rem, clamp(), and a linelength of approximately 65ch. |
Zoom the browser to 200%. |
| Viewport Bugs | Buttons hidden behind browser bars. | Use svh and dvh units whereappropriate. |
Test on real iOS and Android devices. |
| Overflowing Tables and Forms | Cut-off data and awkward mobile keyboards. | Use scroll wrappers and appropriate input types. | Complete every form on a phone. |
| No Performance Testing | Slow, laggy pages. | Meet Core Web Vitals targets for LCP, INP, and CLS. | Review the Core Web Vitals report in Google Search Console. |
1. Designing desktop-first
What it looks like: The site is designed for a wide screen, then every section is stacked and shrunk to fit a phone. The result is long, cluttered pages where the most important action sits five scrolls down.
Why it matters: Just over half of worldwide web traffic now comes from mobile devices (StatCounter, 2026). More importantly for search, Google now indexes the mobile version of your pages. If a section only works well on desktop, that is not the version Google evaluates. This is why responsive design is part of technical SEO, not just design.
How to fix it: Start the design on the smallest screen. Decide what one thing each page must help a mobile visitor do, put that first, then add layout complexity as the screen widens. In CSS, write your base styles for mobile and use min-width media queries to enhance larger screens.
/* Base styles = mobile */
.features { display: grid; gap: 1.5rem; }
/* Enhance when there is room */
@media (min-width: 48em) {
.features { grid-template-columns: repeat(3, 1fr); }
}
How to test: Review designs at mobile width first in every design review. If stakeholders only ever see the desktop mockup, mobile will be an afterthought.
2. A missing or restrictive viewport meta tag
What it looks like: Without the viewport tag, mobile browsers render the page at
a desktop width and shrink it, so everything is tiny. A different mistake is adding user-scalable=no or maximum-scale=1, which stops people from zooming into read.
Why it matters: Blocking zoom is an accessibility failure for people with low vision, and it frustrates everyone else.
How to fix it: Use this tag in the <head> of every page, and nothing more restrictive:
<meta name=”viewport” content=”width=device-width,
initial-scale=1″>
How to test: View the page source and search for “viewport”. Then try pinch-zooming on a real phone.
3. Using fixed pixel widths
What it looks like: A container set to width: 1200px, an image set to width: 600px, or an embedded widget with a hard-coded width. On a phone, these push the page wider than the screen and the whole site scrolls sideways.
Why it matters: Sideways scrolling is one of the fastest ways to make a site feel broken. It also hides content off-screen.
How to fix it: Use relative units and let elements shrink. A few lines cover most cases:
img, video, iframe { max-width: 100%; height: auto; }
/* Container: full width minus a gutter, capped at 70rem */
.container { width: min(100% – 2rem, 70rem); margin-inline: auto;
}
/* Grid that fits as many 18rem columns as there is room for */
.cards {
display: grid;
gap: 1.5rem;
grid-template-columns: repeat(auto-fit, minmax(min(18rem, 100%),
1fr));
}
How to test: Narrow your browser window to 320px wide. If a horizontal scrollbar appears, open DevTools and look for the element sticking out past the edge.
4. Setting breakpoints for devices instead of content
What it looks like: Breakpoints at exactly 375px, 768px and 1024px because those
were popular iPhone and iPad sizes. The layout looks fine on those three widths and breaks on everything in between, including foldable, small laptops and split-screen windows.
Why it matters: There are thousands of screen sizes in use, and new ones every year. Designing for specific devices means the layout is always out of date.
How to fix it: Add a breakpoint where your content starts to look wrong, not where a device happens to be. Slowly widen the browser and add a breakpoint at the point where lines get too long or cards get too stretched. Writing media queries in em also means they respond correctly when users increase their browser’s text size.
@media (min-width: 40em) { /* content needs two columns here */
}
@media (min-width: 62em) { /* and three here */ }
How to test: Drag the browser window slowly from narrow to wide and watch for the moments when the layout looks awkward.
5. Relying only on media queries for components
What it looks like: A product card looks great in the main grid but breaks when the same card appears in a narrow sidebar. Media queries only know the size of the screen, not the space a component actually has.
Why it matters: Modern sites, web apps and dashboards reuse the same components in many places. Older advice to “keep media queries simple” or “use a CSS preprocessor” doesn’t solve this.
How to fix it: Use container queries, which let a component respond to the width of its parent. They have been supported in all major browsers since 2023 and became Baseline “widely available” in
August 2025, so they are safe for production.
.card-list { container-type: inline-size; }
@container (min-width: 32rem) {
.card { display: grid; grid-template-columns: 10rem 1fr; gap: 1rem;
}
}
This matters even more in custom web applications, where panels and sidebars resize constantly.
How to test: Drop the component into the narrowest column on your site and check that it still looks intentional.
6. Using images that don’t adapt
What it looks like: A 2,400px hero image sent to every phone. Images without width and height attributes that make the text jump down as they load. A hero image that is lazy-loaded, so the most important visual on the page appears last.
Why it matters: Images are usually the heaviest part of a page. They drive Largest Contentful Paint (how fast the main content appears) and Cumulative Layout Shift (how much the page jumps), two of Google’s Core Web Vitals.
How to fix it: Serve several sizes and let the browser choose. Always set width and height so the browser reserves space. Load the hero image eagerly, and lazy-load images further down the page.
<!– Hero image: load first –>
<img src=”hero-800.webp”
srcset=”hero-480.webp 480w, hero-800.webp 800w, hero-1400.webp
1400w”
sizes=”(min-width: 64em) 50vw, 100vw”
width=”1400″ height=”788″
fetchpriority=”high”
alt=”Describe what the image shows”>
<!– Images below the fold: lazy-load –>
<img src=”team.webp” width=”800″ height=”533″ loading=”lazy”
alt=”…”>
Use WebP or AVIF instead of PNG and JPEG where you can. For the SEO side of images, file names and alt text.
How to test: Run the page through PageSpeed Insights on mobile and check the LCP element and any layout shift warnings.
7. Hiding content on mobile
What it looks like: To make the mobile page shorter, sections are hidden with display: none: testimonials, FAQs, product details, sometimes whole paragraphs of copy.
Why it matters: Because Google indexes the mobile version of your site, content that mobile visitors can’t see may not count toward your rankings. Hidden elements can also still download, so the page gets no faster. And mobile visitors often want the same detail desktop visitors do.
How to fix it: Keep the same content on every screen and change how it is presented. Use accordions, tabs or “show more” toggles to collapse long sections. The native <details> element is accessible and needs no JavaScript:
<details>
<summary>Technical specifications</summary>
<p>…</p>
</details>
Clear, complete content on every device also makes your pages easier for AI search engines to quote, which we cover in how to enhance your website for the GEO era.
How to test: Compare the mobile and desktop versions of your key pages side by side. Every heading and key fact should appear on both.
8. Making tap targets too small and relying on hover
What it looks like: Tiny close buttons, social icons packed tightly together, and dropdown menus that only open when a mouse hovers over them. On a touchscreen there is no hover, so those menus are hard or impossible to open.
Why it matters: WCAG 2.2, the current accessibility standard, requires interactive targets of at least 24×24 CSS pixels at level AA, unless they have enough space around them or sit inside a sentence. Apple and Google’s own design guidelines recommend larger targets, around 44–48px.
How to fix it: Give icon buttons a minimum size and enough spacing. Make menus open on tap with a real button, and only add hover behavior for devices that support it.
.icon-button { min-width: 44px; min-height: 44px; }
/* Only use hover effects where a mouse is available */
@media (hover: hover) {
.nav-item:hover > .submenu { display: block; }
}<button aria-expanded=”false”
aria-controls=”services-menu”>Services</button>
<ul id=”services-menu” hidden>…</ul>
How to test: Use your site one-handed on a phone. Open every menu and tap every icon. Any mis-tap is a target that needs to be bigger.
9. Using text that doesn’t scale
What it looks like: Body text fixed at 14px, headlines so large on mobile that one word fills a line, or paragraphs that stretch across a wide monitor so the eye loses its place.
Why it matters: If people have to zoom or squint, they leave. Readability also affects how long people stay on the page.
How to fix it: Use rem units so text respects the user’s browser settings, and clamp() so sizes scale smoothly between a minimum and maximum. Limit line length to around 65 characters.
body { font-size: clamp(1rem, 0.95rem + 0.25vw, 1.125rem); line-height:
1.6;
}
h1 { font-size: clamp(2rem, 1.5rem + 2.5vw, 3.5rem); line-height: 1.15;
}
.article-body { max-width: 65ch; }
/* Keep form fields at 16px or larger to stop iOS zooming in on focus
*/
input, select, textarea { font-size: max(1rem, 16px); }
How to test: Zoom your browser to 200%. The text should get bigger without anything overlapping or being cut off.
10. Ignoring mobile viewport bugs
What it looks like: A “full-screen” hero set to 100vh where the call-to-action button sits hidden
behind the phone browser’s address bar. A sticky header that takes up a quarter of a small screen. A form where the on-screen keyboard covers the field you’re typing in.
Why it matters: These bugs hit the most important parts of a page: the first screen and the forms that generate leads.
How to fix it:
- Use the newer viewport units. svh is the height with the browser’s toolbars showing, dvh adjusts as
they appear and disappear. Keep vh as a fallback for old browsers. - Keep sticky headers short on mobile, or hide them on scroll down and show them on scroll up.
- Add scroll-margin-top so links to headings don’t land underneath the sticky header.
.hero { min-height: 100vh; min-height: 100svh; }
h2[id] { scroll-margin-top: 5rem; }
How to test: Test on a real iPhone and a real Android phone. These bugs often don’t show up in desktop browser emulators.
11. Letting tables, forms and embeds overflow
What it looks like: Pricing or comparison tables that are wider than the phone screen. Videos and maps embedded at a fixed size. Forms that bring up the wrong keyboard, such as letters for a phone number field.
Why it matters: Tables and forms are where visitors compare and convert. Friction here directly costs leads and sales.
How to fix it:
/* Let wide tables scroll inside their own box, not the whole page
*/
.table-wrap { overflow-x: auto; }
/* Responsive video and map embeds */
.embed { width: 100%; aspect-ratio: 16 / 9; }
.embed iframe { width: 100%; height: 100%; border: 0; }<!– The right keyboard and autofill for each field –>
<input type=”email” name=”email” autocomplete=”email”>
<input type=”tel” name=”phone” autocomplete=”tel”>
For short tables, consider stacking each row as a card on small screens instead.
How to test: Fill out every form on your site from start to finish on a phone,
including error messages.
12. Skipping performance checks and real-device testing
What it looks like: The site was only ever checked in a desktop browser’s device mode on a fast office connection. On a mid-range phone over mobile data, it loads slowly and lags when people tap.
Why it matters: Google measures page experience with three Core Web Vitals, using data from real visitors:
- Largest Contentful Paint (LCP): the main content should appear within 2.5 seconds.
- Interaction to Next Paint (INP): the page should respond to taps within 200 milliseconds. INP replaced First Input Delay in March 2024.
- Cumulative Layout Shift (CLS): the layout should stay stable, with a score of 0.1 or less.
A slow, jumpy mobile site loses people before they read a word, which is one of the reasons a bad website drives customers away.
How to fix it: Cut unused scripts and plugins, defer non-critical JavaScript, compress images, use caching and a CDN, and keep third-party widgets to a minimum. Most INP problems come from heavy
JavaScript running when someone taps.
How to test: Build a testing routine that includes:
- At least one real iPhone and one mid-range Android phone
- Portrait and landscape orientation
- 320px width and 200% browser zoom, both accessibility requirements
- Chrome DevTools device mode with network and CPU throttling
- PageSpeed Insights for individual pages
- The Core Web Vitals report in Google Search Console for real-user data across the whole site.
Responsive design checklist
Before launching a new site or redesign, check that:
- The viewport meta tag is present and allows zoom
- No page scrolls sideways at 320px wide
- Breakpoints are based on content, and reusable components use container queries
- Images use srcset, have width and height, and the hero image isn’t lazy-loaded
- Mobile pages have the same content as desktop
- Tap targets are at least 24×24px and menus open on tap
- Text uses rem, scales with clamp(), and reads well at 200% zoom
- The first screen and forms work on real iOS and Android devices
- Tables, embeds and forms fit the screen and use the right keyboards
- LCP, INP and CLS are in the “good” range in Search Console
Getting these right is a front-end job. If you’re deciding whether to handle it in-house, our overview of front end development services explains what’s involved, and why website design and development matter for business covers the bigger picture.
Frequently asked questions
What is the most common responsive design mistake?
Designing desktop-first. Most of the other problems on this list, such as hidden content, cramped tap targets and slow mobile pages, come from treating mobile as a smaller copy of the desktop site instead of designing for it first.
Does responsive design affect SEO?
Yes. Google indexes and ranks the mobile version of your pages, so content and usability problems on mobile affect rankings directly. Responsive design also keeps one URL per page, which avoids the duplicate content and split links that separate mobile sites cause.
What breakpoints should I use for responsive design?
There is no fixed list. Start with mobile styles, then widen the browser and add a breakpoint wherever the content starts to look wrong. Many sites end up with two or three breakpoints, often around 40em, 62em and 80em, but your content should decide.
What is the difference between responsive and adaptive design?
A responsive design uses one flexible layout that adjusts continuously to any screen width. An adaptive design serves a few fixed layouts built for specific screen sizes. Responsive design is easier to maintain and handles new devices better, which is why it is the standard approach today.
How do I check if my website is responsive?
Resize your browser from narrow to wide, use Chrome DevTools device mode, and test on at
least one real iPhone and Android phone. Then check the Core Web Vitals report in Google Search Console to see how real mobile visitors experience your site. If your users need features a website can’t offer, such as offline access or push notifications, a mobile app may be the better route.
Get a responsive audit of your website
Responsive problems are easy to miss when you only look at your own site on your own phone. Our team tests sites across real devices, fixes layout and performance issues, and rebuilds where it makes more sense than patching. See examples in our case studies, or tell us about your website and we’ll get back to you within one business day.
