Redirection JavaScript et meta refresh : le point SEO

Une redirection JavaScript ou une balise meta refresh fonctionne pour le visiteur, et Google sait généralement la suivre. Mais elle est moins fiable, plus lente à traiter et moins claire qu'une redirection 301 envoyée par le serveur. La règle pratique tient en une phrase : si vous pouvez répondre avec un code HTTP 301 ou 308, faites-le ; si vous ne pouvez vraiment pas, une redirection côté client bien construite reste acceptable, à condition de respecter quelques garde-fous.

Cet article ne revient pas sur le rendu JavaScript en général. Il traite uniquement de la question des redirections : comment Google les découvre, ce qu'il en déduit sur la page à indexer, et comment s'en sortir quand l'hébergement ou le CMS ne vous laisse pas toucher aux en-têtes HTTP.

Trois façons de rediriger, trois niveaux de clarté

Une redirection serveur répond à la requête avec un code 3xx et un en-tête Location. Le robot n'a rien d'autre à faire : il lit le code, note l'adresse de destination et sait immédiatement si le changement est permanent (301, 308) ou temporaire (302, 307). Aucune page n'a besoin d'être téléchargée ni interprétée.

Une meta refresh vit dans le HTML. Le serveur répond 200 avec une page normale, dont la section head contient une balise du type meta http-equiv refresh, avec un délai et une URL cible. Le robot doit donc télécharger la page, lire le HTML et comprendre l'instruction. C'est déjà un cran en dessous en termes de simplicité.

Une redirection JavaScript passe par une instruction comme window.location.href, window.location.replace ou location.assign, exécutée dans le navigateur. Ici, Google ne peut pas la voir dans le HTML brut : il doit envoyer la page au service de rendu, exécuter le script, puis constater que l'adresse a changé. C'est le mécanisme le plus indirect des trois.

Dans les deux cas côté client, le premier code de réponse est un 200. Pour un outil d'audit, pour un serveur de logs ou pour un autre moteur de recherche, l'URL source ressemble à une page valide et non à une page déplacée. Cette ambiguïté est la racine de la plupart des problèmes décrits plus bas.

Ce que Google documente sur les redirections côté client

La documentation de Google sur les redirections range les méthodes par ordre de préférence. Les redirections serveur sont recommandées. Les meta refresh sont présentées comme acceptables quand le serveur n'est pas modifiable, et les redirections JavaScript comme un dernier recours. Google indique qu'il peut les suivre, mais qu'elles sont moins fiables et moins rapides à traiter.

Sur la nature permanente ou temporaire, la documentation distingue les cas. Une meta refresh avec un délai de zéro seconde est traitée comme une redirection permanente, tandis qu'une meta refresh avec un délai visible est traitée comme temporaire. Pour JavaScript, il n'existe pas de code de statut : Google déduit la nature du changement d'autres signaux, ce qui laisse une part d'incertitude que vous ne contrôlez pas.

Retenez surtout ce que cela implique : avec une 301, vous dites explicitement au moteur quelle URL doit remplacer l'ancienne. Avec une redirection côté client, vous lui demandez de le deviner à partir du comportement de la page. Quand le signal est ambigu, les autres indices (canonical, sitemap, liens internes, liens externes) prennent plus de poids, et s'ils se contredisent, Google choisit à sa façon.

Comment Googlebot suit réellement une redirection JavaScript

Le processus se déroule en deux temps. Googlebot télécharge d'abord le HTML et les ressources. La page part ensuite dans une file d'attente de rendu, où un navigateur sans interface exécute le JavaScript. Ce n'est qu'à ce stade que la redirection est observée. Entre les deux étapes, le délai peut être court ou plus long : vous n'avez aucune garantie.

Il en découle une condition technique simple, et souvent oubliée : le script qui déclenche la redirection doit être accessible. Si le fichier JavaScript est bloqué par le robots.txt, ou si l'instruction dépend d'un appel réseau qui échoue, le rendu ne verra jamais la redirection. Google indexera alors la page de départ telle qu'elle est, parfois avec un contenu vide ou un simple message de chargement.

