Langues

Redirection meta refresh

Comprendre la redirection meta refresh, sa place entre les redirections côté serveur et JavaScript, la différence entre actualisation immédiate et différée, et les raisons de l’éviter.

Première publication : 28 juin 2026 · Dernière mise à jour : 21 août 2026 · Advanced
Langues
AIRédigé parAI v2

Une redirection meta refresh est une balise HTML <meta http-equiv="refresh">, ou un en-tête HTTP Refresh équivalent, et non un code d’état HTTP. Le serveur renvoie une réponse 200 normale, puis le navigateur agit après le chargement de la page. Google interprète la version immédiate content="0" comme permanente et la version différée comme temporaire. John Mueller indique qu’elle devrait fonctionner, mais la déconseille pour des raisons d’expérience utilisateur et de temps d’analyse. Ne l’utilisez qu’en dernier recours sans accès aux redirections côté serveur, privilégiez 0 seconde et remplacez-la par une véritable 301 dès que possible.

TL;DR — Une meta actualisation est une balise HTML <meta http-equiv="refresh"> tag (or le serveur-injected Refresh en-tête), pas a 3xx code d’état — le serveur renvoie 200 et le navigateur navigates seulement après lune page a entièrement chargée. Immédiate (content="0") lit comme permanente to Google, comme un 301/308; différée (> 0) lit comme temporaire. It sits entre côté serveur et JavaScript redirections in Google’s fiabilité ordre parce que of que full-page-load dependency. Mueller: it “devrait just fonctionner,” mais ne la recommande pas (back-button historique + analyser-time cost). Ne l’utiliser que quand vous genuinely lack serveur accès, privilégier 0, pair it avec rel=canonical et a visible fallback lien, et replace it avec a réel 301 as soon as vous pouvez.

Evidence for this claim Google supports instant and delayed meta refresh redirects but recommends server-side permanent redirects when possible. Scope: Google redirect processing and implementation preference. Confidence: high · Verified: Google Search Central: Redirects Evidence for this claim Timed redirects can create accessibility problems, particularly when users cannot control the time limit. Scope: WCAG timing guidance; not a search-ranking claim. Confidence: high · Verified: W3C WCAG: Timing Adjustable

Ce n’est pas un code d’état

C’est le point essentiel à comprendre. Une meta actualisation est pas an HTTP 3xx réponse. Le serveur renvoie une réponse ordinaire 200 OK avec le corps complet d’une page; sitting in que page’s <head> se trouve une directive HTML que le navigateur exécute après le page charge:

<!-- Instant: treated by Google as permanent -->
<meta http-equiv="refresh" content="0;url=https://example.com/newlocation">

Il existe un équivalent côté serveur — le Refresh HTTP en-tête — qui fait le même chose mais est injecté par le code serveur au lieu de figurer dans le balisage:

HTTP/1.1 200 OK
Refresh: 0; url=https://www.example.com/newlocation

Notez que même la version sous forme d’en-tête renvoie 200, pas a 3xx. Dans les deux cas, ce est a redirection côté client: le navigateur effectue le navigation, et non le serveur.

Immédiate ou différée — la distinction de Google

Google élit la distinction selon le nombre de secondes. Dans sa documentation Redirections and Recherche Google Google précise qu’il “differentiates between two kinds of meta refresh redirects” (traduction) « distingue deux types de redirections meta refresh » :

  • Immédiate (content="0") — “Triggers as soon as lune page est chargé… Google Recherche interprets immédiate meta refresh redirections as redirection permanentes.” So pour canonicalization elle appartient donc à la même catégorie qu’ a 301/308: Google la suit et utilise it as a signal que le cible devrait être canonical.
  • Différée (content supérieur que 0) — “Triggers seulement après an arbitrary nombre of secondes… Recherche Google interprets différée meta refresh redirections as redirection temporaires.” Comme a 302/303/307, le cible pourrait encore être indexé via autre signals, mais la redirection elle-même n’est pas considérée comme un signal de déplacement permanente.

Mon propre classement des redirections in le Ahrefs guide to 11 types of redirections reflète cette distinction: pour déplacements permanents I rank les 308 / 301 → meta actualisation 0 → JavaScript → crypto, et différée meta actualisation descend dans la catégorie temporaire aux côtés des 302/303/307.

Sa place dans l’ordre de pdocumentation de Google

