Mobile responsiveness checker
Checks the viewport meta tag and responsive layout signals on every crawled page.
What TMOD checks
- The viewport meta tag on every crawled page, and whether its content value actually enables responsive scaling.
- Responsive layout signals in the markup and stylesheets, media queries, flexible units, and responsive image attributes.
- Patterns that break mobile usability, including fixed-width containers and viewport configurations that disable zooming.
- Consistency across pages, since a responsive homepage attached to a fixed-width article template is a common and easily missed failure.
Why it matters
Google indexes the mobile version of your site. Not primarily, exclusively, for all practical purposes. If content, structured data or links exist only in your desktop layout, they are effectively invisible for both indexing and ranking.
A missing viewport meta tag is the single highest-impact failure here and one of the easiest to fix. Without it, mobile browsers render the page at desktop width and scale it down, producing text too small to read on a site whose CSS may be perfectly responsive. It is one line.
Disabling zoom with user-scalable=no or a locked maximum-scale is an accessibility failure as well as a usability one. Anyone who needs to magnify text cannot, and there is essentially never a good reason for it on a content site.
How to fix it
01Add the viewport tag
Put `<meta name="viewport" content="width=device-width, initial-scale=1">` in the head of every page. Nothing else on this list matters until this is present, because without it the browser is not applying your responsive CSS in the first place.
02Never disable zoom
Remove user-scalable=no and any maximum-scale below 5. It breaks accessibility for anyone with low vision, and modern browsers increasingly ignore it anyway, so it delivers nothing in exchange.
03Test the templates, not the homepage
Check an article page, a category page and a page with an embedded table or video. Homepages get designed carefully; templates get inherited. Tables and iframes are the most common source of horizontal scrolling on mobile.
04Size tap targets properly
Interactive elements need roughly 44 by 44 pixels of touch area with space between them. Navigation links packed tightly together work with a mouse and are frustrating with a thumb.
What mobile-first indexing actually requires
The rule is parity, not similarity. Whatever a search engine is meant to see has to exist in the mobile rendering: the body text, the headings, the structured data, the images with their alt text, and the internal links that connect the page to the rest of the site. A desktop layout that carries a sidebar of related links which the mobile layout drops has quietly removed those links from the site's link graph.
Content inside tabs and accordions is fine. It is present in the markup, and hiding it behind an interaction for space reasons is a normal responsive pattern, not a penalty. What is not fine is content that is absent until an interaction fetches it, since nothing triggers that interaction on a crawl.
Separate mobile sites still exist and still work, with bidirectional canonical and alternate annotations kept correct in both directions and every change made twice. Almost nobody who has a choice chooses that now, and the technical checks assume one URL serving one document to every device.
The things that break first on a real phone
Wide tables come top, because a table is the one element that refuses to reflow. Then embeds with hardcoded pixel dimensions, an old video iframe or a map that pushes the layout wider than the screen. Then images without a max-width rule, which do the same thing. Any one of these produces a page that scrolls sideways, and a single offending element is enough to do it to the whole document.
Text inputs under 16 pixels are the subtle one on iOS: the browser zooms in when the field is focused and does not zoom back out, leaving the visitor stranded at 150% on a form. Fixed elements are the other, where a sticky header, a floating chat button and a consent banner together can claim more than half of a small viewport and leave the content in the gap between them.
Test on a real device rather than a narrow browser window, or at minimum on a device profile with touch emulation and a throttled connection. A desktop browser resized to 400 pixels renders differently from a phone in ways that matter, and it never shows you the thing that actually decides the visit, which is how long the page took to become usable on a mobile connection.
Questions
Does having a separate m.example.com site work?
It can, but it is an outdated approach that needs careful bidirectional canonical and alternate annotations to avoid duplicate-content problems, and it doubles your maintenance. Responsive design serving one URL to every device is the recommended approach and has been for years.
My site uses a responsive theme. Do I still need to check?
Yes. Themes are responsive until someone adds a fixed-width table, an embed with hardcoded dimensions, or a custom section built without media queries. Those additions are exactly what this check finds, and they are usually on the content pages rather than the homepage.
How does this relate to Core Web Vitals?
They are separate and complementary. This checks whether the layout adapts to a small screen at all. Core Web Vitals measures how that layout performs, how fast the main content appears and whether it shifts while loading. A site can be perfectly responsive and still fail Core Web Vitals, and vice versa.