Autre condition : la redirection doit s'exécuter sans interaction. Un script qui attend un clic, un défilement ou la validation d'un bandeau de consentement avant de rediriger ne sera probablement jamais déclenché par le robot. Une redirection conditionnelle selon la langue du navigateur ou selon un cookie pose le même problème, car Googlebot n'a pas votre cookie et ne présente pas forcément la langue que vous attendez.

Enfin, gardez en tête que la redirection est testée à l'exécution. Une erreur JavaScript plus haut dans le même fichier suffit à l'empêcher, sans que rien ne se voie côté serveur. C'est un argument de plus pour réserver ce mécanisme aux situations sans alternative et pour le tester sérieusement.

Les risques concrets face à une 301

Le premier risque est la lenteur de prise en compte. Une 301 est lue dès le crawl de l'ancienne URL. Une redirection JavaScript n'est lue qu'après le rendu, donc plus tard. Sur un petit site, l'écart passe inaperçu. Sur une migration de plusieurs milliers d'URL, il peut prolonger la période pendant laquelle les anciennes et les nouvelles adresses cohabitent dans les résultats.

Le deuxième est l'incertitude sur le transfert des signaux. Google affirme que les redirections qu'il comprend transmettent les signaux de la même façon, mais il ne garantit pas de les comprendre avec la même fiabilité quand elles sont côté client. Personne, en dehors de Google, ne peut chiffrer ce que cela vous coûte sur un site donné. Partez donc du principe que le risque existe et réduisez-le.

Le troisième concerne tout ce qui n'est pas Google. Bing et les autres moteurs, les robots d'aperçu des réseaux sociaux, les outils d'audit et les crawlers d'IA n'exécutent pas tous le JavaScript, ou pas de la même manière. Un partage de lien qui affiche une page vide, parce que l'aperçu lit le HTML et ne suit pas votre script, est un symptôme classique.

Le quatrième est la chaîne. Une redirection JavaScript qui mène à une URL elle-même redirigée par le serveur, puis par une seconde règle, multiplie les étapes de rendu et de crawl. Elle ralentit aussi le visiteur, avec un écran blanc intermédiaire qui pèse sur l'expérience perçue. Sur mobile, la page de départ doit être téléchargée, exécutée, puis la cible chargée : le temps s'additionne.

Quand le côté client est la seule option

Ces cas existent, et il serait malhonnête de prétendre qu'une 301 est toujours possible. Les plus fréquents sont listés plus bas.

Avant de choisir l'une de ces solutions de repli, la bonne démarche consiste d'abord à vérifier qu'aucune règle serveur n'est disponible quelque part. Un plan d'hébergement supérieur, un réseau de diffusion placé devant le site ou un fichier de configuration supporté par la plateforme suffisent souvent à régler le problème sans toucher au code de la page. Le côté client est un plan B, pas un point de départ.

• Hébergement statique sans configuration serveur. Certaines plateformes de pages statiques n'offrent aucun moyen d'émettre un code 301. D'autres, comme Netlify ou Cloudflare Pages, le permettent via un fichier de règles : vérifiez ce que propose la vôtre avant de conclure quoi que ce soit.
• CMS ou constructeur SaaS fermé. Sur certains constructeurs de sites, le champ de redirection n'existe pas, ou se limite à un nombre restreint d'entrées. La seule marge de manœuvre est un champ d'injection de code dans l'en-tête de page.
• Pages que vous ne contrôlez qu'à moitié. Un contenu hébergé chez un tiers, une page de profil ou une boutique en ligne où vous n'éditez que le contenu peuvent vous laisser seulement un bloc HTML ou un script à personnaliser.
• Application monopage. Dans un routeur côté client, un changement de route vers une URL obsolète est naturellement une redirection JavaScript. Le point à surveiller est que l'URL obsolète, appelée directement, reçoive un vrai code de redirection côté serveur ou renvoie un vrai 404 plutôt qu'un 200 trompeur.

Faire une redirection côté client proprement

Quand vous n'avez pas le choix, cumulez les signaux pour que Google n'ait rien à deviner. Voici une construction éprouvée pour une page statique déplacée. Dans le head, placez une meta refresh à zéro seconde vers la nouvelle adresse absolue, ajoutez un lien canonical pointant vers cette même adresse, et gardez un lien visible dans le corps de page pour les visiteurs dont le navigateur bloque la redirection.