Google’s redirection docs publie explicitement un leau de pdocumentation, “ordered by how probable Google est able to interpret [la redirection] correctement.” Pour permanente redirections le ordre est: HTTP 301 → HTTP 308 → meta refresh (0 seconds) → JavaScript location → crypto. Meta actualisation est le middle rung — sous côté serveur, au-dessus de JavaScript.

Google décrit clairement les deux limites. Pour la limite supérieure: “Si côté serveur redirections aren’t possible to implement on votre platform, meta refresh redirections may être a viable alternative.” Pour la limite inférieure: “Seulement utiliser JavaScript redirections si vous pouvez’t faire côté serveur or meta refresh redirections.” That’s le whole ladder in two sentences — et correspondent à l’analyse déjà présentée dans le redirections hub, qui indique que JS et différée meta-actualisation sont moins fiables car elles dépendent du rendu.

Deux “ordres” — à ne pas confondre

Voici une nuance qui piège souvent les développeurs. MDN publishes a différent ordering pour redirections — but it’s à propos de l’ordre d’exécution du navigateur lorsque plusieurs redirection mécanismes coexistent sur une page, et non leur fiabilité SEO. MDN’s ordre est: HTTP redirections d’abord, puis JavaScript, alors meta actualisation en en en dernier, car “le <meta> redirection se produit après le chargement complet de la page, qui est après tout scripts ont executed.”

So JavaScript “beats” meta actualisation in MDN’s temporisation ordre, but meta actualisation “beats” JavaScript in Google’s fiabilité ordre. Les deux sont corrects — ils réponse différent questions. MDN est asking “lequel se déclenche en en en premier dans le navigateur?” (synchronous JS s’exécute pendant le chargement, avant le minuteur post-chargement de la meta actualisation). Google est asking “lequel suis-je le plus susceptible d’interpréter correctement pour la recherche?” (a meta actualisation est lire straight depuis le parsed HTML; a JS redirection nécessite Google’s distinct rendering step to succeed). Distinguez ces deux axes et le apparent contradiction disappears.

Pourquoi elle dépend du chargement de la page — et pourquoi cela la rend moins fiable

A meta actualisation ne peut se déclencher avant que lune page a entièrement chargée. Per MDN’s <meta http-equiv> documentation, “le minuteur démarre lorsque lune page est entièrement chargée, qui est après le load et pageshow events ont les deux fired.” Cela vaut même pour content="0" — “immédiate” signifie aucun délai supplémentaire après le chargement, pas zero elapsed temps. Une page lente retarde même a 0-second actualisation d’une manière qu’ a côté serveur 3xx ne pourrait jamais reproduire, car le serveur envoie la redirection avant quelconque page charge at tout.

Précisons un point: a meta actualisation est pas processed at Google’s render (JS execution) stage de la même manière qu’ a window.location redirection est — it’s lire directement depuis le parsed HTML <head>. Sa faiblesse ne vient pas de le rendering pipeline; mais de la full-page-load dependency (fin des transferts réseau, ressources bloquant le rendu) plus, pour différée variants, une attente arbitraire.

Ce que spécifie réellement le standard HTML

L’algorithme d’actualisation déclarative du standard HTML est plus précis que la formule « attendre le chargement de la page ». Plusieurs détails comptent pour l’audit et le diagnostic :

  • Échéance. L’actualisation arrive à échéance après le chargement complet du document et, pour un élément <meta>, après son insertion — l’événement le plus tardif l’emporte — avec un ajustement possible selon les préférences de l’utilisateur. Les événements réseau et de rendu exacts restent des détails propres à chaque navigateur.
  • URL relatives. La cible est résolue par rapport à l’URL propre du document. Lors d’un audit, calculez donc la destination absolue au lieu de vous fier à la chaîne url= : un chemin relatif peut mener ailleurs que ne le suggère sa lecture rapide.
  • La première instruction l’emporte. Dès qu’un document est marqué pour une actualisation déclarative, l’algorithme ignore toute instruction ultérieure. Deux balises <meta refresh> incompatibles, ou une balise accompagnée d’un en-tête Refresh, constituent une erreur de création et non un mécanisme de secours.
  • Les cibles javascript: sont rejetées. Si la cible analysée utilise le schéma javascript:, l’algorithme s’arrête sans lancer la navigation.
  • Le déclenchement n’est pas garanti. Le standard autorise l’annulation de la navigation, son ajustement selon les préférences de l’utilisateur ou de son agent, son blocage par les restrictions d’un document en bac à sable, son exposition dans l’interface du navigateur, ou son absence pure et simple. Une redirection ne doit donc jamais être tenue pour absolue.
  • Gestion de l’historique. Le standard prévoit de remplacer l’entrée d’historique actuelle lors de la navigation, plutôt que d’en ajouter une nouvelle. Cette règle nuance l’observation rapportée en 2018 par un porte-parole de Google. Considérez l’affirmation “meta refresh always leaves the source page in history” (traduction) « une meta refresh laisse toujours la page source dans l’historique » comme une idée non confirmée comme une idée non confirmée plutôt que comme un comportement établi ; sa vérification nécessiterait des tests propres à chaque navigateur et à chaque version.
