Audit SEO technique : checklist complète pour identifier les problèmes de votre site

Un site peut produire du contenu de qualité, accumuler des backlinks et afficher un bon score de notoriété de domaine — et pourtant stagner en page 2 ou 3 de Google. La cause est presque toujours la même : des problèmes techniques non détectés qui empêchent les robots des moteurs de recherche de crawler, d'indexer et de comprendre correctement les pages. Un audit SEO technique rigoureux est le point de départ de toute stratégie de référencement sérieuse. Voici la checklist complète que l'équipe de Solentia utilise systématiquement, étape par étape.

1. Crawlabilité : permettre aux robots d'accéder à votre site

La crawlabilité est la capacité d'un moteur de recherche à parcourir librement les URLs de votre site. Vérifiez d'abord que votre fichier robots.txt est accessible en HTTP 200, qu'aucune règle Disallow ne bloque accidentellement des sections importantes comme /products ou /services, et que la directive Sitemap: pointe vers votre sitemap XML. Ce dernier doit contenir uniquement des URLs canoniques et indexables — aucune page noindex, aucune redirection 301. Pour les sites de plus de 50 000 pages, un sitemap index segmenté par type de contenu est indispensable. Testez l'ensemble via Google Search Console > Outil de test robots.txt et Screaming Frog en crawl complet.

2. Indexabilité : s'assurer que les bonnes pages entrent dans l'index

Un robot peut accéder à une page sans pour autant l'indexer. Auditez toutes les pages portant une balise <meta name='robots' content='noindex'> ou un en-tête HTTP X-Robots-Tag: noindex — sont-elles vraiment destinées à être exclues ? Chaque page doit disposer d'un canonical auto-référent pour éviter que Google ne choisisse lui-même la version à indexer. Méfiez-vous des canonical loops et des canonicals croisés non intentionnels sur les pages de pagination. Sur les sites belges multilingues, la symétrie des annotations hreflang est obligatoire : utilisez les codes BCP 47 spécifiques (fr-BE, nl-BE, de-BE) et définissez un x-default. Une implémentation partielle est pire qu'une absence totale — elle envoie des signaux contradictoires que Google ignore ou sanctionne.

3. Core Web Vitals et performance mobile

Depuis le Page Experience Update, les Core Web Vitals sont intégrés comme signal de classement. En 2026, les données terrain (CrUX) priment sur les données de laboratoire. Vos seuils cibles : LCP < 2,5 s (identifiez l'élément LCP et préchargez-le avec <link rel='preload'>), CLS < 0,1 (déclarez toujours width et height sur les balises <img>), INP < 200 ms (auditez les gestionnaires d'événements lourds et les long tasks dans Chrome DevTools). Un TTFB > 800 ms pénalise mécaniquement le LCP : vérifiez l'hébergement, le cache serveur et le CDN.

• Testez l'utilisabilité mobile via Search Console > Expérience > Utilisabilité mobile et l'outil Mobile-Friendly Test de Google.
• Les éléments tactiles (boutons, liens) doivent mesurer minimum 48 × 48 px avec un espacement suffisant entre eux.
• Le contenu visible sur mobile doit être identique à la version desktop : Google indexe en mode mobile-first.
• Les popups et interstitiels intrusifs sur mobile restent sanctionnés depuis la mise à jour de 2017, toujours appliquée.

4. Audit des données structurées Schema.org

