L'essentiel
Google ne note pas la beauté d'un site, et sa documentation précise qu'il cherche toujours à afficher le contenu le plus pertinent, même quand l'expérience de page est médiocre. Le design pèse pourtant sur le référencement par trois voies documentées. Les Core Web Vitals, que Google indique utiliser dans ses systèmes de classement, dépendent presque entièrement de choix de conception, image d'en-tête, polices, carrousels, éléments qui bougent au chargement. L'indexation ne se fait plus que sur la version mobile depuis juillet 2024, donc ce qui n'existe pas sur mobile n'existe pas pour Google. Et la lisibilité de la structure décide de ce que Google, et désormais les moteurs de réponse, arrivent à extraire d'une page. Le reste, couleurs, animations, esthétique, n'a aucun effet mesuré.
Google mesure la vitesse, pas la beauté
Les algorithmes de Google ne voient ni vos couleurs ni votre typographie. Ils mesurent en revanche, sur des utilisateurs réels de Chrome, le temps que met le plus grand élément visible à s'afficher, le délai de réaction de la page quand on la touche, et l'ampleur des déplacements d'éléments pendant le chargement. Ce sont les trois Core Web Vitals, et Google écrit noir sur blanc qu'ils sont utilisés par ses systèmes de classement, tout en précisant qu'il n'existe pas de signal unique d'expérience de page et que la pertinence du contenu passe avant.
Une idée reçue mérite d'être écartée. Le taux de rebond et le temps passé sur une page, tels que les mesure Google Analytics, ne sont pas des signaux de classement, et Google l'a répété à de nombreuses reprises. Ce que les documents du procès antitrust américain de 2023 ont montré, c'est l'usage des clics sur la page de résultats elle-même, par un système nommé Navboost. Un visiteur qui revient aussitôt aux résultats pour cliquer ailleurs envoie donc probablement un signal, mais son poids n'est pas connu, et il ne se travaille pas directement. Un design qui fait fuir en trois secondes a des effets certains sur vos ventes, et des effets seulement plausibles sur vos positions.
Les décisions de design qui font les Core Web Vitals
Les trois métriques ont des seuils publics. Le LCP, affichage du plus grand élément, doit rester sous 2,5 secondes. L'INP, délai de réaction à une interaction, sous 200 millisecondes. Le CLS, déplacement cumulé des éléments, sous 0,1. Ces seuils s'évaluent au 75e centile des visites réelles, ce qui veut dire qu'il faut les tenir pour les trois quarts des visiteurs, y compris ceux sur un téléphone d'entrée de gamme en 4G. Presque tout ce qui les dégrade se décide à la maquette.
| Choix de design | Métrique touchée | Ce qui se règle à la conception |
|---|---|---|
| Grande image ou vidéo d'en-tête | LCP | C'est presque toujours l'élément le plus grand de la page. Une image de 2 400 pixels en JPEG de 800 Ko, ou une vidéo en lecture automatique, condamne le LCP quoi qu'on fasse ensuite. Prévoir une image dimensionnée pour son emplacement, en WebP ou AVIF, sans lazy loading sur cet élément précis |
| Carrousel ou slider en haut de page | LCP, INP | Il charge plusieurs images pour n'en montrer qu'une, et son script retarde la réactivité. Les visiteurs ne font presque jamais défiler les diapositives suivantes. Une seule image fixe fait le même travail |
| Polices personnalisées | LCP, CLS | Chaque graisse est un fichier à télécharger, et le texte change de taille quand la police arrive. Se limiter à deux fichiers, les héberger sur son propre domaine, et déclarer une police de repli aux dimensions proches |
| Bandeaux, encarts et publicités insérés après le chargement | CLS | Tout élément qui apparaît au-dessus du contenu le pousse vers le bas. Réserver l'espace dans la mise en page, avec des dimensions fixées en CSS, avant que l'élément se charge |
| Images sans dimensions déclarées | CLS | Le navigateur ne connaît la hauteur qu'à la fin du téléchargement et décale le texte. Les attributs width et height, ou un ratio en CSS, suffisent |
| Animations et effets au défilement | INP | Parallaxe, apparitions progressives et compteurs animés occupent le processeur au moment où l'utilisateur veut cliquer. Ils se justifient rarement en dehors d'une page de marque |
| Menu et fenêtres qui s'ouvrent au clic | INP | Un menu qui met 400 millisecondes à s'ouvrir sur mobile fait rater le seuil. Le rendu doit se faire en CSS, sans attendre un script |
Le rapport Core Web Vitals de la Search Console dit sur quelles pages et sur quelle métrique le site échoue, avec des données d'utilisateurs réels. La vitesse d'affichage a sa propre page, avec les leviers techniques qui viennent après le design.
Google n'indexe que la version mobile
Google a achevé le 5 juillet 2024 sa bascule vers l'indexation mobile uniquement. Depuis, il n'explore et n'indexe que la version que voit un smartphone. Un contenu présent sur ordinateur et retiré sur mobile pour alléger la mise en page n'est simplement pas indexé. C'est la conséquence la plus concrète du design sur le référencement, et la plus fréquente sur les sites dont la version mobile a été conçue après coup.
Trois pratiques de design en découlent. Le même contenu, texte, images et liens, doit exister sur les deux versions, quitte à le placer dans des onglets ou des blocs repliables, que Google indexe normalement sur mobile. Les éléments tactiles doivent être atteignables, la norme WCAG 2.2 demandant 24 pixels de côté au minimum et les audits Lighthouse en réclamant 48, avec un espacement suffisant pour ne pas toucher le voisin. Et les fenêtres qui recouvrent le contenu à l'arrivée sur la page, inscription à la newsletter, promotion, application à télécharger, font partie des interstitiels intrusifs que Google demande explicitement d'éviter, à l'exception des bandeaux légaux comme le consentement aux cookies. Le détail est sur la page mobile-friendly.
La lisibilité décide de ce qui est extrait
Une page est lue par trois publics à la fois, les visiteurs, Googlebot et les moteurs de réponse comme ChatGPT ou les aperçus IA de Google. Les trois butent sur les mêmes choix de design. Un texte placé dans une image n'est lu par aucun robot et par aucun lecteur d'écran. Des titres de section stylés en simple texte gras, sans balises H2 et H3, privent la page de la structure que Google et les modèles de langage utilisent pour repérer la réponse à une question. Un défilement infini sans liens de pagination laisse les contenus du bas de liste hors de portée du crawl. Et un contraste insuffisant, sous le ratio de 4,5 pour 1 fixé par les WCAG pour le texte courant, fait abandonner une partie des lecteurs avant la fin du premier paragraphe.
À l'inverse, les éléments de design qui servent la lecture servent l'extraction : une réponse nette en tête de section, des tableaux pour comparer, des listes numérotées pour les étapes, des paragraphes courts. C'est ce qui fait d'une page une source citable par un moteur de réponse, et les mécanismes sont détaillés sur la page GEO.
Sept contrôles à faire sur la maquette
Corriger un problème de design une fois le site développé coûte dix fois plus que le voir sur la maquette. Sept questions couvrent l'essentiel, et elles se posent devant les écrans mobiles avant les écrans d'ordinateur.
- Quel est le plus grand élément visible à l'arrivée, sur mobile ?
S'il s'agit d'une image ou d'une vidéo, quel poids aura-t-elle une fois exportée, et l'équipe a-t-elle prévu ses dimensions exactes.
- Y a-t-il un carrousel, une vidéo en lecture automatique ou une animation d'entrée ?
Chacun a un coût sur les Core Web Vitals et rarement un bénéfice mesuré. Demander ce qu'il apporte au visiteur.
- Combien de polices et de graisses différentes ?
Au-delà de deux fichiers, le temps d'affichage du texte et sa stabilité se dégradent.
- Le contenu mobile est-il le même que le contenu ordinateur ?
Texte, liens internes, images. Un bloc supprimé « pour alléger » sur mobile disparaît de l'index.
- Les titres de section sont-ils de vrais titres ?
La maquette montre des tailles de texte, le code doit en faire des H2 et des H3 dans un ordre logique. Voir la page sur les balises Hn.
- Qu'est-ce qui apparaît après le chargement ?
Bandeau de consentement, encart promotionnel, barre de recherche flottante. Chacun doit avoir son espace réservé ou se superposer sans pousser le contenu.
- Les zones tactiles font-elles au moins 24 pixels, et le contraste du texte courant atteint-il 4,5 pour 1 ?
Deux contrôles d'accessibilité qui se font en une minute sur la maquette et qui coûtent des semaines après.
Le design ne remplace pas le contenu
Un site graphiquement parfait avec un contenu pauvre ne se positionne pas, et Google le dit lui-même en indiquant qu'il affiche le contenu le plus pertinent même quand l'expérience de page est médiocre. Le design sert à rendre le contenu lisible et rapide à charger, et c'est déjà beaucoup. L'ordre des priorités reste le contenu, puis une structure et une vitesse qui le servent, puis l'esthétique. Les sites très simples visuellement qui dominent leur marché avec des pages complètes et bien structurées ne manquent pas, et les sites magnifiques sans trafic non plus.
Questions fréquentes
Sources (consultées le 13 septembre 2026)
- Google Search Central, « Comprendre l'expérience sur la page dans les résultats de recherche Google » : utilisation des Core Web Vitals par les systèmes de classement, absence de signal unique, interstitiels intrusifs, primauté de la pertinence du contenu
- web.dev, seuils des Core Web Vitals : LCP 2,5 s, INP 200 ms, CLS 0,1, évalués au 75e centile
- Google Search Central, annonce de l'achèvement de l'indexation mobile-first, 5 juillet 2024
- W3C, WCAG 2.2 : critère 1.4.3 sur le contraste minimal de 4,5 pour 1, critère 2.5.8 sur la taille des cibles tactiles de 24 pixels ; documentation Lighthouse sur les 48 pixels
- Pièces du procès United States v. Google LLC, 2023, sur le système Navboost