on répare ce qui vous freine.

Les Core Web Vitals : les trois métriques que Google regarde vraiment

Depuis 2021, Google intègre les Core Web Vitals dans son algorithme de classement. Trois métriques pèsent : le LCP (Largest Contentful Paint), qui mesure le temps de chargement du plus gros élément visible ; le CLS (Cumulative Layout Shift), qui quantifie l'instabilité visuelle ; et l'INP (Interaction to Next Paint), qui a remplacé le FID en mars 2024. Les seuils à viser : LCP sous 2,5 secondes, CLS sous 0,1, INP sous 200 millisecondes. Au-delà, votre page est étiquetée « médiocre » dans Google Search Console.

Nous mesurons ces indicateurs avec PageSpeed Insights, Lighthouse et les Web Vitals exposés dans la console Chrome. Les données de terrain proviennent du Chrome User Experience Report, agrégées sur 28 jours glissants. Le TTFB (Time to First Byte) entre aussi en jeu : un serveur lent plombe tout le reste. Sur les sites WordPress mutualisés, nous observons un TTFB médian de 800 ms à 1,4 s. Avec un hébergement adapté et un CDN, cette valeur descend sous 200 ms.

Le FCP (First Contentful Paint) et le Speed Index complètent le diagnostic. Le FCP indique quand le premier pixel utile apparaît, le Speed Index pondère la vitesse de remplissage de l'écran. Nous publions un guide détaillé sur le passage au vert des Core Web Vitals pour les PME et sur les leviers concrets de vitesse de chargement.

• ▸ LCP cible : moins de 2,5 secondes sur 75 % des sessions
• ▸ INP cible : moins de 200 ms (remplace le FID depuis mars 2024)
• ▸ CLS cible : moins de 0,1 sur l'ensemble du parcours
• ▸ TTFB cible : moins de 600 ms, idéalement sous 200 ms

Indexation et crawl : comment s'assurer que vos pages sont vues par Google

Une page non indexée ne rapporte rien, quelle que soit la qualité de son contenu. Le rapport « Couverture » de Google Search Console (GSC) reste le point de départ. Nous y identifions les URL exclues, les pages détectées mais non indexées, les erreurs de serveur et les redirections en chaîne. Sur un site PME moyen, nous trouvons entre 15 % et 40 % d'URL inutiles consommant du crawl budget pour rien : filtres à facettes, paramètres de tri, pages de recherche interne, archives de tags vides.

L'exploration se contrôle via le robots.txt, les balises meta robots et l'attribut rel=canonical. Une configuration propre du robots.txt évite les blocages accidentels, fréquents après une migration. Le sitemap.xml liste les URL prioritaires et indique les dates de dernière modification (lastmod). Nous le soumettons dans GSC et vérifions le taux d'indexation chaque semaine.

L'analyse de logs serveur complète la photo. Elle révèle ce que Googlebot crawle réellement, à quelle fréquence, et combien de temps il passe sur chaque section. Sur un site e-commerce de 5 000 URL, nous avons par exemple identifié que 62 % du crawl budget partait sur des URL paramétrées sans valeur SEO. Après nettoyage via robots.txt et canonical, l'indexation des fiches produit utiles est passée de 71 % à 94 %. Notre guide détaille les causes fréquentes de non-indexation.

Balises, schema.org et données structurées : parler le langage de l'algorithme

Chaque page a besoin d'une balise title unique de 50 à 60 caractères et d'une méta description de 140 à 155 caractères. Au-delà, Google tronque. La balise canonical déclare l'URL de référence quand plusieurs versions existent. L'attribut hreflang gère les variantes linguistiques. Sur 90 % des audits, nous trouvons des duplications de title, des méta descriptions vides ou des canonical pointant vers une 404. Notre article sur l'optimisation des balises meta title et description détaille les bonnes pratiques.

La structure des balises Hn doit refléter la hiérarchie du contenu : un seul H1 par page, des H2 pour les grandes sections, des H3 pour les sous-parties. Cette structure aide aussi l'accessibilité et les lecteurs d'écran. Le HTML doit rester sémantique : balises article, section, nav, header, footer, main. Les attributs ARIA complètent quand le HTML natif ne suffit pas. L'objectif est la conformité WCAG niveau AA, qui sert à la fois les utilisateurs et le référencement.

