Indexation et crawl : ce que Google peut ou ne peut pas voir
Avant d'optimiser quoi que ce soit, Google doit pouvoir accéder à vos pages. Un fichier robots.txt mal configuré ou une directive noindex erronée peut exclure silencieusement des pans entiers de votre site de l'index — sans aucun message d'erreur visible.
Le sitemap XML est le document de navigation que vous tendez aux crawlers. S'il contient des URLs canonicalisées vers d'autres pages, des redirections ou des pages exclues par noindex, il crée une contradiction que Google résout à son avantage, pas nécessairement au vôtre. La cohérence entre robots.txt, sitemap et balises canoniques est un prérequis, pas un détail.
- robots.txt. Vérifier qu'aucune section stratégique (pages de catégorie, pages produit) n'est bloquée par erreur.
- Sitemap XML. Uniquement les pages indexables, accessibles et canoniques sur elles-mêmes. Soumis dans Google Search Console.
- Balises noindex. Auditer les pages en production portant noindex : pages de panier, paramètres UTM, doublons de facettes.
- Balises canoniques. Chaque page doit se pointer elle-même ou la version de référence. Les canoniques vers des redirections créent des boucles d'interprétation.
Core Web Vitals et performance : les seuils qui comptent
Depuis le déploiement du Page Experience Update, les Core Web Vitals sont un signal de classement explicite. LCP (Largest Contentful Paint), INP (Interaction to Next Paint) et CLS (Cumulative Layout Shift) mesurent respectivement le chargement perçu, la réactivité et la stabilité visuelle. Google utilise les données du Chrome User Experience Report (CrUX) — ce sont vos vrais utilisateurs, pas des tests de laboratoire.
Un LCP supérieur à 2,5 secondes est le problème le plus fréquent et le plus pénalisant. Ses causes habituelles : image de héros non préchargée, polices bloquantes, TTFB élevé dû à un serveur sous-dimensionné ou à l'absence de cache. Un CLS non nul indique souvent des images sans dimensions déclarées ou des injections de bannière au chargement.
- LCP ≤ 2,5 s. Précharger l'image principale (fetchpriority="high"), éviter les chaînes de redirection, activer le cache serveur.
- INP ≤ 200 ms. Réduire les tâches JavaScript longues, différer les scripts tiers non critiques.
- CLS ≤ 0,1. Déclarer width/height sur toutes les images et iframes, éviter les contenus injectés après le rendu.
- Compression et formats modernes. WebP ou AVIF + compression adaptée réduisent le poids sans dégrader la qualité perçue.
Balises title, meta description et Hn : ce que Google lit en premier
La balise title est le premier signal sémantique lu par Googlebot et le premier élément affiché dans les SERPs. Elle doit contenir le mot-clé principal, rester sous 60 caractères et être unique sur l'ensemble du site. Les doublons de titles sont un problème de priorité : Google choisira lui-même laquelle afficher, et pas toujours à votre avantage.
La meta description n'est pas un signal de classement direct, mais elle influence fortement le taux de clic (CTR) qui, lui, l'est. Une description entre 140 et 160 caractères, formulée comme un argument plutôt qu'un résumé, améliore le CTR organique de façon mesurable. Les pages sans meta description laissent Google construire un extrait automatique souvent tronqué et peu accrocheur.
La hiérarchie des balises Hn (H1 unique par page, H2/H3 pour les sous-sections) est à la fois un signal de structure sémantique pour les crawlers et un repère d'accessibilité pour les lecteurs d'écran. Un H1 absent ou dupliqué, des H2 utilisés comme titres décoratifs : ces patterns sont fréquents et corrigibles rapidement.
- Title ≤ 60 car., unique. Mot-clé principal en début de balise. Aucune duplication entre pages.
- Meta description 140-160 car.. Argument de clic, pas résumé. Unique par page.
- H1 unique par page. Distinct du title, contenant une variante sémantique du mot-clé principal.
Structure et maillage interne : guider le PageRank
Le maillage interne est la façon dont vous distribuez l'autorité entre vos pages. Une page orpheline — accessible uniquement via sitemap, sans lien entrant depuis une autre page du site — reçoit peu de PageRank et sera crawlée moins fréquemment. Les pages les plus importantes de votre site (catégories, landing pages, guides piliers) doivent être accessibles en 3 clics maximum depuis la page d'accueil.
Les liens internes doivent utiliser des ancres descriptives plutôt que génériques (« en savoir plus », « cliquez ici »). Ces ancres constituent un signal sémantique supplémentaire sur le contenu cible. Évitez les redirections en chaîne dans les liens internes : chaque saut supplémentaire dilue le PageRank transmis et ralentit le crawl.
- Profondeur de crawl ≤ 3 clics. Toute page stratégique doit être accessible depuis l'accueil en moins de 4 niveaux.
- Ancres descriptives. L'ancre du lien interne décrit le contenu cible — jamais « ici » ou « en savoir plus ».
- Zéro page orpheline. Chaque page indexée doit recevoir au moins un lien interne depuis une page de même niveau ou supérieure.
Schema.org et données structurées : déclencher les rich results
Les données structurées (JSON-LD) permettent à Google de comprendre sans ambiguïté ce que représente une page : un article, une fiche produit, une FAQ, un LocalBusiness, un événement. Elles déclenchent des rich results dans les SERPs — étoiles, prix, disponibilité, horaires — qui augmentent le CTR sans nécessiter de montée en position.
L'erreur la plus fréquente n'est pas l'absence de données structurées, mais leur incohérence avec le contenu visible : une note de 4,8 dans le JSON-LD alors que les avis affichés sur la page donnent 3,9, ou un prix en JSON-LD différent du prix affiché. Google valide la cohérence et peut supprimer les rich results si l'écart est jugé trompeur.
- Article / BlogPosting. datePublished, dateModified, author, image. Requis pour l'éligibilité aux Top Stories.
- LocalBusiness. Nom, adresse, téléphone, horaires, geo. Renforce la cohérence NAP et l'éligibilité au Knowledge Panel.
- FAQPage. Chaque paire question/réponse visible sur la page. Déclenche l'affichage de l'accordéon dans les SERPs.
- AggregateRating. Cohérence obligatoire entre JSON-LD et avis affichés. Google vérifie l'alignement.
Mobile-first et HTTPS : les prérequis non négociables
Google indexe en mode mobile-first : c'est la version mobile de votre site qui détermine votre classement, même pour les requêtes sur desktop. Un contenu masqué sur mobile (onglets non indexables, accordéons bloquant le texte) ou des images non adaptées aux écrans retina pénalisent directement votre visibilité.
HTTPS est un signal de classement depuis 2014 et un prérequis de confiance utilisateur. Un certificat expiré ou mal chaîné déclenche des avertissements navigateur qui font fuir les visiteurs avant même que votre contenu soit vu. Les contenus mixtes (ressources HTTP sur une page HTTPS) annulent partiellement la protection et génèrent des avertissements de sécurité.
- Viewport configuré. Balise meta viewport présente. Texte lisible sans zoom. Boutons cliquables sans précision.
- HTTPS valide. Certificat non expiré, chaîne de certification complète, aucune ressource HTTP sur les pages HTTPS.
- Redirections propres. HTTP → HTTPS en 301 permanent, www/non-www unifié. Pas de chaînes de redirections.
- En-têtes de sécurité. HSTS, X-Content-Type-Options, X-Frame-Options — signaux de confiance pour les crawlers et les utilisateurs.
Comment AudiScale corrige automatiquement ces 12 points
AudiScale audite l'ensemble de ces 12 dimensions à chaque analyse et produit un score par bloc. Les problèmes sont classés par impact potentiel sur votre visibilité — pas par facilité de correction — ce qui vous évite de passer du temps sur des optimisations marginales pendant que des blocages critiques restent ouverts.
Pour chaque problème détecté, l'agent opérateur de AudiScale propose un correctif concret et exécutable : correction du robots.txt, injection de balises title manquantes via snippet, ajout de données structurées JSON-LD, redirection HTTP→HTTPS. Vous validez l'action, AudiScale l'applique via le canal adapté (snippet, WordPress, pull request GitHub) et re-mesure l'impact.
La checklist n'est pas un état figé : AudiScale la rejoue après chaque exécution et met à jour votre score en temps réel. Vous passez d'un audit annuel fastidieux à un suivi en continu, sans charge manuelle supplémentaire.