Un audit SEO technique ne vaut que ce qu'on en fait ensuite. Nous en voyons trop qui finissent en PDF de cent pages, jamais implémentés, pendant que le site continue de charger douze scripts analytics et trois polices inutiles. Notre méthode est pragmatique : crawl, mesures Lighthouse et Core Web Vitals, contrôle des données structurées, priorisation en lots corrigeables, puis recette chiffrée. Nous l'appliquons sur rou9e.com lui-même et régulièrement chez des clients e-commerce ou vitrine, sur des stacks variées : Magento, WordPress, Laravel, React, Svelte, Vue, Shopify. Cet article expose le déroulé et ce qu'il implique concrètement pour une boutique ou un site qui veut gagner en visibilité sans promesses magiques.
Notre audit SEO technique : ce que nous analysons et pourquoi
Nous commençons par l'inventaire : crawl Screaming Frog ou équivalent, export Search Console (couverture, Core Web Vitals, requêtes), sitemap et robots.txt, échantillon de templates critiques (accueil, catégorie, fiche produit, panier, blog). Nous vérifions indexabilité, canoniques, hreflang si multilingue, profondeur de clic, liens internes orphelins, duplication title/meta. Côté technique serveur : HTTPS, redirections en chaîne, compression Brotli ou gzip, cache, headers sécurité. Côté contenu structuré : présence et validité JSON-LD (Product, BreadcrumbList, Organization, FAQPage selon le cas). Chaque anomalie est classée impact / effort : quick wins d'abord (meta manquantes, 404 faciles, images sans alt), chantiers structurants ensuite (refonte template, purge JS). Nous ne livrons pas une liste théorique : nous attachons un propriétaire et un ordre de passage. Sur un Magento multi-store récent, cette phase a identifié plus de deux cents URLs orphelines et des canoniques contradictoires sur les déclinaisons ; sur un WordPress Elementor, c'était surtout le poids des assets. La méthode s'adapte à la stack, l'esprit reste le même.
Core Web Vitals en e-commerce : les problèmes les plus fréquents
Les Core Web Vitals (LCP, INP, CLS) sont devenus un langage commun entre SEO, dev et direction. En e-commerce, les coupables reviennent souvent. LCP : image hero non optimisée, slider lourd, police bloquante, TTFB serveur lent. INP : scripts apps Shopify ou tags GTM qui saturent le thread principal au clic "Ajouter au panier". CLS : bannière cookies, carrousel sans dimensions réservées, fonts qui reflowent la mise en page. Nous mesurons sur mobile en 4G simulée, pas sur le MacBook du développeur en fibre. Les seuils que nous visons : LCP inférieur à 2,5 s, CLS inférieur à 0,1, INP inférieur à 200 ms sur les templates à fort trafic. Sur rou9e.com, notre article PHP's Not Dead : 99/100 Lighthouse détaille comment nous sommes passés d'un score performances autour de 68 à 99 en une journée d'optimisations ciblées : suppression jQuery, PurgeCSS, lazy load, Redis, Swup pour la navigation fluide. Ce cas est volontairement extrême sur un site vitrine PHP ; chez un client Shopify chargé d'apps, gagner trente points est déjà une victoire mesurable.
Structured data et schema.org : corriger les erreurs qui coûtent des positions
Les données structurées ne garantissent pas des rich snippets, mais les erreurs schema.org peuvent bloquer l'éligibilité pendant des mois. Nous passons les URLs clés dans l'outil de test Google, puis nous corrigeons : prix et disponibilité produit cohérents avec la page, aggregateRating seulement si les avis sont réellement affichés, BreadcrumbList aligné sur le fil d'Ariane visible. Sur Shopify, le thème injecte souvent Product de base ; les lacunes viennent des variantes, des FAQ absentes ou des Organization incomplètes. Sur WordPress, les plugins SEO empilent parfois plusieurs JSON-LD contradictoires. Sur React ou Svelte en SSR, le risque est l'absence de balisage côté serveur si le schema n'est rendu qu'au hydratation client. Nous documentons un mapping template par template. Les gains ne sont pas toujours visibles en une semaine : Search Console met du temps à refléter les corrections. En revanche, les erreurs de couverture structured data disparaissent et les pages deviennent éligibles aux enrichissements lorsque le contenu le permet. Notre guide SEO Shopify et la rubrique blog SEO complètent ces chantiers par stack.
Résultats concrets : avant et après notre audit technique sur rou9e.com
Sur rou9e.com, l'audit interne a servi de laboratoire. Avant optimisations : performances Lighthouse mobile autour de 68, LCP supérieur à 10 secondes sur certaines pages chargées d'assets legacy, accessibilité autour de 76. Après cycle corrections (cache Redis, CSS purgé, JS allégé, images optimisées, Swup) : performances 99, LCP autour de 0,9 seconde, TTFB près de 32 ms, accessibilité 96. Ce n'est pas le profil d'une boutique Shopify avec quinze apps : c'est un monolithe PHP volontairement nettoyé. Chez des clients, les gains sont parfois plus modestes mais réels : sur une boutique mode Shopify, LCP passé de 3,8 à 2,1 s et conversion mobile en hausse d'une dizaine de points sur un trimestre ; sur un WordPress restaurant, Lighthouse mobile autour de 85 et meilleure visibilité locale ; sur un headless React, INP amélioré après déport des scripts tiers post-consentement. Nous ne promettons pas des positions Google : nous livrons des métriques reproductibles et un backlog priorisé. L'audit n'est utile que si les tickets qui suivent sont mergés en production.
Comment reproduire cet audit sur votre boutique Shopify ou WordPress
Vous pouvez dérouler une version allégée en interne. Semaine un : crawl + Search Console + export Core Web Vitals field data. Semaine deux : Lighthouse sur cinq templates à fort trafic, liste des scripts tiers avec poids et ordre de chargement. Semaine trois : test structured data, correction des erreurs bloquantes. Semaine quatre : recette et nouvelle mesure. Si vous manquez de bande passage dev, externalisez l'audit et gardez en interne la priorisation métier (quel template rapporte le plus). Sur Shopify, commencez par l'audit apps et le thème avant de réécrire des centaines de fiches. Sur WordPress, traitez Elementor / WooCommerce plugins comme des suspects habituels. Sur Laravel, React ou Svelte, vérifiez le SSR, le cache HTTP et la fonte des métadonnées. Nos tarifs développement sur-mesure incluent des lots audit + correctifs selon la stack. L'objectif final n'est pas un PDF : c'est un site plus rapide, mieux compris par Google, plus agréable pour l'utilisateur qui paie. Et ça, une fois qu'on a vu la différence sur une fiche produit qui convertit, on ne revient pas en arrière.
