Faut-il vraiment rediriger Googlebot vers www pour contourner les erreurs CORB ?

Qu'est-ce qu'une erreur CORB et pourquoi touche-t-elle Googlebot ?

CORB (Cross-Origin Read Blocking) est un mécanisme de sécurité du navigateur qui empêche une page web de lire certaines ressources cross-origin. Quand un service worker fait des requêtes sur un domaine différent de celui de la page (exemple : la page est sur exemple.com, le service worker tape sur www.exemple.com), le navigateur bloque la lecture pour protéger les utilisateurs.

Googlebot utilise un moteur de rendu moderne qui implémente ces protections. Si votre service worker est mal configuré et génère des erreurs CORB, Googlebot peut rencontrer des problèmes de crawl ou de rendu similaires à ceux d'un vrai navigateur. Résultat : des pages mal indexées ou des ressources critiques non chargées.

Pourquoi certains sites redirigent-ils Googlebot vers www ?

Face à ces erreurs, certains développeurs ont trouvé un raccourci technique : détecter Googlebot via le user-agent et le rediriger automatiquement vers le domaine www, tandis que les utilisateurs restent sur le non-www (ou l'inverse). L'idée ? Aligner artificiellement le domaine de la page avec celui ciblé par le service worker, uniquement pour le bot.

C'est techniquement acceptable selon Google — pas de pénalité immédiate — mais c'est un sparadrap sur une jambe cassée. Vous contournez le symptôme sans traiter la maladie, et vous créez une divergence entre l'expérience bot et l'expérience utilisateur.

Pourquoi Google recommande-t-il de corriger la cause racine ?

Martin Splitt est clair : réparer le service worker pour qu'il cible le bon domaine est la seule solution durable. Un workaround comme celui-ci ajoute de la complexité au débogage : si un problème survient plus tard, vous ne saurez plus si c'est lié au service worker, à la redirection conditionnelle ou à un autre facteur.

De plus, cette approche masque un bug réel côté front-end qui pourrait impacter les utilisateurs dans certains scénarios (migration HTTPS, changement de CDN, évolution du service worker). Corriger la racine garantit une cohérence technique et évite les mauvaises surprises lors d'audits ou de refonte.

• CORB protège les utilisateurs en bloquant les lectures cross-origin — Googlebot y est soumis comme un navigateur moderne
• Rediriger Googlebot vers www pour contourner CORB est techniquement autorisé mais fortement déconseillé
• La bonne pratique : corriger le service worker pour qu'il cible le domaine cohérent avec la page
• Un workaround complique le débogage et masque un problème technique réel
• Évitez les divergences bot/utilisateur — elles fragilisent la maintenance à long terme

Cette tolérance de Google est-elle un piège à éviter ?

Quand Google dit « c'est acceptable techniquement », ça ne veut pas dire « c'est une bonne idée ». L'histoire du SEO est pavée de pratiques tolérées qui finissent par poser problème lors d'une mise à jour algo ou d'un changement de guidelines. Ici, Martin Splitt prend la peine de préciser qu'il recommande de ne PAS le faire — c'est un signal fort.

En pratique, rediriger uniquement Googlebot introduit une asymétrie entre ce que voit le bot et ce que vivent les utilisateurs. Même si ce n'est pas du cloaking strict (pas de contenu différent), ça reste une forme de traitement différencié qui peut compliquer les audits, les tests et les migrations. Si demain Google décide de durcir sa position sur les redirections conditionnelles, vous serez en première ligne.

Quels risques concrets pour un site en production ?

Le principal risque n'est pas une pénalité immédiate, mais une dette technique invisible. Imaginez : vous migrez vers un nouveau CDN, vous passez en full HTTPS strict, ou vous refactorez votre service worker. Soudain, la redirection conditionnelle entre en conflit avec un autre mécanisme, et vous passez des heures à comprendre pourquoi Googlebot voit une version différente.

[A vérifier] Google n'a pas publié de données sur la fréquence de ces erreurs CORB en crawl, ni sur l'impact réel sur l'indexation. On manque de retours terrain massifs confirmant que ce workaround reste stable dans le temps. Mon conseil : si vous devez absolument l'implémenter, documentez-le TRES clairement dans votre wiki technique et planifiez un correctif propre dès que possible.

Dans quels cas ce workaround pourrait-il se justifier temporairement ?

Soyons pragmatiques. Si vous êtes en urgence absolue — par exemple, une migration majeure lancée et des erreurs CORB qui bloquent l'indexation de pages critiques —, la redirection conditionnelle peut servir de rustine le temps de corriger le service worker. Mais ça doit rester temporaire et tracé dans un backlog prioritaire.

En revanche, si vous construisez un site neuf ou refactorez votre PWA, ne prenez même pas cette option. Configurez correctement vos domaines et vos service workers dès le départ. C'est moins glamour qu'un hack astucieux, mais c'est ce qui distingue un projet solide d'un château de cartes.

Comment vérifier si mon site est concerné par des erreurs CORB ?

Première étape : inspectez la Search Console dans la section « Couverture » et « Problèmes d'exploration ». Cherchez des erreurs liées au rendu, des timeouts ou des ressources bloquées. Ensuite, utilisez l'outil de test des résultats enrichis ou l'inspecteur d'URL pour voir si Googlebot rencontre des erreurs CORB spécifiques.

Côté navigateur, ouvrez la console développeur (F12), activez le mode Application > Service Workers, et surveillez les requêtes réseau. Si vous voyez des warnings « Cross-Origin Read Blocking » quand le service worker tente de charger des ressources, vous avez un problème. Testez sur plusieurs domaines (www vs non-www, HTTP vs HTTPS) pour identifier les incohérences.

Quelle est la bonne méthode pour corriger un service worker mal configuré ?

Modifiez le scope du service worker pour qu'il cible le même domaine que vos pages. Si vos utilisateurs naviguent sur exemple.com, le service worker doit enregistrer ses fetch handlers sur exemple.com, pas sur www.exemple.com. Vérifiez aussi que les URLs de cache et de requêtes API respectent le même domaine.

Ensuite, testez en local, puis en staging, puis en prod avec un déploiement progressif. Surveillez les métriques Core Web Vitals et les erreurs réseau. Si vous utilisez Workbox ou un framework PWA, assurez-vous que la config de routing et de cache est alignée avec votre architecture de domaines. Pas de bidouille, pas de redirection conditionnelle — juste une config propre.

Faut-il vraiment éviter la redirection conditionnelle même en urgence ?

Si vous êtes en crise de crawl avec des milliers de pages non indexées à cause d'erreurs CORB, la redirection conditionnelle peut être un pansement acceptable pour 48-72h. Mais documentez-la, trackez-la dans un ticket prioritaire, et planifiez le correctif propre immédiatement. Ne laissez jamais ce genre de workaround en production plus de quelques semaines.

Dans tous les autres cas, investissez le temps nécessaire pour corriger la cause racine. Ça peut sembler lourd, mais c'est ce qui garantit la stabilité à long terme. Un service worker bien configuré, c'est un investissement qui paie sur des années. Une redirection conditionnelle, c'est une dette qui vous rattrapera au pire moment.

• Auditez les erreurs CORB dans Search Console et en console navigateur
• Vérifiez que le service worker cible le même domaine que vos pages (www vs non-www)
• Évitez les redirections conditionnelles sauf urgence absolue et temporaire (max 2-3 semaines)
• Testez la configuration en local, staging, puis prod avec un rollout progressif
• Documentez tout workaround technique dans un wiki et un backlog priorisé
• Surveillez les Core Web Vitals et les erreurs réseau après chaque modification