Google finished the switch to mobile-first indexing in July 2024, and the setting that used to tell site owners which crawler was indexing them, the "indexing crawler" field in Search Console, is gone now, removed because Google no longer considers it something you need to check. There's only one crawler left doing the primary work for the overwhelming majority of the web: Googlebot Smartphone.
That removal is a small detail with a real consequence. A whole generation of "how do I check if my site is on mobile-first indexing" advice stopped being useful the moment that setting disappeared, and a lot of it is still floating around uncorrected. So we're going to walk through the actual sequence that matters now, checking what your mobile layout genuinely looks like to Google, and fixing what's broken, in the order you'd realistically do it.
Step 1: Stop asking whether you're on mobile-first indexing
This used to be the first question everyone asked, and it's the wrong first question today. Google confirmed the rollout as substantially complete at the end of October 2023, and by July 5, 2024, the remaining holdouts, a small number of sites with mobile-specific errors or robots.txt blocks that Google genuinely couldn't resolve on its own, were folded in as well. Unless your site is actively broken on mobile in one of those specific ways, you're already being indexed by the mobile crawler. The useful question isn't "am I on it," it's "what is that crawler actually seeing when it renders my page."
Step 2: Check for content parity, not just visual polish
Before touching any layout tool, think through whether your mobile version shows everything your desktop version does. This was the original reason mobile-first indexing existed at all: for years, plenty of sites quietly served a thinner mobile experience, fewer product details, a stripped-down navigation, an accordion that hid an entire section behind a tap nobody made. None of that was necessarily visible as broken. It just meant Google was indexing less of your page than you thought you were publishing.
If your site uses accordions, tabs, or "read more" expansions on mobile to save space, that's fine as a design pattern, but confirm the content is still present in the page's HTML and just visually collapsed, rather than genuinely absent until a script fetches it on click. Content that only loads after a mobile-specific interaction is a common way sites accidentally starve their own mobile-indexed version.
Step 3: Test your layout in our Responsive Web Design Preview tool
This is where guessing stops being useful and you need to see the real thing, and it's the step we built our own tool specifically to handle. Open our Responsive Web Design Preview, paste in your live page URL, and it loads your actual site inside a real browser rendering engine at fixed device viewports, a mobile portrait frame at 375 by 667 pixels, a tablet frame at 768 by 1024, a laptop frame at 1024 by 768, and a standard desktop frame at 1440 by 900. There's nothing to install and nothing to sign up for. Because it's rendering your genuine CSS, media queries, and any script-driven interface behavior rather than a static screenshot, you can scroll, tap navigation links, and open menus inside each frame exactly as a visitor on that device would, directly in our tool, without switching between your phone and your laptop to compare what you're seeing.
Look specifically for three things in the mobile frame. Whether any element pushes wider than the viewport and forces horizontal scrolling, which is one of the most common mobile usability failures and one Google flags directly. Whether tap targets, buttons, menu items, form fields, sit close enough together that a finger would realistically miscount. And whether text is rendering at a size that's actually readable without a visitor needing to zoom, since a font that looked fine on your desktop monitor at arm's length can read as uncomfortably small at phone-in-hand distance.
Step 4: Compare across breakpoints inside our tool to find where it actually breaks
Switch between the tablet and laptop frames in our Responsive Web Design Preview and watch what happens at the transition points, since this is the specific comparison the tool is built to make easy: four real viewports, side by side, without you needing four separate devices on your desk. Most layout failures don't show up cleanly at exactly 375 pixels or exactly 768. They show up in the awkward middle ranges, a sidebar that hasn't collapsed yet at 700 pixels but no longer has room to sit beside the main content, a three-column grid that becomes two overlapping columns before your breakpoint kicks in. Watching the layout live as you move between device frames catches these transition failures in a way that checking only the smallest and largest sizes never will.
If you're testing a page still in development, this same setup can point at a local server address rather than a live public URL, provided your local environment allows cross-origin frame rendering. That's a genuinely useful workflow difference if you're catching layout problems before launch instead of after.
Step 5: Know what our tool can't see, so you don't chase a false negative
Worth being upfront about a real limitation here rather than letting you find it the hard way. Sites that set strict framing protections, an X-Frame-Options header or a content security policy that blocks embedding, won't load inside our Responsive Web Design Preview, or inside any other iframe-based preview tool for that matter. This is a deliberate security measure those sites have chosen, and it's the same reason you can't load Google or Facebook inside a preview frame either. If your own site refuses to load in the tester, that's not necessarily a mobile layout problem, check whether your own server configuration is setting one of those headers before assuming the tool is broken.
Step 6: Fix what you found, in order of what actually costs you the most
Horizontal overflow is worth fixing first, since it's the failure Google's own mobile usability reporting treats as a hard error rather than a soft warning, and it's usually caused by one specific element, a fixed-width table, an image without a max-width constraint, an embedded video with a hardcoded pixel size, rather than a systemic rebuild. Find that one element in the mobile frame and constrain its width before touching anything else.
Tap target spacing and font sizing come next, since they affect real visitors immediately even though they're less likely to trigger an outright indexing problem. And if you're running separate mobile and desktop templates rather than one responsive layout that adapts, that architecture itself is worth reconsidering. A single responsive codebase means there's only one version of your content to keep in parity, which removes the entire category of mistake that made mobile-first indexing necessary in the first place.
The sequence, start to finish
Confirm you're not chasing an outdated question, since the crawler question was settled industry-wide back in 2024. Check that your mobile experience actually contains everything your desktop version does, not just that it looks acceptable. Load the real page in our Responsive Web Design Preview and watch it at mobile, tablet, laptop, and desktop sizes rather than guessing from the code, since that's the one step in this list that no amount of reading your own CSS will substitute for. Pay attention to the awkward transition zones between breakpoints, not just the extremes. Understand which sites simply won't render in any iframe tool, so you don't mistake a security header for a layout bug. Then fix overflow first, spacing and type second, and consider consolidating separate mobile and desktop templates if you're still running them. That's the actual order this gets fixed in, and it starts with looking at the real render rather than assuming your CSS does what you think it does.