Mobile-First Indexing: What Google Actually Reads, and the Menu That Hides 75 Percent of Your Links
· Royking Niba
Mobile-first indexing means Google indexes and ranks the mobile version of your page, not the desktop one. In Google’s own words: “Google uses the mobile version of a site’s content, crawled with the smartphone agent, for indexing and ranking.” If something exists on your desktop page and not in the HTML the smartphone crawler receives, Google does not have it. Below is what the documentation commits to, a parity table you can audit against, and a model of the one mobile template change that quietly removes three quarters of a site’s internal link paths.
What Google actually says, quoted
Everything in this section is quoted from Google Search Central’s mobile-first indexing best practices page, last updated 10 December 2025, checked today.
Make sure that your mobile site contains the same content as your desktop site.
On primary content
Don’t lazy-load primary content upon user interaction. Google won’t load content that requires user interactions.
On lazy loading
While it’s not required to have a mobile version of your pages to have your content included in Google’s Search results, it is very strongly recommended.
On sites with no mobile version
Google recommends Responsive Web Design because it’s the easiest design pattern to implement and maintain.
On site configuration
Read those together and the practical rule is short. Mobile-first indexing is not a mobile-friendliness score and it is not a bonus for having an app-like design. It is a decision about which copy of the page Google reads. The risk is never that your mobile page looks wrong. The risk is that it contains less.
The parity table: what has to match, and what breaks when it does not
The second column is Google’s wording from the same page. The third and fourth columns are mine: how I check it on an audit, and what the failure costs.
| Element | What Google says | How to check | What a mismatch costs |
|---|---|---|---|
| Primary content | “the same content as your desktop site” | Word count of the rendered main content, desktop agent against smartphone agent | Google states you “can expect some traffic loss” |
| Structured data | “the same structured data” | Rich Results Test run with the smartphone agent | Rich result eligibility disappears for the missing types |
| Title and meta description | “equivalent across both versions” | Compare the head of both renders | The snippet is built from the thinner version |
| Headings | “the same clear and meaningful headings” | Extract H1 to H3 from both renders | Section structure Google relies on is gone |
| Image alt text | “the same alt text for images” | Diff the alt attributes | Image search visibility falls |
| Robots meta tags | “the same robots meta tags” | Check for a stray noindex or nofollow on the mobile template | A mobile-only noindex removes the page outright |
| Error status | “the error page status is the same” | Request a deleted URL with both agents | A mobile soft 200 keeps dead pages alive |
| Fragment URLs | “Most of the time, URL fragments are not indexable” | Look for #-based routing on the mobile build | Those views are never indexed as pages |
| Content behind a tap | “Google won’t load content that requires user interactions” | Disable interaction and read the initial DOM | The content, and the links inside it, do not exist for Google |
| Nine checks | All nine are stated in one Google document | Every check is a diff, not a judgement | The last row is the one that does the most damage |
The worked example: a mobile menu that deletes 75 percent of a site’s link paths
The last row of that table matters most because it hits links as well as text. Mobile templates routinely move navigation behind a hamburger that fetches its links only when tapped, and replace long listings with a “load more” button. On a phone that looks identical. To a crawler that does not tap, the links were never there.
Take a catalogue site with 60 category pages and 80 products in each, 4,861 URLs including the homepage. On desktop the homepage carries all 60 category links in the HTML, and each category page lists all 80 of its products. On mobile the homepage HTML carries 12 section links, each section page links to 5 categories, and each category page shows 20 products with the remaining 60 behind a “load more” tap.
| Measure | Desktop template | Mobile template | Change |
|---|---|---|---|
| Links in homepage HTML | 60 | 12 | 80% fewer |
| Click depth of a category page | 1 | 2 | One level deeper |
| Products linked in category HTML | 80 per category | 20 per category | 75% fewer |
| Products with an HTML link path | 4,800 | 1,200 | 3,600 lose their only path |
| Click depth of a reachable product | 2 | 3 | One level deeper |
| Share of products reachable by crawling links | 100.0% | 25.0% | 75 points lost |
| Same site, same content | 4,861 URLs | 3,600 products now depend on the sitemap alone |
The arithmetic is 60 categories times 20 visible products, which is 1,200 of 4,800, or 25.0 percent. The other 3,600 products are still in the XML sitemap and still exist, so they can be discovered. What they lose is every internal link that used to point at them, which is how a crawler finds them in the first place and one of the clearest ways a site tells Google which pages it considers important. Nothing in this change produces an error in Search Console, and the site looks exactly the same to anyone holding a phone.
What this model assumes
It assumes the hamburger and the “load more” button fetch their contents only on interaction, that no other internal links point at the hidden products, and that each category is the same size. If the menu links are present in the HTML and merely hidden with CSS, the paths survive and the loss in this table does not happen. That distinction, present in the HTML versus fetched on tap, is the entire audit.
Separate mobile URLs: the rules that trip people up
Most sites are responsive now, but m-dot setups still turn up on older publishers and on sites that were migrated halfway. Google’s page is explicit on two points. First, “The desktop URL is always the canonical, and the mobile version is the alternate of that URL.” Second, on international sites, “Your mobile URLs’ hreflang must point to mobile URLs, and similarly desktop URL hreflang must point to desktop URLs.” Mixing the two sets is one of the quieter ways to break hreflang reciprocity, which I covered in the international SEO post linked below.
Dynamic serving, where one URL returns different HTML by device, relies on “user-agent sniffing and the Vary: user-agent HTTP response header” in Google’s description. If the Vary header is missing, a cache can hand the desktop HTML to the smartphone crawler or the reverse, and the parity checks above will give different answers on different days.
The order I work in
- Fetch the same ten templates with the desktop agent and the smartphone agent, rendered, and diff word count, headings, links and structured data.
- Check the initial DOM on mobile with no interaction at all, because anything that only appears after a tap is invisible to Google.
- Count internal links in the mobile homepage and mobile category HTML. If the number is a fraction of desktop, model the link paths before touching anything else.
- Confirm robots meta tags and error status codes match by device, since a mobile-only noindex or soft 200 is a template bug that affects every page at once.
- On m-dot sites, verify the canonical points to desktop, the alternate points to mobile, and hreflang stays within its own set.
Mobile-first indexing rarely causes a dramatic drop on the day it applies. It causes a slow one, months later, when someone redesigns the mobile template and nobody diffs it against desktop. That is why I treat any mobile redesign as a migration and audit it the same way.
Related reading
- Google Penalty Recovery: how I diagnose and reverse a traffic collapse
- JavaScript SEO: the three phases Googlebot uses, and the discovery cost of rendering your links
- Internal linking for SEO: what Google documents, and where link equity goes
- Page experience: Google says there is no single signal, and the 75th percentile is why that matters
- International SEO: the URL structure decision, and the hreflang arithmetic behind it
- Content decay: how to tell a decaying page from a seasonal one, and the arithmetic of waiting
Leave a Reply