Audit mobile (CWV + Lighthouse) — Cas butsoccers.com

← Audit SEO · Référencement web

Cas pratique d’audit externe (sans accès Search Console ni logs) sur un site média football sous WordPress : butsoccers.com. L’analyse croise Core Web Vitals (données terrain CrUX via PageSpeed Insights) et Lighthouse mobile (données labo) afin d’identifier les écarts, les freins techniques et les actions prioritaires.

Méthodologie

Audit basé sur des signaux accessibles publiquement : rapports PageSpeed Insights (CrUX + lab), Lighthouse (mobile), et lecture des causes probables (chemin de rendu, ressources bloquantes, scripts tiers, règles robots). Ce format reproduit un audit “boîte noire” : analyser l’expérience et la santé technique d’un site de l’extérieur, puis proposer un plan d’action réaliste.

1) Verdict exécutif (ce que disent vraiment les données)

PageSpeed Insights / CrUX (terrain) : Core Web Vitals validés — l’expérience réelle des utilisateurs est globalement bonne.

Lighthouse (labo) : performance mobile pénalisée — surtout par le rendu bloqué et la charge tierce (consentement, pubs, widgets), malgré un thread principal peu bloqué.

Conclusion : UX rapide ≠ site sain ≠ site indexable. Les métriques peuvent être bonnes côté utilisateur, tout en masquant des problèmes SEO techniques (403) et de conformité robots.txt.

2) Audit CWV — PageSpeed Insights (données terrain / CrUX)

Core Web Vitals : RÉUSSITE

Ces résultats indiquent une expérience mobile stable et réactive sur le terrain. Le contenu principal apparaît vite, les interactions ne sont pas ralenties, et l’interface ne “saute” pas.

Points bloquants signalés (SEO / santé technique)

Remarque : un 403 peut fausser une partie des analyses SEO/accessibilité, car l’outil peut mesurer une page d’erreur ou une réponse filtrée par un WAF/anti-bot.

3) Audit Lighthouse mobile (données labo)

Scores (mobile)

Métriques labo

Profil typique : ce n’est pas le CPU qui bloque (TBT bas), mais le réseau + le rendu bloqué par CSS/polices/tiers. Les overlays (bannière consentement) peuvent aussi gonfler le LCP en “lab” si l’élément le plus visible devient le plus grand élément mesuré.

4) Diagnostics clés (performance)

Chaîne de requêtes critiques et rendu bloqué

Plusieurs CSS (thème + plugins + librairies) sont chargées tôt. Ajout de polices externes (Google Fonts) sans préconnexion, ce qui allonge le chemin critique et retarde le rendu initial sur mobile.

JavaScript inutilisé (tiers)

Les scripts tiers (pubs/Doubleclick, widgets sociaux, consentement) représentent une part importante du JS non utilisé au rendu initial. Même si le thread principal reste relativement libre, le coût réseau et les tâches tierces dégradent le rendu et la stabilité des audits.

Images surdimensionnées

Plusieurs thumbnails sont téléchargées dans des dimensions supérieures à l’affichage. Sur mobile, cela augmente le poids transféré sans valeur visuelle, avec un impact direct sur FCP/Speed Index/LCP.

5) Problèmes techniques (bonnes pratiques)

Erreur console : type MIME CSS incorrect

Lighthouse signale une feuille CSS refusée car l’URL renvoie du HTML (type MIME text/html) au lieu de text/css. Cela indique souvent un fichier manquant, une ressource bloquée (403), une redirection, ou un plugin mal configuré.

APIs obsolètes (tiers)

Avertissements liés à des scripts publicitaires. Non bloquant, mais révélateur d’une dette technique apportée par les tiers.

6) SEO technique (exploration & indexation)

robots.txt invalide

Présence d’une directive non standard (ex. “Content-Signal…”) signalée comme inconnue. Un robots.txt doit contenir uniquement des directives reconnues, sinon il peut générer des erreurs et une interprétation incertaine.

HTTP 403 (bloquant crawl / indexation)

Un 403 sur la page testée ou certaines ressources est un problème critique : Googlebot peut être empêché d’explorer et d’indexer correctement. Les audits automatiques peuvent aussi être filtrés si le serveur/WAF bloque certains user-agents.

Meta description manquante

Signal SEO basique : ajout recommandé au niveau des gabarits (home + articles) pour améliorer la présentation et la pertinence perçue dans les SERP (sans garantir l’affichage).

Mini-rapport (problème / impact / solution)

1) Rendu bloqué par CSS, polices et chemin critique long

Problème : trop de CSS/polices chargées tôt, bloquant le rendu initial.

Impact : FCP/LCP labo élevés sur mobile, risque de dégradation en réseaux lents.

Solution : réduire les CSS au chargement initial, différer le non-critique, optimiser les polices (préconnexion / auto-hébergement / réduction des variantes).

2) Scripts tiers lourds (pubs / social / consentement)

Problème : JS tiers chargé tôt, en partie inutilisé au rendu initial.

Impact : surcharge réseau, variabilité de l’expérience, pénalités Lighthouse.

Solution : charger après consentement et/ou interaction, lazy-load des widgets sociaux, limiter le tiers “global”.

3) Erreurs techniques (403, MIME incorrect)

Problème : certaines ressources renvoient un statut/format inattendu (CSS servie en HTML).

Impact : styles non appliqués, instabilité, baisse du score “bonnes pratiques”.

Solution : corriger plugin/serveur, vérifier headers (Content-Type), purger caches, contrôler WAF/CDN.

4) robots.txt invalide

Problème : directive inconnue.

Impact : avertissements SEO, interprétation incertaine.

Solution : supprimer les directives non standards, conserver un fichier conforme (User-agent/Disallow/Sitemap).

5) Accessibilité (contraste)

Problème : contraste insuffisant sur certains éléments (notamment overlay consentement).

Impact : lisibilité réduite, risque WCAG, baisse de score.

Solution : ajuster couleurs texte/fond, vérifier focus visible et navigation clavier sur la modale.

Plan d’action priorisé

P0 — Critique (bloquant crawl / stabilité)

  1. Supprimer la directive robots.txt invalide et valider le fichier.
  2. Corriger les 403 (pages et ressources) : vérifier WAF/anti-bot, règles serveur/CDN, plugins sécurité.
  3. Corriger l’erreur MIME (CSS servie en HTML) : plugin concerné + headers + cache.

P1 — Gains rapides en performance mobile (rendu)

  1. Optimiser la bannière consentement (éviter un overlay dominant au chargement).
  2. Délayer les tiers (pubs/social) après consentement et/ou interaction.
  3. Optimiser les polices (préconnexion / auto-hébergement / variantes minimales).

P2 — Optimisation structurelle

  1. CSS critique (inline above-the-fold) + différer le reste.
  2. Images : formats WebP/AVIF + tailles adaptées (responsive).
  3. Nettoyage plugins : désactiver scripts/styles non utilisés globalement.

À retenir

Ce cas illustre un point classique : un site peut être bon en Core Web Vitals sur le terrain, tout en restant fragile en audit labo et surtout vulnérable côté SEO technique (403, robots.txt invalide, ressources mal servies). La priorité n’est pas “gagner des points Lighthouse”, mais stabiliser l’accès crawlable et réduire l’entropie (tiers/plugins).

Sources

Note : audit réalisé sans accès aux outils internes du site (Search Console, logs serveur). Les constats “crawl” et “indexation” décrivent des causes probables basées sur les rapports PSI/Lighthouse et les comportements attendus.