# Mobile-first indexing: what Google reads on your mobile pages and what to check > Mobile-first indexing means Google crawls, indexes and ranks the version of your page a smartphone gets. What that changes for SEO, and the parity checks that keep mobile pages complete. Updated 2026-09-26 · Technical SEO · HTML version: https://getreport.app/guides/mobile-first-indexing Mobile-first indexing means Google crawls your pages with its smartphone crawler and indexes and ranks what that crawler finds. If a heading, a paragraph, a link or a block of structured data exists on your desktop page but not on the mobile one, Google does not see it. This guide is for site owners and SEOs who want to know what that means in practice: what Google checks, how to compare your mobile and desktop pages, and what to fix when they differ. It is part of our guide on [how to make a website mobile friendly](https://getreport.app/guides/how-to-make-a-website-mobile-friendly). ## Quick answer - **Google indexes the mobile version only.** Since 5 July 2024 every site is crawled with Googlebot Smartphone; a site whose content cannot be reached on a mobile device is no longer indexed at all. - **Parity is the whole job:** the same main text, headings, internal links, structured data, titles, meta descriptions and robots tags on mobile as on desktop. - **Responsive sites are safe by design,** because both devices get the same HTML. The risk sits with separate m-dot sites, dynamic serving and page builders that swap sections per device. - **Hidden is fine, missing is not.** Text in tabs and accordions is indexed; text removed from the mobile HTML is not. - **Content that loads only after a tap, swipe or typing** is never seen by Google. Lazy-load with the browser's `loading="lazy"` or on scroll into view, not on click. - **Check it:** URL Inspection in Search Console shows which crawler fetched a page, and the free [JavaScript rendering checker](https://getreport.app/tools/js-rendering-check) renders your page on a phone profile so you can see what a smartphone crawler gets. ## What is mobile-first indexing? Google keeps one index, and each page is in it once. Before 2016, the version of a page Google stored was the one its desktop crawler fetched. Google announced mobile-first indexing in November 2016, made it the default for new sites in July 2019, and said in October 2023 that the move was essentially complete. In a Search Central blog post in 2024, it set 5 July 2024 as the date after which the last desktop-crawled sites would be crawled with Googlebot Smartphone too. "Mobile-first" is a slightly misleading name. It is really mobile-only for indexing: Google still sends its desktop crawler occasionally, but the content it ranks is the content the smartphone crawler found. There is no separate mobile index and no desktop index to fall back on. The consequence: rankings on desktop results also come from the mobile page, and anything missing on mobile, such as a product description trimmed for phones or schema only the desktop template prints, is missing everywhere. A site that is not accessible on mobile devices at all is no longer indexed. ## Is mobile-first indexing a ranking factor? No, and it is worth being precise about this. Mobile-first indexing decides *which version* of your page Google reads. It does not add or remove points for being mobile friendly. What it changes is the input: whatever the mobile page contains is what every ranking signal is computed from. Mobile usability is a separate matter. Google's page experience documentation lists "does your content display well on mobile devices?" among its self-assessment questions, and Google's Search Liaison said in April 2023, when page experience was removed from the list of ranking systems, that this did not mean people should ignore being mobile friendly. Page experience is a set of signals, not a single switch. Google retired the Mobile-Friendly Test and the Search Console Mobile Usability report on 1 December 2023, so there is no longer a label to earn; the page simply has to work on a phone. For "mobile friendly SEO", then, there are two separate jobs: make sure the mobile page is complete (this guide), and make sure it is usable and fast on a phone (the [pillar guide](https://getreport.app/guides/how-to-make-a-website-mobile-friendly) and [why mobile scores are lower than desktop](https://getreport.app/guides/mobile-vs-desktop-scores)). ## Responsive design SEO: why one HTML is the safe option Google supports three ways to serve mobile visitors, and they carry very different risk under mobile-first indexing: | Setup | How it works | Mobile-first indexing risk | | --- | --- | --- | | Responsive design | Same URL, same HTML, CSS adapts the layout | Lowest: content is identical by construction | | Dynamic serving | Same URL, the server sends different HTML by user agent | Medium: the mobile HTML can drift from desktop; needs `Vary: User-Agent` | | Separate URLs (m-dot) | `m.example.com` pages linked to `www` pages | Highest: two sites to keep equal, plus annotations on every pair | Google's documentation recommends responsive design as the easiest to implement and maintain. With one HTML document, the smartphone crawler and the desktop crawler get the same text, links and tags, so parity is not something you have to police. Our guide to [responsive web design](https://getreport.app/guides/responsive-web-design) explains how the layout adapts without changing the content. Responsive sites can still create mobile-only gaps, though, in three ways: - **Page builders with per-device sections.** Elementor, Divi and similar builders let you build a "desktop" section and a separate "mobile" section and hide each on the other device. If the mobile section is a shortened version, Google indexes the short one. If the builder removes hidden sections from the HTML instead of hiding them with CSS, content disappears entirely. - **JavaScript that changes content by screen width.** A script that removes a comparison table below 768 px, or loads reviews only on desktop, creates a mobile page Google indexes without them. - **Different menus.** A desktop mega menu with 60 category links and a mobile menu with 8 changes your internal linking as Google sees it. ## What Google checks on the mobile version Google's mobile-first indexing best practices come down to one principle: the mobile page should be equivalent to the desktop page. In detail: ### Content and headings The main content, headings included, should be the same. Google's documentation says that if the mobile page has less content than the desktop page, you should expect some traffic loss, because Google cannot get the information from the mobile page. Shortening a page for phones is a design decision with a ranking cost. Collapsed content is different. Text in an accordion or a tab that is in the HTML and revealed by a tap is read by Google. The problem is only content that is not in the page at all until something happens. ### Lazy-loaded content Google does not tap, swipe, click or type. Its documentation warns against lazy-loading primary content on user interaction: a "Load more reviews" button that fetches reviews over the network, or a tab that loads its content only when opened, hides that content from the index. Lazy-loading that happens as content scrolls into view is fine, because Google's renderer uses a tall viewport; the native `loading="lazy"` attribute on images and iframes is the safest choice. Our guide to [lazy loading done right](https://getreport.app/guides/lazy-loading-done-right) covers what not to lazy-load. ### Robots meta tags and robots.txt Use the same robots meta tags on mobile and desktop. A `noindex` or `nofollow` that only the mobile template carries applies to the page as a whole, because the mobile page is the one Google reads. The same goes for robots.txt: if your mobile site lives on another host, its robots.txt must allow the same resources, including the CSS and JavaScript the page needs to render. ### Structured data Put the same structured data on both versions, with URLs in it updated to the mobile URLs on an m-dot site. Rich results come from the mobile page, so product, breadcrumb or article markup that only the desktop template outputs costs you those results. ### Titles and meta descriptions The title and meta description should be equivalent on both versions. Search results show what the mobile page declares. ### Images and video - Use the same descriptive alt text on mobile images. - Do not use image URLs that change on every page load; Google cannot index an image whose address is never the same twice. - Serve images at a quality and size that is not visibly worse on mobile; very small or low-resolution mobile images can lose image search traffic. - Put videos where visitors can find them on mobile, in a supported format, with the same video structured data. ### Separate mobile URLs If you run `m.example.com`, Google also asks for: - `rel="alternate"` from each desktop page to its mobile page, and `rel="canonical"` from each mobile page back to the desktop page; - hreflang on mobile pages that points to the other language's **mobile** URLs; - mobile error pages that return the same status code as desktop, not a 200 soft error; - the m-dot host verified in Search Console as its own property. Most sites with an m-dot setup would be better served by moving to one responsive site, redirecting each mobile URL to its desktop equivalent with a 301. ## How to check your mobile pages for parity You do not need access to Google's crawler to find most gaps. Work through these checks on your main templates: home, category, product or service, article, and any page built with per-device sections. 1. **Confirm the crawler.** In Search Console, open URL Inspection for a page. The coverage details show "Crawled as" Googlebot smartphone. Click "View crawled page" and read the HTML Google actually stored. 2. **Render the page as a phone.** The free JavaScript rendering checker loads the page on a phone profile, first as raw HTML and then after scripts run, and compares titles, canonicals, robots tags, headings, links, word count and JSON-LD between the two. > **Free tool:** [JavaScript rendering checker: raw vs rendered HTML](https://getreport.app/tools/js-rendering-check): Free JavaScript rendering checker: compare raw HTML with the rendered page and see which text, links, tags and structured data appear only after scripts run. 3. **Compare mobile and desktop by hand.** In Chrome DevTools, device mode (Ctrl+Shift+M or Cmd+Shift+M) with a phone preset changes the user agent, so dynamic serving and m-dot redirects show their mobile HTML. Copy the rendered text of the page at desktop and at mobile width and compare word counts, headings and internal links. Big differences are the gaps to fix. 4. **Check the layout at phone widths.** The [mobile-friendly test](https://getreport.app/tools/responsive-check) renders the page at 360, 414, 768, 1024 and 1440 px and names the elements that overflow, text under 12 px and tap targets under 24 × 24 px. > **Free tool:** [Mobile-friendly test and CSP generator](https://getreport.app/tools/responsive-check): Free mobile-friendly test to replace Google's retired one: screenshots at five widths, sideways scrolling, tiny text and tap targets, plus a CSP generator. 5. **Search your own content.** For a sentence you suspect is desktop-only, search Google for it in quotes with `site:yourdomain.com`. If the page does not come up, Google has not indexed that text. The getReport report runs the checks that most often break mobile indexing: > **Check: Viewport meta tag is present.** Without a viewport tag, phones render the page at desktop width and shrink it. Google indexes the mobile version first, so this hurts rankings directly. > > 1. Add in . > **Check: The page is not set to noindex.** A noindex directive tells Google to drop this page from search results. Unless that is intended, every visit from search is lost. > > 1. Remove noindex from the robots meta tag and from the X-Robots-Tag header, unless the page should stay out of search. > 2. In WordPress, untick Settings → Reading → "Discourage search engines" and check the page's SEO plugin settings. > **Check: The visible text is present without JavaScript.** Google renders JavaScript later and with a budget, so text that only appears after scripts run can be indexed late or not at all. Other search engines and link previews may never see it. > > 1. Serve the main content in the HTML (server-side rendering or static generation) and use JavaScript only to enhance it. > 2. Check the difference in the technical detail; menus and widgets are fine, headlines and body copy are not. > **Check: JavaScript leaves the title, canonical and robots tags alone.** Search engines read the HTML first and the rendered page later, if at all. A canonical or noindex that JavaScript changes sends two different instructions, and Google may act on either. > > 1. Put the final title, description, canonical and robots tags in the HTML the server sends. > 2. In a single-page app, set them on the server for each route (Next.js metadata, Nuxt useHead with SSR, Angular Universal). > 3. Never add noindex with JavaScript to a page you want indexed; Google may drop it before the script runs. > **Check: The page fits every screen width from 360 to 1440 px.** When a page is wider than the phone, visitors have to pan left and right to read it, and Google indexes this mobile version, broken layout included. It is usually one fixed-width element. > > 1. Find the element named in the technical detail and give it max-width:100% instead of a fixed width. > 2. Wrap wide tables in a container with overflow-x:auto, so only the table scrolls. > 3. Let images and embeds shrink with max-width:100%; height:auto. ## Fixing the common gaps **Shortened mobile content.** Put the full text back in the mobile HTML and use design to make it manageable: an accordion for specifications, a "Read more" that expands text already in the page, tabs whose content is in the HTML. Avoid "Read more" buttons that fetch the rest over the network. **Per-device sections in a page builder.** Build one section and adjust it per device (font size, spacing, columns) instead of duplicating it. Where you must have two versions, make the mobile one complete, and check in the page source whether the builder removes hidden sections or only hides them with CSS. **Missing structured data.** Output schema from the template or an SEO plugin, not from a widget that only appears on desktop. Validate the mobile rendering with the [schema validator](https://getreport.app/tools/schema-validator) or Search Console's URL Inspection. **A thinner mobile menu.** Keep the important category and hub links reachable on mobile: in the menu, in a footer link block, or in the page body. Our guide to [internal links](https://getreport.app/guides/internal-links-how-many-where-anchor-text) explains which ones matter most. **Different robots tags or blocked resources.** Print the same robots meta tag on mobile, and check with the [robots.txt tester](https://getreport.app/tools/robots-txt-tester) that no CSS, JavaScript or image the mobile page needs is blocked. **Content loaded on interaction.** Render the content on the server, or load it when it scrolls into view. The guide to [JavaScript-rendered content and Google](https://getreport.app/guides/javascript-rendered-content-and-google) explains why server-rendered HTML is the safest way to be read by every crawler. ## Common mistakes - **Assuming desktop rankings come from the desktop page.** Every result, on every device, is ranked on the mobile page. - **Trimming product descriptions and reviews on phones** to "keep the page short". Collapse them instead. - **Blocking the mobile site in robots.txt** during a relaunch and forgetting to remove it. - **Testing mobile only with a narrow desktop window.** That catches layout problems but not user-agent-based differences; use device mode or the rendering checker. ## Questions people ask ### When did Google switch every site to mobile-first indexing? Google finished the move in stages. It announced mobile-first indexing in 2016, made it the default for new sites in July 2019 and said in October 2023 that the switch was essentially complete. The last sites still crawled as desktop moved after 5 July 2024. Since then every site is crawled and indexed with Googlebot Smartphone. ### Does content hidden in accordions or tabs count for mobile-first indexing? Yes, as long as it is in the page's HTML. Google reads text inside collapsed accordions, tabs and "Read more" sections that expand content already on the page. What Google cannot read is content that is only fetched after a tap, click or swipe, because its crawler never interacts with the page. Keep the text in the HTML and collapse it with CSS or a details element. ### Will my site drop in rankings if the desktop version has more content than mobile? Probably, for the queries the missing content answered. Google indexes the mobile version, so text, links and structured data that only desktop visitors see do not count for ranking at all. Google's own documentation says to expect some traffic loss when the mobile page carries less content. Put the full content in the mobile HTML and use accordions or tabs to keep it tidy. ### Is a separate m-dot mobile site bad for SEO? It is not penalised, but it is the riskiest setup under mobile-first indexing. You must keep two sites equal, link every pair with rel=alternate and rel=canonical, point hreflang at mobile URLs and verify the mobile host in Search Console. Any drift between the two costs rankings. Most sites are better off moving to one responsive site with 301 redirects from the m-dot URLs. ### Does responsive design help SEO? Yes, mostly by removing risk. A responsive site serves the same HTML on one URL to every device, so the smartphone crawler sees exactly the content, links and structured data desktop visitors get, with no redirects or annotations to maintain. Google recommends it as the easiest setup. It does not rank a page higher on its own; it makes sure nothing is lost on mobile.