On a récupéré un PrestaShop 8.1 sur un serveur mutualisé premier prix. Mode debug actif, cache Smarty désactivé, pas de Redis, pas de CDN, un slider jQuery en page d’accueil. Résultat : TTFB à 2,3 secondes, LCP à 5,8 secondes. Le client voulait migrer vers une plateforme « plus performante ». Six heures de configuration plus tard, sans toucher au thème, le TTFB passait sous les 180 ms et le LCP sous les 2,5 secondes.
PrestaShop n’a pas la réputation d’une fusée. Les développeurs front le trouvent vieillot, les marketeurs lui reprochent son interface. Mais pour qui fait du SEO technique au quotidien, c’est un CMS qui a un avantage rare : il ne masque rien. Chaque balise, chaque en-tête HTTP, chaque route est accessible, modifiable, contournable. Encore faut-il savoir où mettre les mains.
PrestaShop te laisse le contrôle du HTML, point par point
Quand tu installes un module SEO sur un CMS, tu délègues la génération des balises meta, des canoniques et parfois même du sitemap. Le problème, c’est que cette délégation s’accompagne souvent d’une couche d’abstraction qui t’empêche d’intervenir quand le module se plante. PrestaShop fonctionne différemment. Le noyau gère déjà les balises essentielles via les contrôleurs et les templates Smarty. Le fichier head.tpl d’un thème classique est un exemple de transparence : une vingtaine de lignes où tu vois exactement comment le title, la meta description et le canonical sont construits.
Cette transparence change tout pour l’optimisation. Tu veux modifier la logique du hreflang pour exclure certaines combinaisons de langues ? Tu ouvres le contrôleur, tu ajustes le tableau, tu testes. Pas besoin de rétro-ingénierer un plugin qui surcharge les hooks avec des regex opaques. Le gain de temps en debug est mesurable : sur une boutique multilingue avec trois domaines, on a corrigé une cascade de canoniques erronées en moins d’une heure, directement dans le FrontController.php. Avec un module tiers, il aurait fallu attendre un ticket support ou patcher en aveugle.
Évidemment, cette liberté a un prix. Si tu n’es pas à l’aise avec PHP, tu vas te retrouver bloqué. Mais le lecteur type de ce magazine lit les logs serveur et sait ce qu’est un curl -I. Pour lui, PrestaShop est un terrain de jeu, pas une boîte noire.
Le vrai coût des plugins SEO : quand une surcouche t’empêche d’optimiser le rendu
L’écosystème PrestaShop compte des centaines de modules SEO. Certains sont bien codés, d’autres alourdissent le front-office avec du CSS et du JavaScript injectés sur toutes les pages, même quand ils n’y font rien. On a vu un module « optimisation SEO » charger un style.css de 800 Ko en plein head, bloquant le premier rendu, parce qu’il embarquait une icône FontAwesome complète pour afficher une petite flèche dans le back-office.
Ce qui est pervers, c’est que ces modules s’installent souvent sans que l’équipe technique en mesure l’impact. Le site continue de fonctionner, le LCP se dégrade lentement, et personne ne fait le lien avec le plugin ajouté six mois plus tôt. Sur PrestaShop, tu peux t’en passer. Le noyau gère les redirections 301, les URLs simplifiées, le sitemap XML natif depuis la version 1.7. La fonction Dispatcher transforme tes URLs en routes propres. Le fichier robots.txt est modifiable via le back-office, mais tu peux aussi le surcharger en plaçant un fichier physique à la racine.
Notre règle : aucun module SEO sur une install qu’on audite. On désactive, on nettoie les overrides, on vérifie que les balises critiques restent cohérentes. La plupart du temps, le score Lighthouse y gagne 10 à 15 points sans autre modification. La performance, c’est d’abord ce que tu retires, pas ce que tu ajoutes.
Cache et TTFB : ce que le noyau fait déjà, et ce que tu peux pousser avec Redis
Beaucoup d’hébergeurs spécialisés PrestaShop activent un Varnish par défaut. C’est bien, mais c’est souvent mal configuré. Le Varnish standard ne distingue pas un panier utilisateur d’une fiche produit statique. Résultat : soit il cache trop et des sessions se mélangent, soit il ne cache rien et le TTFB reste haut.
PrestaShop intègre depuis la version 1.7 un système de cache full page qui utilise le file system, Redis ou Memcached. En activant Redis pour le cache full page et les sessions, on retire la charge de la base de données MySQL à chaque requête. Le TTFB passe alors sous les 100 ms si le serveur est correctement dimensionné. Le gain réel, on l’a mesuré sur une boutique avec 50 000 fiches produit : avant Redis, le temps de réponse moyen était de 450 ms. Après, il tombait à 110 ms. Le tout sans toucher au code métier.
Pour aller plus loin, on peut coupler le cache full page avec un CDN qui respecte les en-têtes Cache-Control émis par PrestaShop. La clé, c’est que le noyau envoie déjà ces en-têtes. Pas besoin de module supplémentaire. Quand on parle d’optimisation Core Web Vitals, on oublie souvent que réduire le TTFB est le premier levier, et que sur une architecture e-commerce, les choix de cache conditionnent tout le reste.
Images, WebP, lazy loading : PrestaShop 8 n’a pas dit son dernier mot
PrestaShop 8 embarque la conversion WebP automatique à l’import. Concrètement, tu uploades une image produit en JPEG, le CMS génère une version WebP dans le dossier img/p/. Le front-office sert ensuite le format le plus adapté via l’attribut <source> dans les balises <picture>. C’est transparent, mais il faut l’activer et surtout vérifier que ton thème ne désactive pas cette fonctionnalité avec un override maladroit.
Le lazy loading natif, basé sur l’attribut loading="lazy", est également présent sur les images des listes de produits. Là encore, un thème bien codé l’implémente dès la page d’accueil. Sur la boutique qu’on a reprise, le slider jQuery mentionné plus haut chargeait 15 images de 200 Ko chacune sans loading="lazy". On a viré le slider, adopté un affichage statique en CSS grid avec les images en lazy load natif. LCP divisé par deux, directement visible dans les données de terrain de la Search Console.
Le piège à éviter : cumuler lazy loading natif et lazy loading via JavaScript. Certains développeurs ajoutent un script de lazy loading par habitude, sans vérifier que l’attribut HTML suffit. Ça crée des conflits d’intersection observer, l’image n’apparaît jamais, et l’INP grimpe parce que le script principal est bloqué. Un vieux réflexe qui coûte cher sur les fiches produit avec galerie.
Le rendu côté serveur par défaut : un atout pour le crawl, pas une évidence
Googlebot ne se comporte pas comme un navigateur moderne. Il n’a pas la même patience face au JavaScript. Quand une fiche produit est générée entièrement côté client, avec un appel API asynchrone pour récupérer le prix et le stock, le bot peut indexer la page sans ces données, ou pire, ne pas l’indexer du tout parce que le rendu échoue. PrestaShop échappe à ce problème : le PHP assemble le HTML sur le serveur, la réponse HTTP est complète, le bot lit tout du premier coup.
Ça ne veut pas dire que toutes les pages sont parfaites. Les pages catégories avec facettes générées en ajax via un module posent problème. Googlebot ne clique pas sur tes filtres de couleur. Conséquence : les URLs facettées indexables se multiplient, le crawl budget part en fumée. On recommande de bloquer les paramètres de facettes dans le robots.txt ou d’utiliser un canonical pointant vers la catégorie principale. C’est du bon sens, mais c’est précisément ce type de détail que les surcouches SaaS masquent sous une interface « intelligente » qui décide à ta place.
Sur PrestaShop, la décision t’appartient. Tu contrôles les directives robots, les méta robots par page, et tu peux même modifier le comportement du Dispatcher pour gérer des patterns d’URL spécifiques. C’est une plateforme pour développeurs qui veulent dormir tranquilles après un crawl de test.
Si tu pars en headless, tu perds le principal avantage de PrestaShop
PrestaShop propose une API Web (la « PrestaShop Web Service ») depuis des années. On peut donc l’utiliser en mode headless avec un front React ou Vue. Sur le papier, c’est séduisant. Dans la vraie vie, c’est un piège à indexation. Dès que tu déplaces le rendu côté client, tu réintroduis tous les problèmes que le SSR natif avait résolus. Googlebot doit exécuter ton bundle JS, ton state management doit être hydraté avant que le contenu soit visible. Si tu as choisi une librairie comme Zustand pour gérer l’état, tu dois t’assurer que le rendu initial produit un contenu statique complet. Si tu te rates, l’indexation conditionnelle te rattrape en quelques semaines.
On a accompagné une migration headless qui devait « moderniser » l’expérience utilisateur. Six mois après la mise en ligne, 30 % des fiches produit étaient en « Détectée, actuellement non indexée ». La cause : le temps de rendu côté client dépassait les seuils tolérés par Googlebot. Résultat, retour au thème Smarty classique, avec optimisation du CSS critique et prefetch des requêtes API. Le trafic organique est revenu au niveau initial en deux mois.
La mode du headless n’est pas mauvaise en soi. Mais pour un site dont la priorité est l’indexation et le crawl budget, PrestaShop a déjà le bon défaut : il est lent à migrer vers du JS moderne, et tant mieux, car il reste un moteur de rendu serveur stable.
Questions fréquentes
PrestaShop ou WooCommerce pour la performance technique ?
WooCommerce repose sur WordPress. Si le site a besoin d’extensions lourdes et d’un page builder, le DOM gonfle vite et le TTFB en souffre. PrestaShop a l’avantage d’un écosystème plus restreint, ce qui limite les dégâts. Mais la réponse dépend surtout de la compétence PHP disponible dans l’équipe. Les deux plateformes peuvent être performantes si on les configure correctement. Ce qui tue la performance, c’est le cumul de plugins installés sans contrôle.
Est-ce que PrestaShop gère bien les sites multilingues pour le SEO ?
Oui, le noyau gère les URLs traduites, les balises hreflang par défaut et les sitemaps multilingues si on utilise le module natif. Il faut surveiller les incompatibilités de thème : certains surchargent la génération des balises hreflang et créent des doublons. Un audit régulier avec un outil de crawl suffit pour détecter ça en quelques minutes.
Faut-il éviter le mode debug en production ?
Le mode debug de PrestaShop désactive tous les caches, expose les requêtes SQL et alourdit le temps de réponse. Il est évidemment à bannir en production. Mais ce qui est moins connu, c’est qu’il peut laisser des traces dans la base de données si un module écrit des logs pendant son exécution. On nettoie toujours la table ps_log après avoir désactivé le mode debug sur un site de production.
