The Complete Index rows on my rebuilt WordPress theme looked correct in Chrome DevTools. On an actual phone, the title text and the category badge were rendering on top of each other, completely unreadable. That gap between what the emulator showed me and what a real screen showed me is the entire reason most people do not know how to test a website on mobile properly, even when they think they already do.
I had just finished a full theme rebuild for RemoteWorkHaven, my remote work content site. Claude Design produced the mockup, the theme got vibe coded from that mockup, and I hand coded the parts that needed a real decision instead of a plausible guess. I already covered the three tier QA framework that build forced on me in testing a vibe coded WordPress theme before deployment. This is the part that post did not go deep on: what actually happens when you test that same build specifically on mobile, and why the desktop pass and the DevTools pass both told me it was fine.
Why Passing DevTools Is Not the Same Claim as Mobile Safe
Most generic advice on testing a website on mobile stops at resizing your browser window or running it through Google’s Mobile-Friendly Test. Both of those are fine as a first pass. Neither of them is testing. They tell you the page did not technically crash. They do not tell you whether a real thumb on a real screen can actually read the thing you shipped.
The theme I built uses fluid CSS, clamp() and container query units scaling font size, padding, and column count smoothly across the whole size range with no breakpoints. That is genuinely good architecture for continuous scaling. What it is not is mobile safety. Fluid scaling and structural reflow are two different problems. A clamp() value has a built in ceiling, so headings and padding stop growing past a certain width, and that is intentional. But collapsing a three column layout into one stacked column, or hiding a sidebar entirely below a certain width, is a binary switch. No formula smoothly interpolates side by side into stacked. That is what a breakpoint is for, and mistaking one problem for the other is exactly how a build that looks finished ships broken.
The Bug Pattern That Kept Repeating
The Complete Index bug was the first one I caught, and it was structural in the most literal sense. The row used a rigid four column grid, number, title, category, read time, and the two fixed width side columns reserved over 200 pixels combined on a roughly 412 pixel phone screen. That left almost nothing for the title, so the wrapped text garbled itself against the badge next to it. The section of the same theme handling “Most read” rows never had this problem because it had already been built as number plus title only. The Complete Index rows just never got the same treatment.
Once I saw that pattern, I went looking for it elsewhere instead of patching that one instance and moving on. I found it three more times. The Author, About, and Contact page heroes used a grid split that crammed a photo and a row of social buttons into a narrow side column below 900 pixels, with no aspect-ratio set and no mobile handling at all. The homepage and post header heroes had the same underlying bug in a different grid ratio, an image column left as an empty strip instead of stacking, and I only found that one because I specifically flagged those two templates as a live deployment risk rather than because systematic testing caught it on its own. The social button row inside that same cramped column used flex with no flex-wrap, so three buttons had nowhere to go and visually intersected on a phone screen.
Four separate templates, same root cause, found one at a time. That is the actual shape of testing a website on mobile on a real build. You do not catch the whole pattern in one pass. You catch one instance, you go hunting for its siblings, and you keep hunting until the pattern stops repeating.
What a Real Phone Catches That DevTools Does Not
Chrome and Firefox’s device toolbars are useful for a fast layout check, confirming how a grid or a breakpoint behaves without needing a phone in your hand. But it is still your desktop browser under the hood, not actual mobile Safari or Chrome on Android. Touch behavior, real viewport rendering, and font handling are not guaranteed to match.
For this build, I tested locally through LocalWP, and Local’s Live Link feature tunnels the local site to a temporary public URL you can open directly on your actual phone. That is where the Complete Index bug actually surfaced as a screenshot instead of a hypothesis. It is also where a caching or security plugin left active on the local environment will make Live Link flaky or fail to load correctly, which is worth knowing before you assume the theme itself is broken when the tunnel is what is actually struggling. A cloud device lab like BrowserStack fills the same real hardware gap once you are past local testing and need a wider spread of actual OS and browser combinations before final sign off.
What came out of testing on a real phone was not just bug fixes, it was an actual design standard. My instinct going in was to shrink everything down proportionally and keep every element present, just smaller. What I landed on instead, after seeing how cluttered that looked on an actual screen, was dropping entire rails rather than compressing them. On mobile, the post body drops both the table of contents rail and the sidebar rail completely, replaced by a collapsible inline summary and the article itself. Desktop gets the full layout. Mobile gets a stripped down, readable version, not a cramped miniature of the desktop one. That standard would not have come from a DevTools pass alone. It came from looking at an actual phone screen and being honest about what “readable” meant there.
The Discrepancy Even Experienced QAs Forget to Check
Here is the one that has nothing to do with this specific build and everything to do with a habit I have caught myself slipping on more than once. Chrome and Firefox render DevTools’ device emulation differently. This is something most QAs learn early, in their junior stage, and then quietly stop checking once they have been doing the work long enough to trust their instincts.
The trap is specific, and it is not simple forgetfulness. Once you have seen a bug get fixed and confirmed in one browser’s DevTools, the visual confirmation convinces you the fix is done everywhere. You watched it get fixed. You saw the screenshot. So you move on, and you do not open the second browser to check, because your brain has already filed the bug as closed. That is a different failure than not knowing the rule exists. It is trusting a single confirmation past the point where it actually proves anything, which is exactly the kind of gap that survives in experienced testers precisely because they are experienced enough to feel confident without rechecking. The parent build for this piece covers cross browser regression in more depth in visual and cross browser regression, the judgment no tool ships with, if you want the deeper mechanics of what a rendering engine difference actually looks like once you go looking for it.
What Testing a Website on Mobile Actually Looks Like
Put together, the actual pass is not one step, it is three, run in order, and skipping any one of them is how bugs like these ship to a monetized site unnoticed. Local first, on an environment like LocalWP where you can iterate fast without touching a live server. DevTools next, in more than one browser engine, not just whichever one happens to be open, since Chrome and Firefox will not always agree with each other. Real device last, whether that is a tunnel like Live Link or a cloud lab like BrowserStack, because that is the only stage that confirms what an actual thumb on an actual screen experiences, and it is the stage every generic “resize your browser” checklist skips entirely.
None of this is specific to WordPress. The theme here happened to be a WordPress theme, and it happened to be built with a mix of AI generated UI and hand coded fixes, but the actual lesson generalizes to any AI generated or vibe coded frontend. If a model generated the layout, it optimized for looking correct in whatever environment produced it, usually a desktop browser at a comfortable resolution. It did not test itself against a cramped viewport, a different rendering engine, or a real thumb, because it cannot. That gap is not a WordPress problem. It is a testing problem, and it is the same one this build kept surfacing until I actually went looking for it in the right order.
Once a pattern like the Complete Index bug shows up more than once in the same build, it stops being a one off fix and starts being a candidate for actual regression coverage, which is exactly the ground covered in how to generate a Playwright script from a bug report without getting flaky output. If you want to see the build side of this same theme, the Claude Design mockup and the vibe coding pipeline itself, that half of the story is covered from the development angle in building with AI as a developer on EngineeredAI. The AI can build the layout. It cannot tell you whether your thumb can actually read it.
Ran QA on a full theme rebuild built through Claude Design, vibe coding, and hand coded fixes, and used a real mobile testing pass across local, DevTools, and real device stages to catch what desktop testing alone missed.
