L'API History est-elle vraiment interprétée comme une redirection par Google ?

Qu'est-ce que l'API History et pourquoi les sites l'utilisent-ils ?

L'API History permet de modifier l'URL affichée dans la barre d'adresse du navigateur sans recharger la page. C'est un mécanisme JavaScript très populaire dans les applications web modernes et les Single Page Applications (SPA).

Les développeurs l'utilisent principalement pour améliorer l'expérience utilisateur : navigation fluide, pas de rechargement complet, interface réactive. Typiquement, quand vous naviguez sur un site et que l'URL change sans que la page ne clignote, c'est l'API History qui travaille en coulisses.

Comment Google interprète-t-il réellement ces changements d'URL ?

La déclaration de Mueller est sans ambiguïté : Google considère ces modifications comme des redirections. Pas comme du simple changement cosmétique d'URL, mais comme un véritable signal de redirection.

Le processus est le suivant : Googlebot charge l'URL initiale, détecte le changement d'URL via JavaScript, enregistre l'URL finale, puis lors du prochain crawl, il tentera de crawler directement l'URL de destination. L'URL initiale sera progressivement délaissée au profit de la nouvelle.

Quelle est la contrainte technique majeure ici ?

Le point critique — et c'est là que beaucoup de sites se plantent — c'est que l'URL finale doit être accessible directement. Si un utilisateur ou Googlebot tape l'URL de destination dans son navigateur, la page doit charger normalement.

Si l'URL finale n'existe que dans le contexte de l'application JavaScript et renvoie une 404 ou redirige ailleurs quand on y accède directement, vous créez un cauchemar d'indexation. Google va tenter de crawler une URL qui n'existe pas réellement en tant que ressource serveur autonome.

• L'API History n'est pas invisible pour Google — le bot l'interprète comme une redirection
• L'URL de destination remplacera progressivement l'URL source dans l'index
• Chaque URL finale doit être crawlable indépendamment, sans passer par le parcours JavaScript
• Cette logique s'applique même si le changement d'URL survient rapidement après le chargement initial
• Les sites utilisant massivement l'API History sans URL serveur correspondantes risquent des problèmes d'indexation structurels

Cette déclaration est-elle cohérente avec les observations terrain ?

Globalement, oui. On observe effectivement que Google suit les changements d'URL JavaScript et tente d'indexer les URL finales. Les tests en laboratoire confirment que Googlebot enregistre l'état final de l'URL après exécution du JavaScript.

Mais — et c'est un gros mais — le délai entre la détection et le crawl effectif de l'URL finale varie énormément. Mueller parle de "prochain crawl", ce qui peut signifier des jours, des semaines, voire des mois selon votre crawl budget. [À vérifier] : la durée typique de ce cycle n'est pas documentée officiellement.

Quelles sont les zones d'ombre de cette explication ?

Mueller ne précise pas comment Google gère les conflits. Que se passe-t-il si l'URL source ET l'URL destination existent toutes deux en tant que pages serveur valides, avec du contenu différent ? Quelle version prévaut dans l'index ?

Autre point flou : le comportement avec les SPA complexes qui effectuent plusieurs changements d'URL successifs en quelques secondes. Google capture-t-il l'URL après un délai fixe (genre 5 secondes) ou attend-il une stabilisation de l'URL ? [À vérifier] sur des cas réels avec multiples transitions rapides.

Dans quels cas cette règle ne s'applique-t-elle pas comme prévu ?

Première exception observable : les sites avec crawl budget extrêmement limité. Si Google crawle votre site une fois par mois, l'URL finale peut mettre un temps fou à être découverte et indexée, créant une période d'incertitude prolongée.

Deuxième cas problématique : les applications avec authentification. Si l'URL finale nécessite une connexion pour être accessible, mais que la page initiale est publique, Google va détecter une redirection vers une URL qu'il ne pourra jamais crawler réellement. Résultat : confusion potentielle dans l'index.

Que faut-il auditer en priorité sur votre site ?

Première étape : identifiez toutes les pages qui utilisent pushState ou replaceState (les deux méthodes de l'API History). Un audit JavaScript complet est nécessaire, pas juste un coup d'œil au code.

Pour chaque changement d'URL détecté, testez manuellement : l'URL finale est-elle accessible en tapant directement l'adresse dans le navigateur ? Renvoie-t-elle un 200 OK avec le contenu attendu, sans nécessiter de parcours JavaScript préalable ?

Quelles erreurs éviter absolument ?

Erreur classique numéro un : créer des URLs "virtuelles" qui n'existent que côté client. Votre router JavaScript gère /produit/chaussures-rouges, mais le serveur renvoie une 404 si on y accède directement. Google va tenter de crawler cette URL et échouer.

Deuxième piège : utiliser l'API History pour des variations mineures (tri, filtres) en pensant que Google ignorera ces changements. Si vous modifiez l'URL, Google le traite comme une redirection — donc comme une page différente à crawler. Réfléchissez à deux fois avant de changer l'URL pour chaque clic de filtre.

Comment vérifier que votre implémentation est conforme ?

Utilisez la Search Console et analysez les URLs indexées versus les URLs que vous pensiez soumettre. Si vous constatez que Google indexe massivement les URLs finales (post-History) mais que certaines sont marquées comme erreurs 404, c'est le signal d'alarme.

Complétez avec un test dans l'outil d'inspection d'URL : soumettez l'URL source, vérifiez quelle URL Google détecte finalement. Si l'URL rendue diffère de l'URL source, Google la traitera comme une redirection lors du prochain crawl.

• Listez toutes les utilisations de pushState/replaceState dans votre codebase
• Testez chaque URL finale en accès direct (curl, navigateur en navigation privée)
• Vérifiez que le serveur renvoie 200 pour toutes les URLs finales, pas 404 ou 302
• Contrôlez dans Search Console les écarts entre URLs soumises et URLs indexées
• Si vous avez des SPA, implémentez du server-side rendering (SSR) ou du prerendering pour les URLs critiques
• Documentez clairement quelles URLs sont censées être des redirections et lesquelles sont des pages autonomes