{"id":29,"date":"2024-09-30T06:39:50","date_gmt":"2024-09-30T06:39:50","guid":{"rendered":"https:\/\/itsonmedia.com\/blog\/blunders-to-avoid-in-responsive-websites\/"},"modified":"2026-10-27T15:36:06","modified_gmt":"2026-10-27T15:36:06","slug":"blunders-to-avoid-in-responsive-websites","status":"publish","type":"post","link":"https:\/\/itsonmedia.com\/blog\/blunders-to-avoid-in-responsive-websites\/","title":{"rendered":"12 Responsive Web Design Mistakes (and How to Fix Each One)"},"content":{"rendered":"

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.<\/span><\/p>\n

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 <\/span>web development team<\/span><\/a> runs responsive audits as part of every rebuild.<\/span><\/p>\n

The 12 mistakes at a glance<\/b><\/h2>\n
    \n
  1. Designing desktop-first<\/b> and squeezing the layout down to mobile.<\/span><\/li>\n
  2. A missing or restrictive viewport meta tag<\/b> that breaks scaling or blocks zoom.<\/span><\/li>\n
  3. Fixed pixel widths<\/b> that cause sideways scrolling.<\/span><\/li>\n
  4. Breakpoints based on devices <\/b>instead of where your content breaks.<\/span><\/li>\n
  5. Relying only on media queries<\/b> when a component needs container queries.<\/span><\/li>\n
  6. Images that don’t adapt<\/b>: no <\/span>srcset<\/span>, no dimensions, or a lazy-loaded hero image.<\/span><\/li>\n
  7. Hiding content on mobile<\/b>, which Google may then ignore.<\/span><\/li>\n
  8. Tap targets that are too small<\/b> and menus that only open on hover.<\/span><\/li>\n
  9. Text that doesn’t scale<\/b>: fixed font sizes, tiny body text, endless line lengths.<\/span><\/li>\n
  10. Mobile viewport bugs<\/b>: <\/span>100vh<\/span> overflow, oversized sticky headers, keyboards covering forms.<\/span><\/li>\n
  11. Tables, forms and embeds that overflow<\/b> the screen.<\/span><\/li>\n
  12. Ignoring performance and real-device testing<\/b>, so Core Web Vitals fail on real phones.<\/span><\/li>\n<\/ol>\n

    Quick reference<\/b><\/h3>\n
    \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
    Mistake<\/th>\nWhat Users Notice<\/th>\nFix<\/th>\nHow to Test<\/th>\n<\/tr>\n<\/thead>\n
    Desktop-First Design<\/th>\nCramped, cluttered mobile pages.<\/td>\nDesign the smallest screen first.<\/td>\nReview the mobile layout before desktop.<\/td>\n<\/tr>\n
    Bad Viewport Tag<\/th>\nTiny, zoomed-out pages or pinch-zoom restrictions.<\/td>\nwidth=device-width, initial-scale=1<\/code><\/td>\nView the page source.<\/td>\n<\/tr>\n
    Fixed Widths<\/th>\nHorizontal scrolling on mobile screens.<\/td>\nmax-width: 100%<\/code>, min()<\/code>, and
    \nminmax()<\/code>.<\/td>\n    		Resize the browser to 320px.<\/td>\n<\/tr>\n
    Device Breakpoints<\/th>\nLayouts break on intermediate screen sizes.<\/td>\nUse content-based breakpoints in em<\/code>.<\/td>\nDrag the browser window slowly from narrow to wide.<\/td>\n<\/tr>\n
    Media Queries Only<\/th>\nCards look wrong in sidebars or grids.<\/td>\nUse container queries.<\/td>\nPlace the component in a narrow column.<\/td>\n<\/tr>\n
    Non-Adaptive Images<\/th>\nSlow loading and content shifting.<\/td>\nsrcset<\/code>, sizes<\/code>, and explicit
    \nwidth<\/code>\/height<\/code> attributes.<\/td>\n    		Test with PageSpeed Insights for LCP and CLS.<\/td>\n<\/tr>\n
    Hidden Mobile Content<\/th>\nMissing information on phones.<\/td>\nCollapse content instead of hiding it.<\/td>\nCompare mobile and desktop content.<\/td>\n<\/tr>\n
    Small Tap Targets<\/th>\nMis-taps and menus that won’t open.<\/td>\nProvide targets of at least 24 \u00d7 24px, ideally 44 \u00d7
    \n44px.<\/td>\n    		Use the site one-handed on a phone.<\/td>\n<\/tr>\n
    Non-Scaling Text<\/th>\nSquinting or zooming to read text.<\/td>\nrem<\/code>, clamp()<\/code>, and a line
    \nlength of approximately 65ch.<\/td>\n    		Zoom the browser to 200%.<\/td>\n<\/tr>\n
    Viewport Bugs<\/th>\nButtons hidden behind browser bars.<\/td>\nUse svh<\/code> and dvh<\/code> units where
    \nappropriate.<\/td>\n    		Test on real iOS and Android devices.<\/td>\n<\/tr>\n
    Overflowing Tables and Forms<\/th>\nCut-off data and awkward mobile keyboards.<\/td>\nUse scroll wrappers and appropriate input types.<\/td>\nComplete every form on a phone.<\/td>\n<\/tr>\n
    No Performance Testing<\/th>\nSlow, laggy pages.<\/td>\nMeet Core Web Vitals targets for LCP, INP, and CLS.<\/td>\nReview the Core Web Vitals report in Google Search
    \nConsole.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

    1. Designing desktop-first<\/b><\/h2>\n

    What it looks like:<\/b> 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.<\/span><\/p>\n

    Why it matters:<\/b> 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 <\/span>technical SEO<\/span><\/a>, not just design.<\/span><\/p>\n

    How to fix it:<\/b> 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 <\/span>min-width<\/span> media queries to enhance larger screens.<\/span><\/p>\n

    \n

    \/* Base styles = mobile *\/<\/span>
    \n<\/span>.features { display: grid; gap: 1.5rem; }<\/span>
    \n<\/span>
    \n<\/span>\/* Enhance when there is room *\/<\/span>
    \n<\/span>@media (min-width: 48em) {<\/span>
    \n<\/span>\u00a0 .features { grid-template-columns: repeat(3, 1fr); }<\/span>
    \n<\/span>}<\/span><\/p><\/blockquote>\n<\/div>\n

    How to test:<\/b> Review designs at mobile width first in every design review. If stakeholders only ever see the desktop mockup, mobile will be an afterthought.<\/span><\/p>\n

    \"Same<\/p>\n

    2. A missing or restrictive viewport meta tag<\/b><\/h2>\n

    What it looks like:<\/b> Without the viewport tag, mobile browsers render the page at
    \na desktop width and shrink it, so everything is tiny. A different mistake is adding <\/span>user-scalable=no<\/span> or <\/span>maximum-scale=1<\/span>, which stops people from zooming into read.<\/span><\/p>\n

    Why it matters:<\/b> Blocking zoom is an accessibility failure for people with low vision, and it frustrates everyone else.<\/span><\/p>\n

    How to fix it:<\/b> Use this tag in the <\/span><head><\/span> of every page, and nothing more restrictive:<\/span><\/p>\n

    \n

    <meta name=”viewport” content=”width=device-width,
    \ninitial-scale=1″><\/span><\/p><\/blockquote>\n<\/div>\n

    How to test:<\/b> View the page source and search for “viewport”. Then try pinch-zooming on a real phone.<\/span><\/p>\n

    3. Using fixed pixel widths<\/b><\/h2>\n

    What it looks like:<\/b> A container set to <\/span>width: 1200px<\/span>, an image set to <\/span>width: 600px<\/span>, 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.<\/span><\/p>\n

    Why it matters:<\/b> Sideways scrolling is one of the fastest ways to make a site feel broken. It also hides content off-screen.<\/span><\/p>\n

    How to fix it:<\/b> Use relative units and let elements shrink. A few lines cover most cases:<\/span><\/p>\n

    \n

    img, video, iframe { max-width: 100%; height: auto; }<\/span>
    \n<\/span>
    \n<\/span>\/* Container: full width minus a gutter, capped at 70rem *\/<\/span>
    \n<\/span>.container { width: min(100% – 2rem, 70rem); margin-inline: auto;
    \n}<\/span>
    \n<\/span>
    \n<\/span>\/* Grid that fits as many 18rem columns as there is room for *\/<\/span>
    \n<\/span>.cards {<\/span>
    \n<\/span>\u00a0 display: grid;<\/span>
    \n<\/span>\u00a0 gap: 1.5rem;<\/span>
    \n<\/span>\u00a0 grid-template-columns: repeat(auto-fit, minmax(min(18rem, 100%),
    \n1fr));<\/span>
    \n<\/span>}<\/span><\/p><\/blockquote>\n<\/div>\n

    How to test:<\/b> Narrow your browser window to 320px wide. If a horizontal scrollbar appears, open DevTools and look for the element sticking out past the edge.<\/span><\/p>\n

    4. Setting breakpoints for devices instead of content<\/b><\/h2>\n

    What it looks like:<\/b> Breakpoints at exactly 375px, 768px and 1024px because those
    \nwere 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.<\/span><\/p>\n

    Why it matters:<\/b> 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.<\/span><\/p>\n

    How to fix it:<\/b> 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 <\/span>em<\/span> also means they respond correctly when users increase their browser’s text size.<\/span><\/p>\n

    \n

    @media (min-width: 40em) { \/* content needs two columns here *\/
    \n}<\/span>
    \n<\/span>@media (min-width: 62em) { \/* and three here *\/ }<\/span><\/p><\/blockquote>\n<\/div>\n

    How to test:<\/b> Drag the browser window slowly from narrow to wide and watch for the moments when the layout looks awkward.<\/span><\/p>\n

    5. Relying only on media queries for components<\/b><\/h2>\n

    What it looks like:<\/b> 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.<\/span><\/p>\n

    Why it matters:<\/b> 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.<\/span><\/p>\n

    How to fix it:<\/b> 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
    \nAugust 2025, so they are safe for production.<\/span><\/p>\n

    \n

    .card-list { container-type: inline-size; }<\/span>
    \n<\/span>
    \n<\/span>@container (min-width: 32rem) {<\/span>
    \n<\/span>\u00a0 .card { display: grid; grid-template-columns: 10rem 1fr; gap: 1rem;
    \n}<\/span>
    \n<\/span>}<\/span><\/p><\/blockquote>\n<\/div>\n

    This matters even more in <\/span>custom web applications<\/span><\/a>, where panels and sidebars resize constantly.<\/span><\/p>\n

    How to test:<\/b> Drop the component into the narrowest column on your site and check that it still looks intentional.<\/span><\/p>\n

    6. Using images that don’t adapt<\/b><\/h2>\n

    What it looks like:<\/b> 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.<\/span><\/p>\n

    Why it matters:<\/b> 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.<\/span><\/p>\n

    How to fix it:<\/b> 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.<\/span><\/p>\n

    \n

    <!– Hero image: load first –><\/span>
    \n<\/span><img src=”hero-800.webp”<\/span>
    \n<\/span> \u00a0 \u00a0 srcset=”hero-480.webp 480w, hero-800.webp 800w, hero-1400.webp
    \n1400w”<\/span>
    \n<\/span> \u00a0 \u00a0 sizes=”(min-width: 64em) 50vw, 100vw”<\/span>
    \n<\/span> \u00a0 \u00a0 width=”1400″ height=”788″<\/span>
    \n<\/span> \u00a0 \u00a0 fetchpriority=”high”<\/span>
    \n<\/span> \u00a0 \u00a0 alt=”Describe what the image shows”><\/span>
    \n<\/span>
    \n<\/span><!– Images below the fold: lazy-load –><\/span>
    \n<\/span><img src=”team.webp” width=”800″ height=”533″ loading=”lazy”
    \nalt=”…”><\/span><\/p><\/blockquote>\n<\/div>\n

    Use WebP or AVIF instead of PNG and JPEG where you can. For the SEO side of images, file names and alt text.<\/span><\/p>\n

    How to test:<\/b> Run the page through PageSpeed Insights on mobile and check the LCP element and any layout shift warnings.<\/span><\/p>\n

    7. Hiding content on mobile<\/b><\/h2>\n

    What it looks like:<\/b> To make the mobile page shorter, sections are hidden with <\/span>display: none<\/span>: testimonials, FAQs, product details, sometimes whole paragraphs of copy.<\/span><\/p>\n

    Why it matters:<\/b> 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.<\/span><\/p>\n

    How to fix it:<\/b> 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 <\/span><details><\/span> element is accessible and needs no JavaScript:<\/span><\/p>\n

    \n

    <details><\/span>
    \n<\/span>\u00a0 <summary>Technical specifications<\/summary><\/span>
    \n<\/span>\u00a0 <p>…<\/p><\/span>
    \n<\/span><\/details><\/span><\/p><\/blockquote>\n<\/div>\n

    Clear, complete content on every device also makes your pages easier for AI search engines to quote, which we cover in <\/span>how to enhance your website for the GEO era<\/span><\/a>.<\/span><\/p>\n

    How to test:<\/b> Compare the mobile and desktop versions of your key pages side by side. Every heading and key fact should appear on both.<\/span><\/p>\n

    8. Making tap targets too small and relying on hover<\/b><\/h2>\n

    What it looks like:<\/b> 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.<\/span><\/p>\n

    Why it matters:<\/b> WCAG 2.2, the current accessibility standard, requires interactive targets of at least 24\u00d724 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\u201348px.<\/span><\/p>\n

    How to fix it:<\/b> 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.<\/span><\/p>\n

    \n

    .icon-button { min-width: 44px; min-height: 44px; }<\/span>
    \n<\/span>
    \n<\/span>\/* Only use hover effects where a mouse is available *\/<\/span>
    \n<\/span>@media (hover: hover) {<\/span>
    \n<\/span>\u00a0 .nav-item:hover > .submenu { display: block; }<\/span>
    \n<\/span>}<\/span><\/p>\n

    <button aria-expanded=”false”
    \naria-controls=”services-menu”>Services<\/button><\/span>
    \n<\/span><ul id=”services-menu” hidden>…<\/ul><\/span><\/p><\/blockquote>\n<\/div>\n

    How to test:<\/b> 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.<\/span><\/p>\n

    9. Using text that doesn’t scale<\/b><\/h2>\n

    What it looks like:<\/b> 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.<\/span><\/p>\n

    Why it matters:<\/b> If people have to zoom or squint, they leave. Readability also affects how long people stay on the page.<\/span><\/p>\n

    How to fix it:<\/b> Use <\/span>rem<\/span> units so text respects the user’s browser settings, and <\/span>clamp()<\/span> so sizes scale smoothly between a minimum and maximum. Limit line length to around 65 characters.<\/span><\/p>\n

    \n

    body { font-size: clamp(1rem, 0.95rem + 0.25vw, 1.125rem); line-height:
    \n1.6;
    \n}<\/span>
    \n<\/span>h1 \u00a0 { font-size: clamp(2rem, 1.5rem + 2.5vw, 3.5rem); line-height: 1.15;
    \n}<\/span>
    \n<\/span>.article-body { max-width: 65ch; }<\/span>
    \n<\/span>
    \n<\/span>\/* Keep form fields at 16px or larger to stop iOS zooming in on focus
    \n*\/<\/span>
    \n<\/span>input, select, textarea { font-size: max(1rem, 16px); }<\/span><\/p><\/blockquote>\n<\/div>\n

    How to test:<\/b> Zoom your browser to 200%. The text should get bigger without anything overlapping or being cut off.<\/span><\/p>\n

    10. Ignoring mobile viewport bugs<\/b><\/h2>\n

    What it looks like:<\/b> A “full-screen” hero set to <\/span>100vh<\/span> where the call-to-action button sits hidden
    \nbehind 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.<\/span><\/p>\n

    Why it matters:<\/b> These bugs hit the most important parts of a page: the first screen and the forms that generate leads.<\/span><\/p>\n

    How to fix it:<\/b><\/p>\n