What Google indexes now, and why it changed
Google started shifting sites to mobile-first indexing in 2018 and finished the job by mid-2024. Googlebot Smartphone crawls the page, the mobile rendering is what gets indexed, and ranking decisions are made on that version.
The reasoning was never subtle: most searches happen on phones, and in India that isn't a majority so much as an overwhelming default — a large share of the country's internet users have only ever browsed on an Android phone over mobile data.
The practical translation is short. Whatever your mobile page contains is what your site contains. Everything else is decoration for the desktop minority.
The parity trap
Responsive design is not the same as content parity, and that's where Indian sites lose ground most often. A responsive theme reflows a layout; it's the CSS and the template conditionals on top that quietly delete things. In rough order of how often we find them:
display: nonestill ships the content in the HTML, so it's usually indexed. Hiding it visually is a design choice, not a deletion.- A template conditional that never renders the block, or a fetch triggered by a tap, genuinely removes it. Hidden in CSS is fine; absent from the HTML is not.
| What's missing on mobile | Why it happens | Consequence |
|---|---|---|
| Body copy trimmed or truncated | "Too long for mobile" — an editor's call, or a theme's display: none. | The trimmed copy is copy Google doesn't have. |
| Specification and pricing tables removed | Tables are awkward on narrow screens, so the template hides them. | Product detail vanishes. Comparison queries stop matching. |
| Images dropped or swapped for tiny versions | A well-meant bandwidth saving. | Image search eligibility goes with them, alt text included. |
| Structured data only on desktop | Schema injected by a desktop-only template partial. | Rich result eligibility disappears — Google reads the mobile HTML. |
| Links hidden in a menu that loads on tap | A JavaScript mega-menu built mobile-last. | Discovery and internal link equity both suffer. |
Accordions, tabs and "read more"
Google has been consistent that content inside tabs and accordions is indexed normally when it's present in the HTML. Collapsing a long FAQ on a phone doesn't hurt you.
What hurts is the version where tapping fires a network request and injects the content afterwards. Googlebot doesn't tap. It renders once, with a tall viewport, and takes what's there. Content that requires an interaction to exist is content that doesn't exist.
Same logic for "read more" links that navigate to a URL — fine, that's a link — versus buttons that lazy-fetch the rest of the article. And infinite scroll: Googlebot doesn't scroll either, so give listing pages real paginated URLs underneath. It's a JavaScript SEO problem in a mobile costume.
How to actually test it
Google retired the Mobile-Friendly Test, its API, and the Mobile Usability report in Search Console in December 2023, so the tool most people reach for no longer exists. Here's what replaced it.
URL Inspection. Test Live URL, then View Tested Page. It uses Googlebot Smartphone, so the rendered HTML it shows you is the mobile HTML Google indexes. Search it for your body copy, your schema block and your internal links. This is the authoritative test; everything else is a convenience.
A `curl` diff. Fetch the same URL twice, once with a desktop user-agent and once with Googlebot Smartphone's, and diff the two responses. If the mobile version is materially shorter, you've found your problem without opening a browser. Lighthouse covers the usability signals the retired report used to — tap target size, viewport configuration, legible fonts.
One more thing no tool will do for you: open your own site on a three-year-old Android, on mobile data, somewhere with bad signal, and buy something. The list you compile in four minutes will be longer and more useful than the audit — and it's the same list your Core Web Vitals data has been trying to tell you.