Comment identifier les erreurs 404 et soft 404 sur PrestaShop ?

Une boutique PrestaShop de taille moyenne peut accumuler plusieurs centaines de pages en erreur sans qu’aucune manipulation d’URL n’ait eu lieu : il suffit qu’un produit passe en rupture de stock. Ce guide détaille comment repérer les vraies 404 et les soft 404 sur un catalogue PrestaShop, et surtout le point que les guides génériques ignorent : ce sont deux réglages précis du back-office, croisés entre eux, qui décident si une fiche produit épuisée devient une page fantôme indexable ou une 404 propre.

404 et soft 404 sur PrestaShop : la distinction qui change tout

Les deux erreurs se ressemblent pour un visiteur, mais pas du tout pour Google. Confondre les deux fait perdre un temps précieux au moment du diagnostic.

L’erreur 404 franche

Le serveur répond honnêtement : code HTTP 404, « Not Found ». Google le comprend immédiatement, traite la page comme absente et l’exclut de l’index dans un délai raisonnable. C’est la version « propre » du problème.

La soft 404, la page qui ment sur son statut

Ici, le serveur répond 200 (« OK ») alors que le contenu affiché est un message d’indisponibilité, une page vide ou un texte générique sans rapport avec la requête qui y mène. Pour Google, cette page existe et mérite d’être indexée et recrawlée, alors qu’elle n’apporte rien. C’est cette divergence entre le code HTTP et le contenu réel qui définit la soft 404, et c’est elle qui pose problème sur un catalogue e-commerce, où elle touche rarement une page isolée.

Détecter ces erreurs à l’échelle d’un catalogue PrestaShop

Sur un site vitrine de dix pages, un coup d’œil suffit. Sur un catalogue de plusieurs milliers de références, il faut croiser plusieurs sources, car aucune n’est fiable seule.

Les outils et rapports à croiser

Le rapport de couverture de Google Search Console distingue les deux : l’onglet « Erreurs » remonte les 404 franches, l’onglet « Exclues » liste les pages explorées puis écartées, où se cachent la plupart des soft 404. En complément, un crawl complet du site avec Screaming Frog ou un outil équivalent donne les codes HTTP réels de chaque URL, y compris celles que Google n’a pas encore recrawlées. Un analyseur d’en-tête HTTP (extension navigateur type Redirect Path, ou httpstatus.io) permet de vérifier une URL isolée en quelques secondes.

Pourquoi une détection page par page ne suffit pas

Google Search Console échantillonne et retarde ses rapports de plusieurs jours, un crawl externe ne voit pas toujours le contenu réellement servi si des règles serveur diffèrent selon le user-agent, et aucun des deux ne vous dit lequel de vos réglages PrestaShop a produit la page. Il faut donc croiser les URLs remontées par GSC et par le crawl avec la fiche produit correspondante dans le back-office, pour identifier la cause réelle plutôt que son seul symptôme.

Le réglage qui décide si un produit épuisé devient une soft 404

C’est l’angle que ni la documentation générique sur les 404, ni les guides soft 404 non spécifiques à PrestaShop, ne traitent : la mécanique n’est pas liée au contenu de la page ni à un crawl mal configuré, mais à deux réglages du back-office, indépendants l’un de l’autre, qui se croisent sur chaque fiche produit.

Quantités et Mise en ligne : les deux leviers à vérifier

Chaque produit PrestaShop porte, dans son onglet Quantités, un réglage de comportement en cas de rupture : « Refuser les commandes », « Autoriser la commande » (préventes) ou « Utiliser le comportement par défaut » de la boutique. Indépendamment, un second bouton contrôle sa mise en ligne : un produit désactivé devient invisible, y compris via un lien direct. Le point que personne ne relie explicitement : ce sont les valeurs croisées de ces deux réglages, et non la rupture de stock en elle-même, qui déterminent si la fiche produit devient une soft 404 silencieuse.

Ce que révèle chaque combinaison

