Official statement
Other statements from this video 25 ▾
- □ Does Google really experience delays in discovering JavaScript links?
- □ Why does Google ignore your canonical tags when the raw HTML contradicts the rendered output?
- □ Does a raw HTML noindex really prevent JavaScript rendering by Google?
- □ Can you really modify title, meta, and links on the client side with JavaScript without risks?
- □ Is client-side JavaScript really holding back your SEO performance?
- □ Raw HTML vs Rendered: Does Google really not care?
- □ Does Google AdSense really penalize your site's speed like any other third-party script?
- □ Should you be worried about 'other error' issues with images in the Search Console?
- □ Do JavaScript navigation links really affect your site's SEO?
- □ Can you really lose control of your canonical by leaving the href attribute empty at load time?
- □ Does Google really use different crawlers for its SEO testing tools?
- □ Are the structured data from your mobile version also applicable to desktop?
- □ Should you really stop fearing JavaScript for SEO?
- □ Do JavaScript links really slow down Google's discovery process?
- □ How can a different canonical tag between raw HTML and rendered output destroy your canonicalization strategy?
- □ Can you really remove a noindex via JavaScript without risking de-indexation?
- □ Is it truly safe to modify meta tags and links with JavaScript without risking your SEO?
- □ Do Google products really get a hidden SEO advantage in search results?
- □ Should you be concerned about 'other' errors in the URL Inspection Tool?
- □ Does Google really overlook your images during web search rendering?
- □ User agent or viewport: Does Google really differentiate for mobile indexing?
- □ Do JavaScript-generated links truly pass ranking signals like traditional HTML links?
- □ Can an empty HTML canonical tag mistakenly force Google to auto-canonicalize your page?
- □ Can the Mobile-Friendly Test really substitute the URL Inspection Tool for auditing mobile crawling?
- □ Why does Google ignore your desktop structured data after switching to mobile-first indexing?
Google states that the user agent is sufficient for serving separate mobile and desktop versions, yet still recommends viewport detection for an enhanced overall user experience. This nuance highlights a gap between what works for Googlebot and what truly optimizes UX. In practice, if you are still maintaining separate URLs like m.site.com, the user agent remains technically valid for SEO — but switching to responsive design or viewport detection ensures less user friction.
What you need to understand
What is the reason behind Google's distinction between user agent and viewport?
Detection via user agent relies on analyzing the string sent by the browser or bot during the HTTP request. It is a server-side method: the site identifies the device (mobile, desktop, bot) before even sending the HTML. Google accepts this without issue for serving separate versions — typically m.site.com versus www.site.com. On the other hand, detection by viewport is based on the actual dimensions of the screen through CSS and JavaScript. The server sends the same HTML, but the display adapts dynamically. This is the logic of responsive design. Google prefers this approach because it better covers edge cases: tablets, foldables, resized windows, modified or spoofed user agents. No. Martin Splitt clearly states: the user agent is sufficient for Google. If your legacy infrastructure relies on separate mobile URLs detected by user agent, you are not penalized. Googlebot mobile identifies correctly, the server redirects or serves the right version, and everything works. The issue is not strictly SEO; it is UX. A user switching devices, moving from portrait to landscape, or using a browser with an atypical user agent risks landing on the wrong version. The viewport, on the other hand, adjusts in real-time. This is why Google promotes this method “in general” — not for its algorithm, but for your users. It mainly concerns legacy sites that still maintain separate mobile versions rather than a unified responsive design. These architectures still exist — major media outlets, legacy e-commerce, complex platforms where a complete redesign is not budgeted. If you are in this situation, Google reassures you: continuing with the user agent will not break your mobile-first indexing. But it also reminds you that it is a compromise solution, not the optimum. The real target remains responsive or adaptive designs based on viewport.Does this mean that the user agent is obsolete for SEO?
In what context does this statement remain relevant today?
SEO Expert opinion
Is this statement consistent with on-the-ground practices?
Yes, absolutely. We still see legacy news or e-commerce sites serving m.domain.com via user agent, and they rank without issues. Googlebot mobile identifies correctly, the server makes a 302 redirect or serves the right version directly, with no indexing issues observed. What Martin Splitt does not explicitly state is that configuration errors remain frequent. Variants include forgetting the cross alternate/canonical tags, using a 301 redirect instead of a 302, or user agent detection that misses modern bots or tablets. In these cases, the viewport would have bypassed the problem — a single HTML, one set of canonicals. Google says “in general,” and that’s where it gets tricky. There are contexts where serving radically different HTML between mobile and desktop remains relevant — for instance, a mobile app that displays less content for performance reasons or specific touch usage. In those cases, server-side user agent detection allows for precise control. The viewport assumes that the same DOM is visually adapted. If your mobile loads 50% fewer features, the viewport is not enough — the device must be accurately detected before sending the HTML. [To be verified]: Google has never detailed if a significant content delta between versions is accepted in mobile-first. If you are using a unified responsive design (one URL, one HTML, CSS adaptation), the user agent vs viewport question does not even arise — you are already on the path recommended by Google for years. If you are serving dynamic server-side content (SSR with Next.js, Nuxt, etc.) and detecting viewport via CSS media queries, likewise: you are in the optimal case. Splitt's statement targets historical separate architectures, not modern stacks that are already responsive by default.What nuances should be added to this recommendation?
In what cases does this rule not apply?
rel="alternate" and rel="canonical" tags are strictly symmetrical and tested. A configuration error here carries more weight than the user agent vs viewport choice.
Practical impact and recommendations
What practical steps should you take if you are still using the user agent?
First, ensure that your detection works for Googlebot mobile (user agent containing “Mobile”, “Android”, “iPhone”). Test with the URL Inspection tool in Search Console — mobile mode. If the correct version displays, you are covered for strict SEO. Next, test with real devices: tablets, foldables, less common browsers. If some end up on the desktop version when they should see the mobile one, that’s where the viewport would have avoided the pitfall. In this case, assess the cost of migrating to a unified responsive design versus the current UX risk. Never make a permanent 301 redirect between desktop and mobile. Use a 302 (or 307 if you want to be picky about HTTP method). Google must understand that both versions exist in parallel, not that one replaces the other. Another classic trap: forgetting the cross rel="alternate" and rel="canonical" tags. The desktop page must point to the mobile one with Analyze your mobile bounce rates and user journeys. If you notice users manually switching to the desktop version (link at the bottom of the page “View full site”), it’s a signal that the user agent detection is missing its target. Also, look at your server logs: how many requests with a mobile user agent still end up on the desktop version (or vice versa)? If the volume is marginal, sticking with the user agent remains defensible. If it represents 5-10% of traffic, migration becomes worthwhile.What errors should you avoid with separate mobile versions?
<link rel="alternate" media="only screen and (max-width: 640px)" href="https:\/\/m.site.com\/page">, and the mobile must canonicalize back to the desktop with <link rel="canonical" href="https:\/\/www.site.com\/page">. Without this, Google may duplicate indexing or choose the wrong version.How can you tell if a migration to viewport is necessary?
rel="alternate" and rel="canonical" tags on all page pairs.
❓ Frequently Asked Questions
Est-ce que Google pénalise les sites qui utilisent encore le user agent pour servir des versions mobiles séparées ?
Quelle différence entre détection user agent et détection viewport en termes de SEO pur ?
Dois-je migrer vers un design responsive si j'ai déjà des URLs mobiles séparées qui fonctionnent ?
Quels sont les risques concrets de mal configurer des versions mobiles séparées ?
Le viewport est-il toujours la meilleure solution, même pour des sites complexes ?
🎥 From the same video 25
Other SEO insights extracted from this same Google Search Central video · published on 26/04/2021
🎥 Watch the full video on YouTube →
💬 Comments (0)
Be the first to comment.