How to fix an AI-built website that isn't mobile friendly
The AI built the site against a desktop preview. The preview is roughly 1280 pixels wide. The real visitor is on a phone that's roughly 390 pixels wide. The layout that worked at 1280 doesn't necessarily work at 390, and most of the mobile failures in AI-built sites come from that gap.
This matters because more than half of typical website traffic is mobile. If the mobile experience is broken, half of your visitors are bouncing before they ever see what the site is for. The desktop traffic might think the site is fine. The mobile traffic knows it isn't.
Five failures show up most often. Each has a real-device diagnostic and a fix.
Failure one: horizontal overflow
The page is supposed to be confined to the viewport width. Instead, something inside the page extends past the right edge and the visitor can scroll horizontally. The site feels broken because page elements are partially off-screen.
The cause is usually an element with a fixed width (a table, an image, a wide container, sometimes a long unbreakable URL) that doesn't shrink to fit the smaller viewport. The AI didn't constrain the element because the desktop preview never tested at a narrow viewport.
The diagnostic is to open the site on a real phone and try to scroll horizontally. If you can, something is overflowing. Devtools has a "responsive mode" that simulates phone viewports, but the real device surfaces failures the simulator misses, especially around scrollbar behavior and font rendering.
The fix is to find the overflowing element (devtools shows you when you inspect) and add proper responsive sizing. Most often this is a CSS issue: max-width: 100%, overflow handling, or flexible width units instead of fixed pixels.
Failure two: touch targets too small
The AI styled buttons, links, and form controls for a mouse cursor. The mouse cursor can hit a 16-pixel target accurately. A human thumb cannot. Apple's interface guidelines say touch targets should be at least 44 pixels. Google's say 48. AI-built sites often have touch targets in the 24-30 pixel range, which means visitors mis-tap, hit the wrong thing, get frustrated, leave.
The diagnostic is the real-device walk. Try to tap every button, link, form field, and navigation element with your thumb. Note every mis-tap or near-mis. Each one is a percentage of visitors who're hitting the same friction.
The fix is to enforce minimum touch-target sizes. Buttons get adequate padding. Links in tight clusters get extra hit area. Form controls (especially checkboxes and radio buttons) get bigger interactive zones than their visual zone if necessary. The visual design can stay tight; the interactive hit area expands to thumb-friendly.
Failure three: virtual keyboard breaks the layout
The visitor taps an input field. The mobile keyboard pops up and covers the bottom half of the viewport. Now the submit button is hidden, or the field they're typing into is hidden, or the layout has reflowed in a way that makes the form impossible to complete one-handed.
This is one of the most consistently broken behaviors on AI-built mobile sites because the AI's environment doesn't simulate the keyboard. The visitor experience is genuinely worse than the operator realizes.
The diagnostic is to open the form on a real phone, tap each field, and verify you can see what you're typing and reach the submit button without dismissing the keyboard. Common failures: submit below the fold, layout that uses 100vh sizing (which assumes the keyboard isn't there), focus-traps that don't release cleanly.
The fix involves several patterns: avoid 100vh on layout containers (use dvh dynamic viewport height instead, which accounts for the keyboard), make sure the submit button stays reachable when keyboard is open, ensure focus styles are visible enough that the visitor can see which field they're in, test that switching between fields with the next-field arrow works smoothly.
Failure four: modals that can't be dismissed
The site has a modal (newsletter signup, age verification, cookie banner, account creation). On desktop, the close button is clickable. On mobile, the close button is either off-screen, behind the keyboard, too small to tap, or positioned in a way the thumb can't reach one-handed. The visitor can't dismiss the modal and can't see the page underneath. They leave.
This is one of the most expensive mobile failures because it blocks the entire visitor experience until resolved. And the visitor's resolution is usually to close the tab.
The diagnostic is to load every modal on a real phone and try to dismiss it. Try with one thumb, not two hands. The close button has to be reachable, large enough, and clearly close-buttonish (an X, not just a small icon).
The fix is to design modals mobile-first. The close button should be in the upper-right corner with adequate size. The modal should be dismissible by tapping outside it or by swipe-to-dismiss patterns. The modal shouldn't trigger on mobile if it can't render properly there.
Failure five: performance is worse on cellular
The site loads acceptably on the operator's home wifi. On a 4G cellular connection (let alone 3G or LTE in a weak-signal area), the page is unusable. Images that downloaded in 200ms over wifi take 4 seconds over cellular. Scripts that parsed in 100ms on the operator's modern desktop take 2 seconds on the visitor's three-year-old phone.
This is a mobile performance failure separate from desktop performance. A site can hit acceptable desktop Core Web Vitals while failing mobile Core Web Vitals badly.
The diagnostic is to load the site on a real phone, over cellular (not wifi), and measure how long it takes to become usable. PageSpeed Insights also separates mobile and desktop scores so you can see the gap.
The fix is the same mobile-first thinking: smaller images for smaller viewports, lazy-loading for everything below the fold, reduced JavaScript on mobile if possible, simpler interactions that don't require loading heavy libraries. The performance post covers the broader patterns.
The architectural pattern that fixes this durably
The pattern that prevents mobile failures from creeping back is to design with the mobile path as the primary path, then enhance to desktop. Not the reverse. When mobile is the first-class consideration, the layout works at narrow viewports by default, touch targets are thumb-sized from the start, modals are dismissible without precision, and performance is measured against cellular conditions.
The pattern shows up in component architecture too. On this site, the /log mesh visualization has explicit different code paths for desktop and mobile. Desktop renders a 3D interactive canvas with cursor-driven hover tooltips. Mobile renders a 2D radial fallback with touch-friendly nodes. They are not the same component with conditional styles. They are two distinct rendering paths chosen at the gate, because the interaction patterns are too different to share. The principle is documented as an invariant in the SPEC: the navigable surface must work for the device type, not be a compromise across types.
That's heavier than most AI tools default to, but it's the discipline that produces sites that don't have hidden mobile failures.
The patch vs the redesign
If the site is shipping with mobile failures and needs to be fixed quickly, patching the five failures above gets the worst of it. Real-device walk, fix the overflow, fix the touch targets, fix the keyboard interaction, fix the modals, audit the cellular performance. A focused day of mobile work usually moves the site from "broken on phones" to "acceptable on phones."
If the site needs to perform well on mobile (and most sites do, given the traffic mix), the redesign with mobile-first thinking is the durable answer. Patching keeps the symptom in check. Redesigning removes the source.
Pick the one that matches your timeline and your audience's mobile reliance.
Got an AI-built site that breaks on phones and you can't tell whether the patch is enough or you need a redesign? Send the site URL and a description of what fails. VibeKoded can scope the build, ship the prototype, or hand off the production site. → Work with VibeKoded