Les données structurées au format JSON-LD activent les rich snippets dans les résultats Google : étoiles d'avis, fil d'Ariane (breadcrumb), FAQ, prix, disponibilité. Nous implémentons les types schema.org pertinents selon l'activité : LocalBusiness, Product, Article, Service, FAQPage, Organization. Le microdata reste possible mais Google recommande désormais JSON-LD. Notre guide schema.org et JSON-LD pour PME couvre les cas concrets. Le validateur officiel de Google et le Schema Markup Validator de schema.org permettent de vérifier l'implémentation.

• ▸ Title : 50-60 caractères, mot-clé principal en début
• ▸ Méta description : 140-155 caractères, accroche avec CTA implicite
• ▸ Canonical : une seule URL de référence par contenu
• ▸ Hreflang : codes ISO corrects et auto-référencement
• ▸ JSON-LD : validé via le Rich Results Test de Google

Vitesse de chargement : où sont les vrais leviers

Les images représentent en moyenne 50 % du poids d'une page. Nous les convertissons en WebP ou AVIF, ce qui réduit le poids de 25 à 50 % à qualité visuelle équivalente. Les attributs srcset et sizes servent des résolutions adaptées à chaque appareil. Le lazy loading natif (loading="lazy") diffère le chargement des images hors écran. La compression côté serveur (Gzip ou Brotli) divise le poids des fichiers texte par 4 à 7. Brotli, plus récent, surpasse Gzip de 15 à 20 % sur HTML, CSS et JavaScript.

Le JavaScript et le CSS demandent un travail spécifique. La minification supprime espaces et commentaires. Le bundling regroupe les fichiers pour limiter les requêtes HTTP. Les scripts render-blocking, chargés en haut du document, retardent le rendu : nous les déplaçons en async ou defer quand possible. Les scripts tiers (tag manager, tracking, chat, widgets sociaux) plombent souvent l'INP. Nous auditons leur impact réel et challengeons leur nécessité au cas par cas.

Le cache navigateur, contrôlé par les en-têtes Cache-Control, évite de retélécharger les ressources stables. Un CDN (Cloudflare, Bunny, Fastly) distribue les fichiers depuis le point de présence le plus proche du visiteur. Pour la France métropolitaine, un CDN avec POP à Paris ramène la latence sous 30 ms. Les fonts demandent une attention particulière : font-display: swap évite le FOIT (Flash Of Invisible Text), le préchargement (preload) réduit le FOUT (Flash Of Unstyled Text) perçu. Notre guide vitesse de site pour PME détaille les gains par levier.

Mobile-first indexing : pourquoi votre site mobile compte plus que le desktop

Depuis 2023, Google indexe exclusivement la version mobile des sites (mobile-first indexing complet). Cela signifie que le contenu absent de la version mobile n'est pas pris en compte pour le classement. Nous vérifions systématiquement la parité de contenu, des balises meta, des données structurées et des liens internes entre versions desktop et mobile. Un site responsive bien conçu n'a normalement pas d'écart, mais les sites avec sous-domaine m.exemple.com cumulent souvent des manques.

Le test mobile-friendly de Google (intégré à PageSpeed Insights) signale les problèmes courants : viewport mal configuré, texte trop petit, cibles cliquables trop proches, contenu plus large que l'écran. Le DOM doit rester léger : sous 1 500 nœuds idéalement, sous 3 000 maximum. Un DOM massif ralentit le render et dégrade l'INP. Les frameworks JavaScript modernes (React, Vue) génèrent parfois des DOM excessifs sans précautions.

L'AMP (Accelerated Mobile Pages) a perdu son statut prioritaire dans les résultats Google depuis 2021. Nous le déconseillons aux PME : la maintenance double, les contraintes techniques sont fortes, et un site responsive bien optimisé atteint les mêmes performances. La priorité reste un responsive propre, des Core Web Vitals au vert sur mobile, et une expérience tactile soignée (tap targets de 48x48 px minimum).

HTTPS, sécurité et gestion des redirections

