Does mobile-first indexing really require distinct annotations for separate URLs?

Why does Google still emphasize separate URLs when responsive has become the standard?

Because thousands of legacy sites still use configurations with distinct mobile URLs (typically m.site.com or site.com/mobile/). These architectures from the early 2010s still represent a significant part of the web, especially in e-commerce and media where complete overhauls are costly.

Google here reiterates a key principle: if you maintain separate versions, bidirectional annotations remain mandatory. The desktop version must point to the mobile version via rel="alternate" and the mobile version must point to the desktop version via rel="canonical". Without this symmetry, Googlebot cannot determine which version should take precedence in the mobile-first index.

Does mobile-first indexing really eliminate desktop indexing all at once?

No. This is exactly what Google clarifies here. The shift to mobile-first is not a binary switch that instantly removes any trace of your desktop version from the index. There is a transition period where both versions can coexist in different sections of the index.

Specifically, some crawls can still target the desktop version for a few weeks after the official switch. This floating period creates situations where your annotations must remain consistent even after receiving the notification for migration to mobile-first in Search Console. Neglecting the maintenance of these tags prematurely opens the door to canonicalization errors.

What real risks do we run with faulty annotations?

The first risk is perceived content duplication. If Google cannot clearly link m.site.com/page-a and www.site.com/page-a, it may treat them as two distinct entities with similar content. The result: dilution of PageRank, cannibalization in SERPs, and in the worst case, filtering out one of the two versions.

The second risk affects ranking signals. Your backlinks primarily point to the desktop version. If the annotations are broken, these signals may not transfer correctly to the mobile version, which becomes your canonical URL in the mobile-first index. You then lose authority where it matters most.

• Maintain bidirectional rel="alternate" and rel="canonical" annotations between mobile and desktop versions
• Check the consistency of annotations even after the confirmed mobile-first switch
• Monitor crawl logs to detect if Googlebot continues to visit both versions
• Do not prematurely remove tags on the pretext that the site has switched to mobile-first
• Test signal propagation (backlinks, redirects) between the two architectures

Does this statement really reflect observed behavior on the ground?

Yes, but with an important nuance. Field observations confirm that Google does crawl both versions for several weeks post-migration. However, the duration of this transition phase varies greatly depending on the site's size, its usual crawl frequency, and the quality of its technical implementation.

For sites with a few hundred well-structured pages, the switch can be nearly instantaneous. For sites with millions of URLs and significant technical debt, residual desktop crawls can be observed up to 3-4 months after the official notification. Google remains deliberately vague on this timeline, making planning for technical overhauls challenging. [To be verified]: no official document provides a precise SLA on this coexistence period.

Are bidirectional annotations still necessary with modern JavaScript rendering?

This is where it gets tricky. Google recommends these annotations in a context of physically distinct URLs (m.site.com vs www.site.com). But with the explosion of JavaScript frameworks serving adaptive content on a single URL via server-side user-agent detection, the line becomes blurry.

If you serve mobile content via user-agent detection without changing the URL, these annotations are theoretically not necessary. The problem: Google does not always crawl with the correct user agents, and JavaScript rendering can produce DOM variations that can create confusion. In these edge cases, some practitioners still add annotations in the rendered HTML to push Googlebot in the right direction. Actual effectiveness? [To be verified] — field reports are mixed.

Should we still maintain separate mobile URLs today?

Let’s be honest: no, unless there is an insurmountable inherited technical constraint. Maintaining two parallel architectures doubles the attack surface for bugs, complicates analytics tracking, fragments ranking signals, and slows down deployments. Responsive design (or adaptive serving on a single URL) solves all these problems at once.

But the reality on the ground is that thousands of sites cannot migrate to a single architecture without a complete overhaul of their technical stack. For these sites, Google’s statement is a harsh reminder: you are stuck maintaining this complexity of annotations as long as you keep this architecture. The cumulative maintenance cost often ends up economically justifying a redesign.

How can I check that my annotations are correctly configured?

First step: crawl your site with a tool like Screaming Frog in both mobile and desktop modes. Export the rel="alternate" and rel="canonical" tags for each URL and check that each desktop page points to its mobile counterpart via alternate, and that each mobile page points to its desktop counterpart via canonical. A pivot table will instantly show you any inconsistencies.

Second step: use the URL inspection tool in Search Console. Test a few representative URLs from each page type (homepage, product page, article, category). Check that Google correctly identifies the mobile version as canonical and that the annotation to the desktop version is present in the rendered HTML. If Google ignores your tags, that’s a red flag.

What should I do if my site has already switched to mobile-first but the annotations are faulty?

Don’t panic, but act quickly. If you notice missing or contradictory annotations after the switch, immediately correct them and force a recrawl through Search Console. Google will recalculate canonical relations during the next Googlebot visit. Monitor your positions for 2-3 weeks after the correction to detect any residual impact.

If you observe a drop in organic traffic correlated with the mobile-first switch AND your annotations were faulty, it’s likely related. In this case, also audit the content parity between your versions (texts, images, structured data, internal links). Often, annotation issues mask deeper content disparities that significantly penalize ranking.

What critical errors should you absolutely avoid?

Error number 1: removing alternate/canonical annotations as soon as you receive the mobile-first notification in Search Console. As Google specifies, desktop indexing does not disappear instantly. Keep these tags active for a minimum of 2 months after the switch, then verify in your logs that Googlebot-desktop has stopped crawling before removing them.

Error number 2: asymmetrical annotations. If your desktop page points to m.site.com/page-a but m.site.com/page-a points to www.site.com/another-page, Google cannot resolve the loop. Check for perfect symmetry with an automated script. A single misconfigured URL can contaminate the signal for an entire section of the site.

• Crawl the site in both mobile AND desktop modes to extract all alternate and canonical tags
• Verify the bidirectional symmetry of annotations with a pivot table
• Test representative URLs with the Search Console inspection tool
• Monitor crawl logs to detect continued visits from Googlebot-desktop post-migration
• Keep annotations active for at least 2 months after the mobile-first switch
• Audit content parity between the two versions (text, images, structured data, links)