Audit SEO technique — crawl, Core Web Vitals, schema, indexation

Il existe deux grands types d’audit SEO, et les confondre coûte du temps. L’audit SEO éditorial analyse ce que disent vos pages — thématiques, maillage, intention. L’audit technique, lui, analyse comment vos pages sont construites, servies et interprétées par les robots. Un site peut avoir du contenu excellent et rester invisible parce qu’un fichier robots.txt mal configuré bloque Googlebot, ou parce que le JavaScript empêche le moteur de lire le texte. C’est précisément ce que je dissèque dans cet audit.

Quand commander un audit technique

Trois situations rendent l’audit technique non négociable :

Avant une refonte ou une migration. Changer de CMS, restructurer les URLs, passer en HTTPS, fusionner deux domaines — chacune de ces opérations peut effacer des mois de trafic si elle n’est pas préparée. Je cartographie l’existant avant de toucher quoi que ce soit. Voir aussi ma page dédiée à la migration SEO.

Après une chute de trafic inexpliquée. Une mise à jour Google, une mauvaise manipulation de fichier, un changement d’hébergeur — le diagnostic commence par les logs serveur et la Search Console, pas par le contenu.

Au démarrage d’une mission SEO. Je ne construis pas sur des fondations inconnues. Avant de produire du contenu ou de chercher des liens, j’ai besoin de savoir que les robots peuvent accéder, indexer et comprendre vos pages correctement.

Crawl complet — Screaming Frog comme couteau suisse

Le crawl, c’est l’étape zéro. J’utilise Screaming Frog configuré pour se comporter comme Googlebot : même user-agent, rendering JavaScript activé, suivi de tous les liens internes et externes.

En clair : le crawler visite chaque URL du site, exactement comme le ferait Google, et retourne pour chaque page une centaine de paramètres — code HTTP, balise title, meta description, balises Hn, temps de réponse, taille de la page, nombre de liens entrants internes, présence de canonical, état du fichier robots.txt…

Ce que je cherche en priorité : les pages orphelines (aucun lien interne ne les pointe), les chaînes de redirections à plus de deux sauts, les erreurs 404 qui auraient dû être redirigées, les pages dupliquées sans canonical explicite. Sur un site de cent pages, on trouve en moyenne douze à vingt anomalies structurelles. Sur un site de mille pages, c’est souvent plusieurs dizaines.

Indexabilité — robots.txt, meta robots, canonicals

Une page bien écrite que Google ne peut pas indexer ne sert à rien. Les pièges les plus fréquents que je rencontre chez mes clients :

robots.txt trop large. Une règle Disallow: /wp-admin/ est normale. Une règle Disallow: / laissée par erreur après un chantier — j’en ai vu chez des sites qui s’interrogeaient sur leur absence totale des résultats depuis six mois.

Meta robots conflictuels. Certains plugins ajoutent noindex sur des pages de catégories ou de tags sans que personne ne s’en rende compte. La balise est invisible à l’œil nu dans le navigateur ; il faut l’inspecter dans le code source.

Canonicals contradictoires. Un canon pointe vers une URL, la sitemap XML en liste une autre, et la page elle-même en présente une troisième avec ou sans www, avec ou sans slash final. Google finit par choisir — mais rarement celle que vous espériez.

Paramètres d’URL non gérés. Les filtres d’un catalogue e-commerce, les paramètres de tracking, les sessions — s’ils ne sont pas filtrés dans la Search Console ou via canonical, ils créent des centaines d’URLs en doublon que Googlebot doit arbitrer seul.

Rendering JavaScript — pourquoi Vue/React/Next peuvent casser le SEO

Quand une page est construite en JavaScript côté client (React, Vue, Angular), le HTML brut renvoyé par le serveur ne contient parfois rien d’autre qu’une balise <div id="app"></div>. Tout le contenu visible est injecté par le navigateur après exécution du script.

Google exécute bien JavaScript depuis 2015, mais avec un délai. Le crawler doit d’abord télécharger la page, l’ajouter à une file de rendu, puis revenir pour exécuter les scripts — parfois plusieurs jours plus tard. Pendant ce temps, la page est indexée à moitié ou pas du tout.

