Erreurs avec Screaming Frog404, 5xx et liens cassés

Pourquoi les erreurs pèsent-elles sur votre SEO ?

Une erreur, en SEO technique, c’est une URL qui ne renvoie pas la page attendue. La plus connue est la 404, la page introuvable : le serveur répond que l’adresse demandée n’existe pas. Il y a aussi les erreurs serveur 5xx, bien plus graves, où le serveur lui-même plante et ne parvient pas à répondre. Dans les deux cas, l’utilisateur et le robot se heurtent à un mur au lieu d’atteindre du contenu.

Ces erreurs dégradent votre référencement de plusieurs façons. Elles gaspillent le budget de crawl que Google consacre à votre site, puisqu’il dépense de l’énergie à explorer des URLs qui ne mènent nulle part. Elles cassent le maillage interne quand des liens de votre site pointent vers ces pages mortes. Et elles offrent une expérience utilisateur désastreuse, qui fait fuir les visiteurs et augmente votre taux de rebond.

C’est pourquoi la détection des erreurs est un poste central de tout audit technique. Cette page approfondit un aspect essentiel de ma méthode de crawl avec Screaming Frog : une fois le site exploré proprement, l’outil vous révèle chaque erreur, sa localisation et son origine, pour que vous puissiez corriger méthodiquement plutôt qu’au hasard.

Comprendre les codes de réponse HTTP

Chaque fois qu’un navigateur ou un robot demande une URL, le serveur répond avec un code HTTP qui résume l’état de la réponse. Le code 200 signifie que tout va bien, la page existe et se charge normalement. Les codes 3xx sont des redirections. Les codes 4xx signalent une erreur côté client, dont la fameuse 404. Les codes 5xx signalent une erreur côté serveur, les plus critiques.

Comprendre cette classification est essentiel pour prioriser vos corrections. Une 404 est ennuyeuse mais localisée : une seule page est concernée. Une erreur 5xx peut au contraire toucher tout un site si le serveur est surchargé ou mal configuré. La 403, interdiction d’accès, révèle souvent un problème de permissions. La 410, page définitivement supprimée, est un signal volontaire et plus propre que la 404 pour une page retirée exprès.

Trouver toutes les erreurs dans l’onglet Response Codes

Une fois votre crawl terminé, la détection des erreurs se fait dans l’onglet Response Codes de Screaming Frog. C’est le centre de commande pour tout ce qui touche aux codes HTTP. Appliquez le filtre Client Error 4xx pour afficher toutes les pages en erreur côté client, dont les 404. Appliquez le filtre Server Error 5xx pour voir les erreurs serveur. En quelques clics, vous avez la liste exhaustive de toutes les URLs problématiques de votre site.

Chaque ligne vous donne l’URL concernée et son code exact. Mais l’information la plus précieuse vient ensuite : d’où vient le lien qui pointe vers cette erreur ? Une 404 isolée, vers laquelle rien ne pointe, est sans gravité. Une 404 vers laquelle pointent vingt liens internes est un vrai problème qui casse votre maillage et gaspille du budget de crawl à chaque passage de robot.

C’est là qu’intervient l’onglet Inlinks, en bas de l’interface. Sélectionnez une URL en erreur, ouvrez Inlinks, et vous voyez immédiatement toutes les pages de votre site qui font un lien vers elle. Cette information transforme une simple liste d’erreurs en plan d’action précis : vous savez exactement quel lien corriger, sur quelle page, pour éliminer chaque erreur à la source.

Corriger une erreur 404 : les trois options

Face à une 404, vous avez toujours trois options, et le bon choix dépend du contexte. La première option, quand la page a déménagé ou a un équivalent pertinent, est de mettre en place une redirection 301 vers la nouvelle adresse. C’est la solution idéale quand l’ancienne URL recevait du trafic ou des liens externes : vous préservez l’autorité et vous évitez de perdre les visiteurs.

La deuxième option, quand la page n’existe plus et n’a pas d’équivalent, est de corriger ou supprimer les liens internes qui pointent vers elle. Grâce à l’onglet Inlinks, vous savez où ils se trouvent. Vous les mettez à jour pour qu’ils pointent vers une page valide, ou vous les retirez. Cette approche est la bonne quand la 404 provient uniquement de liens internes obsolètes, sans enjeu de trafic externe.

La troisième option, pour une page volontairement supprimée sans remplacement, est de renvoyer un code 410 plutôt qu’une 404. Le 410 dit explicitement à Google que la page a été supprimée définitivement et volontairement, ce qui accélère sa désindexation. C’est un signal plus propre et plus clair que la 404, utile lorsque vous faites le ménage dans un vieux site avec beaucoup de contenu obsolète.

