Quand un site WooCommerce commence à vous jouer des tours, c’est rarement “juste un bug”. Le scénario “le panier est vide” et “les pages produits ne s’affichent plus” ressemble souvent à un problème de session, de cache, de mise à jour qui a cassé un bout du rendu, ou d’un conflit entre extensions. Et plus on attend, plus la boutique perd des ventes, mais aussi de la confiance, car l’erreur est visible immédiatement.
Je vais vous guider pas à pas, avec une logique de terrain. L’idée n’est pas de cocher des cases à l’aveugle, mais de repérer vite la cause la plus probable, puis de tester sans aggraver. Vous verrez aussi comment on distingue un souci “simple” (cache, minification, thème) d’un souci plus sérieux, comme une erreur critique WordPress, une erreur 500 WordPress, ou un site WordPress piraté qui a modifié des fichiers liés au rendu et à la sécurité.
Le tableau de bord mental avant d’agir
Avant de toucher à quoi que ce soit, j’ai pris l’habitude de reformuler le problème en trois questions simples, parce que ça oriente toute la suite.
Première question: quand vous allez sur une page produit, que voyez-vous exactement. Une page blanche, un message d’erreur, un retour vers la page d’accueil, ou juste un contenu vide (sans prix, sans description, sans bouton ajouter au panier) ?
Deuxième question: le panier se vide comment. Est-ce que le bouton “ajouter au panier” fonctionne, puis le panier se réinitialise dès que vous rechargez la page. Ou bien est-ce que rien ne se passe, comme si l’ajout échouait silencieusement. Selon votre réponse, on n’est plus du tout sur les mêmes mécanismes.
Troisième question: à partir de quand ça casse. Après une mise à jour WordPress ratée, un changement de thème, l’installation d’une extension, une migration hébergement, ou une bascule DNS. Si vous avez une fenêtre temporelle, même approximative, vous gagnez un temps énorme.
Et oui, WooCommerce peut tomber en panne sans que WooCommerce soit le coupable direct. J’ai déjà vu un panier vide causé par une règle de cache mal configurée côté reverse proxy, ou par une extension de sécurité qui bloquait des requêtes AJAX. J’ai aussi vu l’inverse: des pages produits ne s’affichent plus parce que le thème surcharge un template et qu’une extension de mise en page a injecté du JavaScript incompatible.
Les symptômes qui orientent vraiment (pages produits d’abord)
Quand une page produit ne s’affiche plus, le risque principal est de confondre deux familles de problèmes:
1) Le contenu est réellement cassé (PHP, templates, base de données, requêtes manquantes). 2) Le contenu est présent côté serveur, mais rendu côté navigateur est cassé (JavaScript, CSS, chargement bloqué, cache “sale”, CDN).
Pour ne pas tourner en rond, observez ce qui change entre une visite “normale” et une visite “en navigation privée”, ou sur un autre navigateur, voire sur un autre appareil.
Si en navigation privée, la page produit s’affiche mieux, c’est souvent une piste cache ou cookies. Si c’est identique, on suspecte davantage un problème serveur, un conflit de thème, ou une erreur critique WordPress / erreur 500 WordPress.
Si vous voyez “page blanche” systématique, j’ajoute presque toujours l’hypothèse d’une fatale côté PHP. Dans ce cas, les logs sont vos meilleurs amis. Ne comptez pas seulement sur le ressenti. Un site WordPress en panne, c’est parfois une seule ligne qui explique tout: une fonction WooCommerce appelée dans un contexte incorrect, ou une incompatibilité après mise à jour.
Première approche: un triage rapide, sans “tout casser”
Je conseille de commencer par des actions à faible risque, celles qui remettent souvent le site d’équerre sans toucher au code.
Voici ma mini-checklist de triage. Elle est courte volontairement, car l’objectif est de vous faire gagner du temps sans multiplier les variations.
Si après ces étapes le problème se résout, vous avez un diagnostic probable. Si ça ne change rien, on passe à une analyse plus ciblée, notamment côté hooks, compatibilité, et sessions.
Pourquoi un panier peut être vide même si la page produit charge
Le panier WooCommerce repose sur un ensemble d’éléments: sessions, cookies, endpoints, requêtes AJAX, et templates. Selon la façon dont votre site est configuré, le “panier vide” peut provenir de raisons très différentes.
Par exemple, si l’ajout au panier déclenche une requête vers un endpoint, et que cette requête est bloquée (sécurité, règle de pare-feu, CORS, proxy), l’ajout ne se persiste pas. Le bouton peut sembler répondre, mais aucune donnée n’est réellement enregistrée côté serveur.
Autre cas fréquent: la page produit se charge, mais le bouton “ajouter au panier” déclenche du JavaScript qui ne s’exécute pas. Dans ce scénario, vous avez souvent des indices dans la console navigateur: une erreur JavaScript qui casse l’exécution, ou un chargement de fichier bloqué.
J’ai aussi vu des boutiques où le panier se vide après redirection, parce qu’une règle de cache renvoyait un HTML “par défaut” au lieu du contenu dynamique attendu. C’est typiquement une erreur de configuration de cache côté CDN ou proxy, surtout si les règles ne distinguent pas bien les pages WooCommerce, les paramètres d’URL, ou les requêtes du panier.
Les causes les plus fréquentes (et celles qui reviennent vraiment)
Plutôt que de lister des hypothèses vagues, je préfère vous donner la palette des causes qu’on rencontre le plus souvent quand on combine “pages produits” et “panier vide”. Vous pourrez ensuite éliminer ce qui ne colle pas à votre cas.
Ce classement n’est pas une vérité absolue, mais dans la pratique, quand on enquête sur plusieurs incidents, on retombe souvent dans ces zones.
Ce que je vérifie côté WordPress et WooCommerce, dans l’ordre
Une enquête réussie ressemble moins à une chasse aux sorcières qu’à une série de tests progressifs.
1) Les permaliens et l’URL des produits
Quand les pages produits ne s’affichent plus, les permaliens sont un classique. Un souci de réécriture peut donner des pages 404, une boucle de redirection, ou un contenu incomplet.
Je commence par vérifier dans WordPress que la structure des permaliens est bien cohérente avec WooCommerce. Ensuite, je “re-sauvegarde” les permaliens, c’est un geste simple, mais il réinitialise les règles de réécriture côté serveur. Dans certains environnements, ça corrige immédiatement des problèmes de pages produits.
Attention toutefois: si votre serveur dépend de règles spécifiques, ce geste doit être fait avec prudence. C’est rarement dangereux, mais ça peut déclencher une latence au premier chargement et générer des erreurs si la configuration Apache ou Nginx est atypique.
2) Les pages “panier”, “boutique” et “compte” dans les réglages WooCommerce
WooCommerce s’appuie sur des pages assignées: panier, boutique, mon compte. Si ces pages ont été modifiées ou si un plugin les a renommées, WooCommerce peut envoyer l’utilisateur vers une destination qui ne fait pas ce qu’on attend.
Je vérifie dans WooCommerce, Réglages, l’onglet qui gère ces associations. Parfois, on découvre que la page “panier” pointe vers une page qui a été supprimée, ou qu’elle a changé d’identifiant lors d’une migration.
3) Le statut des pages et la présence de contenu produit
Ensuite, je regarde si les pages produits sont réellement publiées et visibles. Ce point semble basique, mais je l’ai déjà vu: un rôle utilisateur modifié, une visibilité produit passée en brouillon après une maintenance, ou une règle de sécurité qui modifie l’accès.
Si l’affichage est “vide” plutôt que “inexistant”, je suspecte davantage le rendu ou un plugin qui filtre le contenu.
4) Les erreurs dans la console et les requêtes réseau
Pour le panier vide, je prends l’habitude d’ouvrir l’inspecteur navigateur, puis d’observer les requêtes réseau quand on clique sur “ajouter au panier” ou quand on ouvre le panier.
Si vous voyez des requêtes échouer avec un statut HTTP comme 403 ou 500, vous avez une piste solide. Si vous voyez une requête “AJAX” vers un endpoint WooCommerce échouer, c’est souvent là que se cache le conflit avec une extension de sécurité, un script d’optimisation, ou un firewall.
Si vous voyez une erreur JavaScript du type “script bloqué” ou “variable non définie”, je reviens aux plugins de performance et de minification. Sur ce type de panne, c’est l’une des causes les plus fréquentes.
Le rôle discret du cache (celui qui rend tout plus difficile)
Le cache est utile, mais il est aussi capable de vous donner de fausses pistes. Quand les pages produits ne s’affichent plus, un cache “trop agressif” peut servir une version partiellement rendue. Le résultat ressemble à un bug PHP, alors que le serveur fournit correctement le contenu.
Selon votre configuration, vous pouvez avoir plusieurs niveaux:
- cache du plugin (souvent un plugin dédié à l’optimisation)
- cache CDN
- cache proxy côté hébergement
- minification et concaténation JavaScript et CSS
La bonne approche consiste à désactiver temporairement et tester, puis à réactiver progressivement. Si vous avez l’option, vous testez d’abord en mode “dév” ou “désactivation totale du cache”. Si le site redevient stable, la cause se situe presque toujours dans les règles de cache.
J’ai déjà eu un incident où la boutique ne cassait que pour certains pays, à cause d’une règle CDN basée sur le header ou sur la localisation. Dans un tel cas, tester “depuis votre bureau” ne suffit pas, car vous ne voyez pas la même version mise en cache.
Mise à jour WordPress ratée ou extension qui a rompu WooCommerce
Quand une mise à jour WordPress ratée arrive, WooCommerce peut rester fonctionnel, mais certaines pages ne s’affichent plus ou certains boutons ne répondent plus. Souvent, ce n’est pas WooCommerce qui a “craché”, c’est un mix d’éléments.
Exemples typiques que j’ai rencontrés:
- le thème ne charge plus correctement ses templates WooCommerce après mise à jour
- un plugin de builder a changé une manière d’insérer du contenu et casse le modèle de page produit
- une extension de traduction modifie des fragments de page de façon inattendue
- un plugin de sécurité a durci ses règles et bloque des requêtes nécessaires au panier
Dans ces cas, l’enquête ressemble à un domino. Vous désactivez les extensions une par une, ou vous revenez temporairement à un état précédent si vous avez une sauvegarde. Je dis “temporairement”, parce que laisser le site dégradé pendant des heures n’aide personne.
Si vous avez un doute sur une extension récente, la méthode la plus rentable est de créer un environnement de test, ou au minimum de tester via un accès restreint (mode maintenance WordPress ou protection par IP pendant que vous manipulez). Personne ne veut découvrir une erreur critique WordPress en pleine transaction.
Et si c’était plus grave: erreur critique, erreur 500, ou site WordPress piraté
Quand je vois “pages produits ne s’affichent plus” sur plusieurs navigateurs, avec une erreur 500 WordPress ou une page blanche, je traite ça comme un incident serveur jusqu’à preuve du contraire.
Côté vérifications, je commence par:
- vérifier les logs PHP et les logs serveur
- activer temporairement un mode d’affichage des erreurs uniquement en environnement de test, ou mieux, consulter les erreurs dans les logs
- vérifier l’intégrité de certains fichiers WordPress et WooCommerce
- contrôler les fichiers récemment modifiés si vous avez un outil de suivi
Je ne vous conseille pas de “nettoyer au hasard” si vous suspectez un site WordPress piraté. Le bon réflexe est de stopper l’accès public si nécessaire, sauvegarder, puis analyser. Une réparation site WordPress piraté se fait mieux avec une méthode, sinon vous effacez des symptômes, mais vous laissez la cause.
Si vos pages produits et votre panier cassent à la suite d’une compromission, on observe parfois des modifications dans les thèmes, des injections dans les fichiers PHP, ou des modifications de hooks. Ce n’est pas une règle, mais c’est un signal fort.
Comment diagnostiquer sans se perdre: une logique de décision
Quand je suis appelé sur un “WooCommerce en panne” qui présente ce duo “panier vide + pages produits cassées”, je raisonne en deux axes: côté serveur, côté navigateur.
Si les pages produits sont cassées aussi en désactivant JavaScript (tests simplifiés), ou si les logs montrent une erreur fatale PHP, on se concentre sur la partie serveur.
Si les logs côté serveur semblent propres, mais que la console navigateur affiche des erreurs, on se concentre sur le front: JS, dépendances, minification, compatibilité.
Si ça ne casse que pour certains utilisateurs ou certaines zones, je pense au cache ou aux cookies.
Cette logique permet d’éviter le piège le plus courant: passer deux heures à chercher une incohérence dans le panier alors que le vrai problème est une erreur 500 WordPress dans un fichier de template.
Exemple concret: ce qui m’a le plus surpris (et pourquoi)
Je me souviens d’un incident où tout semblait lié à WooCommerce. Les pages produits affichaient une partie du layout, le bouton “ajouter au panier” était présent, mais rien ne s’ajoutait au panier. Pourtant, la base de données semblait intacte.
Le diagnostic a basculé quand j’ai désactivé temporairement la minification et l’optimisation JavaScript. La page produit s’est alors comportée normalement. Le bug venait d’un script d’optimisation qui recomposait un fichier, et une fonction attendue par WooCommerce n’était plus définie dans le bon ordre.
Ce genre de cas ne se règle pas en changeant “deux réglages WooCommerce”. Ça se règle en corrigeant l’optimisation. Et souvent, la solution est de mettre WooCommerce dans les exceptions du plugin de performance, ou de désactiver une fonctionnalité précise.
Deux actions “prudentes” qui sauvent souvent une boutique
Sans entrer dans un protocole strict, il y a deux actions que je tente assez souvent, car elles ont un bon ratio effort-résultat.
La première, c’est de tester avec un thème neutre temporairement. Si vous utilisez un thème personnalisé ou un thème enfant, je préfère tester avec le thème parent ou un thème minimal. Si les pages produits redeviennent visibles, vous tenez le coupable: soit une surcharge de template, soit un script injecté dans le thème.
La seconde, c’est de désactiver toutes les extensions de performance et de sécurité, une par une ou en mode regroupé si vous êtes en environnement de test. Si le site revient à la normale, on réactive ensuite en identifiant l’extension qui casse un endpoint ou un rendu.
Ces actions sont “prudentes” parce qu’elles ne demandent pas de modifier directement le code WooCommerce. Vous testez l’écosystème, pas les fondations.
Et si vous visez une approche plus “maintenance” pour éviter que ça se reproduise
Quand un site a déjà connu une panne, j’aime bien remettre de l’ordre autour des mises à jour et des déploiements. Ce n’est pas de la peur, c’est une hygiène.
Sur WordPress, je recommande de planifier les mises à jour, en particulier si vous avez un thème complexe et plusieurs extensions. Une maintenance WordPress correctement préparée, c’est aussi un moyen de réduire le risque d’une mise à jour WordPress ratée. La même logique existe pour une boutique PrestaShop, mais comme votre cas est WooCommerce, on se concentre ici sur WordPress.
Si vous avez aussi une autre plateforme, je mentionne seulement ceci pour cadrer, car c’est déjà arrivé à des clients qui géraient plusieurs sites: une maintenance PrestaShop mal préparée peut donner une boutique PrestaShop inaccessible ou une page blanche PrestaShop. Sur le fond, la démarche de validation avant mise en production reste identique: test, validation, puis déploiement encadré.
Quand il faut arrêter de bricoler et faire une réparation
Il y a un moment où “chercher à tâtons” devient coûteux. Faites appel en urgence si vous observez:
- des erreurs répétées de type erreur 500 WordPress
- des signes de site WordPress piraté (fichiers modifiés, injections, redirections)
- une casse globale après une mise à jour (pages, scripts, panier)
- une impossibilité d’accès à l’administration
Une urgence WordPress, ce n’est pas seulement technique. C’est aussi commercial, juridique parfois si votre site affiche des mentions sensibles, et réputationnel. Dans ces cas, la meilleure stratégie est de diagnostiquer vite, avec sauvegardes, contrôle des logs, et restauration ciblée.
Cas spécial: sauvegardes, restauration et méthode propre
Si vous avez une sauvegarde récente, vous pouvez tester une restauration partielle ou complète, mais je vous conseille de ne pas restaurer “au hasard” si vous êtes en production. Une bonne pratique consiste à:
- valider le périmètre (quand ça a cassé)
- identifier les fichiers ou dossiers probablement impliqués
- restaurer uniquement ce qui est nécessaire quand c’est possible
Une “réparation site WordPress” réussie, c’est souvent une restauration ciblée. Une restauration complète peut résoudre le problème, mais elle peut aussi remettre d’anciennes configurations obsolètes et créer une dette technique.
Je parle de cela parce que WooCommerce touche au parcours d’achat. Restaurer un système cassé sans recoller ce qui a changé au même erreur 500 WordPress moment, c’est comme remplacer une porte sans régler la serrure. Ça marche un peu, puis ça bloque à l’usage.
Où vous pouvez trouver les premiers indices (sans attendre)
Si vous voulez une approche très concrète, je vous propose de rassembler, avant toute manipulation, trois éléments:
- une capture de ce que montre la page produit (ou le message exact)
- le comportement du panier après ajout (avec rechargement de page et sans rechargement)
- les erreurs visibles dans la console navigateur, au moment où vous ajoutez au panier
Ensuite seulement, vous attaquez les réglages, cache, plugins, et thème. Cette méthode évite les cycles “je change, je teste, je ne sais pas ce que j’ai amélioré”.
En résumé opérationnel (sans magie)
Pour résoudre “panier vide” et “pages produits qui ne s’affichent plus” sur WooCommerce, vous gagnez à suivre une logique simple:
Commencez par vérifier cache et scripts, car ce sont les causes les plus rapides à tester. Puis passez à la cohérence des permaliens et des pages WooCommerce. Ensuite, regardez les logs et la console navigateur pour distinguer problème serveur (erreur 500 WordPress, fatales PHP, erreur critique) de problème front (JS cassé, minification, conflit de thèmes).
Et si vous observez des signaux de compromission, traitez le cas comme un site WordPress piraté jusqu’à preuve du contraire. Dans ce domaine, le bon réflexe vaut plus que la rapidité.
Si vous voulez, décrivez-moi exactement ce que vous voyez sur la page produit (message, code erreur, page blanche ou contenu partiel) et ce qui se passe quand vous cliquez sur “ajouter au panier”. Je pourrai vous proposer une piste de diagnostic plus précise, adaptée à votre configuration (cache, thème, extensions de sécurité ou d’optimisation, et version récente de WordPress).