Mobile-first indexing: What it means for a website

Mobile-first indexing: What it means for a website, in the final form Google announced in 2023: all sites are crawled, indexed and ranked based on the phone version, using Googlebot Smartphone, while the desktop version is used only in rare cases. The consequence: what does not exist on the mobile version does not exist for Google; a site with its menu, text or links hidden on phones is indexed without them.

This guide briefly explains the history, what Google assesses on the mobile version, what must be the same on mobile and desktop, how to check in Search Console, the differences between responsive, dynamic and m-dot, the mistakes we find in audits and the checklist.

Mobile-first indexing: What it means for a website

A brief history

2016: the experiment is announced. 2018: the first sites switch over. 2020-2021: almost all sites switch, with notifications in Search Console. October 2023: Google declares the transition complete and ends separate reporting; from 2024, Googlebot Desktop crawling is reduced to a few sites that do not work on mobile at all. In 2026, the question "am I on mobile-first indexing?" has only one answer: yes, like everyone else.

What Google assesses on the mobile version

• Content: text, headings, images and videos as they appear in the HTML served to the phone (including content rendered from JavaScript).
• Metadata: title, description, robots, canonical, hreflang and structured data.
• Internal links: the mobile menu and links within mobile content are the ones followed.
• Page experience: Core Web Vitals measured on mobile, mobile compatibility and intrusive pop-ups; details are in the article on page experience signals.
• Resources: CSS, JavaScript and images must be accessible to Googlebot Smartphone, otherwise the page renders incorrectly.

Parity: what must be identical

1. The same main content: the full text, not a shortened version; content in tabs and collapsed sections is indexed, but must exist in the HTML rather than loading on click.
2. The same titles and descriptions, the same robots and canonical tags.
3. The same structured data, with the same values.
4. The same images, with the same addresses and alt text; lazy-loaded images must be in the HTML (srcset or data-src recognised during rendering).
5. The same internal links: the mobile menu, even when collapsed, contains every section; pages linked only from the desktop footer become hard to find.
6. The same response for bots and visitors: no "light" versions served only to bot user agents.

Responsive sites (the same HTML, with layout adapted through CSS) have parity by default; problems arise on sites with a separate mobile version or content hidden through CSS on small screens without being removed from the HTML (this is fine for indexing), or removed entirely (this is not fine).

How to check what Google sees

• URL Inspection in Search Console: the bot used (Googlebot smartphone), rendered HTML, the mobile page screenshot and blocked resources. Compare the rendered HTML with what you see on your phone.
• The crawl stats report: the Smartphone-to-Desktop proportion by bot type; Smartphone should dominate.
• The Core Web Vitals report, Mobile tab: poor-performing addresses on phones.
• Lighthouse in Chrome, in mobile mode, for lab diagnostics; the Mobile-Friendly test was retired in 2023.
• A crawler configured with the Googlebot Smartphone user agent, for the whole site: titles, descriptions, links and content compared with the desktop version.

Responsive, dynamic or m-dot

Configuration	How it works	Recommendation
Responsive	the same HTML and address, layout through CSS	recommended by Google; no parity risks
Dynamic serving	the same address, different HTML by user agent	accepted; requires the Vary: User-Agent header and strict parity
Separate addresses (m.exemplu.ro)	a separate mobile site, with rel=alternate and canonical between versions	avoid; Google has announced it no longer supports this configuration well and recommends migrating to responsive

The m-dot sites remaining in 2026 usually have indexing problems and need to migrate to responsive, with redirects from m. addresses to the main ones, following the rules in the guide to website migration.

Mistakes we find in audits

• Main text removed on mobile "to make it cleaner": pages lose rankings for phrases in the missing text.
• A mobile menu with only three entries, with no links to the other pages anywhere on phones.
• CSS background images instead of img elements: these are not indexed.
• Tables extending beyond the screen, buttons touching each other, 12-pixel text: poor experience signals.
• Pop-ups covering content on arrival, on phones: penalised as intrusive.
• Resources blocked in robots.txt (theme folders, scripts), dating from when "Google doesn't need CSS".
• A slower mobile version because of scripts and desktop-sized images; LCP above 4 seconds.
• Structured data only on desktop, added by a module that does not run on the mobile template.