Les solutions dépendent de l’architecture. Le rendu côté serveur (SSR) ou la génération statique (SSG avec Next.js, Nuxt, Astro) résolvent le problème à la source. Pour les apps existantes, le prerendering via un service tiers peut suffire. Dans tous les cas, je valide le résultat avec l’outil « Inspecter l’URL » de la Search Console, qui affiche exactement ce que Google a vu lors du dernier crawl.

Core Web Vitals 2026 — LCP, INP, CLS expliqués sans jargon

Depuis mars 2024, Google utilise trois métriques de performance comme signal de classement. Elles mesurent l’expérience ressentie par l’utilisateur réel, pas les performances en laboratoire. Voici ce que chacune signifie concrètement.

LCP — Largest Contentful Paint (chargement)

Le LCP mesure le temps qu’il faut pour que l’élément le plus large visible à l’écran soit affiché — le plus souvent une image hero ou un bloc de texte principal. En dessous de 2,5 secondes, c’est bon. Au-delà de 4 secondes, Google considère la page comme lente.

Les causes fréquentes d’un LCP dégradé : image hero non optimisée (format WebP manquant, pas de preload), hébergement mutualisé lent, pas de CDN, trop de CSS bloquant le rendu. Je mesure avec PageSpeed Insights et Lighthouse, mais je croise toujours avec les données de terrain de la Search Console — ce sont les chiffres réels, sur de vraies connexions.

INP — Interaction to Next Paint (réactivité, depuis mars 2024)

L’INP remplace l’ancienne métrique FID depuis mars 2024. Il mesure le délai entre une interaction de l’utilisateur (clic, saisie, tap) et la réponse visuelle de la page. Un bon score est inférieur à 200 millisecondes.

L’INP est difficile à diagnostiquer car il dépend du fil JavaScript principal. Trop de scripts tiers (publicités, chatbots, trackers analytiques), un gestionnaire d’événements mal optimisé, ou des animations lourdes peuvent le dégrader. Sur les sites Maroc que j’audite, les widgets de chat WhatsApp et les scripts publicitaires sont les responsables les plus courants.

CLS — Cumulative Layout Shift (stabilité visuelle)

Le CLS mesure les déplacements de mise en page inattendus — quand une image se charge et pousse le texte vers le bas, ou quand une bannière apparaît et déplace les éléments. Un score inférieur à 0,1 est acceptable.

Les causes classiques : images sans attributs width et height, polices web qui se substituent tardivement, publicités à taille dynamique. La correction est souvent simple une fois le coupable identifié.

Schema.org — les types essentiels selon votre business

Le balisage structuré (Schema.org en JSON-LD) permet à Google de comprendre la nature exacte de votre contenu et d’afficher des résultats enrichis — étoiles, FAQ déroulante, fil d’Ariane, informations produit. Ce n’est pas un facteur de classement direct, mais les rich snippets augmentent le taux de clic, ce qui améliore les signaux comportementaux.

Les types que j’implémente selon le contexte :

LocalBusiness (et ses sous-types) pour les prestataires de services locaux — adresse, horaires, zone géographique, numéro de téléphone structuré. Indispensable pour le référencement local.

FAQPage pour les pages qui répondent à des questions fréquentes — génère des accordéons directement dans la SERP et peut doubler la hauteur de votre résultat.

Article et BlogPosting pour le contenu éditorial — date de publication, auteur, image principale. Utile pour les indexeurs de contenu comme Google News.

Product avec Offer et AggregateRating pour les pages e-commerce — prix, disponibilité, note moyenne. Condition pour apparaître dans Google Shopping sans campagne payante.

BreadcrumbList pour structurer la navigation — affiche le chemin de la page directement sous le titre dans les résultats.

Je valide chaque implémentation avec le Rich Results Test de Google et le Schema Markup Validator. Un balisage incorrect peut être pire qu’aucun balisage.

Log analyzer — comprendre comment Googlebot crawle vraiment

La Search Console donne une vue partielle du crawl. Les logs serveur, eux, enregistrent chaque requête HTTP de Googlebot — avec l’URL demandée, la date, le code de réponse et le bot exact (Googlebot Desktop vs Smartphone vs AdsBot). C’est la source de vérité.

J’analyse les logs avec Screaming Frog Log Analyser ou des scripts Python selon le volume. Ce que je cherche : les URLs qui consomment du budget de crawl sans valeur (paramètres inutiles, URLs de session), les pages importantes que Googlebot ne visite pas ou visite trop rarement, les erreurs 500 intermittentes qui n’apparaissent pas dans la Search Console parce qu’elles sont trop fugaces.

