Test your website on mobile before launch

If your launch checklist for mobile is “I looked at it in Chrome’s device mode and it seemed fine,” you haven’t tested mobile — you’ve previewed it. The two are different. A preview shows you a phone-shaped frame and trusts your eye; a test loads the page at a real phone width and tells you, specifically, what’s broken: the page is 103 pixels wider than the screen, this element is the one overflowing, fourteen of your buttons are too small to tap. That’s a verdict you can act on, not a vibe.

The safe way to test your website on mobile before launch is to check three things plain code can measure at a phone viewport — does the page fit the screen, are the tap targets big enough for a finger, and do any JavaScript errors fire on mobile that didn’t on desktop — and then load the live site on an actual phone to confirm. This piece is what breaks on mobile, ranked, and how to verify each one. In a June 2026 audit of 49 fresh web launches, 38 (78%) shipped with at least one critical verified finding on day one. (That audit walks public pages, so it’s a launch-day quality signal, not a mobile-specific one — but launch-day code ships broken far more often than founders expect, and the phone is where it shows.)

Why a desktop self-test and devtools miss this

You build on a wide screen. You test on the same wide screen. The one time you check mobile, you toggle your browser’s device mode — which resizes the viewport but is still your desktop browser, with your desktop extensions, your warm cache, and your habit of not actually tapping anything with a fingertip. Device mode is genuinely useful while you build, but it’s an emulation of size, and it gives you no pass/fail: nothing flags that a button is 18px tall, nothing diffs the mobile console against the desktop one, nothing measures that the page is wider than the screen. You have to notice, and on a page you’ve seen a thousand times, you won’t.

Static checkers miss it from the other direction. A pre-launch static audit confirms the page exists, returns 200, and has its meta tags — but it loads the markup, it doesn’t render the page at a phone width, so it never sees a layout that overflows or a tap target that’s too small. Mobile breakage is a rendering problem, and rendering problems only appear when something actually renders the page at that width. The good news is the same as with signup flows and checkout flows: the surface is small and bounded. A handful of things break on mobile. You can know all of them.

The things that break on mobile

In rough order of how often they show up — on real launches and on our own site:

1. The page is wider than the screen (sideways scroll). The single most common mobile bug, and the most embarrassing: a phone visitor lands and the whole page can be dragged sideways, with content clipped off the right edge. Why it happens: one element — a fixed-width image, a table, a min-width on a container, a negative margin — is wider than the viewport, and it drags the whole layout with it. Or a responsive rule that was supposed to hide or shrink something got silently overridden. Verify it: load the page on a phone (or at a 390px-wide viewport) and try to scroll horizontally. If it moves, something is overflowing — and you want the specific element, because the fix is almost always one constraint on one node.

2. Tap targets are too small to hit with a finger. Links and buttons that are easy to click with a 1px cursor are a coin toss to tap with a fingertip. Why it happens: desktop-sized buttons, icon links with no padding, menu items packed tight, or a “close” X that’s 12px square. Verify it: the WCAG 2.5.8 minimum is 24×24px of hit area; many design systems push for 44px. On your most important actions — the signup button, the nav, the checkout CTA — confirm they’re at least finger-sized. Undersized targets mean mis-taps and rage-taps on exactly the elements you most need pressed.

3. JavaScript errors that fire only on mobile. The page works on your desktop and throws on a phone — a script that assumes a hover event, a library that chokes on a touch interface, an API that behaves differently on a mobile user-agent. Why it happens: code paths that only execute on touch/mobile, or third-party scripts that branch on user-agent. Verify it: this is the one you can’t catch by looking — you have to read the console on mobile and compare it to desktop. An error that’s present on the phone but not the desktop is a mobile-only break, and it’s invisible until someone hits it.

4. Content clipped or hidden behind a broken responsive rule. A media query meant to hide a desktop-only element on small screens fires when it shouldn’t — or fails to fire when it should — and a button, a price, or a whole section vanishes on mobile. Why it happens: CSS specificity. A @media rule gets out-ranked by a more specific selector, so the rule you wrote “to fix mobile” never actually applies. Verify it: check that everything important on desktop is also present and reachable at a phone width — especially your primary CTA.

5. The viewport meta tag is missing or wrong. Without <meta name="viewport" content="width=device-width, initial-scale=1">, the phone renders a zoomed-out desktop layout — tiny text, everything shrunk to fit. Why it happens: it’s one line in <head> and easy to omit on a hand-built page. Verify it: view the page on a phone; if it loads zoomed out and you have to pinch to read, the viewport tag is the first thing to check.

