Official statement
Other statements from this video 9 ▾
- 9:23 Faut-il vraiment rediriger les mobiles vers l'accueil quand la page n'existe pas en responsive ?
- 11:21 Pourquoi les redirections mobiles cassent-elles encore votre SEO ?
- 19:14 Les redirections 301 suffisent-elles vraiment à sauver vos rankings lors d'un changement de domaine ?
- 23:38 Les interstitiels mobiles sont-ils vraiment un handicap pour votre SEO ?
- 38:06 Les données structurées JavaScript sont-elles vraiment indexées par Google ?
- 43:24 Faut-il vraiment dupliquer vos données structurées entre mobile et desktop ?
- 44:44 Comment éviter que le contenu dupliqué sabote votre indexation avec la balise canonical ?
- 47:37 Pourquoi Google n'indexe-t-il pas toutes les URLs de votre sitemap ?
- 50:46 Google a-t-il vraiment besoin d'optimisations spécifiques pour la recherche vocale ?
Google confirms that the HTTP Vary header is only needed if you serve different content based on devices. If your site uses responsive design with the same HTML for all devices, this header is pointless. However, its presence won't penalize your SEO if you implemented it in the past.
What you need to understand
What is the HTTP Vary header and what does it do?
The HTTP Vary header informs browsers and proxies that the content of a URL can vary based on certain criteria. For SEO, we mainly refer to Vary: User-Agent, which signals that the server delivers different HTML depending on the type of device.
This header was crucial during the dynamic serving era when sites served specific HTML for mobile and different HTML for desktop under the same URL. Without this signal, intermediate caches risked serving the desktop version to a mobile user or vice versa. Google strongly recommended this practice at the time.
Why does Google now say it’s optional?
Responsive design has replaced dynamic serving. Today, the majority of sites use the same HTML with CSS breakpoints to adapt to screens. In this case, the content doesn't vary based on User-Agent: it is identical.
Google is simplifying its position. If you serve the same content to all devices, the Vary: User-Agent header doesn't provide any useful information to the search engine. It becomes redundant, a remnant from a different time in mobile web development.
What happens if I have already implemented it?
Google states that the presence of the Vary header is not problematic. It’s not a negative signal that would harm your crawl budget or indexing. The engine simply ignores what it doesn't understand or that does not apply.
This tolerance makes sense. Many sites have migrated from dynamic serving to responsive without cleaning up their server configuration. Removing this header may involve changes in Nginx, Apache, or the CDN. Google does not want to penalize a harmless historical configuration.
- The Vary: User-Agent header is relevant only with distinct content per device (dynamic serving)
- With a responsive design, this header is unnecessary but harmless
- Google does not penalize its presence; it simply ignores it
- This statement clarifies a gray area that has persisted since the adoption of mobile-first strategies
SEO Expert opinion
Does this statement align with what we observe in the field?
Yes. Technical audits have shown for years that responsive sites with Vary: User-Agent do not experience crawl or indexing disadvantages. Google has always been quite flexible on this point in practice, even if its documentation remained vague.
What confuses practitioners is that Google long recommended this header in its documentation on dynamic serving. Many developers implemented it as a precaution, even on responsive sites. This statement now avoids wasting time debating its usefulness during audits.
What nuances should be added to this claim?
The devil is in the details. Some sites serve identical HTML but with different resources (images, scripts) depending on the device. In this case, Vary remains relevant for intermediate caches, even if Google doesn’t care.
Moreover, this statement does not cover Vary: Accept-Encoding or other variants. It specifically targets the User-Agent in a mobile vs desktop context. Do not remove all your Vary headers without careful consideration.
When does this rule not apply?
If you are still practicing dynamic serving, the Vary: User-Agent header remains mandatory. Some complex e-commerce sites or legacy platforms maintain this architecture for performance or compatibility reasons.
Similarly, if you use separate URLs for mobile (m.example.com) and desktop, the Vary header does not apply: each URL serves unique content. In this case, the rel alternate links the versions, not the HTTP header.
Practical impact and recommendations
What should you do with this information?
If you have a responsive site and the Vary: User-Agent is present in your HTTP headers, you can keep it. There is no urgency to remove it; Google will not penalize you. It is a minor technical debt, not a blocking issue.
If you are launching a new site or restructuring your architecture, do not add it. Simplify your server stack. The less unnecessary configuration you have, the less maintenance you will need to manage.
How can I check if my site uses this header?
Inspect the HTTP headers of your main pages using a tool like curl, Postman, or Chrome's DevTools (Network tab). Look for the line "Vary:" in the server response. If it contains "User-Agent", you are using it.
Also test by simulating different User-Agents. If the returned HTML is strictly identical, the header is redundant. If you see differences (hidden sections, different scripts), you are practicing dynamic serving and need to keep the Vary.
What pitfalls should I avoid when cleaning up this configuration?
Do not remove the Vary header if you are unsure whether you serve exactly the same HTML. Some CMS or frameworks subtly modify content based on the device, even on a supposedly responsive site. Check first.
If you use a CDN like Cloudflare or Fastly, the Vary header can influence their caching strategy. Removing a Vary: User-Agent can unify your caches and improve your hit ratio. Test in staging before deploying.
- Inspect your HTTP headers for Vary: User-Agent
- Compare the HTML served to different User-Agents (mobile vs desktop) to confirm it is identical
- If you are practicing dynamic serving, definitely keep this header
- On a modern responsive site, remove the header during the next technical overhaul to simplify the stack
- Clear CDN caches after any modifications to the Vary configuration
- Document your choice in the project’s technical guidelines to avoid future regressions
❓ Frequently Asked Questions
Dois-je retirer l'en-tête Vary: User-Agent de mon site responsive ?
L'en-tête Vary: User-Agent ralentit-il le crawl de Googlebot ?
Qu'est-ce que le dynamic serving et pourquoi l'en-tête Vary était-il important ?
Que se passe-t-il si je retire le Vary: User-Agent d'un site en dynamic serving ?
L'en-tête Vary: Accept-Encoding est-il concerné par cette déclaration ?
🎥 From the same video 9
Other SEO insights extracted from this same Google Search Central video · duration 57 min · published on 30/10/2015
🎥 Watch the full video on YouTube →
💬 Comments (0)
Be the first to comment.