Mobile-first indexing
Google crawls and ranks the phone version of your page, so anything missing on mobile is missing from search.
See it
What it is
Google crawls with a smartphone Googlebot and indexes what that crawler sees. The desktop rendering of your page is no longer the reference copy for anything, and this is not an opt-in setting: it applies to every site. If content, headings, structured data, or internal links exist on desktop but not on the phone layout, they effectively do not exist.
So the work is parity, not responsiveness in the visual sense. Same primary copy, same H1 and H2s, same alt text, same JSON-LD, same meta robots directives, same nav and footer links on both. The classic failures are a stripped-down mobile template, a hamburger menu built entirely in client-side JS, and images that only load after a real user scroll event.
Gotchas: content hidden behind accordions and tabs is fine as long as it is in the HTML, since Google indexes CSS-hidden text. Content fetched only after a tap is not. Also, mobile-first indexing is about which copy gets indexed, not about speed; page experience signals are a separate thing people constantly merge into this one.
Ask AI for it
Check this page for mobile-first indexing parity and fix the gaps. Fetch it with a smartphone user agent and again with a desktop one, and compare both the raw HTML and the rendered DOM in each case; smartphone Googlebot runs JavaScript, so a JS-disabled screenshot proves nothing. List every difference in primary content, heading order, meta robots directives, structured data, internal links, and image alt text. Separate what exists after initial rendering from what only appears after a tap, scroll, or other user interaction, because the second kind is what actually goes missing. Then fix the markup so both user agents get equivalent primary content, using CSS for the layout differences rather than shipping two templates.