Checklist

1. A responsive site, with the same HTML for all screens.
2. Identical content, headings, meta, canonical, hreflang and structured data.
3. A complete mobile menu, with internal links present in the HTML.
4. Images in img elements, with srcset, alt and dimensions.
5. Resources accessible to Googlebot; robots.txt with no blocks on CSS or JavaScript.
6. Mobile Core Web Vitals in the good range; checks and fixes are in the article on optimising Core Web Vitals.
7. No intrusive pop-ups; a small cookie banner with an equally accessible rejection option.
8. A monthly URL Inspection test on five important pages, comparing rendered HTML with what the user sees.

Collapsed content, tabs and scrolling

Google has confirmed that on mobile, content hidden by default (tabs, accordions, "read more" sections) is indexed with normal weight, because on small screens collapsing is a layout practice rather than concealment. The condition is that the text exists in the HTML on loading; content fetched through an additional request on click is not seen. Infinite scrolling (products or articles loaded as you scroll) requires pagination accessible to bots as well, with addresses for each page, otherwise Google sees only the first screen. The check: does the rendered HTML from URL Inspection contain all the text? If not, the problem is real.

Mobile speed, the visible part

Googlebot Smartphone measures within the budget of an average phone; a site that "works well on a laptop" may have an LCP of 5 seconds on a 200-euro Android phone over 4G. Usual causes: desktop-sized images served to phones (missing srcset), third-party scripts (chat, maps, ads) loaded before content, large fonts and missing caching. Real-world data from the Core Web Vitals report, Mobile tab, is what matters, and the fixes, in order of impact, are in the article on improving the PageSpeed Insights score.

Frequently asked questions

1. Can I have extra content on desktop? Yes, but do not rely on it for ranking; Google rarely sees it.
2. Do I need AMP? No; Google withdrew AMP's advantages in 2021, and a fast responsive page does the same job.
3. My site has no mobile version at all; is it indexed? Yes, with Googlebot Smartphone, which sees the desktop page scaled down; it is ranked with poor experience signals and loses out to responsive competitors.
4. How do I know whether Google uses the mobile version of my site? Since 2023 it has used it for all sites; the crawl stats report confirms this through the Smartphone proportion.

A real-world case

A shop with a theme "optimised for mobile" by an external supplier: on phones, product descriptions were removed from the HTML (not hidden), and filters and links to related categories disappeared. Search Console showed a drop in impressions for long phrases from the descriptions, exactly after the theme launched. The fix: descriptions restored to the HTML, collapsed by default on mobile (allowed), a complete menu and category links moved into a visible block. Impressions recovered in six weeks. The lesson: "optimised for mobile" means adapted, not amputated.

What this means for writers and designers

The person writing the content checks the article on a phone before publication: subheadings within a reasonable scrolling distance, short lists, tables that fit or scroll within their own container, images with captions and a first paragraph containing the answer before any large image. The person designing the theme starts with the small screen (mobile-first in design, not just indexing): a complete menu, buttons at least 48 pixels wide, text at least 16 pixels and no elements dependent on hovering. An excellent article in a theme that cuts it on mobile is, for Google, a cut article.

How it connects to everything else

Mobile-first indexing is not a separate ranking factor but the rule of the game: everything you do in SEO (content, structure, speed, structured data) is assessed on the phone version. That is why a technical audit starts on mobile, and the general steps are in the guide to optimising a site step by step; for WordPress, the specifics of themes and modules are in the guide to technical SEO for WordPress. Indexing errors arising from mobile-desktop differences are covered in the article on common indexing errors.

Sources

• Google Search Central, mobile-first indexing: best practices, content parity and supported configurations.
• Google Search Central, page experience in Google results: signals assessed on mobile.

Source references

• Google Search Central, indexarea mobile-first
• Google Search Central, experiența paginii în rezultatele Google