We’ve shipped #1 ourselves. A green CI deployed a 103px horizontal overflow on prufa.dev: a @media (max-width: 520px) { .header-cta { display: none } } rule that was supposed to hide a header button on small screens, silently out-ranked by a more specific a.btn-primary selector, so the button stayed visible and pushed the page 103px past the edge of a phone screen. Our test suite was green; the page was broken on every phone. We caught it only when an automated pass loaded the page at the mobile viewport and measured the overflow — the full story is in the time we pointed our chaos-QA agent at our own site. The lesson: this class of bug is invisible to a passing test suite and to a quick desktop glance, and visible the instant something renders the page at a phone width.

How Prufa checks mobile

Prufa runs the same pattern here it runs everywhere: an LLM does the navigation, plain code does the verification. For mobile, the verification is literal measurement — which is why these findings are verified, not opinion.

On every audit, Prufa does a second pass: it re-opens your entry page in a real browser engine at a 390×844 phone viewport (iPhone-class), lets it settle, and then measures the rendered page directly. Three checks run against what it measured, and each one is plain arithmetic on real numbers, so each carries Prufa’s highest evidence tier:

• Horizontal overflow. It computes scrollWidth − innerWidth. If the page is more than a few pixels wider than the viewport, that’s the sideways-scroll bug — and it reports the exact overflow in pixels and the selectors of the offending elements, so you fix the cause, not hunt for it. (Our own 103px bug is exactly what this check is built to catch.)
• Tap targets. It finds interactive elements smaller than 24px and counts them, with samples, citing the WCAG 2.5.8 minimum. Ten or more is flagged as a warning — a layout that wasn’t built for fingers.
• Mobile-only JavaScript errors. It captures the console at the phone viewport and diffs it against the desktop console, reporting only the errors that appear on mobile and not on desktop. That diff is the point: a raw console dump is noise; the errors that are new on mobile are the signal.

Because the LLM only navigates and never grades the result, its blind spots can’t become the verifier’s blind spots — the pixel measurement is what decides, not the model’s opinion of how the page looks.

What the free 60-second audit does for mobile

Here’s where mobile differs from the auth flows: the mobile pass runs in the free audit on prufa.dev, no card and no signup required. The flow walks (signup, login, checkout) need a credential the anonymous tier doesn’t have — but rendering your public entry page at a phone viewport needs nothing but the URL. So the free audit already loads your page at 390px and reports the overflow (with the offending selector), the small-tap-target count, and any mobile-only console errors, alongside the rest of the pre-launch checks. It’s the fastest way to get a real mobile verdict, free — to turn “looks fine on my screen” into a list of specific things to fix.

Keeping it fixed after launch is the paid tier’s job: Starter ($29/mo) re-verifies your site daily and on every deploy and alerts you when something regresses — which matters because a responsive layout that’s fine today breaks the day you add a wide component or a third-party embed, exactly the kind of silent rot that hits an app after launch.

What the audit doesn’t do (honest limits)

A phone-viewport check is one representative width (390px) in a real browser engine — it’s an emulation of size, not a physical device. It catches the big three: overflow, undersized tap targets, and mobile-only JS errors. It does not replace real-device testing: it won’t exercise real touch gestures, the iOS notch and safe-area insets, GPU-specific rendering, device-specific Safari or Chrome quirks, or a long matrix of OS and browser versions. That’s exactly where real-device clouds like BrowserStack and LambdaTest genuinely win — when you need to confirm behavior on specific hardware, pay for the device lab. And if the mobile pass can’t load your page at all (a timeout, a hard block), it reports nothing for mobile rather than a false “all clear” — a skipped check is never a passing one. For the rest of the pre-launch surface — sitemaps, meta tags, broken links, console errors — see the website QA checklist before launch.

What to do before you launch

In order of impact:

1. Open the live site on a real phone. Not device mode — an actual phone, on cellular if you can, so you also feel the load. Try to scroll sideways; if it moves, you have an overflow.
2. Run the free audit and fix overflow first. It gives you the overflow in pixels and the offending selector. Sideways scroll is the most visible mobile bug and usually a one-line fix once you know the element.
3. Size your key tap targets to at least 24px. The signup button, the nav, the primary CTA — anything a thumb has to hit. 44px if you can.
4. Read the console on mobile. Compare it to desktop. Anything new on mobile is a mobile-only break to chase down before a user finds it.
5. Confirm the viewport meta tag is present. If the page loads zoomed out and you’re pinching to read, that one line in <head> is missing or wrong.

Get those five right and the phone — where most of your visitors actually are — stops being the place your launch quietly falls apart. This is pre-launch QA for indie hackers above all — when you’re shipping your own site, no one else is going to catch the phone bugs for you.