Evidence for this claim The HTML Standard's declarative refresh algorithm returns without navigating when the parsed target uses the javascript scheme. Scope: meta refresh and Refresh header processing Confidence: high · Verified: HTML Standard: Refresh state

John Mueller a résumé les raisons de cette recommandation (propos relayés par Search Engine Roundtable, 2018) : une meta refresh “should just work” (traduction) « devrait fonctionner », mais Google la déconseille pour l’expérience utilisateur — “it keeps the page in browser history, afaik” (traduction) « elle conserve la page dans l’historique du navigateur, à ma connaissance » — et pour le temps de traitement, puisque Google doit analyser la page avant de détecter la redirection. “Once processed, it’s just like a redirect.” (traduction) « Une fois traitée, elle se comporte comme une redirection. » Cette explication nomme des coûts concrets sans transformer l’observation sur l’historique en garantie normative.

Pourquoi it’s discouraged — le historical baggage

Distinct depuis Mueller’s UX/analyser-time raisons, meta actualisation carries a reputation. In le 2000s web-spam era it était a courant doorway-page vehicle: une page ranks pour a requête, alors near-instantly meta-refreshes le visitor to a différent, moins relevant destination — showing moteur de recherches et utilisateurs effectively différent outcomes. That’s le origin of le “spammy” étiquette. It’s worth étant accurate ici: aucun actuel Google spam-policy page noms “meta actualisation” explicitly; le policies define “sneaky redirections” et “doorway” abuse as general categories que meta actualisation historiquement served as a mechanism pour. Treat ce as historical/secteur context, pas an explicit actuel policy citation.

Il existe aussi a concrete, non-spam échec mode Mueller flagged in a 2018 hangout (via Moteur de recherche Journal): a site que meta-refreshed listing pages to a shared payment page. “So si vous faire ce à travers votre pages there’s a big chance we’ll follow ce redirection et think ‘Oh, ce payment page est en réalité ce que vous vouloir to ont indexé et pas le réel contenu.’” Mass-refreshing nombreux source pages to un generic destination peut obtenir le destination indexé au lieu de votre contenu.

None of que rend an isolated, legitimate meta actualisation a penalty risk. Google’s propre actuel docs appel it “a viable alternative” quand redirection côté serveurs aren’t possible. Le risk est pattern et intent, pas le mechanism.

Evidence for this claim Google says meta refresh can be a viable alternative when server-side redirects are not possible, while permanent server-side redirects are recommended whenever possible for a URL move. Scope: meta refresh and HTTP Refresh interpretation Confidence: high · Verified: Redirects and Google Search

Accessibilité: le même immédiate-vs-différée split

Le SEO framing a an presque exact twin in accessibilité guidance — avec un qualification worth stating up front: W3C’s WAI techniques sont, in leur propre words, exemples of façons to meet WCAG success criteria, pas mandatory conformance rules. Meeting or manquant a spécifique technique isn’t itself an automatic réussir or échouer; le réel requirement est le success criterion (ici, 2.2.1 Temporisation Adjusle). Avec que indiqué, W3C’s propre pdocumentation matches le SEO guidance au-dessus de: it recommends a redirection côté serveur en en premier, et où a redirection côté client est genuinely necessary, its sufficient techniques (H76, G110) appel pour aucun delay (content="0") et a source page whose contenu est limited to redirection-related information plus a visible lien to le destination. That’s a narrower bar que “tout 0-second actualisation automatiquement passes” — it’s “zero delay, redirection-seulement contenu, et a fallback lien” as le documented sufficient pattern. A différée meta actualisation avec aucun façon to pause, extend, or disable it risks failing 2.2.1, parce que it peut navigate away avant a screen-reader utilisateur or quelqu’un avec low vision a finished reading — but si a spécifique différée actualisation en réalité fails le criterion est a case-by-case WCAG evaluation, pas quelque chose a technique nombre alone settles. MDN’s accessibility remarque describes le même underlying risk: too-short actualisation intervals signifier personnes en utilisant assistive tech “may être unable to lire via et comprendre lune page’s contenu avant étant automatiquement redirigé.”

