Does an AI website audit check mobile?
Revslip renders your page at a phone viewport and reads the screenshot next to the HTML, so it measures mobile layout exactly. It does not measure your thumb, and this post draws the line precisely.
Revslip renders your page at a phone viewport, screenshots it, and reads that picture next to the HTML. So it sees your mobile layout. It does not see your thumb.
The objection arrives in one sentence: "These things just read my code. They have no idea what my site actually looks like on a phone."
That was fair about the first audit tools. A crawler fetched the HTML, counted headings and filed a report. Nothing in it had a screen. Rendering changed that.
Does an AI website audit check mobile, or just the code?
Revslip crawls your key pages, captures a desktop and a mobile screenshot plus a full-page render, then reads those images beside the HTML. Anything the browser computes at that width, including layout, text size and button dimensions, gets measured directly. The handset's own contribution does not.
A render is a real measurement, not a real device. Chrome's DevTools documentation calls device mode "a first-order approximation" and warns of "aspects of mobile devices that DevTools will never be able to simulate".
What does your own site look like at 390 pixels?
Open your homepage in Chrome on a laptop, press Ctrl+Shift+I or Cmd+Option+I, click the small phone icon at the top left of the panel that appears, pick iPhone 14 Pro and reload. You are now seeing roughly what an audit sees. Ninety seconds, no account.
Then ask one question. Is the button you want pressed visible without scrolling? Your hero gets about 900 pixels of height on a laptop and about 700 at 390 by 844.
Not sure which page breaks first? Revslip renders each one at phone width.
Why does a code-only read miss the fold?
Because the fold is not in the code. Where a page cuts off depends on the browser's own furniture, the address bar and toolbar, which take height from the page and hand it back as you scroll. A headless render has no address bar, so it never shows the cut.
MDN's reference states that "all default viewport units (vh, vw, etc.) are equivalent to their large viewport counterparts", the large viewport being what you get when "browser interfaces" retract.
So a hero built at 100vh is sized for the phone with the bar hidden. Nobody has scrolled on first load, so its bottom edge sits off screen. Often that bottom is the button.
A rendered page tells you what your layout does. A real phone tells you what the browser does to your layout.
What do the standards bodies actually require?
They disagree by a factor of two. WCAG 2.2 from the W3C sets the minimum tap target at "24 by 24 CSS pixels". Google's own Lighthouse audit flags any target "smaller than 48 px by 48 px". Both are current, and any tool reporting "too small to tap" has quietly picked one.
A 30 pixel button passes the W3C minimum and fails the Lighthouse tap target audit. Same button, two verdicts, no bug in either tool. So the question is which threshold the finding used, and whether that fits your visitors.
There is also no single phone to design for. Statcounter's September 2026 figures, from an analytics vendor measuring its own network, list six mobile screen sizes above three per cent of traffic.
- 13.35% of mobile traffic at 414x896
- 7.54% at 360x800
- 7.1% at 384x832
- 41.61% all six most common sizes added together
Widths bunch between 360 and 414. Heights spread from 780 to 896. Width is the stable half of a screenshot.
What founders say when the phone view breaks
"It looks fine on my MacBook." "I only check it on my own phone, and my phone is four years old." "I did not know the menu covered the price until my brother screenshotted it." Colour, not evidence, but the shape repeats: you cannot be a stranger to your own site.
How do you check the mobile view in ten minutes?
Work top down and change nothing yet. Open your four most visited pages at phone width, screenshot the first screenful of each, and write one line per page on what is missing or unreadable. Then fix them in traffic order.
- The first screenful. Headline, one line of support, one button. If the button is missing, move it up.
- Thumb reach. Anything under 44 pixels square gets missed, and links closer than 8 pixels get mistapped.
- Text size. Body copy under 16 pixels invites pinch zoom, and pinchers usually leave.
- The overlays. Cookie banner, chat bubble and sticky bar stack up at 390 pixels wide, where they can own a third of the screen.
- One real handset. Load the page on the office's oldest phone, on cellular. No tool does this.
Want the first four done for you? Paste your URL and read the mobile findings.
What should move after you fix the fold?
Watch mobile conversion rate on the page you changed, and watch it against desktop across the same weeks. Desktop is your control, because a slow trading week hits both. Give it four full weeks before reading the gap between them.
If that page does 40 mobile sales a month, 40 to 44 is noise. Mobile up while desktop sits still means you fixed a mobile problem. Both up means your traffic mix changed. Check the normal size of the mobile gap first.
Which mobile problems no audit tool will catch
Touch is not in a picture. Neither is the keyboard sliding up over the field you are typing into, nor how a page feels under a thumb on a four-year-old handset. Revslip reads a render, so every mobile finding it hands you is a layout finding.
The part a screenshot cannot show you Revslip renders one mobile viewport per audit, not a matrix of handsets, and it never runs on a physical phone. So pair it with two minutes on a real device before you sign off a page, which is where keyboard overlap, iOS Safari quirks and sluggish scrolling show up.
The device cloud vendors push this harder than we would. BrowserStack, which sells real handsets by the hour, calls emulators "not reliable for UI/UX or performance testing". It profits from saying so and is right about touch and speed. Chrome's team lands on the same advice from the other side: "when in doubt, your best bet is to actually run your page on a mobile device".
Both are right, once you split the subject. Layout, exact. Feel, guess.
Revslip runs no accessibility conformance review either, so a tap target finding from us is a conversion observation and not a WCAG verdict, which a conformance checker alongside gives you. Across the 134 businesses audited so far, mobile layout problems turn up constantly, though those are worried owners, not a random sample.
Questions people ask about mobile audits
These three come up on nearly every call, and all three are really the same question from different angles. How much of what a visitor meets on a phone can be measured by a machine that is not holding one?
Does it test on a real iPhone?
No. Revslip renders your pages at phone dimensions and reads the result, accurate for layout and wrong for touch and speed. Hence the last step above.
Which phone width should I design for?
Design so nothing breaks at 360 pixels, then check at 414. Statcounter's September 2026 data puts the common widths inside that band, and a layout surviving the narrow end survives the rest.
Is a Lighthouse mobile score the same thing?
No. Lighthouse grades speed, and its SEO checks include tap targets. It does not read your headline. The two meanings of AI audit tool covers why these get confused, and how far to trust an AI audit the rest.