La taille de police influence-t-elle réellement le classement Google ?

Pourquoi Google distingue-t-il taille de police et mobile-friendliness ?

La compatibilité mobile mesure l'accessibilité globale d'une page sur smartphone : viewport configuré, espacement des liens tactiles, absence de contenu plus large que l'écran. C'est un critère binaire testé via Mobile-Friendly Test.

La taille de police, elle, relève du design. 12px ou 14px impacte le confort visuel mais ne casse pas la navigation mobile. Google sépare donc clairement ce qui bloque l'usage (critère de ranking) de ce qui l'améliore (UX sans effet algorithmique direct).

Cette déclaration contredit-elle les Core Web Vitals ?

Pas vraiment. Les CWV mesurent la performance perçue : chargement, interactivité, stabilité visuelle. La taille de texte n'entre pas dans ces métriques.

En revanche, un texte trop petit peut provoquer du zoom involontaire sur mobile, ce qui dégrade l'expérience et peut indirectement impacter CLS si le layout bouge. Mais Mueller parle ici de ranking direct — et là, la police seule ne pèse rien.

Faut-il ignorer la typographie pour autant ?

Non. Un texte illisible fait fuir les visiteurs, détruit le taux d'engagement et tue les conversions. Google ne classe peut-être pas sur la police, mais les signaux comportementaux (dwell time, pogo-sticking) eux, parlent.

Le message de Mueller est clair : optimisez pour l'humain d'abord. Si votre 12px génère du bounce massif, votre ranking en souffrira — mais par ricochet, pas par pénalité directe sur la taille de caractère.

• La compatibilité mobile reste un facteur de classement officiel depuis 2015 (mobile-friendly update).
• La taille de police n'est pas un critère algorithmique isolé, contrairement aux idées reçues.
• Les signaux UX indirects (engagement, conversions) peuvent compenser ou amplifier l'effet d'un design médiocre.
• Le Mobile-Friendly Test vérifie 16px minimum recommandé pour la lisibilité, mais c'est un conseil, pas un seuil de ranking.
• Une police trop petite peut déclencher du zoom automatique iOS (seuil 16px sur les champs de formulaire), ce qui dégrade l'expérience.

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui et non. Sur des milliers d'audits, je n'ai jamais vu un site ranker mieux après passage de 12 à 14px toutes choses égales par ailleurs. Aucun test A/B SEO ne montre de corrélation directe. [A vérifier] en revanche : l'impact indirect via l'engagement, lui, est mesurable.

Des sites avec du 11px en gris clair sur fond blanc affichent des métriques catastrophiques (40% bounce en plus). Quand on corrige, le temps sur page remonte, le CTR organique améliore — et six mois plus tard, des pages gagnent 5-10 positions. Mais Google attribuera ça aux signaux comportementaux, pas à la font-size CSS.

Quelle nuance Mueller omet-il volontairement ?

Il ne parle pas des seuils critiques d'accessibilité. En dessous de 12px, certains navigateurs forcent un zoom minimal, cassent le viewport, déclenchent le flag « texte trop petit » dans Search Console. Là, on bascule dans la non-conformité mobile — et Mueller a dit que ça, ça compte.

Autre angle mort : les polices customs lourdes qui plombent LCP (Largest Contentful Paint). Un Montserrat en 14px mais qui charge 300ms peut tuer votre CWV. Mueller parle de taille, pas de poids — or c'est le poids qui impacte le ranking via les Core Web Vitals.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Si votre police déclenche des erreurs Search Console (« Contenu plus large que l'écran », « Éléments cliquables trop rapprochés »), vous n'êtes plus dans le débat 12 vs 14px. Vous êtes en non-conformité mobile-friendly, et là le ranking trinque.

Enfin, sur des requêtes à forte intention commerciale (« acheter X », « meilleur Y »), un texte microscopique fait exploser le taux de rebond e-commerce. Google ne le voit pas comme « mauvaise police », mais comme « page qui ne satisfait pas l'intent ». Résultat identique : vous dégringollez.

Que faut-il faire concrètement sur ses pages ?

Concentrez-vous sur la conformité mobile globale, pas sur les pixels de typo. Lancez le Mobile-Friendly Test Google sur vos templates principaux. Si ça passe au vert, vous êtes clean côté ranking.

Pour la taille de police, visez 16px minimum sur body mobile — non par obligation algorithmique, mais parce que c'est le seuil de confort universel. En dessous, vous forcez le zoom sur iOS, ce qui casse l'UX et déclenche des signaux négatifs indirects.

Quelles erreurs éviter absolument ?

Ne tombez pas dans le piège du sur-optimisation typographique. J'ai vu des clients passer des jours à A/B tester 13 vs 14px en espérant gratter du ranking. Zéro impact. Ce temps aurait mieux servi à corriger des liens 404, améliorer le maillage interne ou bosser la profondeur de contenu.

Autre erreur classique : des polices customs non optimisées. Un fichier .woff2 mal compressé retarde l'affichage du texte (FOIT), dégrade le First Contentful Paint et peut tuer votre score CWV. Utilisez font-display: swap, préchargez les fonts critiques, et limitez-vous à 2-3 variants maximum.

Comment vérifier que mon site est conforme ?

Ouvrez Search Console, section Ergonomie mobile. Si Google remonte « Texte trop petit pour être lu », vous avez un problème — mais c'est rarement juste la font-size, souvent un souci de viewport ou de zoom désactivé dans le meta viewport.

Testez ensuite sur device réel : iPhone SE (petit écran), Galaxy S10, iPad mini. Si vous devez zoomer pour lire, vos visiteurs aussi — et ça, Google le verra via les signaux d'engagement faibles. Corrigez avant que ça impacte votre trafic.

• Vérifier Search Console > Ergonomie mobile pour détecter les erreurs bloquantes
• Valider le viewport meta (width=device-width, initial-scale=1) sur tous les templates
• Tester la lisibilité réelle sur smartphone 5 pouces (seuil minimal actuel)
• Optimiser le chargement des polices (woff2, font-display swap, preload)
• Mesurer l'impact UX : temps sur page, scroll depth, bounce rate mobile vs desktop
• Prioriser les quick wins (contraste, line-height) avant de peaufiner les pixels