Declaration officielle
Autres déclarations de cette vidéo 4 ▾
- 0:03 Googlebot ignore-t-il vraiment les redirections 307 HSTS ou y a-t-il un piège ?
- 0:34 Googlebot ignore-t-il vraiment vos redirections HTTPS forcées ?
- 1:05 Googlebot suit-il vraiment les redirections HTTP vers HTTPS comme un navigateur classique ?
- 1:05 Les redirections 307 HSTS peuvent-elles nuire au référencement de votre site ?
Les redirections 307 HSTS affichées dans Chrome ne sont pas de véritables redirections serveur — c'est le navigateur qui génère ce code de statut pour signaler qu'une requête HTTP a été convertie en HTTPS. Concrètement, aucune redirection n'est réellement exécutée côté serveur, donc aucun impact sur le crawl ou le passage de PageRank. Mais attention : cette nuance technique échappe souvent aux audits automatisés qui signalent ces 307 comme des problèmes à résoudre.
Ce qu'il faut comprendre
Qu'est-ce qu'une redirection 307 HSTS exactement ?
Lorsque vous activez HSTS (HTTP Strict Transport Security) sur votre site, vous demandez aux navigateurs de ne jamais accéder à votre domaine en HTTP. Le navigateur stocke cette information dans une liste interne et convertit automatiquement toute tentative d'accès HTTP en HTTPS — avant même de contacter le serveur.
Chrome affiche un code de statut 307 Internal Redirect dans ses outils de développement pour signaler ce comportement. Ce n'est pas une redirection HTTP classique : aucune requête réseau n'est envoyée, aucune réponse serveur n'est reçue. C'est une conversion locale effectuée par le navigateur.
Pourquoi cette distinction est-elle importante pour un SEO ?
Les redirections serveur (301, 302, 307 réelles) consomment du crawl budget, introduisent une latence, et nécessitent que Googlebot suive la chaîne de redirections. Les redirections HSTS, elles, n'existent tout simplement pas pour Googlebot — le bot crawle directement en HTTPS si le domaine est dans la preload list ou si un en-tête HSTS a déjà été reçu.
Cette nuance change radicalement l'analyse d'un audit technique. Un outil qui signale des dizaines de redirections 307 sur un site HSTS ne détecte pas un problème réel, mais une interprétation erronée des logs navigateur. Le serveur, lui, reçoit directement des requêtes HTTPS — aucune redirection n'a lieu.
Comment Googlebot gère-t-il HSTS en pratique ?
Googlebot respecte les en-têtes Strict-Transport-Security et mémorise la directive pour les crawls futurs. Si votre domaine est dans la preload list officielle, le bot crawle d'emblée en HTTPS sans jamais tenter de requête HTTP. Résultat : aucune redirection serveur n'est nécessaire ni exécutée.
Mais Googlebot ne se comporte pas exactement comme Chrome. Il ne génère pas de 307 fictif dans ses logs — il passe simplement directement au HTTPS. Cela signifie que les Search Console ne remonteront jamais ces 307 comme des erreurs ou des redirections, contrairement à ce qu'on peut observer dans un navigateur classique.
- Les 307 HSTS sont générés par le navigateur, pas par le serveur — aucune requête réseau réelle
- Googlebot ne rencontre pas ces 307 s'il crawle déjà en HTTPS (preload list ou directive HSTS mémorisée)
- Les outils d'audit basés sur Chrome peuvent signaler ces 307 comme des problèmes alors qu'ils n'en sont pas
- Une redirection serveur 301 HTTP vers HTTPS reste nécessaire pour les utilisateurs sans historique HSTS ou les bots qui ne supportent pas la directive
- La preload list HSTS garantit que Chrome, Firefox, Safari et Googlebot passent directement en HTTPS sans jamais tenter de requête HTTP
Avis d'un expert SEO
Cette déclaration est-elle cohérente avec les observations terrain ?
Absolument. Les tests de crawl réels confirment que Googlebot ne signale jamais ces 307 HSTS dans Search Console. Si vous analysez les logs serveur d'un site HSTS activé, vous ne verrez que des requêtes HTTPS directes — aucune trace de redirection pour les bots respectant la directive.
En revanche, les outils d'audit SEO basés sur Chrome (Screaming Frog, OnCrawl, Sitebulb) remontent souvent ces 307 comme des redirections à traiter. C'est une source de confusion récurrente : les clients paniquent devant des milliers de redirections qui, en réalité, n'ont aucun impact SEO. Il faut distinguer les 307 HSTS (navigateur) des 307 serveur réels (beaucoup plus rares).
Quelles nuances faut-il apporter à cette affirmation ?
John Mueller clarifie un point technique précis : les 307 affichés dans Chrome ne sont pas des redirections serveur. Mais il ne dit pas que HSTS dispense d'une redirection 301 HTTP vers HTTPS côté serveur. Soyons clairs : cette redirection reste indispensable pour les premiers visiteurs, les bots non compatibles, et les scénarios où l'historique HSTS n'est pas encore établi. [A vérifier] — certains pensent qu'être dans la preload list suffit, mais c'est oublier les crawlers tiers et les anciennes versions de bots.
Autre nuance : si votre site n'est pas dans la preload list et qu'un utilisateur tape manuellement http://votresite.com pour la première fois, le navigateur tentera bien une requête HTTP initiale. C'est là qu'une vraie redirection serveur 301 ou 302 entre en jeu — avant que l'en-tête HSTS ne soit reçu et mémorisé. Le 307 HSTS n'intervient qu'après cette première exposition.
Dans quels cas cette règle ne s'applique-t-elle pas ?
Si vous configurez une redirection 307 serveur manuelle (via .htaccess, nginx, ou un CDN), alors il s'agit bien d'une vraie redirection HTTP avec impact crawl. Ce n'est plus du HSTS navigateur — c'est une directive serveur classique. Googlebot la suivra, consommera du crawl budget, et la Search Console la remontera dans les rapports d'exploration.
De même, si vous utilisez des redirections 307 temporaires pour des tests A/B ou des migrations partielles, ces redirections existent bel et bien côté serveur. Elles ont un impact SEO réel : elles ne passent pas forcément de PageRank (selon la durée), elles introduisent une latence, et elles peuvent être ignorées par Googlebot si elles durent trop longtemps sans passer en 301 permanent.
Impact pratique et recommandations
Que faut-il faire concrètement pour éviter toute confusion ?
Commencez par auditer vos logs serveur plutôt que de vous fier aveuglément aux rapports d'outils basés sur Chrome. Si vous voyez des 307 dans Screaming Frog mais aucune trace dans vos logs Apache/Nginx, c'est du HSTS navigateur — aucune action nécessaire. Si vous voyez des 307 dans les deux, alors vous avez un problème de configuration serveur à corriger.
Ensuite, vérifiez que votre en-tête Strict-Transport-Security est bien configuré avec une durée suffisante (au minimum 1 an, soit 31536000 secondes) et l'option includeSubDomains si pertinent. Testez avec les outils de développement Chrome : un 307 Internal Redirect dans l'onglet Network indique que HSTS fonctionne — c'est un bon signe, pas un problème.
Quelles erreurs éviter lors de la mise en place de HSTS ?
Ne supprimez jamais votre redirection serveur 301 HTTP vers HTTPS sous prétexte que HSTS s'en charge. HSTS ne protège que les navigateurs compatibles ayant déjà visité le site — tous les autres (premier visiteur, vieux bots, crawlers tiers) ont besoin de cette redirection classique. Les deux mécanismes cohabitent, ils ne s'excluent pas.
Évitez aussi de confondre max-age court et preload list. Un max-age de quelques jours ne suffit pas pour un effet durable — le navigateur oublie la directive après expiration. Si vous visez une sécurité maximale et un crawl Googlebot optimal, soumettez votre domaine à la preload list officielle. Mais attention : c'est une décision quasi-irréversible, à ne pas prendre à la légère.
Comment vérifier que votre configuration HSTS est correcte ?
Testez avec https://hstspreload.org pour vérifier l'éligibilité de votre domaine à la preload list. Contrôlez également que l'en-tête est bien présent sur toutes les pages, y compris les sous-domaines si includeSubDomains est activé. Un en-tête manquant sur une partie du site crée une faille de sécurité et un comportement incohérent pour Googlebot.
Enfin, surveillez vos rapports d'exploration Search Console pour détecter d'éventuelles vraies redirections 307 serveur. Si vous n'en voyez aucune alors que Screaming Frog en remonte des centaines, vous avez confirmation que ce sont bien des 307 HSTS navigateur — donc sans impact SEO. Documentez cette distinction dans vos audits pour éviter les fausses alertes récurrentes.
- Comparez les 307 remontés par les outils d'audit avec les logs serveur réels pour identifier les faux positifs HSTS
- Conservez une redirection serveur 301 HTTP vers HTTPS même avec HSTS activé — les deux mécanismes se complètent
- Configurez l'en-tête Strict-Transport-Security avec max-age d'au moins 31536000 (1 an) et includeSubDomains si pertinent
- Testez l'éligibilité à la preload list sur hstspreload.org avant de soumettre (décision quasi-irréversible)
- Vérifiez que l'en-tête HSTS est bien présent sur toutes les pages, sous-domaines inclus si nécessaire
- Documentez dans vos audits la distinction entre 307 HSTS (navigateur) et 307 serveur pour éviter les fausses alertes
❓ Questions frequentes
Les redirections 307 HSTS consomment-elles du crawl budget ?
Dois-je garder ma redirection 301 HTTP vers HTTPS si j'active HSTS ?
Pourquoi Screaming Frog détecte-t-il des centaines de 307 alors que Search Console n'en signale aucun ?
Faut-il soumettre mon site à la preload list HSTS ?
Comment vérifier si les 307 que je vois sont bien du HSTS navigateur et non du serveur ?
🎥 De la même vidéo 4
Autres enseignements SEO extraits de cette même vidéo Google Search Central · durée 1 min · publiée le 28/10/2020
🎥 Voir la vidéo complète sur YouTube →
💬 Commentaires (0)
Soyez le premier à commenter.