Sur un site de 500 pages, il n’est pas rare de découvrir que Googlebot passe 40 % de son budget sur des URLs sans valeur — pages de filtre vides, URLs avec paramètres de tracking, versions dupliquées. Corriger ça, c’est souvent aussi efficace que d’écrire dix nouveaux articles.

HTTPS, HTTP/2, HTTP/3 — l’infrastructure compte

HTTPS est un critère de classement depuis 2014 et un prérequis absolu aujourd’hui. Mais la présence d’un certificat SSL ne suffit pas — je vérifie que toutes les URLs HTTP redirigent proprement en 301 vers HTTPS, que le certificat n’expire pas dans moins de trente jours, et qu’aucune ressource mixte (image ou script servi en HTTP sur une page HTTPS) ne génère d’avertissement dans le navigateur.

HTTP/2 et HTTP/3 permettent au serveur d’envoyer plusieurs ressources en parallèle plutôt qu’une par une. La majorité des hébergeurs modernes les supportent, mais la configuration est parfois désactivée par défaut. Avec HTTP/2, le chargement des pages riches en ressources peut être 30 à 50 % plus rapide — sans changer une ligne de code.

Je vérifie le protocole actif avec un simple en-tête HTTP et je note les opportunités dans le rapport.

Mobile-first — ce que ça veut dire concrètement en 2026

Google indexe les pages en mode mobile depuis 2019. Concrètement : si votre version mobile affiche moins de contenu que la version desktop — texte masqué derrière un onglet, images supprimées, liens manquants — c’est la version appauvrie que Google indexe et classe.

Au Maroc, plus de 75 % du trafic web est mobile. Un site conçu pour desktop d’abord laisse donc la majorité de ses visiteurs avec une expérience dégradée, et envoie à Google une version dégradée de son contenu.

Je teste la version mobile avec Chrome DevTools en émulation smartphone, et je croise avec le rapport « Convivialité mobile » de la Search Console. Les problèmes courants : texte trop petit, éléments cliquables trop proches, viewport non configuré, contenu plus large que l’écran.

Sitemap XML, IndexNow — propulser l’indexation

Le sitemap XML est la liste des URLs que vous voulez voir indexées, avec leur date de dernière modification. Ce n’est pas une garantie d’indexation — Google reste libre de ses choix — mais c’est le moyen le plus direct de signaler l’existence de vos pages.

Je vérifie que le sitemap est à jour (pas d’URLs 404 incluses, pas de pages exclues par noindex qui s’y retrouvent quand même), qu’il est soumis dans la Search Console et qu’il est référencé dans le fichier robots.txt.

IndexNow est un protocole plus récent, supporté par Bing et Yandex (et indirectement par Google via le partage de données), qui permet de notifier les moteurs en temps réel quand une page est créée ou modifiée. Sur les sites à forte fréquence de publication, c’est un gain de temps d’indexation significatif. La plupart des plugins SEO modernes (Yoast, Rank Math) l’implémentent nativement.

Le livrable — PDF 30-50 pages priorisé impact/effort

À l’issue de l’audit, je remets un PDF de trente à cinquante pages structuré pour l’action, pas pour la documentation.

Chaque problème identifié est classé selon deux axes : l’impact SEO estimé (fort / moyen / faible) et l’effort de correction (rapide / moyen / complexe). La matrice résultante définit l’ordre d’intervention : on commence par les corrections à fort impact et faible effort — souvent des erreurs de configuration qui se résolvent en quelques heures — avant de s’attaquer aux chantiers de fond.

Le rapport comporte : un résumé exécutif d’une page (pour le décideur), un tableau de bord technique (métriques clés, scores CWV, taux d’indexation), puis les fiches de problèmes détaillées avec captures d’écran, explication du problème, impact estimé et recommandation de correction précise.

Je m’assure que chaque recommandation est actionnable par votre développeur — ou par moi si vous optez pour un accompagnement complet. Le rapport n’est pas une fin en soi : c’est un plan de travail.

Pour en savoir plus sur l’ensemble de ma méthode d’audit, consultez la page Audit SEO — méthode complète. Si vous avez récemment changé d’hébergeur ou restructuré votre site, la page Migration SEO détaille les précautions spécifiques à cette étape.