Audit technique d'un site

Un audit technique de site est une vérification du fonctionnement du site « sous le capot » : vitesse et Core Web Vitals, codes de réponse du serveur (404, 5xx), redirections, robots.txt et sitemap, HTTPS, version mobile. Son but est de trouver les erreurs qui empêchent les acheteurs d'utiliser le site et les moteurs de recherche de l'explorer et de l'indexer.

En clair

Un audit technique répond à la question « le site est-il en état de marche ? ». Il n'évalue ni les textes ni le design ; il vérifie si les pages s'ouvrent vite sur un téléphone, si la mise en page « saute », si le serveur répond sans erreurs, si des liens ne mènent nulle part, si la connexion est sécurisée. Pour une boutique en ligne, c'est directement lié à l'argent : une fiche produit lente ou une erreur dans le panier sur mobile, c'est une commande perdue.

Ce qui est vérifié

1. Core Web Vitals

Les Core Web Vitals sont trois métriques de Google qui décrivent l'expérience réelle des utilisateurs (web.dev) :

Sources des seuils : LCP, INP, CLS.

Comment c'est évalué. Une page est validée si, au 75e centile des consultations de page, les trois métriques sont dans la zone verte ; les données mobile et ordinateur sont comptées séparément (web.dev). Autrement dit, ce n'est pas la meilleure expérience qui compte mais une expérience assez mauvaise : trois visiteurs sur quatre doivent obtenir « bon ».

INP au lieu de FID. L'INP succède à la métrique First Input Delay ; il est devenu un Core Web Vital stable en 2024 (web.dev, web.dev/inp).

Ce qui dégrade typiquement les métriques dans une boutique : - LCP — une grande photo principale de produit ou une bannière sur la page d'accueil. Sur une fiche produit, l'élément LCP sera le plus souvent la photo. - CLS — des images sans dimensions définies, des polices web qui s'affichent plus grandes ou plus petites que la police de secours, des widgets tiers et des publicités qui changent de taille après le chargement, du contenu inséré au-dessus de ce qui est déjà visible (une bannière « livraison gratuite » au-dessus de l'en-tête) (web.dev/cls). Les décalages survenant dans les 500 ms après une action de l'utilisateur (par exemple, le déploiement d'un filtre) ne comptent pas dans le CLS (même source). - INP — des scripts lourds : chats, outils d'analyse, widgets d'avis, filtres JavaScript complexes.

2. Codes de réponse : 404, 5xx, « soft 404 »

Comment Google traite les codes de réponse (Google Search Central) :

• 4xx (sauf 429), dont 404 et 410 — le contenu est considéré comme inexistant, la page est retirée de l'index, et l'exploration de cette adresse s'espace progressivement.
• 429 et 5xx — signal de surcharge du serveur : Google ralentit l'exploration ; si les erreurs persistent, les pages indexées finissent par sortir de l'index.
• Soft 404 — une page répond avec le code 200 mais affiche une erreur ou un contenu vide. Dans les boutiques, ce sont souvent des catégories vides et des pages de produits arrêtés.

L'audit cherche : les liens internes vers des 404, les pages en 5xx (souvent la recherche et les filtres sous charge), les soft 404.

3. Redirections