Les liens externes cassés : un poste oublié

On pense souvent aux erreurs internes, mais Screaming Frog détecte aussi les liens externes cassés : ces liens que vous faites vers d’autres sites et qui pointent désormais vers des pages disparues. Le web bouge en permanence, les sites ferment, changent de structure, et vos liens sortants d’il y a deux ans pointent peut-être aujourd’hui vers des 404 chez vos voisins. C’est mauvais pour l’expérience utilisateur et ça envoie un signal de négligence.

Pour les trouver, activez l’option Check External dans la configuration avant votre crawl, puis consultez l’onglet External une fois l’exploration terminée. Appliquez le filtre sur les codes 4xx et 5xx. Vous obtenez la liste de tous vos liens sortants qui mènent vers des erreurs. Comme pour les erreurs internes, l’onglet Inlinks vous dit sur quelle page de votre site se trouve chaque lien cassé à corriger.

Corriger ces liens externes est un travail simple mais souvent négligé. Vous pouvez soit les mettre à jour vers la nouvelle adresse de la ressource, soit les retirer s’ils n’ont plus de raison d’être. Un site qui ne pointe que vers des ressources vivantes et pertinentes inspire confiance aux visiteurs comme aux moteurs. C’est un détail de qualité qui distingue un site tenu avec soin d’un site laissé à l’abandon.

Distinguer les 404 normales des 404 problématiques

Toutes les 404 ne méritent pas votre attention. Certaines sont parfaitement normales : un utilisateur qui tape une URL au hasard, un vieux lien externe d’un site tiers que vous ne contrôlez pas, une page de test supprimée depuis longtemps. Passer du temps à corriger ces 404 sans enjeu serait une perte d’énergie. La compétence clé consiste à séparer le signal du bruit.

Une 404 devient problématique dans deux cas précis. Le premier : des liens internes de votre propre site pointent vers elle. C’est un problème que vous contrôlez entièrement et que vous devez corriger, car il casse votre maillage. Le second : la page recevait du trafic ou des backlinks avant de disparaître. Là, vous perdez de la valeur accumulée, et une redirection 301 s’impose pour la récupérer plutôt que de la laisser filer.

La gravité dépend aussi du trafic : une 404 sans lien ni visite peut attendre, une ancienne page qui recevait des visites passe en premier.

Soigner votre page 404 personnalisée

Même avec un audit impeccable, des 404 surviendront toujours : liens externes que vous ne contrôlez pas, URLs tapées à la main, vieux liens partagés. La question n’est donc pas seulement d’éliminer les 404, mais aussi de soigner ce qui se passe quand un visiteur en rencontre une. Une page 404 personnalisée bien conçue transforme une impasse frustrante en une occasion de retenir le visiteur.

Une bonne page 404 rassure et guide. Elle explique clairement que la page demandée n’existe pas, tout en gardant le ton et le design du site. Elle propose des issues : un lien vers la page d’accueil, une barre de recherche, des liens vers les contenus populaires. L’objectif est d’éviter que le visiteur ne quitte le site, en lui offrant immédiatement un chemin vers ce qu’il cherchait probablement.

Vérifiez un point technique essentiel avec Screaming Frog : votre page 404 doit bien renvoyer un vrai code 404, et non un code 200. C’est une erreur fréquente appelée soft 404, où une page affiche un message d’erreur mais renvoie techniquement un code 200. Google se retrouve alors à indexer des pages d’erreur comme si elles étaient du contenu valide. L’outil vous permet de vérifier que le code renvoyé correspond bien à la réalité de la page.

Ma méthode de correction, du plus grave au plus léger

Pour corriger les erreurs d’un site, je suis toujours le même ordre de priorité, du plus critique au plus cosmétique. Je commence par les erreurs serveur 5xx, car elles peuvent toucher tout le site et signalent souvent un problème d’infrastructure urgent. Une seule 5xx récurrente peut faire désindexer des pages entières, c’est donc là que se concentre mon attention en premier.

Je passe ensuite aux 404 liées depuis des pages internes, car ce sont celles que je contrôle totalement et qui cassent le maillage. Grâce à l’onglet Inlinks, je corrige chaque lien à la source. Je traite après les anciennes pages à trafic ou à backlinks par des redirections 301, pour récupérer la valeur accumulée. Je termine par les liens externes cassés et la vérification de la page 404 personnalisée.

Cette hiérarchie garantit que l’effort se concentre là où l’impact est le plus fort. Corriger d’abord une soft 404 sans gravité pendant qu’une erreur 5xx fait planter le site serait une erreur de priorisation. Un crawl de contrôle après corrections, comme toujours, valide que les erreurs ont bien disparu et que votre site renvoie désormais des codes propres sur l’ensemble de ses URLs.