Pourquoi la meta refresh plutôt que le JavaScript quand les deux sont possibles ? Parce qu'elle figure dans le HTML brut : Google la voit sans passer par le rendu, les autres robots la voient aussi, et elle ne dépend d'aucun fichier externe. Le JavaScript ne devient préférable que si la décision dépend d'une condition, ce qui est rare pour une simple page déplacée.

Utilisez window.location.replace plutôt que window.location.href quand vous redirigez. La méthode replace remplace l'entrée dans l'historique au lieu d'en ajouter une, ce qui évite que le bouton retour ramène le visiteur sur la page qui le renvoie aussitôt, dans une boucle agaçante. Utilisez une adresse absolue, sans dépendre du contexte courant.

Mettez à jour le reste de l'écosystème : liens internes qui pointent directement vers la nouvelle adresse, sitemap qui ne liste que l'URL finale, et liens externes sous votre contrôle corrigés. Une redirection côté client ne doit jamais être le seul chemin vers la cible ; elle ne fait que rattraper les visiteurs et les robots qui arrivent par l'ancienne URL.

Gardez la page de départ légère et sans contenu concurrent. Si elle contient un long texte indexable à côté de l'instruction de redirection, vous laissez à Google deux pages qui se ressemblent et un signal ambigu. Une page minimale, avec le titre, le lien de secours et rien d'autre, suffit.

Vérifier ce que Google a retenu

Ne supposez pas que la redirection a été comprise : contrôlez-le. Dans Search Console, l'outil d'inspection d'URL montre l'adresse que Google a retenue comme canonique, la page explorée et, avec le test en direct, le rendu tel que le robot le voit. Si la redirection JavaScript fonctionne, l'inspection de l'ancienne URL doit mener, après rendu, vers la nouvelle.

Comparez ensuite l'URL déclarée et l'URL choisie par Google. Si Google continue d'indexer l'ancienne page comme canonique plusieurs semaines après la mise en place, c'est un signe que la redirection n'a pas été vue, ou qu'elle est jugée insuffisamment fiable face à d'autres signaux contradictoires. Cherchez d'abord un script bloqué, une erreur JavaScript ou une condition jamais remplie chez le robot.

Côté crawler d'audit, activez ou non le rendu JavaScript et comparez les deux résultats. La plupart des outils signalent les meta refresh et les redirections détectées après rendu dans des rapports distincts. Une URL qui n'apparaît comme redirigée que si le rendu est activé est exactement le genre de page qui dépend du bon vouloir du moteur.

Et surveillez le rapport de pages dans Search Console : une ancienne URL qui reste longtemps dans la catégorie des pages indexées ou marquées comme alternatives avec balise canonique appropriée mérite une vérification manuelle, une par une sur un échantillon représentatif.

Les erreurs à éviter

Quelques erreurs reviennent régulièrement sur les sites que l'on audite, et elles sont toutes évitables.

• Bloquer le script de redirection dans le robots.txt, ce qui rend la redirection invisible pour le rendu.
• Rediriger toutes les anciennes URL vers la page d'accueil. Google peut l'assimiler à une erreur 404 douce, car la cible ne correspond pas au contenu d'origine. Redirigez vers l'équivalent le plus proche.
• Laisser un délai de plusieurs secondes dans une meta refresh. Il est lu comme temporaire et dégrade l'expérience du visiteur.
• Empiler les mécanismes sans cohérence : une meta refresh vers l'adresse A, un script vers l'adresse B et un canonical vers l'adresse C. Le moteur choisira, et pas forcément comme vous le souhaitez.
• Déclencher la redirection selon la langue ou le pays du visiteur en JavaScript, sans adresses distinctes et sans liens visibles entre versions. Googlebot, qui crawle le plus souvent depuis un même contexte, ne verra qu'une seule variante.
• Retirer la redirection trop tôt après la migration, alors que des liens et des robots arrivent encore par l'ancienne URL, ou laisser traîner des boucles créées pendant un test.