• Par défaut, Google suit jusqu'à 10 sauts de redirection (Google), mais pour les grands sites il conseille d'éviter les longues chaînes (Google, budget d'exploration).
• 301 et 308 sont un signal fort que l'adresse principale est la cible ; 302, 303 et 307 un signal faible (Google). Les déplacements définitifs (anciennes URL après un changement de plateforme) se font en 301.
• http, https, www et sans www doivent tous mener à une seule version du site.

4. robots.txt et sitemap

• robots.txt contrôle l'exploration pour que le site ne soit pas surchargé de requêtes. Il ne cache pas une page de la recherche : pour cela il faut `noindex` ou un mot de passe (Google). Vérifiez que les CSS, JS et images nécessaires au rendu ne sont pas bloqués, et que les adresses inutiles (filtres, tri, panier) le sont.
• Un sitemap est nécessaire aux grands sites, aux nouveaux sites avec peu de liens externes et aux sites avec beaucoup de vidéos ou d'images ; un site d'environ 500 pages au maximum avec un bon maillage interne peut ne pas en avoir besoin (Google). Une boutique en ligne avec un catalogue en a en général besoin.

5. Sécurité

• HTTPS sur toutes les pages, sans contenu mixte. Google recommande de servir les pages de façon sécurisée et de le vérifier dans le rapport HTTPS de Search Console (Google, expérience de page).
• Un CMS et des extensions à jour, une administration protégée, des sauvegardes. Ce ne sont pas des points de Google, mais sans eux le reste de l'audit n'a pas de sens : une boutique piratée peut diffuser du spam ou des virus.

6. Version mobile

Google indexe un site d'après sa version mobile. Les pages mobiles doivent donc contenir le même contenu principal, les mêmes données structurées (surtout Breadcrumb et Product) et les mêmes title et description que celles pour ordinateur ; un contenu qui n'apparaît qu'après un balayage, un clic ou une saisie de texte peut ne pas être vu par Google (Google, indexation mobile-first). Google conseille aussi d'éviter les fenêtres contextuelles intrusives qui recouvrent le contenu (Google, expérience de page).

Comment les différentes sources le voient

• web.dev (l'équipe de Chrome) traite les Core Web Vitals comme la qualité de l'expérience utilisateur, indépendamment du SEO.
• Google Search Central précise : les Core Web Vitals sont le seul aspect de l'expérience de page utilisé directement par les systèmes de classement ; HTTPS, l'adaptation au mobile et l'absence de fenêtres intrusives n'influencent pas directement le classement mais rendent le site plus pratique. De bons scores ne garantissent pas les premières places, et poursuivre des chiffres parfaits uniquement pour le SEO peut ne pas valoir la peine (Google).

Erreurs fréquentes

• Ne regarder que le score de PageSpeed Insights issu d'un test en laboratoire. Les seuils des Core Web Vitals sont calculés à partir de données réelles d'utilisateurs au 75e centile.
• Ne vérifier que la page d'accueil. Dans une boutique, les modèles de page comptent davantage : catégorie, fiche produit, panier, commande.
• Tester depuis le Wi-Fi du bureau sur un ordinateur portable puissant. Les acheteurs viennent de téléphones sur internet mobile.
• Bloquer des pages avec 401/403 pour réduire la charge de Googlebot. Ces codes n'affectent pas la fréquence d'exploration (Google).
• Ne pas mettre en place de 301 depuis les anciennes adresses après un passage à une nouvelle plateforme.

FAQ

Qu'est-ce qu'un audit technique de site ? Une vérification de l'état technique du site : vitesse et Core Web Vitals, erreurs serveur, redirections, robots.txt et sitemap, HTTPS et version mobile.

Quelles valeurs des Core Web Vitals sont considérées comme bonnes ? LCP jusqu'à 2,5 s, INP jusqu'à 200 ms, CLS jusqu'à 0,1 — au 75e centile des consultations de page, séparément pour mobile et ordinateur.

En quoi un audit technique diffère-t-il d'un audit SEO ? Un audit technique vérifie que le site est en état de marche. Un audit SEO comprend les points techniques qui touchent la recherche, plus le contenu, les requêtes, la structure et les liens. Voir Audit SEO d'une boutique en ligne.

Quand faire un audit technique ? Avant le lancement et après une refonte ou un passage à une nouvelle plateforme, quand le trafic ou la conversion mobile baisse, et après la connexion de nouveaux scripts tiers.

Termes associés

• Audit SEO d'une boutique en ligne
• E-commerce

Sources

• web.dev, Web Vitals — web.dev/articles/vitals
• web.dev, Largest Contentful Paint (LCP) — web.dev/articles/lcp
• web.dev, Interaction to Next Paint (INP) — web.dev/articles/inp
• web.dev, Cumulative Layout Shift (CLS) — web.dev/articles/cls
• Google Search Central, HTTP status codes, network and DNS errors — developers.google.com/search/docs/crawling-indexing/http-network-errors
• Google Search Central, Large site owner's guide to managing your crawl budget — developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget
• Google Search Central, Introduction to robots.txt — developers.google.com/search/docs/crawling-indexing/robots/intro
• Google Search Central, Sitemaps overview — developers.google.com/search/docs/crawling-indexing/sitemaps/overview
• Google Search Central, Understanding page experience — developers.google.com/search/docs/appearance/page-experience
• Google Search Central, Mobile-first indexing best practices — developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing