
Liste de contrôle de l’optimisation technique
Extraction et indexation
La première chose à examiner lors de l’audit technique est la manière dont votre site est indexé et parcouru par les moteurs de recherche. En effet, si les pages de votre site ne peuvent pas être explorées, elles ne seront pas indexées (à quelques exceptions près). Par conséquent, les pages non représentées dans l’index ne participeront pas au classement.
Consultez le rapport d’indexation des pages dans Google Search Console
La manière la plus précise et la plus fiable d’analyser l’indexation de votre site web est d’analyser le rapport d’indexation des pages dans Google Search Console. Examinez le rapport des pages indexées et vérifiez quelles pages sont dans l’index. Voyez s’il y a des pages avec des options de filtrage ou de tri, s’il y a des pages de test ou d’autres pages que vous ne voulez pas indexer. Regardez également les pages qui ont été exclues. Tous les statuts dans le rapport Pages exclues ne sont pas un problème. Vous ne devez pas concentrer votre attention sur toutes les pages exclues, mais uniquement sur celles pour lesquelles le comportement de Google ne correspond pas à vos intentions. Dans le tableau ci-dessous, vous pouvez voir les statuts qui ont tendance à nécessiter une attention et une analyse plus approfondies :
Statut | Ce qu’il signifie | Ce que vous devez faire |
---|---|---|
Erreur de redirection | Google n’a pas pu suivre l’URL en raison de problèmes de redirection. |
|
Erreur du serveur | Le serveur a renvoyé une erreur 5xx. |
|
Découvert – non indexé | Google connaît l’existence de la page mais ne l’a pas encore explorée. Indique des problèmes avec le budget d’exploration. |
|
Explorée – non indexée | Google a visité la page mais a choisi de ne pas l’indexer. Cela indique généralement une mauvaise qualité de la page. |
|
Duplicata sans canonical sélectionné par l’utilisateur | Google considère la page comme un doublon, mais vous n’avez pas spécifié d’élément canonique. |
|
Duplicata, Google a choisi un nom de page canonique différent de celui de l’utilisateur | Google n’a pas tenu compte de l’élément canonique que vous avez spécifié. |
|
404 souple | La page semble « vide » ou « introuvable », mais renvoie un statut 200 OK. |
|
Les autres statuts ne signalent probablement aucun problème. Toutefois, ces rapports méritent d’être examinés pour s’assurer que les pages n’ont pas été supprimées, redirigées, canonisées ou bloquées de l’indexation par erreur.
Statut | Ce que cela signifie | Ce que vous devez savoir |
---|---|---|
Page alternative avec balise canonique appropriée | Google a correctement reconnu la balise canonique que vous avez indiquée. |
|
URL bloquée par robots.txt | Google ne peut pas explorer la page. |
|
URL marquée « noindex | La page contient la directive noindex. |
|
Introuvable (404) | La page n’existe pas. |
|
Bloquée en raison d’une demande non autorisée (401)/ Bloquée en raison d’un accès interdit (403) | La page est bloquée par autorisation ou interdite. |
|
Page avec redirection | La page redirige vers une autre page. |
|
URL bloquée en raison d’un autre problème 4xx | La page est inaccessible en raison d’une erreur 4xx autre que 404 (par exemple, 403, 401, 410, etc.). |
|
Dans le Centre d’aide de Google, vous trouverez une description complète du rapport de page, y compris des exemples de problèmes et une explication détaillée de chaque état. Screaming Frog peut également vous aider à analyser les pages qui sont indexées ou exclues de l’index. Pour ce faire, vous devez vous connecter à l’API de la Search Console de Google avant de commencer l’exploration du site. Pour vous connecter, allez dans Configuration -> Accès API -> Google Search Console. Cliquez sur Se connecter avec Google et suivez les instructions.

Source: Screaming Frog
Une fois connecté, activez l’inspection des URL, et vous pouvez également activer l’option permettant d’ignorer l’inspection de l’indexation pour les URL qui ne peuvent pas être indexées.

Source: Screaming Frog
Vous pourrez alors voir et comparer l’état de chaque page selon la Search Console (tel que Google le voit) et son état réel tel qu’il a été déterminé au cours du processus d’exploration.

Source: Screaming Frog
Veuillez noter que seules 2000 URL par jour sont disponibles pour chaque site, cette méthode est donc plus adaptée aux petits sites.
Vérifiez le contenu de votre sitemap.xml
Sitemap.xml est un fichier XML qui fournit aux robots d’exploration des moteurs de recherche une liste des pages d’un site, ainsi que (facultativement) des informations sur leur date de dernière modification, leur fréquence de mise à jour et la priorité d’exploration recommandée. Il est généralement placé à la racine du site, par exemple : https://example.com/sitemap.xml. Sitemap.xml aide les moteurs de recherche à trouver plus rapidement les pages nouvelles ou mises à jour. En outre, l’inclusion d’une page dans ce fichier est l’un des signaux permettant de déterminer la version canonique d’une page, même s’il s’agit d’un signal faible.

Source: e-commerce sport store
Le fichier sitemap.xml est particulièrement utile pour :
- les nouveaux sites avec peu de liens externes ;
- les grands sites comportant de nombreuses pages ;
- les sites contenant beaucoup de médias ;
- les sites d’information fréquemment mis à jour.
Le fichier sitemap.xml doit contenir toutes les pages que vous souhaitez indexer. Vous pouvez utiliser le même Screaming Frog ou d’autres robots d’indexation pour analyser les pages incluses dans le fichier sitemap.xml. Dans Screaming Frog, sitemap.xml peut être analysé séparément en mode liste, ou il peut être inclus dans une analyse régulière du site. Pour ce faire, dans Configuration -> Spider -> Crawl, activez l’analyse XML sitemap et ajoutez les URL absolues des sitemaps que vous souhaitez explorer. Il n’est pas recommandé d’utiliser divers services en ligne pour générer un sitemap, car ils peuvent ne générer qu’un sitemap statique qui ne sera pas mis à jour automatiquement. La meilleure solution consiste à générer le fichier sitemap.xml à l’aide de plugins pour le système de gestion de contenu (CMS) sur lequel le site est exécuté, ou à écrire un script personnalisé qui génère le sitemap selon des conditions spécifiques et le met automatiquement à jour lorsque des modifications sont apportées au site. Lorsque vous générez le fichier sitemap.xml, assurez-vous qu’il est conforme au protocole sitemap.xml. Pour ce faire, vous pouvez utiliser divers validateurs en ligne, tels que https://www.xml-sitemaps.com/validate-xml-sitemap.html. Est-il nécessaire d’inclure toutes les balises énumérées dans le protocole ? Ce n’est pas toujours le cas. Par exemple, Google ne prend en compte que les balises <loc> et <lastmod>. Assurez-vous que la date figurant dans la balise <lastmod> est exacte. S’il y a des tentatives de manipulation, Google peut ignorer cette balise.
Veillez à ce qu’il n’y ait pas d’erreurs dans le fichier robots.txt
Le fichier robots.txt est le premier endroit qu’un robot de recherche consulte avant d’explorer un site. Il détermine quelles sections du site peuvent ou ne peuvent pas être explorées et, par conséquent, quelles pages seront indexées par les moteurs de recherche. Il doit toujours être situé à l’adresse https://example.com/robots.txt. Ce fichier permet de gérer l’exploration (et non l’indexation !) du site. Certaines pages, même si elles sont bloquées dans le fichier robots.txt, peuvent encore être indexées (généralement s’il existe des liens internes ou externes vers elles). Ces pages (indexées malgré leur blocage dans robots.txt) sont visibles dans Google Search Console dans le rapport « Indexées, bien que bloquées par robots.txt ».

Source: Search Console
Voici ce qu’il faut vérifier concernant le fichier robots.txt dans le cadre d’un audit technique de référencement :
- Disponibilité du fichier
Le fichier doit être accessible à l’adresse https://example.com/robots.txt et donner un statut de réponse 200 OK. Son absence, des erreurs de téléchargement ou des redirections (301, 302, 403, 404) peuvent empêcher les moteurs de recherche de comprendre correctement les règles d’exploration du site.
- Syntaxe et exactitude
Vérifiez que la structure du fichier respecte la norme. Exemple de modèle de base :
- User-agent : *
- Disallow : /admin/
- Autoriser : /public/
- Plan du site : https://example.com/sitemap.xml

Source: nike.com
- Directives Disallow et Allow
Vérifiez que des pages importantes ne sont pas accidentellement interdites, par exemple
- Accueil (/)
- Fiches produits (/product/)
- Blog ou articles (/blog/, /articles/)
Une erreur courante consiste à bloquer les images, les styles et les scripts lors du blocage des dossiers administratifs. Dans ce cas, il convient de préciser que même si le dossier administratif est bloqué, certains types de fichiers doivent être ouverts à l’analyse. Cela se produit souvent sur les sites WordPress lorsque le dossier contenant tout le contenu de l’utilisateur, Disallow : /Dans ce cas, seuls les fichiers d’un certain format peuvent être ouverts à l’analyse :
- Allow : /wp-content/uploads/*.css
- Autoriser : /wp-content/uploads/*.css /wp-content/uploads/*.js
- Autoriser : /wp-content/uploads/*.js /wp-content/uploads/*.jpeg
Pour valider votre robots.txt et tester les directives que vous allez ajouter, vous pouvez utiliser cet outil.
- Vérifier la compatibilité avec d’autres directives
Des erreurs se produisent souvent lorsque robots.txt entre en conflit avec :
- la balise meta <meta name= »robots » content= »noindex »>
- canonique
Par exemple, si une page est ouverte dans robots.txt mais bloquée par noindex, elle sera explorée, mais n’entrera pas dans l’index. C’est acceptable, mais il est important que cela soit fait intentionnellement. Par ailleurs, un problème courant se pose lorsqu’il y a d’autres instructions pour les robots dans le code source et un blocage simultané de la page dans robots.txt. Les robots des moteurs de recherche n’analysent pas les pages bloquées dans robots.txt. Ils ne voient pas les balises spécifiées dans le code, par exemple la canonisation. En d’autres termes, une telle canonisation ne sera tout simplement pas prise en compte.
Vérifiez vos liens internes
L’une des principales tâches d’un audit technique consiste à s’assurer que les liens internes du site fonctionnent correctement. Cela signifie que tous les liens internes doivent mener à de vraies pages existantes, ouvertes à l’indexation, renvoyant un code d’état 200 OK, ne contenant pas de redirections et, surtout, ne pointant pas vers des pages contenant des erreurs 4xx/5xx. À première vue, cela peut sembler un détail mineur, mais dans la pratique, même des liens internes incorrects peuvent avoir un impact négatif :
- L’efficacité de l’exploration du site web par les moteurs de recherche,
- La distribution du poids SEO interne (PageRank),
- l’expérience de l’utilisateur.
La première étape de l’analyse consiste à vérifier que tous les liens internes ne comportent pas d’erreurs. Il est particulièrement important d’identifier les liens rompus qui mènent à des pages comportant une erreur 404, 410 ou d’autres erreurs (telles que 403, 500). Le tableau ci-dessous présente les principaux types d’erreurs qui peuvent se produire dans les liens internes, leur signification et les actions recommandées pour les corriger.
Type d’erreur | Signification | Ce qu’il faut faire |
---|---|---|
404 | Page non trouvée | Supprimez le lien ou remplacez-le par un lien fonctionnel. |
403 | Accès interdit | Vérifier les paramètres d’accès |
301/302 | Redirection | Mettre à jour le lien vers l’URL final |
5xx | Erreur de serveur | Vérifier le serveur ou le CMS |
Il est également important d’analyser la profondeur de la hiérarchie des pages, c’est-à-dire de déterminer à quel niveau et à combien de clics de la page d’accueil se trouve le contenu clé. Il est préférable que les pages importantes ne soient pas plus profondes que le troisième niveau – cela augmente leur accessibilité à la fois pour les moteurs de recherche et les utilisateurs. L’un des éléments clés de l’analyse est l’identification des pages « orphelines » – celles qui n’ont pas de liens internes pointant vers elles. Même si ces pages sont incluses dans le plan du site, l’absence de liens internes les rend moins accessibles. En outre, il est important d’analyser les textes d’ancrage, c’est-à-dire les mots et les phrases qui contiennent les liens. Ils doivent être pertinents et significatifs, car les textes d’ancrage aident les moteurs de recherche à comprendre le contexte du lien.
Analyser les statistiques d’exploration
L’analyse des statistiques de navigation est un moyen de comprendre comment Googlebot interagit avec un site : quelles pages sont explorées, à quelle fréquence, et comment cela affecte le référencement. Ces données sont disponibles dans Google Search Console → Paramètres → Statistiques de crawl. Dans le tableau ci-dessous, vous pouvez voir les problèmes les plus courants que vous pouvez trouver dans ce rapport :
Problème | Ce qu’il faut rechercher dans le rapport | Causes possibles |
---|---|---|
Forte diminution de l’exploration | Moins d’explorations par jour | Problèmes d’accessibilité, paramètres incorrects dans robots.txt, blocages, erreurs 5xx |
Nombreuses erreurs 4xx et 5xx | Erreurs dans les URL | Pages supprimées, liens brisés, problèmes de serveur |
Augmentation du temps de réponse | >1 seconde – un signe d’alerte | Problèmes d’hébergement, surcharge du serveur |
Nombreuses redirections 3xx | Redirections au lieu d’URL directes | Redirections incorrectes, chaînes de redirections, grand nombre de liens internes avec redirections |
CSS/JS non explorés | Ils sont absents des statistiques | bloqués par robots.txt |
En outre, les journaux du serveur peuvent être analysés. Ils vous permettent de voir les requêtes réelles des robots de recherche (non seulement Googlebot mais aussi Bingbot, YandexBot, et d’autres), plutôt que les données agrégées de Google Search Console. Il s’agit d’une méthode de diagnostic avancée, « brute », qui nécessite beaucoup de temps. Pour visualiser les données, vous pouvez utiliser des outils open-source comme GoAccess ou Screaming Frog Log File Analyser.
Mettre en œuvre des données structurées
Les données structurées sont un format de balisage spécial sur une page web qui aide les moteurs de recherche à comprendre le contenu de la page de manière plus précise et plus approfondie. Elles servent d' »indice » à Google et aux autres moteurs de recherche pour savoir ce que contient exactement la page – un article, un produit, une recette, une critique, une vidéo, etc. Bien qu’il ne s’agisse pas d’un signal de classement officiel, il influe indirectement sur le classement en améliorant la façon dont les moteurs de recherche comprennent la page. La principale norme ou le principal protocole utilisé pour les données structurées sur les sites web est Schema.org. Il existe d’autres protocoles, comme OpenGraph, mais il est utilisé pour les réseaux sociaux. Schema.org est un projet collaboratif de Google, Microsoft, Yahoo et Yandex, créé pour développer et maintenir une norme unifiée pour les données structurées sur le web. Schema.org comprend des centaines de types d’entités, dont les plus couramment utilisés sont répertoriés dans le tableau ci-dessous :
Catégorie | Entité (@type) | Objectif |
---|---|---|
Contenu et pages | Article | Un article ou un contenu d’actualité |
BlogPosting | Un billet de blog | |
Article d’actualité | Un article d’actualité pour Google News | |
Page FAQ | Une page de questions fréquemment posées (FAQ) | |
HowTo | Un guide étape par étape | |
Page Web | Informations générales sur une page web | |
Produits et offres | Produit | Description du produit |
Offre | Offre de prix | |
Offre globale | Fourchette de prix pour un produit proposé par différents vendeurs | |
Critiques et évaluations | Évaluation | Une évaluation d’un produit ou d’un service |
Note | Une note numérique (souvent au sein d’un avis) | |
Note globale | Note moyenne basée sur plusieurs commentaires | |
Organisations et personnes | Organisation | Description d’une entreprise ou d’une marque |
Entreprise locale | Une entreprise locale avec ses coordonnées et ses horaires | |
Personne | Une personne (par exemple, un auteur d’article, un conférencier, etc.) | |
Evénements | Événement | Un événement en ligne ou hors ligne |
Navigation et structure | Liste de fils d’Ariane | Navigation en fil d’Ariane |
SiteNavigationElement | Éléments du menu principal | |
Multimédia | Objet vidéo | Vidéo avec métadonnées (pour les extraits vidéo) |
ImageObject | Image avec description | |
Formation et emploi | Cours | Un cours en ligne ou un programme de formation |
Offre d’emploi | Offre d’emploi (pour Google for Jobs) |
Il est recommandé de mettre en œuvre des données structurées au format JSON-LD. Ce bloc est placé dans le <head> ou le <body> du document HTML, mais il n’est pas affiché à l’utilisateur – il est lu par les robots de recherche. Tous les principaux moteurs de recherche, tels que Google, Bing et Yahoo, prennent en charge ce format. Un exemple de code JSON-LD est présenté ci-dessous : <script type= »application/ld+json »> { « @context » : « https://schema.org », « @type » : « Article », « headline » : « Qu’est-ce que JSON-LD ? », « author » : { « @type » : « Person », « name » : « John Smith » }, « datePublished » : « 2025-12-01 » } </script> Lorsque vous mettez en œuvre des données structurées, suivez le protocole Schema.org et utilisez le validateur pour vérifier l’exactitude des types de microdonnées mis en œuvre.Certains types de données structurées du protocole Schema.org peuvent également contribuer à l’affichage de rich snippets dans les résultats de recherche Google. Notez que les exigences de Google en matière de données structurées pour les rich snippets diffèrent légèrement de la norme Schema.org. Souvent, il est nécessaire de spécifier davantage de champs que ce que le protocole Schema.org exige. Par conséquent, si vous souhaitez obtenir un Rich Snippet, suivez les directives de Google en matière de données structurées. Vous pouvez vérifier l’exactitude de l’implémentation des microdonnées à l’aide du validateur de rich snippet. Il existe également de nombreux générateurs de microdonnées, mais ils ne peuvent créer qu’un code statique qui ne sera pas mis à jour en fonction des modifications apportées au contenu de la page. S’assurer que les informations contenues dans les microdonnées correspondent à ce qui est visible par les utilisateurs sur la page fait partie des exigences de Google en matière de données structurées. En cas de violation des règles relatives aux données structurées, la page risque de perdre tous les rich snippets et, dans certains cas, de faire l’objet de sanctions manuelles. Assurez-vous donc que vos microdonnées sont générées et mises à jour automatiquement.
Contenu
Dans le cadre d’un audit SEO technique, il est important d’évaluer les caractéristiques de base du contenu : de la structure des titres et des balises méta à la présence d’attributs alt pour les images et les pages dupliquées potentielles. Ces éléments ont une incidence directe sur l’indexation et la perception du site par les moteurs de recherche.
Testez votre site web pour détecter les doublons complets
Il y a duplication complète lorsqu’un contenu identique est accessible par différentes URL sur le site. Les duplicatas peuvent complètement nuire au classement de votre site. Les types de duplicatas les plus courants sont les suivants :
- Accessibilité via HTTP et HTTPS
- Accessibilité avec et sans WWW
- Accessibilité avec ou sans barre oblique finale
- Accessibilité des URL en majuscules et en minuscules
- La page est accessible avec des extensions de fichier telles que .html, .htm, .php, .aspx, et sans elles.
- les paramètres qui ne modifient pas le contenu de la page, tels que les balises UTM
- un contenu identique sous différentes URL. Par exemple, un produit est répertorié dans deux catégories, accessibles via deux URL différentes. Ou bien la page du produit est accessible avec et sans la catégorie dans l’URL.
- Versions de test du site (domaine DEV utilisé pour le développement).
Pour trouver des pages dupliquées liées à des variations d’URL, testez les URL manuellement et vérifiez le code de réponse du serveur pour ces variantes d’URL. Vous pouvez utiliser n’importe quel outil pour vérifier les codes de réponse du serveur, tel que https://httpstatus.io/. Saisissez les variations d’URL et vérifiez leur accessibilité.

Source: httpstatus.io/ website + test of a client’s website
Pour résoudre les problèmes liés aux variantes HTTP/HTTPS, www/sans-www, avec/sans barre oblique, majuscules/minuscules, et à l’accessibilité des pages avec des extensions telles que .html, .htm, .php, .aspx, et sans extension, il est nécessaire de mettre en place une redirection 301 vers la version préférée. Lorsque des doublons sont détectés en raison de la disponibilité d’un contenu identique en ajoutant ou en supprimant des parties de l’URL (par exemple, un produit est disponible dans deux catégories), il est préférable de reconsidérer la structure de l’URL et la structure du site. Pour les paramètres UTM et autres, la canonicalisation peut également être une solution. Toutefois, il est important de noter que Google considère la balise canonique comme une recommandation et que la décision finale quant à l’URL à choisir revient à Google. Si une version test du site est trouvée dans l’index de Google, elle doit être bloquée de l’indexation et une demande de suppression doit être envoyée via la Search Console de Google.
Résoudre les doublons partiels
Il y a duplication partielle d’une page lorsque deux pages ou plus du site ont un contenu très similaire, mais pas complètement identique. Les types de doublons partiels les plus courants sont les suivants :
- Pages de tri
- Pages de filtrage
- Pages de pagination
- Pages contenant des produits similaires (par exemple, les produits ne diffèrent que par leur couleur)
- Plusieurs versions du site dans la même langue, mais pour des régions différentes (par exemple, trois sites en anglais pour les États-Unis, le Royaume-Uni et l’Australie).
Bien entendu, chaque site est unique et, au cours d’un audit technique, vous pourrez identifier d’autres cas de contenu dupliqué nécessitant des solutions spécifiques. Toutefois, les exemples ci-dessus sont les plus courants. Les doublons partiels sont généralement découverts au cours du processus d’exploration du site par différents robots d’exploration. Pour éliminer les doublons partiels, vous ne pouvez pas mettre en place de redirection, car ces pages sont nécessaires à la fonctionnalité du site. Nous examinerons ci-dessous les méthodes permettant de traiter les doublons partiels.
Trier et filtrer les pages
Ces pages peuvent être bloquées dans le fichier robots.txt, même si Google n’en tient pas compte, surtout si des liens pointent vers ces pages. Vous pouvez également les bloquer via la directive <meta name= »robots » content= »noindex, nofollow » />, qui empêchera l’indexation de ces pages mais n’indiquera pas à Google qu’elles ne doivent pas être explorées. La meilleure approche dans ce cas est d’utiliser JavaScript pour mettre à jour le contenu de la page lorsque l’utilisateur applique un tri ou un filtre, sans générer d’URL et de liens supplémentaires vers les pages de filtrage ou de tri.
Variantes de produits disponibles à différentes URL
Idéalement, toutes les variantes de produits devraient être regroupées sur une seule page, où l’utilisateur peut sélectionner la couleur ou la taille souhaitée sans modifier l’URL, à l’aide de JavaScript. Toutefois, si une page distincte est utilisée pour chaque variante, un lien canonique vers la page principale du produit doit être spécifié. Toutefois, comme indiqué précédemment, Google peut ignorer le lien canonique défini par l’utilisateur.
Pages de pagination
Les pages de pagination ne doivent pas être exclues de l’indexation. Pour s’assurer que Google considère la première page de la catégorie comme la page principale :
- N’incluez que la première page dans le fichier sitemap.xml.
- Ajoutez un lien vers la page principale de la catégorie sur toutes les pages de pagination.
- Ajoutez des numéros de page au titre et à la page H1 des pages de pagination. Par exemple, « Chemises blanches – Page 2 ».
Pages disponibles dans une langue mais pour des régions différentes
Dans ce cas, il convient d’utiliser les attributs Hreflang. Ils servent à indiquer aux moteurs de recherche la langue et la version régionale d’une page web qu’ils doivent afficher aux utilisateurs en fonction de leur préférence linguistique et de leur localisation. Il existe plusieurs façons de mettre en œuvre les attributs Hreflang :
- Dans les en-têtes HTTP
- Via les balises de la section <head>.
- Via des balises dans sitemap.xml
La méthode la plus simple consiste à utiliser des balises dans la section <head>. Les attributs hreflang mis en œuvre via des balises dans la section <head> doivent respecter certaines règles :
-
- L’attribut doit avoir le format suivant : <link rel= »alternate » hreflang= »lang_code_country_code » href= »url-of-page » />
- Les codes de langue et de pays doivent être valides. Pour choisir le code valide pour chaque mutation linguistique, veuillez consulter cette page.
- Chaque version linguistique doit se lister elle-même ainsi que toutes les autres versions linguistiques dans ses attributs hreflang. Cela signifie que chaque page doit avoir le même nombre d’attributs hreflang.
- Les liens dans les attributs hreflang doivent être absolus et indexables.
Exemple de code : <link rel= »alternate » href= »https://example.com/en-us/page » hreflang= »en-us » /> <link rel= »alternate » href= »https://example.com/en-gb/page » hreflang= »en-gb » /> <link rel= »alternate » href= »https://example.com/en-us/page » hreflang= »x-default » />
Vérifier les titres, les h1, les h2 et les descriptions pour détecter les doublons
Bien que les titres, les descriptions et les en-têtes H1-H6 soient liés au référencement sur la page, leur analyse dans le cadre d’un audit technique peut être utile pour détecter les doublons. Pour les analyser, vous pouvez utiliser n’importe quel robot d’exploration qui collecte ces balises. Lorsque vous trouvez des titres, des balises H1-H6 et des descriptions en double, analysez les données de la page et identifiez la cause de la duplication. Cela peut être dû à la disponibilité du site via HTTP et HTTPS, à la duplication des balises de la catégorie principale sur les pages de filtrage, ou simplement à une erreur humaine où ces balises ont été incorrectement remplies.
Optimiser les attributs alt des images
Les attributs Alt sont des attributs HTML utilisés à l’intérieur de la balise <img> comme ceci : <img src= »image.jpg » alt= » Description de l’image »>. Son objectif principal est de fournir une description textuelle du contenu de l’image. Ce texte s’affiche si l’image ne se charge pas et est lu à haute voix par les lecteurs d’écran pour aider les utilisateurs malvoyants. Un texte alt approprié et descriptif peut aider vos images à se classer dans la recherche d’images et améliorer la pertinence globale de la page. Si vous avez un site web avec beaucoup de contenu visuel, l’optimisation des attributs alt est une étape plus importante que pour les sites web classiques qui reposent sur du contenu textuel. De nombreux robots d’indexation comme Screaming Frog, Ahrefs, SemRush, etc. analysent les attributs alt, et vous pouvez y obtenir des données sur les attributs alt manquants ou vides. Vous pouvez en savoir plus sur la création d’attributs alt descriptifs dans les documents officiels de Google.
Vitesse, mobilité et convivialité du site web
Utiliser le protocole HTTP
L’utilisation du protocole sécurisé HTTPS est essentielle pour garantir la sécurité de la transmission des données entre l’utilisateur et le serveur. Il permet non seulement d’accroître la confiance des utilisateurs, mais a également un impact positif sur le référencement. Pour vérifier la présence du protocole HTTPS, il suffit de regarder la barre d’adresse du navigateur – une icône de cadenas doit apparaître. Pour une analyse plus détaillée, vous pouvez utiliser le service SSL Labs, qui fournira un rapport complet sur l’état du certificat SSL et identifiera tout problème potentiel. Il est également important de s’assurer qu’il n’y a pas de contenu mixte – des ressources HTTP sur des pages HTTPS. Pour cette analyse, vous pouvez utiliser le rapport HTTPS dans Google Search Console, qui montrera les URL avec à la fois HTTP et HTTPS.

Source: Search Console
Source : Google Search Console de notre client : Search Console de notre client
Améliorer Core Web Vitals
Core Web Vitals est un ensemble de mesures proposées par Google pour évaluer la qualité de l’expérience utilisateur sur un site web. Ces indicateurs se concentrent sur la vitesse de chargement, l’interactivité et la stabilité visuelle du contenu de la page. Elles comprennent trois indicateurs clés :
Indicateur | Description | Valeur optimale |
---|---|---|
Plus grand tableau de contenu (LCP) | Mesure le temps de chargement du plus grand élément visible de la page (image ou texte, par exemple). | Moins de 2,5 secondes |
Délai de première entrée (FID) | Mesure le temps nécessaire à la page pour répondre à la première interaction de l’utilisateur (par exemple, cliquer sur un bouton ou un lien). | Inférieur à 100 millisecondes |
Décalage cumulatif de la mise en page (CLS) | Évalue la stabilité visuelle de la page, c’est-à-dire l’ampleur du déplacement des éléments pendant le chargement de la page. | Inférieur à 0,1 |
Les données recueillies auprès d’utilisateurs réels peuvent être consultées dans le rapport « Core web vitals » de la Search Console (données agrégées) ou dans PageSpeed Insights (pour les tests individuels). Lorsque vous travaillez sur Core Web Vitals, gardez à l’esprit que vous devez définir les problèmes qui ont une grande influence sur les métriques CWV. Par exemple, lors de l’optimisation de LCP, vous devez définir lequel des 4 aspects (TTFB, Load Delay, Load Time, ou Render delay) contribue le plus à un score LCP élevé. Dans l’exemple ci-dessous, il est visible que nous n’avons pas besoin de nous concentrer sur l’optimisation du TTFB ou du Load Time. Au lieu de cela, nous pouvons consacrer toute notre énergie à l’amélioration du délai de chargement, puis du délai de rendu.

Source: pagespeed.web.dev
Source : https://pagespeed.web.dev/ – test du sitenike.com (à titre d’exemple). Le domaine est flou
Veillez à ce que votre site soit adapté aux mobiles
La convivialité mobile est devenue un facteur crucial depuis 2018, lorsque Google est passé à une approche d’indexation mobile-first. Cela signifie que Google utilise désormais principalement la version mobile d’un site web pour le classement et l’indexation, plutôt que la version de bureau. Dans Google Search Console, vous pouvez tester vos pages en cliquant sur « Tester l’URL en direct » dans l’outil d’inspection d’URL et voir comment Googlebot-Mobile la voit.
Compression des images
L’optimisation des images visant à les compresser sans perte de qualité permet d’accélérer le chargement du site web, surtout si les pages contiennent beaucoup de contenu graphique. Des outils en ligne tels que TinyPNG ou Squoosh peuvent être utilisés pour compresser les images. Il convient également de vérifier si les formats d’image modernes, tels que WebP, sont utilisés, car ils permettent de réduire considérablement la taille des fichiers.
Utiliser un CDN pour les sites web internationaux
L’utilisation d’un CDN est judicieuse si votre site web dessert un grand nombre de régions géographiquement éloignées. Un CDN (Content Delivery Network) distribue le contenu du site sur des serveurs situés plus près des utilisateurs, ce qui réduit le temps de latence lors du chargement. Vous pouvez vérifier l’utilisation d’un CDN en examinant les en-têtes des requêtes HTTP dans les outils de développement du navigateur (onglet Réseau), où des références au fournisseur de CDN, comme Cloudflare ou Akamai, peuvent apparaître. Il existe également des outils en ligne pour tester les CDN. La configuration du CDN s’effectue généralement via le panneau d’hébergement ou le CMS. Utiliser la mise en cache La mise en cache permet aux navigateurs et aux serveurs proxy de stocker des copies des ressources, ce qui réduit la charge du serveur et accélère le chargement lors des visites suivantes. Vous pouvez vérifier l’exactitude de la mise en cache dans les outils de développement du navigateur – dans la section Réseau, vérifiez les en-têtes Cache-Control, Expires et ETag. Google PageSpeed Insights fournit également des recommandations pour la mise en cache. Il est important que les ressources statiques (images, scripts, styles) soient correctement mises en cache et que les règles correspondantes soient configurées sur le serveur (par exemple, dans la configuration .htaccess ou nginx). Pour vérifier la mise en cache, vous pouvez utiliser des services en ligne comme GiftOfSpeed.
Conclusion
L’audit technique d’un site web n’est pas une procédure ponctuelle, mais un processus continu qui nécessite une attention régulière aux facteurs techniques susceptibles d’influer sur ses performances et sa visibilité. Comme chaque site web est unique, l’objectif spécifique et la fréquence des vérifications varieront. Cette liste de contrôle pour un audit technique de référencement vous aidera à vous assurer que vous n’avez rien oublié d’important.