Should you really keep the Vary User-Agent header for your mobile sites?

Why does Google still insist on this particular HTTP header?

The HTTP Vary User-Agent header indicates to intermediate servers and caches that a URL can return different content versions depending on the user-agent making the request. Specifically, this means that an intelligent cache will not serve the mobile version of a page to a desktop user and vice versa.

Google uses this signal to understand that a site employs dynamic serving, meaning it serves different HTML content from the same URL depending on the device. Without this header, intermediate caches may serve the wrong version to your users, and Googlebot might struggle to distinguish your mobile and desktop content during crawling.

This recommendation has existed for years, but Google reiterates it because many sites still neglect this setup. The problem is particularly acute for architectures that have not migrated to pure responsive design or to separate URLs for mobile.

In what scenarios does this header play a critical role?

This situation primarily concerns sites practicing dynamic serving, where the same URL returns different HTML depending on whether the user is coming from mobile or desktop. If your site is fully responsive with a single HTML that is identical for all devices, this header adds no value.

CDNs and cache proxies rely on this header to decide whether they can serve a cached version or need to query the origin server. Google explicitly mentions that Akamai and some other CDNs do not always correctly detect this header, which can create situations where mobile users receive cached desktop content.

For indexing, Googlebot uses two distinct user-agents (desktop and mobile). The Vary header helps Google understand that it needs to crawl the URL with both user-agents to get both versions of the content. Without this signal, Google might only crawl one version and miss important differences for mobile-first indexing.

How does this differ from other mobile approaches?

Google recognizes three main configurations for mobile sites: responsive design (a single HTML that adapts), dynamic serving (identical URLs, different HTML depending on the device), and separate URLs like m.example.com. The Vary User-Agent header only relates to dynamic serving.

If you use separate URLs with dedicated mobile subdomains, you do not need this header since the versions are physically distinct. Responsive design does not need it either since the HTML is identical. It's only when you serve dynamically different content from the same URL that this header becomes essential.

The important nuance: even if your site is primarily responsive, certain sections may practice dynamic serving for performance or functionality reasons. In this case, the header must be present on those specific URLs.

• The Vary User-Agent header is mandatory only for dynamic serving (same URL, different HTML depending on the device)
• It helps caches store and serve the correct versions based on the requesting user-agent
• Google uses it to know that it should crawl a URL with its two bots (mobile and desktop)
• Some CDNs like Akamai do not always respect it correctly, creating risks of misconfigured cache
• Pure responsive sites or those with separate URLs do not need this header

Is this recommendation still relevant with mobile-first indexing?

Let's be honest: this Google statement comes late in the game. Mobile-first indexing has been deployed for several years now, and the majority of professional sites have migrated to pure responsive design. Dynamic serving has become a minority practice, mainly used by large legacy sites or platforms with specific technical constraints.

The fact that Google continues to recall this recommendation suggests two things. First, there remains a significant volume of sites in dynamic serving that do not configure this header correctly. Second, Google is likely observing recurring indexing issues on these poorly configured sites, hence the need to reiterate best practices.

What's less clear in the statement is the actual impact on ranking. Google says it "improves indexing" and helps "differentiate content," but does not quantify the effect. [To be validated] in the field: do sites that add this header afterward see a measurable improvement in Search Console? Public data is lacking.

Is the problem of CDNs ignoring this header really widespread?

Google explicitly cites Akamai as an example of a CDN that does not always detect the Vary User-Agent header. This is a precise technical claim that deserves attention. Being one of the largest CDNs on the market, this potentially concerns millions of sites.

Specifically, if your CDN ignores this header, it will cache the first served version (mobile or desktop) and serve it to all subsequent visitors, regardless of their device. Result: mobile users receive non-responsive desktop HTML, and vice versa. This is a major user experience issue that also impacts the behavioral signals Google measures.

The nuance: most modern CDNs allow manual configuration of cache rules based on the user-agent, even if they do not honor the Vary header. You should check the specific configuration of your CDN rather than solely relying on this header. [To be validated]: ask your CDN provider how they manage cache by user-agent.

When can this recommendation be safely ignored?

If your site serves exactly the same HTML to all devices and only uses CSS and JavaScript to adjust the display, you absolutely do not need this header. This applies to 90% of modern WordPress sites with recent responsive themes.

Similarly, if you use separate URLs (m.example.com vs www.example.com) with correctly configured rel=alternate and rel=canonical tags, the Vary header adds nothing. Google already knows they are distinct versions thanks to these tags.

The real use case today is limited to sites that have consciously chosen dynamic serving for server performance (to avoid sending unnecessary HTML to mobiles) or for very different functionalities between mobile and desktop. These sites are in the minority but still exist, particularly in high-volume e-commerce or media.

How can you check if your site needs this header?

The first step: identify your current mobile architecture. Open your site on mobile and desktop, then examine the HTML source code. If the HTML is strictly identical (same tags, same content, only the CSS changes the display), you are responsive and do not need the header.

If the HTML significantly differs between the two versions while the URL is identical, you are practicing dynamic serving, and the header becomes mandatory. To check technically, use curl with different user-agents and compare the responses.

Then check the HTTP headers currently sent by your server. In Chrome DevTools, under the Network tab, refresh the page and examine the Response Headers. Look for a line "Vary: User-Agent". If it is missing while you are doing dynamic serving, that's a problem to fix quickly.

What is the correction procedure based on your technical stack?

On Apache, add the following to your .htaccess or in the vhost configuration: Header append Vary User-Agent. This directive appends the header to all HTML responses. Be careful not to add it to static resources (CSS, JS, images) where it would be unnecessary.

On Nginx, in your server or location block, use: add_header Vary User-Agent always; The "always" flag ensures that the header is added even if the response has an error code. Restart Nginx after modification.

For sites under Cloudflare, Fastly, or another CDN, first check the configuration of the CDN itself. Some CDNs have predefined cache rules based on user-agent that may conflict with your Vary header. Consult your provider's specific documentation.

What indicators to monitor after implementation?

In Search Console, monitor the evolution of the number of indexed pages in the coverage reports. If Google is now correctly crawling your two versions, you should see stabilization or a slight increase in indexed URLs. Also check the error reports for any potential mobile compatibility issues.

On the analytics side, examine bounce rate and time on site segmented by device type. If mobile users were previously receiving cached desktop content, you should see an improvement in engagement metrics after correction. This is an indirect signal that the header is doing its job.

Also keep an eye on your Core Web Vitals in Search Console. A poorly configured cache can force users to load resources that are unsuitable for their device, degrading performance. Improving the cache via the Vary header can have a measurable positive effect on mobile LCP and CLS.

• Audit your current mobile architecture (responsive, dynamic serving, or separate URLs)
• Check for the presence of the Vary User-Agent header in the Response Headers with DevTools
• Test your site with curl and different user-agents to confirm content variations
• Add the header in your server configuration (Apache, Nginx) if necessary
• Check your CDN configuration and its cache rules by user-agent
• Monitor Search Console for 2-4 weeks to measure the impact on indexing