Most guides to Google mobile-first indexing are written as though it were coming. They tell you to prepare, to audit, to make the transition. That framing is several years out of date: Google announced the completion of the mobile-first indexing migration in October 2023, in a Search Central post titled “Mobile-first indexing has landed”.
There is nothing left to prepare for. Google crawls and indexes the web with its smartphone crawler, and the mobile version of your pages is the version that determines what gets indexed and how it ranks. That is simply the current state of Search, not an upcoming change.
Which changes the useful question. It is no longer “is my site mobile-friendly?”, and Google reinforced that by retiring the tool that answered it. It is now something more specific and more consequential: does the mobile version of your page contain everything Google needs to index, and can a person on a mid-range phone on mobile data actually use it? Those are different questions with different answers, and most sites that pass the first fail the second.
This guide covers what mobile-first indexing actually means, the widely repeated misconceptions about it, the tools Google has retired and what to use instead, and the failure mode that causes real ranking damage. Mobile SEO in 2026 is largely about content parity, and almost nothing about a binary friendliness verdict.
What mobile-first indexing actually means
Mobile-first indexing means Google uses the mobile version of your content for indexing and ranking. Googlebot crawls as a smartphone user agent, renders the page as a mobile browser would, and indexes what it finds there.
The single practical consequence, from which nearly everything else follows: if content exists on your desktop layout but not on your mobile layout, Google may not see it at all. Not rank it lower. Not see it. A page whose mobile version hides half its content is, from Google's perspective, a page with half that content.
Three misconceptions worth clearing up
“There is a separate mobile index.” There is not. There is one index, built from the mobile version of pages. Your desktop rankings are determined by what Google found on your mobile page.
“Mobile-first indexing is a ranking factor.” It is not a factor at all; it is how indexing works. Mobile usability and page experience do feed into Google's ranking systems, but those are separate concepts from mobile-first indexing itself. Conflating them is why people expect a ranking boost from making a site responsive and are then puzzled when nothing happens.
“If my site is responsive, I am done.” Responsive design is the easiest way to achieve parity, and it does not guarantee it. A responsive theme can still hide content behind display rules, omit structured data on narrow viewports, drop navigation, or serve smaller images that fail to convey the same information. Responsive is the mechanism; parity is the requirement.
How we got here: the actual timeline
Worth knowing because it explains why so much published advice is stale. This migration took seven years, and content written at each stage still circulates as though it were current.
| Date | Google announcement | What it meant |
| Nov 2016 | Mobile-first indexing | First announcement of the concept and early experiments |
| Dec 2017 | Getting your site ready for mobile-first indexing | Preparation guidance for site owners |
| Mar 2018 | Rolling out mobile-first indexing | Migration begins for sites assessed as ready |
| Dec 2018 | Mobile-first indexing, structured data, images and your site | Clarified that structured data and images must be present on the mobile version |
| May 2019 | Mobile-first indexing by default for new domains | All newly discovered sites start out mobile-first |
| Mar 2020 | Announcing mobile-first indexing for the whole web | A deadline set for the remaining sites |
| Jul 2020 | Prepare for mobile-first indexing (with a little extra time) | Deadline extended; a share of sites were still not ready |
| Nov 2021 | A 2021 update on mobile indexing | Acknowledged that some sites still had not migrated |
| Oct 2023 | Mobile-first indexing has landed | Migration complete |
| Dec 2023 | Tool retirements take effect | Mobile Usability report, Mobile-Friendly Test tool and its API retired |
If an article you are reading tells you to check whether your site has been switched to mobile-first indexing, or describes a Search Console notification about the migration, it was written before October 2023 and its advice should be treated accordingly.
The tools Google retired, and what to use instead
This is the most practical thing in this guide, because several published mobile SEO checklists still instruct you to use tools that no longer exist.
Announced in April 2023 and effective from 1 December 2023, Google retired the Search Console Mobile Usability report, the Mobile-Friendly Test tool, and the Mobile-Friendly Test API. Google's stated reasoning was not that mobile usability had stopped mattering, but that in the nearly ten years since those tools launched, more capable resources had emerged, and it pointed specifically to Lighthouse. The Search Console Page Experience report was also reduced to a page linking to general guidance.
| Retired | What it did | What to use now |
| Mobile-Friendly Test tool | Gave a binary mobile-friendly verdict and showed rendered HTML | URL Inspection in Search Console for the rendered mobile page; Lighthouse for usability diagnostics |
| Mobile-Friendly Test API | Programmatic access to the same verdict | No direct replacement. Lighthouse CI or the PageSpeed Insights API for automated checks |
| Search Console Mobile Usability report | Site-wide list of mobile usability errors | No direct replacement. Core Web Vitals report for performance; Lighthouse per page; manual testing for the rest |
| Page Experience report | Combined page experience summary | Core Web Vitals report, plus Google's page experience guidance |
The loss worth noting for technical work: the Mobile-Friendly Test was the quickest way to see the rendered HTML of any page, including pages you do not own. URL Inspection only works on properties you have verified. That is a genuine gap, and it means competitive rendering checks now require browser devtools rather than a Google tool.
| What did not change when the tools went away Everything the old test checked still matters: a configured viewport, legible text without zooming, tap targets that can be hit accurately, no horizontal scrolling, and no content wider than the screen. What disappeared was the single yes-or-no answer, not the requirements behind it. Google folded mobile usability into broader page experience guidance rather than dropping it. |
Content parity: the requirement that actually matters
If you take one thing from this guide, take this. Under mobile-first indexing, the mobile version of a page must contain the same primary content as the desktop version. Where it does not, the missing content is not indexed.
Parity failures are the most damaging mobile SEO problem because they are invisible in every obvious check. The site looks fine on a phone. It passes performance tests. And it has silently stopped being indexed for a third of its content.
What must be present on the mobile version
- The full primary content. Not a summary, not the first three paragraphs with the rest behind a truncation that does not load the remainder into the DOM.
- The same headings, in the same hierarchy. Headings dropped on narrow viewports remove the structure Google uses to understand the page.
- The same structured data. Google was explicit about this back in December 2018 and it remains true. Schema present only on desktop is schema Google does not see.
- The same metadata: title element, meta description, canonical tag, robots directives and hreflang annotations.
- The same images, with the same alt text. Images omitted on mobile cannot rank in Google Images.
- Crawlable navigation and internal links. Menus that only exist in a desktop layout remove the discovery paths for the pages they linked to.
How parity gets broken in practice
Six patterns account for nearly all of it, and none of them looks like a mistake at the time.
| Pattern | How it happens | Why it damages indexing |
| Content hidden with CSS display rules | A designer hides a long section on small screens to keep the page tidy | Content hidden but present in the HTML is generally still indexed; content removed from the DOM is not. The distinction is invisible in a browser |
| Content loaded only on interaction | Accordions or tabs that fetch content by JavaScript when tapped | If the content is not in the rendered HTML, Google does not index it. Accordions with content already in the DOM are fine |
| Truncated content with “read more” | Mobile shows an excerpt; the full text loads on tap via a request | The full text is absent at render time |
| Simplified mobile templates | A separate lighter template for mobile that omits secondary sections | Everything omitted is deindexed for that page |
| Structured data omitted on mobile | Schema injected by a desktop-only script or template block | Rich result eligibility is lost entirely |
| Navigation replaced, not adapted | A hamburger menu with fewer items than the desktop nav | Internal links disappear, which can orphan pages |
A note on hidden content, because this is where guidance is often mangled. Content that is present in the HTML but visually collapsed, such as a genuine accordion whose text is already in the DOM, is normally indexed. Content that does not exist in the rendered HTML until a user acts is not. The test is not whether a user can see it, it is whether it is there when Google renders the page.
Separate mobile URLs and dynamic serving
Three configurations exist, and two of them create ongoing risk that responsive design does not.
| Configuration | How it works | Risk under mobile-first indexing |
| Responsive | One URL, one HTML, CSS adapts the layout | Lowest risk. Parity is the default unless you actively break it. Google's recommended approach |
| Dynamic serving | One URL, server detects the device and serves different HTML | Parity must be actively maintained on two codebases. Detection errors serve the wrong version to Googlebot |
| Separate mobile URLs (m-dot) | Distinct mobile URLs, typically m.example.com | Highest risk. Requires correct rel=canonical and rel=alternate pairing, and the mobile version is the one indexed, so any content gap there is a gap in your index |
If you still run an m-dot site, migrating to responsive is worth planning. Under mobile-first indexing the m-dot version is what gets indexed, so a thinner mobile site means a thinner presence in Search, and every annotation error compounds the problem. Google published migration guidance on moving from m-dot URLs to responsive as far back as 2017, and it remains the sound direction. We cover the case for the destination in the benefits of responsive website design.
With dynamic serving, the specific failure to watch for is device detection that misidentifies Googlebot's smartphone user agent and serves it the desktop HTML. That produces exactly the mismatch mobile-first indexing exists to expose, and it is invisible unless you test with a smartphone user agent.
Mobile usability that still matters
The tool that checked these is gone; the requirements are not. Each of these is also a conversion problem, which is a better reason to fix them than any ranking argument.
- A configured viewport meta tag. Without it, mobile browsers render at a desktop width and scale down, making everything unreadable.
- Legible text without zooming. Roughly 16 pixels or larger for body copy, and enough contrast to read outdoors.
- Tap targets with adequate size and spacing. Adjacent links that are hard to hit accurately are the reason people tap the wrong thing and leave.
- No horizontal scrolling. Usually caused by a fixed-width element, an oversized image or a table that does not reflow.
- Navigation that works by thumb. Hover-dependent menus do not exist on touch devices.
- Forms that are usable on a phone: correct input types so the right keyboard appears, sensible autocomplete attributes, and labels that stay visible.
- No intrusive interstitials. Pop-ups covering the content immediately on arrival are a usability problem Google treats as one, and separately they are the single most reliable way to lose a first-time visitor.
Test all of this on an actual mid-range phone on mobile data, not a desktop browser resized to a narrow window. The resized window tells you the layout reflows. It tells you nothing about how the page behaves on a slower device, a slower connection, in bright light, with a thumb.
Mobile performance and Core Web Vitals
Core Web Vitals are assessed separately for mobile and desktop, and mobile is almost always the weaker of the two. It is also the one that matters more, since mobile is what Google indexes and where most of your visitors are.
The current metrics, measured at the 75th percentile of real-user visits: Largest Contentful Paint at 2.5 seconds or less, Interaction to Next Paint at 200 milliseconds or less, and Cumulative Layout Shift at 0.1 or less. Any mobile SEO guide still listing First Input Delay predates March 2024, when Interaction to Next Paint replaced it.
What tends to fail specifically on mobile: LCP, because a hero image sized for a desktop viewport is downloaded in full on a phone; INP, because mobile CPUs are slower and the same JavaScript that feels fine on a laptop blocks the main thread noticeably; and CLS, because narrower viewports reflow more dramatically when a late-arriving element appears.
Underneath all of it sits server response time, which is device-independent but disproportionately punishing on mobile connections where every round trip costs more. Time to First Byte is a direct component of the LCP chain, and web.dev treats 0.8 seconds or less at the 75th percentile as good. If your TTFB is two seconds, a good mobile LCP is arithmetically out of reach regardless of how well the front end is built. We cover this in Core Web Vitals and hosting and server-side caching versus plugin caching, and for WordPress specifically in speeding up slow WordPress sites.
For a Canadian audience, origin proximity is a genuine lever here: Canadian web hosting in Canadian data centres shortens round trips for Canadian visitors, which feeds TTFB and therefore LCP. The honest caveat, since it is frequently overstated: that improves latency, and server location is not itself a ranking bonus for Canadian results.
How to audit your mobile pages now
With the old tools gone, this is the workable sequence. It takes about an hour per template and finds the problems that matter.
| Step | What to do | What you are looking for |
| 1 | Open URL Inspection in Search Console for a representative URL of each template, and view the tested page's rendered HTML and screenshot | Whether Google sees your full content. This is the single most valuable check available |
| 2 | Compare the rendered mobile HTML against your desktop page: word count, headings, structured data, metadata, image count | Parity gaps. Anything present on desktop and absent here is not being indexed |
| 3 | Load the page in a browser with a smartphone user agent and JavaScript disabled | Content that depends on JavaScript to exist at all, and device-detection errors on dynamically served sites |
| 4 | Run Lighthouse in mobile mode | Viewport configuration, tap target sizing, font legibility, contrast, and lab performance diagnostics |
| 5 | Read the Core Web Vitals report in Search Console, mobile segment | Real-user field data at the 75th percentile, which is what Google acts on |
| 6 | Open the page on a real mid-range phone on mobile data | Everything the tools cannot tell you: whether it is actually usable |
| 7 | Check the Crawl stats report for smartphone crawl errors and response times | Server-side problems that affect crawling specifically |
Steps one and two are the ones people skip, and they are where the expensive problems hide. A parity gap found here explains ranking losses that months of content work would not have fixed.
Mobile SEO considerations for Canadian businesses
A few points genuinely differ, and one commonly repeated claim does not hold.
Connection quality varies more than national averages suggest. Canadian mobile networks are strong in urban centres and considerably less so in rural and remote areas, and if you serve customers outside major metros, your 75th-percentile field data will reflect that. Optimising for a Toronto office connection under-serves a meaningful share of Canadian visitors.
Local and mobile intent overlap heavily. Queries with local intent skew mobile, and someone searching for a service near them on a phone is closer to acting than almost any other visitor. That makes mobile usability on location and contact pages disproportionately valuable, and it is where broken tap targets and unusable forms cost real revenue. See local SEO for Canadian cities for the local side, and product page SEO if you sell online.
If you serve Quebec, French-language mobile pages need the same parity as everything else. A French version that omits content present in the English version is a parity failure in a second language, and it compounds a compliance consideration under Quebec's Charter of the French Language, as amended by Bill 96, which treats commercial publications as within scope regardless of medium. Confirm your own obligations with a qualified Quebec adviser.
What does not hold: the idea that hosting in Canada improves Canadian mobile rankings. Google infers geographic relevance from your domain, content and language, Search Console targeting, and links, not from server coordinates. Canadian hosting reduces latency, which helps performance metrics, and that is the accurate version of the claim.
JavaScript rendering, and why it is the main cause of parity failure
Most serious parity problems are not design decisions. They are rendering problems, and they occur on sites where content is assembled by JavaScript in the browser.
Googlebot does render JavaScript. That is genuinely true and frequently offered as reassurance, and it is where the reasoning usually stops. Rendering happens, but it is queued, it is resource-constrained, and it can fail in ways that produce a partially built page. What gets indexed is whatever existed in the rendered output at that moment, not what a patient user would eventually see.
So the practical risks on a JavaScript-heavy mobile site:
- Content that arrives after render completes is simply absent from the index.
- A failed API call during rendering produces an indexed page with an empty content area, and there is no error anywhere in Search Console to tell you.
- Client-side routing that does not update the URL, or that relies on fragments, can leave whole sections undiscoverable.
- Internal links built as JavaScript click handlers rather than anchor tags with href attributes may not be followed, which orphans the destinations.
- Metadata and structured data injected client-side can be missed if injection happens late.
The reliable mitigation is not to abandon JavaScript but to ensure the primary content, headings, navigation, metadata and structured data are in the HTML the server sends. Server-side rendering, static generation or hydration of pre-rendered markup all achieve that. What you should avoid is a mobile page whose content exists only as the outcome of successful client-side execution.
To check: load your page with JavaScript disabled and see what remains, then compare against the rendered HTML in URL Inspection. The gap between those two views is your exposure, and on many modern sites it is larger than anyone expected.
Smartphone Googlebot and crawl behaviour
Since indexing is mobile-first, the crawler visiting you is predominantly the smartphone Googlebot, and a few of its characteristics matter operationally.
It needs access to your resources. If robots.txt blocks the CSS or JavaScript required to render the mobile layout, Google renders an incomplete page and indexes that. Blocking asset directories is a surprisingly common legacy configuration, often added years ago to save crawl budget, and it now actively damages indexing.
It has practical limits. Google has noted that Googlebot processes roughly the first 15 MB of an HTML file, with referenced resources fetched separately. That is generous for normal pages and reachable on bloated ones, and anything beyond the cutoff is not considered. Enormous inlined payloads are the usual culprit.
It responds to server behaviour. Persistent server errors cause Google to slow crawling, which delays discovery of everything new you publish. For planned maintenance, return a 503 rather than a 200 page saying the site is unavailable, since a 200 invites Google to index an apology. Check the Crawl stats report for smartphone crawl errors and average response time; a rising trend there is your server telling on itself before your rankings do.
One consequence worth internalising: mobile performance is a crawl issue as well as a ranking one. A slow server reduces how much Google fetches per visit, which on a large site means slower discovery and slower re-evaluation of the pages you just improved.
What to prioritise by site type
The general requirements are the same everywhere. The failure modes are not.
| Site type | Where mobile parity usually breaks | Priority check |
| Ecommerce | Product descriptions truncated on mobile; review widgets and specification tables loaded on interaction; variant selectors as JavaScript-only controls | Compare rendered mobile HTML of a product page against desktop, paying attention to specifications and reviews |
| Local service business | Contact and location details rendered as images or in a desktop-only sidebar; unusable tap targets on phone numbers and forms | Test the contact and location pages on a real phone, then confirm NAP details are in the rendered HTML as text |
| WordPress | Page builder modules with visibility rules that remove content on small screens; plugin-injected schema loading only on desktop; theme dropping secondary sections | Audit builder visibility settings, and verify structured data appears in the rendered mobile HTML |
| Publisher or blog | Related content and author information dropped on mobile; long articles truncated behind a read-more that fetches the remainder | Word count comparison between rendered mobile and desktop versions |
| Single-page or app-like site | Content assembled client-side; routing that does not produce crawlable URLs; links as click handlers | JavaScript-disabled load, then rendered HTML comparison |
| Multilingual or bilingual | hreflang annotations present only on desktop; French or English version thinner on mobile | Confirm hreflang and full content on the mobile rendering of every language version |
Prioritised mobile SEO checklist
Ordered by consequence. Work down, and stop when the remaining items stop mattering for your site.
Parity, first and most important
- Rendered mobile HTML contains the full primary content of each template
- Headings present, in the same hierarchy as desktop
- Structured data present on the mobile version
- Title, meta description, canonical, robots directives and hreflang match desktop
- Images present with the same alt text
- Navigation and internal links crawlable, with no items dropped on mobile
Crawlability and rendering
- txt permits the CSS and JavaScript needed to render
- Primary content present with JavaScript disabled, or served pre-rendered
- Internal links are anchor tags with href attributes, not click handlers
- No smartphone crawl errors in the Crawl stats report
Usability
- Viewport meta tag configured
- Body text legible without zooming
- Tap targets adequately sized and spaced
- No horizontal scrolling on any template
- Forms usable by thumb, with correct input types
- No intrusive interstitial on entry
Performance
- Mobile LCP 2.5 s or less at the 75th percentile on field data
- Mobile INP 200 ms or less
- Mobile CLS 0.1 or less
- TTFB measured from your audience's region, ideally under 0.8 s
- Main mobile image excluded from lazy loading and correctly sized
- Third-party scripts audited against their business value
How to measure whether mobile work paid off
Mobile SEO improvements are measurable, but only if you segment. A site-wide traffic figure hides the effect entirely, because desktop and mobile move differently and the mobile segment is where your changes land.
What to watch, in Search Console with the device filter set to mobile: impressions and clicks by landing page group, since template-level movement is what tells you whether a fix worked; average position for mobile specifically, read per query rather than as a site average; indexed page count against published, which is the check that catches parity failures returning after a deployment; and the mobile segment of the Core Web Vitals report.
Two timing points that cause teams to misjudge their own work. Parity fixes require re-crawling and re-indexing before they show, which takes weeks on most sites and longer on large ones, because Google has to revisit each affected URL. And Core Web Vitals field data moves on a rolling window of roughly 28 days, so a genuine performance fix appears gradually rather than at once. Judging either after a week produces the wrong conclusion, and reverting a working change is a common and expensive outcome.
Set a performance budget once you are in good shape, because mobile performance regresses by default. Every new tag, tracking script, chat widget, campaign pixel and design flourish adds weight, and each is added by someone who does not see the cumulative cost. A stated ceiling for mobile LCP on key templates, and a review requirement before third-party scripts are added, is what stops you repeating this project in eighteen months.
Mobile pages and AI search surfaces
One newer consideration worth stating carefully, because the specifics are moving and much of what is written about it is speculation.
Google's AI experiences in Search draw on the same indexed content, which means they draw on your mobile version. That has a direct implication for parity: content missing from your mobile rendering is not merely absent from traditional results, it is absent from anything built on top of the index. A specification table, FAQ block or explanatory section dropped on mobile cannot be cited in an AI answer, because as far as the system is concerned it does not exist.
The durable principle, rather than a tactic that will date: clean structure and unambiguous facts are extractable, and marketing prose is not. Question-led headings with direct answers beneath them, real tables rather than tables rendered as images, and self-contained statements that do not depend on three preceding paragraphs all survive extraction. Those are the same practices that make a mobile page readable on a small screen, which is a convenient alignment rather than a coincidence.
What is not settled is the traffic consequence, and anyone presenting a definitive answer on that is guessing. Treat parity and structure as the controllable part and leave the forecasting alone.
Twelve common mobile SEO mistakes
| Mistake | Why it costs you |
| Treating mobile-first indexing as upcoming | It completed in October 2023. Advice framed as preparation is years stale |
| Hiding content on mobile to simplify the layout | If it leaves the rendered HTML, it leaves the index |
| Loading content only on tap | Accordions are fine when the text is already in the DOM. Fetching it on interaction is not |
| Omitting structured data on mobile | Rich result eligibility is lost entirely, since the mobile version is what Google reads |
| Reducing the mobile navigation | Removes internal links and can orphan the pages they pointed to |
| Different metadata on mobile | Titles, descriptions, canonicals and hreflang must match. Google uses the mobile values |
| Testing by resizing a desktop browser | Confirms the layout reflows. Says nothing about a slower device and connection |
| Still using the Mobile-Friendly Test | Retired December 2023. Use URL Inspection and Lighthouse |
| Assuming responsive equals compliant | Responsive is the mechanism. Parity is the requirement, and responsive themes can still break it |
| Lazy-loading the main mobile image | Delays the element LCP measures, on the segment where LCP is already weakest |
| Optimising desktop Core Web Vitals | Assessment is segmented, and mobile is the weaker and more consequential half |
| Intrusive interstitials on entry | A page experience problem and a conversion problem simultaneously |
When to bring in help
Most of this is self-serviceable. Comparing rendered mobile HTML against your desktop page requires patience rather than expertise, and it is the highest-value check on the list. The SEO fundamentals you can handle yourself covers the surrounding fundamentals.
Where outside help earns its cost: parity failures caused by a JavaScript framework, where the fix is architectural; dynamic serving or m-dot migrations, which carry real risk to existing rankings; INP problems distributed across a framework and several third-party scripts, where no single owner can resolve them; and situations where mobile field data is failing but you cannot establish whether the cause is your server or your front end.
If you do engage someone, a quick currency test: ask what the current Core Web Vitals are. The answer should be LCP, INP and CLS. Anyone naming First Input Delay, or proposing to run the Mobile-Friendly Test, is working from material that is at least two years out of date. Our SEO services team works with Canadian businesses on this kind of diagnosis, and that test should be applied to us as readily as to anyone else.
Conclusion
Mobile-first indexing is finished business. Google indexes the mobile version of your pages, that has been universally true since October 2023, and the tool that used to give you a friendliness verdict was retired that December. Any guide still treating this as a migration to prepare for is describing a world that ended three years ago.
What replaced the binary question is more demanding and more useful. Content parity is the requirement: whatever is missing from your mobile page is missing from Google's understanding of it, and that failure is invisible in casual testing. Mobile usability still matters, but as a conversion issue at least as much as a ranking one. And mobile performance is where most sites have genuine room to improve, because the mobile segment of Core Web Vitals is almost always the weaker one and the mobile visitor is the one you are most likely to lose.
The practical sequence is short. Open URL Inspection, look at the rendered mobile HTML for each of your important templates, and compare it against the desktop page. If content, headings, structured data or metadata are missing, fix that before anything else, because no amount of content or link work compensates for content Google cannot see. Then test on a real phone, then work on performance.
That first check costs nothing and takes an hour. On most sites it either confirms the fundamentals are sound, which lets you spend elsewhere with confidence, or it finds something that has quietly been costing you traffic for years.
FAQ
What is Google mobile-first indexing?
Mobile-first indexing means Google uses the mobile version of your pages for indexing and ranking. Googlebot crawls as a smartphone user agent and indexes what it finds in the mobile rendering. There is no separate mobile index: there is one index, built from mobile versions, and it determines your desktop rankings too.
Is mobile-first indexing still rolling out?
No. Google announced completion in October 2023 in a Search Central post titled “Mobile-first indexing has landed”. The migration ran from 2016 to 2023 in stages. Any guidance framed as preparing for the switch, or referring to a Search Console migration notification, predates that.
Is mobile-first indexing a ranking factor?
No, it is how indexing works rather than a ranking signal. Mobile usability and page experience, including Core Web Vitals, do feed into Google's ranking systems, but those are separate from mobile-first indexing itself. Making a site responsive does not by itself produce a ranking increase.
What happened to Google's Mobile-Friendly Test?
Google retired it, along with the Mobile-Friendly Test API and the Search Console Mobile Usability report, effective 1 December 2023, having announced the change in April 2023. Google said mobile usability remained important but that better resources had emerged, pointing to Lighthouse. Use URL Inspection in Search Console to see the rendered mobile page, and Lighthouse for usability diagnostics.
How do I test if my site is mobile-friendly now?
Use URL Inspection in Search Console to view the rendered mobile HTML and screenshot for pages on properties you own; run Lighthouse in mobile mode for viewport, tap target, font and contrast checks; read the mobile segment of the Core Web Vitals report for real-user data; and open the page on an actual mid-range phone on mobile data. No single tool now gives the old yes-or-no verdict.
What is content parity and why does it matter?
Content parity means the mobile version of a page contains the same primary content, headings, structured data, metadata and images as the desktop version. It matters because Google indexes the mobile version, so anything absent there is not indexed at all. This is the most damaging mobile SEO problem because the site still looks fine to a human on a phone.
Can I hide content on mobile without hurting SEO?
It depends on the mechanism. Content present in the rendered HTML but visually collapsed, such as an accordion whose text is already in the DOM, is normally indexed. Content that is not in the rendered HTML until a user taps something is not indexed. The test is whether the content exists when Google renders the page, not whether a visitor can see it immediately.
Do I need a separate mobile site?
No, and it is the riskiest of the three configurations. Google recommends responsive design: one URL, one set of HTML, layout adapting via CSS. Separate mobile URLs require correct canonical and alternate annotations and constant parity maintenance, and under mobile-first indexing the mobile version is the one indexed, so any content gap there becomes a gap in your search presence.
Does mobile page speed affect rankings?
Mobile Core Web Vitals form part of page experience, which Google's ranking systems consider, so performance contributes. It is not a tiebreaker that overrides relevance. Its bigger effect is usually commercial: mobile visitors abandon slow pages, and the mobile segment of Core Web Vitals is almost always weaker than desktop.
What are the current Core Web Vitals for mobile?
Largest Contentful Paint at 2.5 seconds or less, Interaction to Next Paint at 200 milliseconds or less, and Cumulative Layout Shift at 0.1 or less, each at the 75th percentile of real-user visits, with mobile and desktop assessed separately. First Input Delay was replaced by Interaction to Next Paint in March 2024 and is no longer current.
Does hosting in Canada improve mobile rankings for Canadian searches?
Not directly. Google determines geographic relevance mainly from your domain, content and language, Search Console country targeting, and links, not from where your server sits. Hosting near your audience does reduce latency, which improves Time to First Byte and therefore Largest Contentful Paint, so the benefit is real but indirect.
My desktop rankings dropped. Could mobile be the cause?
Yes, and it is a commonly missed diagnosis. Because Google indexes the mobile version, a parity failure on mobile affects your rankings on all devices. If content, headings, structured data or internal links were removed from the mobile layout, the effect shows up in desktop results too. Check the rendered mobile HTML in URL Inspection before looking anywhere else.
Key takeaways
- Mobile-first indexing completed in October 2023. It is how indexing works, not an upcoming change to prepare for.
- There is one index, built from mobile versions. Your desktop rankings are determined by what Google found on your mobile page.
- Mobile-first indexing is not itself a ranking factor. Mobile usability and page experience are separate concepts that do feed ranking systems.
- Content parity is the operative requirement: content absent from the mobile rendering is not indexed at all.
- Structured data, metadata, headings, images and internal links must all be present on the mobile version.
- Content collapsed but present in the DOM is normally indexed. Content fetched only on interaction is not.
- Google retired the Mobile-Friendly Test, its API and the Search Console Mobile Usability report on 1 December 2023. Use URL Inspection and Lighthouse instead.
- JavaScript rendering is the main cause of parity failure. Test with JavaScript disabled and compare against the rendered HTML.
- txt must permit the CSS and JavaScript needed to render, or Google indexes an incomplete page.
- Current Core Web Vitals are LCP 2.5 s, INP 200 ms, CLS 0.1 at the 75th percentile, assessed separately for mobile. First Input Delay is retired.
- A desktop ranking drop can be caused by a mobile parity failure, which is a commonly missed diagnosis.
- Canadian hosting reduces latency and is not a Canadian ranking bonus.