Les données structurées ne sont pas directement un facteur de classement, mais elles activent les rich results (étoiles, FAQ accordéon, breadcrumbs) qui améliorent le taux de clic et alimentent les AI Overviews de Google avec des données factuelles fiables. Priorités selon le type de site : Organization et LocalBusiness pour toutes les entreprises belges (incluez l'adresse complète avec addressCountry: BE), Article ou BlogPosting pour les contenus éditoriaux, FAQPage pour les sections questions-réponses, BreadcrumbList pour la hiérarchie du site, Product avec AggregateRating pour l'e-commerce, Service pour les prestataires.

• Validez chaque implémentation avec l'outil Rich Results Test (search.google.com/test/rich-results).
• Consultez Search Console > Expérience > Résultats enrichis pour les erreurs remontées sur l'ensemble du site.
• Erreur fréquente 1 : déclarer une FAQPage dont les Q/R ne correspondent pas au contenu visible — c'est du spam de schema pénalisable.
• Erreur fréquente 2 : JSON-LD malformé (virgules manquantes, guillemets non échappés). Validez systématiquement avec jsonlint.com avant déploiement.
• Erreur fréquente 3 : utiliser des types dépréciés de Schema.org sans consulter schema.org/version/latest.

5. Analyse du maillage interne

Le maillage interne remplit trois fonctions critiques : distribuer le PageRank vers les pages prioritaires, aider les robots à découvrir toutes les URLs, et guider les utilisateurs pour réduire le taux de rebond. Commencez par identifier les pages orphelines (aucun lien interne entrant) via Screaming Frog > Reports > Orphan Pages — ces pages sont invisibles pour Google sauf si elles figurent dans le sitemap. Aucune page stratégique ne devrait être à plus de 3 clics de l'accueil.

• Remplacez les ancres génériques ('cliquez ici', 'en savoir plus') par des ancres descriptives contenant le mot-clé cible de la page de destination.
• Repérez les pages avec plus de 100 liens sortants internes : le PageRank est dilué au point de perdre son effet.
• Corrigez tous les liens internes brisés (404) — ils perdent du jus de lien et dégradent l'expérience utilisateur.
• Organisez vos contenus en silos thématiques : les articles sur le SEO technique se lient entre eux ET vers la page de service SEO.

6. Détection du contenu dupliqué

Le contenu dupliqué n'est pas une pénalité directe, mais il dilue l'autorité entre pages concurrentes et contraint Google à choisir quelle version indexer — souvent pas celle que vous préférez. Le contenu dupliqué interne touche les sites accessibles via plusieurs URLs (avec/sans www, avec/sans slash final, HTTP vs HTTPS, paramètres UTM indexés). Consolidez via canonical et redirections 301. Sur les sites e-commerce, les pages de facettes génèrent des milliers de combinaisons quasi-identiques : configurez des règles robots.txt ou des balises noindex pour les variantes sans trafic organique.

• Les fiches produits ou pages de services très similaires doivent être différenciées par au moins 30 % de contenu unique, ou consolidées via canonical.
• Utilisez Copyscape ou Siteliner pour détecter si votre contenu est repris sans attribution sur des sites tiers.
• Vérifiez les pages de pagination : /?page=2 doit être traitée par canonical vers la page principale ou via rel='next' / rel='prev' selon votre stratégie.

7. Sécurité HTTPS et rendu JavaScript

Vérifiez que votre certificat SSL est valide et non expiré, que toutes les URLs HTTP redirigent vers HTTPS en 301, et qu'aucun contenu mixte (mixed content) ne subsiste (images, scripts ou iframes chargés en HTTP sur une page HTTPS). Les en-têtes HTTP de sécurité obligatoires : Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options. Concernant le rendu JavaScript, comparez le HTML source (Ctrl+U) avec le DOM rendu (DevTools > Elements) : si votre contenu n'existe que dans le DOM, Google peut le rater. Privilégiez le SSR ou le SSG pour toutes les pages indexables, vérifiez que les balises meta (title, canonical, og:) sont dans le HTML initial et utilisez l'outil 'Inspecter l'URL' de Search Console pour voir exactement ce que Googlebot voit après rendu.

8. Analyse des fichiers journaux (log files)

• Demandez à votre hébergeur l'accès aux access logs sur au moins 30 jours, puis filtrez les requêtes de Googlebot (user-agent contenant 'Googlebot') — les logs sont la seule source de vérité objective sur le comportement réel du crawler.
• Identifiez les pages crawlées très fréquemment mais sans valeur SEO (connexion, panier, URLs de session) : bloquez-les dans robots.txt pour économiser le budget de crawl.
• Repérez les pages stratégiques crawlées rarement ou jamais : elles manquent de maillage interne ou sont trop profondes dans l'arborescence.
• Détectez les pics d'erreurs 5xx dans les logs : ils dégradent l'expérience de crawl et peuvent provoquer une désindexation temporaire.
• Outils : Screaming Frog Log File Analyser (version autonome) pour les sites de taille moyenne, Botify pour les très grands sites (> 1M URLs).

9. Outils de référence et priorisation des corrections

• Screaming Frog SEO Spider : crawler incontournable pour l'audit on-page, les redirections, les canonicals, les meta et le maillage interne. Version payante (250 £/an) indispensable au-delà de 500 URLs.
• Google Search Console (gratuit) : source de vérité sur les performances terrain, les erreurs d'indexation, les Core Web Vitals et les données structurées.
• Google PageSpeed Insights / Lighthouse : audit de performance et Core Web Vitals en données laboratoire et terrain.
• Ahrefs Site Audit : efficace pour les backlinks, les pages orphelines et la détection des erreurs on-page à grande échelle.
• Semrush Site Audit : complémentaire pour le contenu dupliqué et l'analyse des balises meta.
• Chrome DevTools : débogage JavaScript, analyse du rendu, Coverage et Network requests — indispensable pour le diagnostic du rendu JS.

1. 1Priorité critique — immédiatement : pages stratégiques bloquées par robots.txt ou noindex accidentel, erreurs 5xx généralisées, absence de HTTPS, contenu dupliqué massif sans canonical. Ces 'quick wins' à fort impact et faible effort passent en premier.
2. 2Priorité haute — dans les 30 jours : Core Web Vitals en échec sur les pages à fort trafic, hreflang mal implémenté, pages orphelines sur les sections clés, schema invalide bloquant les rich results.
3. 3Priorité moyenne — dans les 90 jours : optimisation du budget de crawl via logs, amélioration du maillage interne, déduplication du contenu quasi-similaire, audit complet des redirections.
4. 4Priorité basse — améliorations continues : enrichissement des données structurées, optimisation des ancres, monitoring des performances, analyse régulière des logs.

“Un audit SEO sans plan de correction est une liste de problèmes. Un audit avec priorisation est une feuille de route vers la croissance organique.”

— Équipe SEO Solentia

Combien de temps dure un audit SEO technique complet ?

Pour un site de taille moyenne (1 000 à 10 000 URLs), un audit complet prend 3 à 5 jours de travail — crawl, analyse manuelle, vérification des logs, tests de performance et rédaction du rapport priorisé. Pour un grand site e-commerce (> 100 000 URLs), comptez 2 à 3 semaines.

À quelle fréquence faut-il réaliser un audit SEO technique ?

Un audit complet annuel est le minimum. Les sites qui publient régulièrement, font évoluer leur plateforme ou subissent des migrations doivent réaliser un audit partiel trimestriel. Google Search Console permet une surveillance continue entre deux audits complets.

Les problèmes techniques peuvent-ils faire chuter un site dans Google ?

Oui. Une balise noindex déployée par erreur sur toutes les pages, un changement de structure d'URL sans redirections 301, ou un robots.txt bloquant les sections principales suffisent à provoquer une chute brutale du trafic organique. Ces incidents prennent des semaines à plusieurs mois à se corriger une fois résolus.

La SEO technique varie-t-elle selon le CMS utilisé ?

Les problèmes à détecter sont universels, mais les solutions dépendent du CMS. Sur WordPress, Yoast SEO ou Rank Math simplifient la gestion des meta et sitemaps. Sur Shopify, les URLs de collection génèrent souvent des doublons canonicaux. Sur Next.js ou Nuxt, le rendu JavaScript est la préoccupation centrale. Quelle que soit la plateforme, les fondamentaux de crawlabilité, d'indexabilité et de performance s'appliquent identiquement.