So les deux a moteur de recherche et a standards corps land on le même rule: immédiate est fine, différée est risky. That’s a nice bit of reinforcement — et un plus raison to privilégier content="0" si vous utiliser meta actualisation at tout.

Quand it’s a legitimate en en dernier resort

Utiliser meta actualisation seulement quand vous genuinely can’t faire une redirection côté serveur. Réel cas où que se produit:

  • Static hosts avec aucun serveur config — e.g. GitHub Pages, où vous pouvez’t ajouter .htaccess/nginx rules.
  • Static-site generators whose “aliases” fonctionnalité outputs meta actualisation, pas 301s. Hugo est a connu exemple — its aliases: front-matter generates little meta-actualisation HTML fichiers, pas réel serveur redirections. (Plus on que in Hugo SEO.)
  • No-code / website-builder exports et some doc generators que seulement let vous emit static HTML.

Si you’re stuck avec it, faire it bien:

  • Préférer immédiate (content="0") over quelconque delay — permanente signal, et it clears le accessibilité bar.
  • Pair it avec rel="canonical" pointing at le destination, so le canonicalization intent est explicit même avant Google processes l’actualisation.
  • Inclure a visible, clickable fallback lien in le corps pour le rare navigateur or assistive-tech setting où auto-actualisation est disabled.
  • Don’t stack it dans a chaîne de redirections — si le meta-actualisation page’s URL plus tard aussi obtient une redirection côté serveur layered on, you’ve construit a chain (voir chaîne de redirectionss).
  • Replace it avec a réel 301 le moment vous ont serveur accès. Meta actualisation est a bridge, pas a destination.

Detecting meta actualisation on votre site

Robots d’exploration surface ces, usually as a low-to-medium severity flag plutôt que a critical error — Screaming Frog, Sitebulb, Ahrefs Site Audit, et Semrush tout report les. Pour an isolated handful of URLs it’s a “fix lorsque convenient” item, pas an emergency; site-wide utiliser on pages importantes est où it becomes worth prioritizing. To vérifier a unique URL by hand, view source or curl lune page et regarder pour http-equiv="refresh" in le <head> (là sont ready snippets in le Scripts lens).

Faites attention avec claims in soit direction on popularité des liens. Le Ahrefs help-center line que meta actualisation “fait pas pass much or tout lien juice” est worth questioning — Google’s redirection le classifies an immédiate meta actualisation in le même permanente-redirection interpretation bucket as a 301, qui est a signal à propos de how Google interprète et canonicalizes la redirection, pas a stated promise à propos de identical PageRank, lien-equity, or ranking transfer. Neither Google’s redirections documentation nor le HTML Standard rend an explicit claim à propos de equity parity entre a meta actualisation et a 301 — so treat “it passes le même value as a 301” et “it passes little or none” as equally unverified au-delà what’s en réalité documented: Google classifies it comme permanente, et processes it après it charge le page.

A meta-actualisation source page encore a its propre HTTP réponse et its propre HTML document — auditing un shouldn’t arrêter at reading l’actualisation tag. Vérifier, in ordre: l’URL source’s HTTP état et réponse headers (notamment a possible Refresh en-tête); le raw HTML versus ce que a navigateur en réalité parses; qui actualisation directive est le en en premier (et therefore effective) un, et its resolved absolute cible; how Google’s redirection le voudrait classify it (immédiate/permanente vs. différée/temporaire); le source page’s propre balise canonical, robots directives, et indexability; le final destination’s réponse; si la redirection est cancelable, controllable, or skipped by utilisateur/navigateur preferences; cache et historique behavior in le spécifique named navigateur et version you’re testing (pas as a universal claim); lien internes encore pointing at le source; et, en en dernier, votre plan to replace it avec une redirection côté serveur. Le Checklists et Scripts lenses on ce page break ces dans concrete steps et commands.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.