Voici à quoi ressemble l’onglet Response Codes filtré sur les erreurs : l’adresse, le code renvoyé et le nombre de liens internes qui pointent vers chaque URL. Les adresses sont des exemples.

# filtrer l’onglet Response Codes sur Client Error (4xx)
Address Status Code Inlinks
/blog/vieil-article-supprime 404 7
/produit/reference-obsolete 404 3
# puis sur Server Error (5xx) pour les urgences
/categorie/promo 503 12
Bulk Export > Response Codes > Client Error (4xx) Inlinks

Les chaînes d’erreurs : quand une correction en révèle une autre

Corriger une erreur en révèle parfois une autre, cachée derrière la première. Un exemple classique : une redirection 301 qui pointe vers une page elle-même en 404. Tant que vous ne suivez pas la chaîne jusqu’au bout, vous ne voyez que la redirection, apparemment saine. Screaming Frog, en suivant chaque saut, révèle ces erreurs de second niveau que les contrôles superficiels manquent systématiquement.

C’est pourquoi un audit d’erreurs rigoureux ne s’arrête pas au premier code de réponse. Il faut vérifier où mènent réellement les redirections, contrôler que les pages de destination existent, et s’assurer qu’aucune correction n’en crée une nouvelle. Rediriger en masse vers une page qui sera supprimée plus tard, par exemple, revient à semer de futures erreurs. La vision d’ensemble qu’offre l’outil évite ce genre de piège en cascade.

Je recommande toujours un crawl de contrôle complet après une campagne de correction d’erreurs, précisément pour détecter ces effets de bord. Ce que vous croyiez réglé peut avoir déplacé le problème ailleurs. Seul un nouveau crawl, analysé avec le même sérieux que le premier, garantit que votre site renvoie désormais des codes propres sur l’ensemble de son périmètre, sans erreur résiduelle ni nouvelle erreur introduite.

Prioriser selon le trafic et les backlinks perdus

Toutes les erreurs ne se valent pas en termes d’enjeu business, et c’est le croisement avec les données de trafic qui permet de vraiment prioriser. Une 404 sur une page qui recevait des centaines de visites par mois est une urgence absolue : chaque jour qui passe, vous perdez des visiteurs et potentiellement des conversions. Une 404 sur une page que personne ne visitait n’a aucun impact réel, même si elle apparaît dans le rapport.

En connectant Screaming Frog à la Search Console, vous voyez quelles pages en erreur recevaient du trafic organique avant de disparaître. Ce sont celles-là qu’il faut rediriger en priorité, pour récupérer le trafic et les positions accumulés. La même logique vaut pour les backlinks : une page qui recevait des liens externes de qualité mérite une redirection 301 pour ne pas perdre cette autorité durement acquise.

Cette priorisation par la donnée change radicalement l’efficacité d’un audit d’erreurs. Plutôt que de traiter mécaniquement une liste de centaines de 404, vous concentrez votre énergie sur les quelques dizaines qui pèsent réellement. C’est la différence entre un travail mécanique et un travail stratégique, où chaque correction est justifiée par un impact mesurable sur le trafic ou l’autorité du site.

Mettre en place une surveillance des erreurs dans le temps

Les erreurs ne sont jamais réglées une fois pour toutes. Un site vivant en génère continuellement : une page supprimée ici, un lien mal mis à jour là, une mise à jour de CMS qui casse des URLs. C’est pourquoi la détection d’erreurs doit devenir une routine régulière plutôt qu’une opération ponctuelle. Un site sain se maintient par une surveillance continue, pas par des grands nettoyages espacés.

Screaming Frog, dans sa version payée, permet de programmer des crawls automatiques qui détectent les nouvelles erreurs à intervalle régulier. Couplée à la Search Console, qui remonte de son côté les erreurs rencontrées par Googlebot, cette surveillance forme un double filet de sécurité. Vous êtes alerté rapidement dès qu’une erreur apparaît, avant qu’elle ne s’installe et ne pèse sur votre référencement.

Sur les sites à forte activité, où le contenu change souvent, cette discipline fait toute la différence. Une 404 détectée et corrigée en quelques jours n’a aucun impact ; la même 404 laissée des mois fait perdre du trafic et de la confiance. Intégrer la surveillance des erreurs à votre routine de maintenance technique, aux côtés du suivi des redirections et du robots.txt, c’est adopter l’hygiène SEO des sites qui durent.

Trier les 404 avec la vue Inlinks

Toutes les 404 ne se valent pas, et c’est une nuance essentielle. Une page supprimée volontairement, sans aucun lien pointant vers elle et sans trafic, génère une 404 parfaitement saine : c’est le comportement attendu. Le problème commence quand une 404 reçoit encore des liens internes, des backlinks externes ou du trafic direct. Là, chaque visite se solde par une impasse et une perte de valeur.

Screaming Frog vous permet de faire ce tri grâce à la vue Inlinks, qui liste les pages pointant vers chaque URL en erreur. Une 404 avec dix liens internes est prioritaire : ces liens gaspillent du maillage et dégradent l’expérience. Une 404 sans aucun lien entrant peut souvent être ignorée, ou simplement laissée telle quelle. Ce filtrage par nombre d’inlinks transforme une liste brute en plan d’action hiérarchisé.

Je croise aussi les 404 avec les données de la Search Console et des backlinks. Une URL morte qui capte encore des liens externes de qualité mérite une redirection 301 vers la page équivalente la plus proche, pour récupérer cette autorité. C’est souvent sur ces quelques pages à fort potentiel que se trouve le vrai gain d’un audit d’erreurs, bien plus que dans le nettoyage de centaines de 404 anonymes et sans enjeu.

Réagir vite face à un pic de 5xx

Une erreur 5xx n’attend pas. Contrairement aux 404 qui peuvent traîner sans catastrophe immédiate, une vague de 500 ou de 503 signale un serveur en souffrance, et Google le remarque très vite. Si le moteur rencontre trop d’erreurs serveur lors de ses explorations, il ralentit son crawl, voire désindexe temporairement des pages qu’il n’arrive plus à charger. Le réflexe doit être la réactivité.

Quand un crawl Screaming Frog remonte des 5xx en nombre, la première question est de savoir si elles sont permanentes ou liées à la charge. Un serveur qui répond bien en navigation manuelle mais renvoie des 503 sous le rythme du crawl est probablement sous-dimensionné ou trop agressivement protégé. Baisser la vitesse de crawl dans la configuration permet de confirmer cette hypothèse : si les erreurs disparaîssent, le problème est bien la charge.

Ces épisodes de 5xx sous charge sont un signal précieux. Ils révèlent la fragilité d’une infrastructure qui tiendra d’autant moins lors d’un pic de trafic réel, un jour de forte affluence ou une campagne réussie. C’est un point à ne jamais négliger : un serveur qui craque dès qu’un crawler insiste un peu craquera aussi le jour où les visiteurs afflueront. Le crawl devient alors un test de résistance révélateur.

La page 404 elle-même, un détail qui compte

Au-delà de la détection des URLs en erreur, la qualité de la page 404 servie compte pour l’expérience utilisateur. Une bonne page 404 renvoie bien le code HTTP 404, ce que Screaming Frog vous confirme, mais elle propose aussi un contenu utile : un lien vers l’accueil, une barre de recherche, quelques suggestions. Une impasse brutale fait fuir le visiteur ; une 404 bien conçue le récupère.

Le piège technique le plus courant sur ce sujet est la soft 404 : une page qui affiche un message d’erreur à l’utilisateur mais renvoie un code 200 au robot. Google déteste ces pages ambiguës, car elles polluent l’index avec du contenu vide déguisé en page valide. Screaming Frog aide à les repérer en croisant le code de réponse avec le contenu, notamment via un faible nombre de mots sur une page censée être riche.

Corriger une soft 404 consiste à lui faire renvoyer le bon code : soit une vraie 404 si la page n’existe plus, soit une 301 vers une page pertinente si un équivalent existe. Ce détail technique, invisible pour l’œil humain, fait une vraie différence sur la façon dont Google perçoit la propreté de votre site. C’est typiquement le genre de finition qu’un audit Screaming Frog sérieux ne laisse jamais passer.

Mon verdict sur Screaming Frog pour les erreurs

Screaming Frog est l’outil le plus efficace pour détecter les erreurs d’un site. En un crawl, l’onglet Response Codes révèle toutes les 404, les erreurs serveur 5xx et les liens externes cassés. Couplé à l’onglet Inlinks, il vous dit exactement d’où vient chaque erreur, ce qui transforme une simple liste en plan de correction précis, page par page, lien par lien.

Mon conseil pour démarrer : filtrez l’onglet Response Codes sur Client Error 4xx et Server Error 5xx, puis utilisez Inlinks pour trouver l’origine de chaque erreur. Traitez les 5xx d’abord, puis les 404 liées en interne, puis les anciennes pages à trafic par des 301. Vérifiez enfin que votre page 404 renvoie bien un vrai code 404.