Un produit désactivé sort proprement du parcours (le back-office documente cette invisibilité même en accès direct). Mais un produit resté en ligne avec « Refuser les commandes » actif reste accessible à son URL, continue de répondre 200, garde son contenu indexable, et n’offre simplement plus aucune action d’achat : c’est une soft 404 par définition, et elle peut apparaître sur des centaines de références simultanément, dès qu’un réassort tarde, sans qu’aucune action n’ait été faite sur l’URL elle-même.

Pour les fiches identifiées comme soft 404 par ce croisement, la décision de les rediriger ou de les laisser en l’état dépend ensuite du trafic et des backlinks qu’elles portent : c’est exactement l’arbitrage détaillé dans notre article sur les pages PrestaShop à indexer, désindexer ou bloquer.

Les autres causes fréquentes de 404 sur une boutique PrestaShop

Au-delà du cas produit, les 404 classiques viennent le plus souvent d’une faute de frappe dans une URL saisie manuellement, d’un lien interne cassé après une modification de catégorie, d’une page supprimée lors d’une refonte sans redirection prévue, ou d’une régénération des URL simplifiées mal exécutée après une mise à jour du module de réécriture d’URL. Ce dernier cas mérite une vérification à part : un renommage manuel du fichier .htaccess combiné à une réactivation des URL simplifiées régénère la structure entière et peut faire apparaître des centaines de 404 d’un coup si l’opération n’est pas suivie d’un contrôle de cohérence.

Corriger : redirection, code 410 ou page 404 personnalisée

Une fois la cause identifiée, la correction dépend de ce que la page représentait.

Quand rediriger, et vers quoi

Une redirection 301 vers un produit équivalent ou la catégorie parente se justifie quand la page portait du trafic ou des liens entrants. Rediriger systématiquement toutes les 404 vers la page d’accueil est une fausse bonne idée : Google perd la correspondance sémantique, et Search Console ne peut plus vous signaler si une redirection précise manque.

410 : le cas où c’est le bon choix

Sur une suppression volontaire et définitive, sans page équivalente, le code 410 (« Gone ») accélère la désindexation de quelques jours par rapport à un simple 404 : Google interprète un 410 comme une intention explicite du site, quand un 404 laisse planer le doute sur une erreur temporaire. Notre article sur la gestion du budget crawl sur un gros catalogue PrestaShop détaille pourquoi ce détail compte davantage à mesure que le nombre de références augmente.

Ce que ça coûte en SEO de laisser les 404 s’accumuler

Un volume élevé de pages en erreur signale à Google un site mal tenu, réduit la part du budget de crawl consacrée aux pages qui comptent réellement, et dégrade l’expérience utilisateur si un visiteur y atterrit depuis une recherche ou un lien externe encore actif. Sur PrestaShop, l’effet se cumule avec d’autres pièges d’indexation propres au CMS : une page en noindex mal positionnée consomme le crawl exactement de la même façon qu’une 404 non traitée, sans qu’on l’associe spontanément au même problème.

Mettre en place une surveillance continue

1. Contrôlez le rapport de couverture Search Console chaque semaineRepérez toute hausse soudaine dans les onglets Erreurs et Exclues, signe d’un incident récent (mise à jour, migration, module).
2. Programmez un crawl complet mensuelUn crawl Screaming Frog ou équivalent, comparé au précédent, révèle les nouvelles 404 avant qu’elles ne s’accumulent sur des mois.
3. Croisez chaque soft 404 avec la fiche produit correspondanteVérifiez systématiquement les réglages Quantités et Mise en ligne avant de conclure à un bug.
4. Documentez les redirections lors de chaque refonte ou suppression de catégorieUn tableau de correspondance anciennes URLs vers nouvelles URLs évite l’essentiel des 404 de refonte.

Ce qu’il faut retenir

Repérer les 404 sur PrestaShop est à la portée de n’importe quel crawl. Repérer les soft 404, et surtout comprendre pourquoi elles apparaissent sans intervention directe sur les URLs, demande de regarder du côté du back-office plutôt que du seul contenu affiché. Sur un catalogue actif, ce sont les réglages de disponibilité produit, bien plus que les fautes de frappe ou les liens cassés, qui pilotent le volume réel de ces pages.