Un client m'a envoyé un site qui avait été « optimisé pour le SEO par une agence professionnelle » pendant 18 mois. Les classements étaient stables. Le trafic baissait d'une année sur l'autre. Le rapport de l'agence faisait 47 pages et incluait une section sur « l'alignement de la voix de marque ». Ce qu'il ne mentionnait pas, c'est que 3 400 pages retournaient des codes de statut 200 mais avaient des balises noindex intégrées dans la meta. Trois mille cinq cents pages. Disparues. Invisibles. L'agence n'avait jamais réellement crawlé le site.
Point clé : un crawl Screaming Frog recoupé avec les données de Search Console identifie toujours la plupart des problèmes de SEO technique sur n'importe quel site ; la méthode compte plus que les outils exotiques.
Je l'ai réparé en une semaine. Avec Screaming Frog et Google Search Console.
C'est ça, le truc avec le SEO technique : ça récompense ceux qui regardent réellement les données au lieu d'en parler. Et honnêtement, pour 90 % des sites que j'audite via Seahawk, je n'ai pas besoin d'Ahrefs, Semrush ou aucune des grandes plateformes pour trouver les problèmes qui nuisent vraiment à la performance. Deux outils. Un processus. Le voici.
---
Avant de crawler quoi que ce soit, configurez Screaming Frog correctement
La plupart des gens ouvrent Screaming Frog, collent une URL, et cliquent sur démarrer. C'est correct pour un blog de 50 pages. Pour tout ce qui est plus gros, vous attendrez 40 minutes pour un crawl qui vous donne des données incorrectes.
La configuration compte plus que la vitesse de crawl.
Première chose : aller dans Configuration > Spider et m'assurer que je crawle le bon protocole. Si le site est en HTTPS (il devrait l'être), je commence par la homepage canonique HTTPS. Je désactive aussi le crawl de certains types de fichiers, PDFs, images, vidéos, sauf si je veux spécifiquement les auditer. Ça divise par deux le temps de crawl.
Ensuite je mets Configuration > Respect Canonical Tags sur off. C'est contre-intuitif, je sais. Mais je veux voir chaque URL canonicalisée pour pouvoir auditer si la canonicalisation est réellement correcte. Si Screaming Frog saute les pages canonicalisées, vous ne saurez jamais qu'elles existent.
Une chose de plus : dans Configuration > Custom Extraction, je configure une règle d'extraction pour récupérer les balises <title> brutes et meta description directement depuis la source HTML. Pourquoi ? Parce que certains sites WordPress, particulièrement ceux qui utilisent Yoast avec un page builder, génèrent deux balises title. La colonne par défaut de Screaming Frog ne te montre que la première. La règle d'extraction te montre tout.
---
Le premier passage : ce que je cherche dans les données de crawl
Une fois le crawl terminé, je ne commence pas par les liens brisés. Tout le monde commence par les liens brisés. Je commence par l'onglet Response Codes et je filtre les redirections 3xx.
En 2021, Seahawk a pris un client e-commerce, un détaillant de meubles de taille moyenne, environ 8 000 URLs. Leur équipe dev gérait les redirects au coup par coup depuis deux ans. On a trouvé 19 chaînes de redirects, certaines avec quatre sauts. La Page A redirigait vers la Page B, qui redirigait vers la Page C, qui redirigait vers la Page D. Google dit qu'il suit jusqu'à 10 sauts, mais en pratique, tout ce qui dépasse deux sauts gaspille le budget de crawl et dilue l'équité des liens. On a tout réduit à des redirects à un seul saut. Rien que ça, sans changement de contenu, sans link building, a fait passer trois pages de catégories de la page 3 à la page 1 en six semaines.
L'ordre dans lequel je traite les onglets
- Response Codes → 3xx, chaînes et boucles de redirects
- Response Codes → 4xx, pages cassées (filtrer par inlinks pour prioriser)
- Indexability → Non-Indexable, noindex, canonicals pointant ailleurs, bloqué par robots.txt
- Page Titles, manquantes, dupliquées, plus de 60 caractères
- Meta Description, manquantes ou dupliquées (pas un facteur de ranking, mais le CTR compte)
- H1, manquant, en doublon, ou plus d'un par page
- Images → Texte Alt manquant, gain rapide, surtout pour les sites de produits
- Directives → Canonique, vérifiez que ces éléments correspondent à l'URL réellement indexable
Cet ordre est délibéré. Je pars des problèmes structurels (redirections, pages cassées) jusqu'aux problèmes on-page. Corriger une chaîne de redirection cassée aide chaque page de cette chaîne. Corriger une meta description manquante aide une seule page.
---
La stratification dans Search Console : là où ça devient intéressant
Screaming Frog te dit ce qui est sur le site. Search Console te dit ce que Google pense qui est sur le site. L'écart entre ces deux ensembles de données, c'est là que vivent les vrais problèmes.
Couverture (ou Indexation → Pages dans la nouvelle interface). Tu regardes quatre choses :
- Erreur, pages que Google a tenté d'indexer sans succès
- Valide avec avertissements, souvent « L'URL soumise n'a pas été sélectionnée comme canonique », c'est un vrai gâchis qu'il faut démêler
- Exclue, pages que Google a choisi de ne pas indexer (analysées mais non indexées, noindexées, etc.)
- Valide, pages que Google a indexées
Le bucket « Exclue » est criminellement sous-utilisé. La plupart des gens l'ignorent. Moi, j'y vais directement. Filtrez par « Analysée, actuellement non indexée ». C'est Google qui dit : j'ai trouvé cette page, je l'ai lue, et j'ai décidé qu'elle ne valait pas la peine d'être indexée. C'est presque toujours un problème de contenu maigre. Ou c'est une page qui va bien en elle-même mais qui est trop similaire à une autre page, un problème classique avec la navigation à facettes ou les archives de tags.
Mettre en correspondance les exclusions GSC avec ton crawl Screaming Frog
Exporte ton crawl Screaming Frog en CSV. Exporte les URLs « Exclues » de Search Console. Charge les deux dans Google Sheets et exécute une VLOOKUP. Toute URL qui apparaît dans le crawl Screaming Frog et dans la liste GSC exclue est une investigation prioritaire.
Je sais que les gens se tournent vers des scripts Python pour ça. Vous n'en avez pas besoin. VLOOKUP dans Sheets prend quatre minutes et vous donne la même réponse.
---
Budget de crawl : Ne pose problème que si votre site est vraiment volumineux
D'accord, soyons honnêtes. Si votre site a moins de 1 000 pages, le budget de crawl n'est pas votre problème. Vous pouvez arrêter de vous en préoccuper.
Mais une fois que vous dépassez environ 10 000 URL, et beaucoup de magasins WooCommerce ou Magento atteignent ce seuil juste à cause des variantes de produits et des URL filtrées, le budget de crawl commence à poser problème. La documentation de Google Search Central sur le budget de crawl est en fait l'une des choses les plus claires qu'ils aient écrites. Ça vaut le coup de la lire correctement.
Les deux leviers que vous avez dans Search Console sont le rapport Crawl Stats et l'outil URL Inspection. Crawl Stats vous montre l'activité de crawl de Google sur 90 jours : pages crawlées par jour, temps de réponse, codes de réponse. Si vous voyez un pic de 404 à une date spécifique, c'est un déploiement qui a mal tourné. Si le temps de crawl moyen est supérieur à 2 secondes, c'est votre serveur qui pose problème, pas votre SEO.
---
Linking interne : Ce que les agences oublient toujours
J'ai audité bien plus d'une centaine de sites chez Seahawk où le client dépensait de l'argent réel en création de liens, articles invités, relations publiques numériques, tout le tralala, et avait des pages orphelines sur lesquelles aucun lien interne ne pointait. Google ne peut pas prioriser ce qu'il ne peut pas trouver à travers la structure de votre site.
Dans Screaming Frog, filtrez le crawl par Inlinks = 0. Toute page avec zéro lien interne est orpheline. Croisez-la avec les pages indexées de Search Console. Si la page est indexée mais n'a aucun lien interne, c'est que Google l'a trouvée via un sitemap XML ou un backlink externe. C'est fragile. Donnez-lui un lien interne depuis une page pertinente et vous donnez à Google un signal structurel que cette page compte.
Quelques points sur lesquels je veille concernant les liens internes
- Les pages de pagination qui renvoient vers des pages produit/article, mais ces pages ne renvoient pas vers les pages catégories
- Les articles de blog publiés en 2019 qui n'ont jamais été liés à partir de contenu plus récent
- Les pages qui ont des dizaines de liens internes entrants mais très peu de trafic dans la Search Console sont souvent le signe d'un problème au niveau de la page elle-même, pas au niveau des liens.
---
Core Web Vitals : Lire les données, ne pas paniquer
La Search Console propose un rapport Core Web Vitals. Il s'appuie sur les données du rapport Chrome UX Report des utilisateurs réels, ce sont des données de terrain, de vrais utilisateurs sur de vrais appareils, pas une simulation en laboratoire. C'est plus significatif que ce que vous obtiendriez avec une seule exécution Lighthouse.
Le rapport classe les URLs dans les catégories « Bon », « À améliorer » et « Faible » selon le LCP, le FID (désormais remplacé par l'INP) et le CLS. N'essayez pas de tout corriger à la fois. Triez par le groupe « Faible » et regardez quel modèle d'URL a le plus de pages défaillantes. C'est généralement un seul modèle, toutes les pages produit qui échouent le CLS, ou toutes les pages catégorie avec un LCP lent. Corrigez le modèle, corrigez des centaines de pages en une seule fois.
Une chose que j'ai apprise à la dure : les problèmes de CLS sur les sites avec des publicités ou des bannières de consentement proviennent presque toujours d'éléments qui s'injectent au-dessus de la ligne de flottaison après le rendu initial. Screaming Frog ne détectera pas cela. Vous devez regarder la page réelle. Utilisez Chrome DevTools avec les régions de Layout Shift activées dans Rendering.
---
La Vérification Robots.txt et du Sitemap (10 Minutes, Vous Économisez des Semaines)
Allez sur yourdomain.com/robots.txt. Lisez chaque ligne. J'ai vu de mes propres yeux un site de production en direct avec Disallow: / dans le robots.txt. Pas un site de staging. Production. Une entreprise vieille de sept ans. Leur développeur avait copié le robots.txt de staging lors d'une migration et ne l'avait jamais vérifié. Ils avaient été essentiellement invisibles pour Google pendant quatre mois avant de s'en apercevoir.
Dans la Search Console, allez dans Plans de site. Vérifiez ce qui a été soumis. Vérifiez la dernière fois que Google l'a récupéré. Si le plan de site n'a pas été récupéré depuis plus d'une semaine, quelque chose ne fonctionne pas. Vérifiez aussi le nombre d'URLs soumises par rapport au nombre d'URLs indexées, si vous avez soumis 4 000 URLs et seulement 1 200 sont indexées, c'est une conversation que vous devez avoir sur la qualité du contenu, pas sur les correctifs techniques.
---
FAQ
Ai-je besoin de la version payante de Screaming Frog ?
La version gratuite est limitée à 500 URLs. Pour tout ce qui dépasse, ce qui concerne la plupart des sites qui valent la peine d'être audités, vous avez besoin de la licence payante. Elle coûte 259 £ par an au moment de la rédaction. C'est à peu près le prix d'une seule heure de travail en agence. Achetez-la.
À quelle fréquence dois-je exécuter un audit technique ?
Pour les sites actifs qui publient régulièrement ou qui changent fréquemment de produits, je dirais trimestriellement. Pour les sites plus petits et plus statiques, deux fois par an, c'est bien. Exécuter un audit une fois et le considérer comme « terminé », c'est comme changer l'huile d'une voiture une fois et s'attendre à ce qu'elle fonctionne éternellement.
Screaming Frog affiche un statut 200 mais la Search Console montre que la page n'est pas indexée, pourquoi ?
C'est presque toujours l'une de trois choses : une balise meta noindex, un en-tête HTTP noindex, ou une balise canonical pointant ailleurs. Vérifiez l'URL à l'aide de l'outil Inspection des URLs de la Search Console et il vous dira exactement ce qu'il a trouvé. Cet outil est sous-estimé, il vous montre la dernière version de la page crawlée par Google, y compris le HTML rendu, ce qui attrape les balises noindex injectées par JavaScript qu'une simple requête HTTP ne verrait pas.
Et pour les sites rendus en JavaScript ?
Screaming Frog dispose d'un mode de rendu JavaScript sous Configuration > Spider > Rendering. Activez-le pour les sites qui font une utilisation intensive du JS. C'est plus lent, beaucoup plus lent, mais c'est le seul moyen d'attraper les problèmes de contenu ou de liens injectés par JavaScript après le chargement du HTML initial. Pour un site React ou Next.js, crawlez toujours en mode rendu JS.
Google Search Console suffit-il pour la recherche de mots-clés ?
Pour trouver les requêtes pour lesquelles vos pages existantes se classent, oui, c'est excellent. Pour découvrir de nouvelles opportunités de mots-clés, non, vous aurez besoin de quelque chose d'autre. Mais c'est hors de la portée d'un audit technique.
---
Deux outils. Une feuille de calcul. Quelques heures. C'est vraiment tout ce que cela prend. Les plateformes coûteuses ont leur place, je ne suis pas contre, mais j'ai vu trop de propriétaires de sites supposer que payer plus signifie trouver plus. Les problèmes sont presque toujours dans les bases. Ils ont juste besoin que quelqu'un y jette vraiment un œil.