Le HTTPS est un prérequis depuis 2018. Un certificat SSL valide (Let's Encrypt suffit, gratuit et renouvelé automatiquement) protège les échanges et constitue un signal de confiance pour Google. Le mixed content (ressources HTTP sur une page HTTPS) bloque le cadenas vert et déclenche des avertissements dans Chrome. Nous auditons les appels d'images, scripts et iframes pour éliminer ces résidus. L'en-tête HSTS (Strict-Transport-Security) force le HTTPS sur les visites suivantes. Notre article sur l'impact SEO du HTTPS et SSL détaille les vérifications.

Les redirections 301 (permanente) transfèrent l'autorité SEO de l'ancienne URL vers la nouvelle. La 302 (temporaire) ne transfère pas et doit rester exceptionnelle. La 410 (gone) signale une suppression définitive, utile pour évacuer rapidement du contenu obsolète. Les redirections en chaîne (URL A → B → C → D) gaspillent du crawl budget et ralentissent l'utilisateur. Nous limitons à un saut maximum.

Les erreurs 404 sont normales sur un site vivant. Le problème commence quand des liens internes ou externes pointent vers ces 404 : nous les redirigeons en 301 vers la page la plus proche thématiquement, ou nous restaurons l'URL si la suppression était fortuite. Notre guide sur la gestion des erreurs 404 et des redirections 301 couvre les cas types après migration, refonte ou changement de CMS.

• ▸ Certificat SSL valide, renouvellement automatique configuré
• ▸ Aucun mixed content : audit via la console Chrome (onglet Security)
• ▸ Redirections : une seule 301, pas de chaîne
• ▸ 404 internes : zéro toléré, audit mensuel via Screaming Frog ou Sitebulb
• ▸ En-têtes de sécurité : HSTS, X-Content-Type-Options, Referrer-Policy

Architecture URL, navigation et pagination

Une URL lisible améliore le taux de clic et la compréhension par Google. Nous privilégions les slugs courts, en minuscules, séparés par des tirets, sans accents ni caractères spéciaux, sans paramètres superflus. La structure hiérarchique (domaine.fr/categorie/sous-categorie/page) facilite l'analyse thématique. Les paramètres de tri ou de filtre, quand ils n'ont pas de valeur SEO, sont neutralisés via robots.txt ou canonical vers la page parente.

Le fil d'Ariane (breadcrumb) renforce la navigation et active un rich snippet dans les résultats Google quand il est marqué en JSON-LD (BreadcrumbList). Il aide aussi l'utilisateur à se situer. La navigation principale doit rester stable, accessible au clavier, et exposer les rubriques clés en moins de trois clics depuis l'accueil. Nous vérifions la profondeur de chaque URL : au-delà de 4 niveaux, le crawl ralentit.

Pour la pagination, deux approches coexistent. La pagination classique avec liens numérotés reste la plus sûre côté SEO : chaque page est indexable, avec un canonical auto-référent. L'infinite scroll, populaire en UX, pose problème si les pages suivantes ne sont pas accessibles sans JavaScript : Google peut ne pas les voir. Nous combinons systématiquement les deux : infinite scroll côté utilisateur, liens paginés en fallback dans le HTML. Les attributs rel="next" et rel="prev" ne sont plus utilisés par Google depuis 2019, mais restent utiles pour d'autres moteurs.

Méthode d'intervention : diagnostic, quick wins, suivi

Tout démarre par un audit technique de 7 à 14 jours selon la taille du site. Nous croisons un crawl complet (Screaming Frog, Sitebulb ou OnCrawl), les données de Google Search Console (couverture, performance, Core Web Vitals), PageSpeed Insights sur un échantillon de 20 à 50 URL représentatives, et une analyse de logs sur 30 jours. Le livrable : un rapport priorisé par impact estimé sur le trafic organique, avec une cartographie des problèmes par sévérité.

La phase « quick wins » couvre les corrections à fort ROI et faible complexité : balises title et meta description manquantes ou dupliquées, images non compressées, redirections en chaîne, canonical incorrects, sitemap.xml obsolète, robots.txt mal configuré. Sur un site moyen, 15 à 25 actions tiennent dans deux à trois semaines de production. Les gains de Core Web Vitals sont mesurables sous 28 jours, le temps que le Chrome UX Report se mette à jour.

Les chantiers structurants (refonte du rendu JavaScript, migration HTTPS, restructuration des URL, refonte du schema.org) demandent 1 à 3 mois selon le CMS. Nous travaillons sur WordPress (avec ou sans Yoast / RankMath), Shopify, Webflow, PrestaShop, Magento, et sur sites sur-mesure. Le suivi mensuel post-intervention inclut un tableau de bord avec couverture GSC, Core Web Vitals, positions sur 50 à 200 mots-clés cibles, et trafic organique segmenté. Les recommandations évoluent à mesure que Google met à jour son algorithme : les rapports d'analyse signalent les écarts et proposent des ajustements chiffrés.