« Too many redirects » : votre boutique PrestaShop renvoie le navigateur d’une adresse à une autre, puis de nouveau à la première, sans jamais afficher de page, ni à vous ni à vos clients. Deux réglages se contredisent : ceux de PrestaShop, du serveur, de l’hébergeur ou de Cloudflare.
Chrome l’écrit ainsi : « … vous a redirigé à de trop nombreuses reprises. »
En anglais, « redirected you too many times », code ERR_TOO_MANY_REDIRECTS ; Firefox dit « La page n’est pas redirigée correctement » : une boucle de redirection (redirect loop). Supprimer les cookies, comme le propose Chrome, ne règle pas une boucle qui vient d’un réglage.
Repérez votre dernière modification dans le tableau.
Cloudflare : « Full (strict) » au lieu de « Flexible », si un certificat est installé sur l’hébergement (détails).
Domaine, hébergeur ou www changés : corrigez l’URL de la boutique, depuis l’administration si elle s’ouvre.
« Forcer HTTPS » du panel, règle du .htaccess : une seule couche doit forcer le https.
Renvoyé vers un site inconnu : possible piratage, ne touchez à rien.
Boutique bloquée : 09 72 03 59 17, réponse en moins d’une heure, 7j/7, de 8 h à 22 h. Dépannage PrestaShop en urgence dès 150 € HT, prix fixe validé avant toute intervention.
Trop de redirections : qu’est-ce qui a changé juste avant ?
Cliquez sur la ligne qui ressemble à votre cas.
| Juste avant la boucle | Cause probable |
|---|---|
| Passage de la boutique sous Cloudflare | Mode SSL « Flexible » et redirection https du serveur. |
| Certificat installé, « Activer le SSL » sur OUI | SSL actif sans « sur tout le site » (1.6 à 8), ou redirection https d’un serveur qui ne voit pas la visite en https (Cloudflare, proxy). |
| Changement de nom de domaine | URL de la boutique restée sur l’ancien domaine. |
| Changement d’hébergeur | Le nouvel hébergeur force aussi https ou www. |
| www ajouté ou retiré | URL de la boutique contre réglage www du serveur. |
| Règle ajoutée au .htaccess, bouton « forcer HTTPS » | Une règle https ou www qui contredit Cloudflare, le panel ou l’URL de la boutique. |
| Produit ou catégorie désactivé, module de redirections | Deux redirections qui se renvoient. |
| Rien de visible, une mise à jour, ou vous ne savez pas | À identifier : regardez où la boutique vous renvoie. |
Autres situations :
- La boutique s’ouvre en navigation privée ou en 4G : votre navigateur garderait une ancienne redirection ou un cookie.
- Le panier et le compte s’ouvrent, l’accueil et les fiches bouclent : probablement « Activer le SSL » sans « sur tout le site » (1.6 à 8).
- Seules quelques pages bouclent : produit, catégorie, panier.
- Seule l’administration part en boucle : voyez « trop de redirections » sur le back-office.
Quatre règles avant tout essai :
- Notez la valeur d’origine de chaque réglage avant de le changer (mode Cloudflare, interrupteur, champ, ligne du .htaccess) : c’est elle que vous remettrez pour annuler.
- Avant de modifier un fichier, téléchargez-en une copie.
- Pour la base de données, un export complet d’abord : phpMyAdmin (panel de l’hébergeur, rubrique des bases de données) > Exporter. Toute la base, pas une table.
- Une modification à la fois ; sans effet, annulez-la.
Votre version : Paramètres avancés > Informations (« Version de PrestaShop : »), ou sous le logo de la page de connexion de l’administration en 1.6 et 1.7. Sans administration, voyez le tableau des dossiers de notre page sur le back-office.
Faites-vous aider plutôt que d’essayer si :
Accès : ni l’administration ni phpMyAdmin ne s’ouvrent, la base n’a jamais été exportée, ou vous n’avez pas accès au compte Cloudflare ni au panel de l’hébergeur.
Configuration : le HSTS (réglage qui interdit aux navigateurs de revenir en http) est activé, la boutique est en multiboutique, ou un autre proxy que Cloudflare, ou un répartiteur de charge, est placé devant le serveur.
Situation : la boucle n’apparaît qu’au retour du paiement, ou une modification a empiré les choses et vous ne savez plus quoi remettre.
Vous ne savez pas ce qui a changé ? Suivez les redirections
Les adresses parcourues désignent le coupable. Sur ordinateur, dans Chrome ou Edge :
- En navigation privée, ouvrez les outils de développement (F12).
- Onglet « Réseau » : cochez « Conserver le journal ».
- Tapez l’adresse de la boutique. Chaque ligne en 301 ou 302 (parfois 307 ou 308, colonne « État ») est un saut : cliquez dessus, la ligne « location » donne l’adresse suivante. Quand c’est réglé : un ou deux sauts en 301 au plus (vers https, vers www ou sans www), puis une ligne en 200.
Dans le même onglet, cliquez sur la réponse : un en-tête server: cloudflare ou cf-ray veut dire que la boutique passe par Cloudflare ; un en-tête strict-transport-security, que le HSTS est actif.
| Les adresses alternent | Où chercher |
|---|---|
| http → https → http | « Activer le SSL » sans « sur tout le site » (1.6 à 8), ou une règle https vers http du serveur |
| www → sans www → www | URL de la boutique contre le réglage www du serveur |
| ancien domaine → nouveau → ancien | URL de la boutique |
| la même adresse en https, encore et encore | Cloudflare en « Flexible », ou un autre proxy |
| une page → une autre page → la première | Certaines pages |
Sans ordinateur, un vérificateur de redirections en ligne (« redirect checker ») affiche la même chaîne. Ou confiez la recherche à votre hébergeur avec le message ci-dessous. Vous pouvez aussi nous appeler au 09 72 03 59 17 ou nous décrire la boucle.
Détail : message type et commande pour votre hébergeur
« Bonjour, ma boutique PrestaShop https://votre-boutique.fr affiche « trop de redirections » (ERR_TOO_MANY_REDIRECTS) depuis le [date], après [changement]. Pouvez-vous me dire quelles redirections votre serveur applique (http vers https, www ou sans www : bouton du panel, règle du serveur, .htaccess) et m’envoyer le résultat de la commande ci-dessous ? La boutique est / n’est pas derrière Cloudflare. » N’y joignez aucun mot de passe.
curl -sS -L -o /dev/null -D - --max-redirs 10 https://votre-boutique.fr/ affiche chaque saut (lignes Location:) ; en boucle, il s’arrête sur « Maximum (10) redirects followed ». Pas de curl -I : jusqu’à la 9.1, une requête HEAD ne montre pas la redirection canonique de PrestaShop.
Derrière Cloudflare : mode SSL « Flexible » ou « Full »
En « Flexible », Cloudflare chiffre la connexion du visiteur, mais appelle votre serveur en http. Si ce serveur force le https, la boucle se forme :
- Le visiteur demande la boutique en https.
- Cloudflare la demande à votre serveur en http.
- Le serveur répond « allez en https ».
- Le navigateur redemande la même adresse en https, et tout recommence.
C’est la redirection du serveur (règle du .htaccess, bouton du panel) qui boucle. Gardez le mode actuel sous la main, puis, dans l’ordre :
- Un certificat valide pour le domaine (et le www) sur l’hébergement : Let’s Encrypt depuis le panel, ou un certificat d’origine Cloudflare.
- Dans Cloudflare, SSL/TLS > Overview (« Vue d’ensemble » en français) : si le mode affiché est « Automatic SSL/TLS », passez à l’option personnalisée (Custom SSL/TLS), puis choisissez « Full (strict) » (« Complet (strict) »). « Full » seulement si le certificat du serveur est auto-signé (modes de chiffrement de Cloudflare).
- Pas de certificat tout de suite ? Retirez la redirection https du serveur, provisoirement : Cloudflare déconseille « Flexible » pour un site où l’on saisit des identifiants. HSTS activé : faites-vous aider.
Une page d’erreur Cloudflare 525 ou 526 remplace la boucle ? Le certificat du serveur manque ou n’est pas valide : installez-le. Revenir à « Flexible » en attendant ramènerait la boucle, sauf à retirer provisoirement la redirection https du serveur (étape 3).
Encore une boucle en « Full (strict) »
- Un retour vers http : le serveur ou PrestaShop renverrait les pages en http. Jusqu’à la 8, c’est en général « Activer le SSL » sans « sur tout le site » (section suivante), ou une vieille règle https vers http dans le .htaccess.
- Les règles de redirection (Redirect Rules, anciennes Page Rules) : deux règles qui se contredisent, www vers sans www et l’inverse.
- Le HSTS (SSL/TLS > Edge Certificates, « Certificats de périphérie ») : s’il est activé, ne coupez jamais le https, ni en retirant le certificat ni en mettant Cloudflare en pause. Les navigateurs refuseraient la boutique pendant la durée réglée, jusqu’à 12 mois.
« Always Use HTTPS » (« Toujours utiliser HTTPS ») force déjà le https : Cloudflare déconseille d’ajouter une redirection https sur le serveur. Sa page sur ERR_TOO_MANY_REDIRECTS reprend ces causes.
Un autre proxy (Varnish, nginx, répartiteur de charge) qui ne transmet pas l’en-tête X-Forwarded-Proto ferait boucler PrestaShop, SSL activé, de la même façon : réglage à voir avec l’hébergeur.
Sur les boutiques que nous hébergeons, Cloudflare est placé devant, et le serveur n’accepte que le trafic venu de Cloudflare ; ce verrou n’est pas en place sur nos serveurs PrestaShop 1.6.
« Activer le SSL » : le piège des versions 1.6, 1.7 et 8
| Version | Où et quoi |
|---|---|
| 1.6 | Préférences > Paramètres généraux « Activer le SSL », « Activer le SSL sur tout le site » |
| 1.7 et 8 | Paramètres de la boutique > Paramètres généraux mêmes interrupteurs ; le second reste grisé tant que le premier est à NON |
| 9 | Paramètres de la boutique > Paramètres généraux « Activer le SSL » seul ; l’aide parle encore de « sur tout le site », option qui n’existe plus |
Jusqu’à la 8, « Activer le SSL » seul ne met en https que certaines pages : compte, panier, commande, contact. L’accueil, une catégorie ou une fiche ouverte en https est renvoyée vers http. Si l’hébergeur ou Cloudflare renvoie tout vers https, ces pages tourneraient en rond, pas le panier.
La correction : les deux interrupteurs sur OUI (le seul en 9), certificat en place. En 1.7 à 9, l’interrupteur n’apparaît que si l’administration est ouverte en https ; sinon, le lien « Veuillez cliquer ici pour vérifier que votre boutique supporte le protocole HTTPS. » le remplace ; derrière un proxy, il pourrait s’afficher même en https.
Désactiver le SSL par la base de données, le temps d’entrer
L’administration boucle elle aussi ? Couper le SSL dans la base vous rouvre la porte. Ce n’est pas la correction : la cause reste à trouver une fois connecté.
Un export complet de la base, téléchargé sur votre ordinateur ; un accès à phpMyAdmin ; le préfixe de vos tables, lu dans app/config/parameters.php (database_prefix, 1.7 à 9) ou config/settings.inc.php (_DB_PREFIX_, 1.6).
HSTS activé dans Cloudflare (« Certificats de périphérie ») ou par l’hébergeur, ou vous ne savez pas ? Ne touchez ni au certificat ni au https du serveur ou de Cloudflare. S’il manque un point, n’allez pas plus loin : confiez-nous la correction.
Détail : dans phpMyAdmin, pas à pas
Table configuration (avec votre préfixe), onglet « Rechercher », name = PS_SSL_ENABLED, puis « Modifier » : valeur 0 (elle valait 1). Cela suffit : PS_SSL_ENABLED_EVERYWHERE n’a alors plus d’effet (et n’existe plus en 9). Plusieurs lignes PS_SSL_ENABLED (multiboutique) : arrêtez-vous. La boutique, elle, peut rester en boucle : ce réglage ne sert qu’à vous connecter. Corrigez la cause, puis remettez « Activer le SSL » sur OUI depuis l’administration en https, ou 1 dans la base.
Dépannage dès 150 € HT, prix fixe validé avant toute intervention ; ces 150 € sont déduits si vous passez ensuite à la maintenance.
Après un changement de domaine, d’hébergeur ou de www : l’URL de la boutique
PrestaShop cherche l’adresse demandée dans sa table shop_url (domaine ou domaine SSL). Introuvable, il renvoie vers le domaine enregistré, en 302 par défaut. Si ce domaine renvoie à son tour vers la nouvelle adresse (ancien domaine redirigé, réglage www de l’hébergeur), la boutique tournerait en rond.
L’ancien domaine renvoie vers le nouveau par une 301 directe, posée sur le serveur. Nouvel hébergeur : voyez aussi ses réglages https et www (section suivante). Vous cherchez encore un hébergeur ? Nous proposons aussi l’hébergement PrestaShop, dès 30 € HT/mois en option de la maintenance, et transfert gratuit vers nos serveurs avec l’abonnement.
Si l’administration s’ouvre
Elle ne suit pas l’URL de la boutique : elle peut s’ouvrir sur le nouveau domaine alors que la boutique boucle.
- Paramètres de la boutique > Trafic et SEO, bloc « URL de la boutique » (1.7 à 9) ; Préférences > SEO & URL en 1.6.
- « Domaine de la boutique » et « Domaine SSL » : la même valeur, sans http:// ni « / » final, avec ou sans www comme l’adresse où vous renvoie l’hébergeur ou Cloudflare (la dernière de la chaîne). Copiez d’abord les anciennes valeurs quelque part.
- « Chemin de base » :
/si la boutique est à la racine,/dossier/sinon. - Enregistrez : le .htaccess est régénéré au passage.
Le bloc « URL de la boutique » n’affiche qu’un message qui renvoie à la page « Multiboutique » ? Le multiboutique est actif (Paramètres avancés > Multiboutique) : arrêtez-vous là et confiez-nous la correction.
Sans administration
Mêmes prérequis que pour couper le SSL : la base exportée en entier sur votre ordinateur, phpMyAdmin ouvert, le préfixe des tables sous les yeux. S’il manque un point, c’est pour nous : décrivez la panne.
Détail : l’URL de la boutique dans phpMyAdmin
Lisez d’abord la table shop_url (avec votre préfixe), ligne où main vaut 1 (une seule en mono-boutique). Corrigez domain et domain_ssl (même valeur), physical_uri si besoin, puis PS_SHOP_DOMAIN et PS_SHOP_DOMAIN_SSL dans configuration. Une fois dans l’administration, enregistrez Trafic et SEO : le .htaccess porte encore l’ancien domaine (des images pourraient manquer).
Le .htaccess et le bouton « forcer HTTPS » de l’hébergeur
PrestaShop n’écrit dans le .htaccess aucune redirection vers https ni vers www. Une telle règle a été ajoutée par vous, un ancien prestataire, un module ou l’hébergeur. Les panels ont aussi leur bouton.
Régénérer le .htaccess sans perdre vos règles
À l’enregistrement de Trafic et SEO (SEO & URL en 1.6), PrestaShop ne réécrit que ce qui est entre # ~~start~~ et # ~~end~~. Régénérer ne retire donc pas une règle https placée au-dessus. Supprimer le fichier la retire, avec toutes les autres : version de PHP de l’hébergeur, 301 faites à la main.
- Le fichier est à la racine de la boutique (gestionnaire de fichiers du panel ou FTP). Son nom commence par un point : affichez les fichiers cachés. Téléchargez-en une copie.
- Lisez le haut du fichier, avant
# ~~start~~: cherchez%{HTTPS},%{SERVER_PORT},%{HTTP:X-Forwarded-Proto}ou%{HTTP_HOST}, suivis d’une ligneRewriteRuleenR=301. Exemple de règle https :RewriteCond %{HTTPS} offpuisRewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]. - Neutralisez une règle à la fois : un
#devant la ligneRewriteRuleet devant les lignesRewriteCondqui la précèdent. Testez en navigation privée. Pire qu’avant : remettez la copie.
| Panel | Où regarder |
|---|---|
| cPanel (o2switch et d’autres) | outil « Domaines », « Forcer la redirection HTTPS » (Force HTTPS Redirect) |
| Plesk | « Redirection 301 permanente (SEO vérifié) de HTTP vers HTTPS », active par défaut, et « Domaine préféré » (www ou non) |
| Hostinger | « Force HTTPS », actif par défaut une fois le certificat installé |
| OVHcloud, IONOS | pas de bouton : la règle est dans le .htaccess |
| Infomaniak | redirection souvent automatique côté serveur, sinon dans le .htaccess |
Une seule couche doit forcer le https, et une seule trancher entre www et sans www. Cloudflare, panel ou .htaccess : gardez-en une, neutralisez les autres.
On vérifie l’URL de la boutique, on repère les couches qui forcent le https ou le www, et on n’en garde qu’une. Réponse en moins d’une heure, 7j/7, de 8 h à 22 h.
La boucle ne touche que certaines pages
- Un produit désactivé redirige, selon « Redirection quand le produit est désactivé » (onglet « Référencement – SEO » de la fiche ; « Rediriger lorsqu’inactif », onglet « Informations », en 1.6), vers un autre produit ou une catégorie (un produit seulement en 1.6). Seule la redirection vers lui-même est bloquée : deux produits désactivés qui se renvoient l’un à l’autre créeraient une boucle. Changez la cible de l’un d’eux.
- Une catégorie désactivée, depuis la 9 : réglage « Redirection en cas de non-affichage » de la catégorie, même risque.
- Un module de redirections : une règle de A vers B, une autre de B vers A. Cherchez l’adresse dans sa liste.
- « Rediriger vers l’URL canonique » (Trafic et SEO ; SEO & URL en 1.6) : le passer à « Aucune redirection » ne corrige pas la cause, et un domaine inconnu de la boutique partirait même en 301 au lieu de 302.
- Panier, connexion client ou retour de paiement : la piste serait les cookies ou un module (paiement, transporteur). Au retour du paiement, c’est un cas où s’arrêter ; dans le formulaire, choisissez « Paiement impossible ».
Corrigé, mais la boucle continue chez vous ?
Le navigateur peut garder certaines redirections en mémoire : les 301 du serveur, du panel ou de vos règles Cloudflare, celles des produits désactivés réglés en 301, et le HSTS. Après la correction :
- testez en navigation privée, ou sur un téléphone en 4G ;
- videz le cache de votre navigateur (Chrome : Paramètres > Confidentialité et sécurité > Supprimer les données de navigation > Images et fichiers en cache) ;
- purgez le cache de Cloudflare (Caching > Configuration > Purge Everything), et celui du serveur (Varnish, LiteSpeed) s’il y en a un ;
- contrôlez une catégorie, une fiche produit, le panier, une commande jusqu’au retour de paiement, puis la connexion client ;
- dans Search Console, la boucle apparaît dans le rapport Pages, motif « Erreur liée à des redirections » : inspectez l’URL pour voir ce que Google reçoit, puis ouvrez ce motif et cliquez sur « Valider la correction ».
Pendant la boucle, aucune commande ne passe par les pages touchées. Si elle touchait le retour de paiement, rapprochez les paiements reçus (banque, PayPal, Stripe) des commandes enregistrées dans PrestaShop. Mettez en pause les campagnes payantes qui pointent vers la boutique tant qu’elle boucle.
Notez le réglage corrigé et son emplacement. Un nouveau certificat, un changement d’hébergeur, un passage sous Cloudflare : la boucle reviendrait par là.
Renvoyé vers un autre site ? Ce n’est pas une boucle
Un renvoi vers un site de jeux, de pharmacie ou une fausse page de paiement n’est pas un conflit de réglages : c’est peut-être le signe d’un piratage. Ce renvoi peut ne viser que certains visiteurs (venus de Google, sur mobile) : ne pas le voir chez vous ne l’exclut pas.
Ne supprimez rien et ne restaurez rien : les fichiers modifiés montrent par où l’intrus est entré.
Lisez notre page boutique PrestaShop piratée, ou appelez le 09 72 03 59 17. Dans notre formulaire, choisissez « Site piraté / Malware ».
Les conseils de forum à ne pas suivre
- Supprimer le .htaccess « pour qu’il se recrée ». Les règles ajoutées partent avec lui. À la place : copie, puis lecture du haut du fichier.
- Laisser la boutique en http pour de bon. Identifiants et adresses des clients circulent en clair, et avec le HSTS les navigateurs refusent la boutique.
- Modifier un fichier du cœur, comme
Link.php: écrasé à la prochaine mise à jour, et la cause reste là.
Questions fréquentes sur l’erreur too many redirects de PrestaShop
Que veut dire « trop de redirections » (ERR_TOO_MANY_REDIRECTS) sur PrestaShop ?
« Too many redirects », ou « trop de redirections », signifie que la boutique renvoie le navigateur d’une adresse à l’autre sans jamais afficher de page. Deux réglages se contredisent (PrestaShop, serveur, hébergeur, Cloudflare). Regardez ce qui a bougé juste avant : certificat, Cloudflare, domaine, hébergeur, www.
Cloudflare : mode Flexible ou Full pour PrestaShop ?
« Full (strict) », avec un certificat valide sur l’hébergement (« Full » s’il est auto-signé). En « Flexible », Cloudflare appelle le serveur en http : si celui-ci force le https, la boutique tourne en rond.
Comment désactiver le SSL de PrestaShop par la base de données ?
Après un export complet, PS_SSL_ENABLED à 0 dans la table configuration, le temps d’entrer dans l’administration. Corrigez la cause, puis réactivez « Activer le SSL ». Si le HSTS est activé, ne le faites pas seul : faites-vous aider.
Faut-il supprimer ou régénérer le .htaccess de PrestaShop ?
Régénérer, après une copie : enregistrez Trafic et SEO (SEO & URL en 1.6). Seul le bloc entre # ~~start~~ et # ~~end~~ est réécrit ; une règle https placée au-dessus reste en place.
Comment changer le nom de domaine d’une boutique PrestaShop sans créer de boucle ?
Même domaine dans les deux champs d’« URL de la boutique » (Trafic et SEO), sans http ni « / ». L’ancien domaine renvoie vers le nouveau en une seule 301, et une seule couche choisit www ou non.
Combien coûte un dépannage pour une boucle de redirection ?
Chez CYBERIAL, dès 150 € HT, avec un prix fixe validé avant toute intervention. Pour une boutique bloquée, réponse en moins d’une heure, 7j/7, de 8 h à 22 h, au 09 72 03 59 17.
Vous préférez qu’on s’en occupe ?
Le formulaire ci-dessous suffit : l’adresse de la boutique (celle que voient vos clients), le navigateur et le message affiché, ce qui a changé juste avant (Cloudflare, certificat, hébergeur, domaine, module) et, si vous la connaissez, votre version. Choisissez « Autre », sauf si la boucle a suivi une mise à jour (« Mise à jour qui a tout cassé »), n’apparaît qu’au retour du paiement (« Paiement impossible ») ou vous renvoie vers un site inconnu (« Site piraté / Malware »). N’écrivez ni mot de passe ni accès (administration, hébergeur, Cloudflare) dans le formulaire.
Pour aller plus vite que le formulaire, appelez le 09 72 03 59 17 (7j/7, de 8 h à 22 h). Une fois la boucle de redirection corrigée, pour un suivi régulier : maintenance PrestaShop à 69 € HT/mois, sans engagement.
