Les polices non-Unicode nuisent-elles vraiment à l'indexation de votre contenu ?

Pourquoi Google parle-t-il de polices non-Unicode ?

Dans certains pays, des sites historiques utilisent encore des polices propriétaires au lieu d'Unicode pour afficher des caractères locaux. C'est courant en Birmanie, au Bangladesh ou en Inde, où des systèmes d'encodage anciens persistent depuis les années 2000.

Concrètement, ces polices affichent visuellement le bon caractère, mais le code HTML sous-jacent contient des codes non-standards. Un « က » birman peut être encodé comme un « a » latin avec une police spécifique appliquée via CSS. Pour Google, ça ressemble à du charabia.

Comment Google gère-t-il cette situation ?

Mueller explique que Googlebot tente de reconnaître ces polices propriétaires et de les transcrire en Unicode. Un système d'inférence analyse les glyphes, détecte les patterns et mappe les caractères vers leur équivalent standard.

Ce processus n'est pas documenté publiquement. On ignore quels formats sont supportés, avec quel taux de fiabilité, ni si cette détection fonctionne pour toutes les langues. C'est une couche de traitement supplémentaire qui introduit de la latence et de l'incertitude.

Quelle différence avec Unicode directement ?

Avec Unicode, le caractère est correctement encodé dès le départ. Le texte est immédiatement lisible par tous les moteurs, tous les navigateurs, tous les screen readers. Zéro ambiguïté.

Sans Unicode, vous dépendez du bon vouloir de Google pour interpréter votre contenu. Bing, Yandex ou Baidu n'ont peut-être pas cette capacité. Votre texte risque d'être indexé comme du texte latin incohérent ou tout simplement ignoré.

• Google peut mapper certaines polices non-Unicode, mais ce n'est pas garanti à 100%
• Unicode élimine toute ambiguïté d'encodage pour tous les moteurs de recherche
• Les polices propriétaires créent une dépendance technique sur la capacité de détection de Google
• L'accessibilité et le référencement international nécessitent Unicode comme standard
• Les erreurs de mapping peuvent entraîner un contenu indexé de façon incorrecte ou partielle

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

Oui, on constate effectivement que Google indexe des sites birmans ou bengalis avec des polices anciennes. Mais la qualité de cette indexation varie énormément. Certains contenus sont bien extraits, d'autres apparaissent tronqués ou mal transcrits dans les snippets.

Le problème : Mueller ne donne aucun chiffre sur le taux de réussite du mapping. [A vérifier] Si Google détecte 95% ou 60% des cas, l'impact opérationnel n'est pas du tout le même. Cette imprécision rend la déclaration difficilement exploitable pour un audit technique.

Quels risques concrets pour un site multilingue ?

Si vous utilisez des polices non-Unicode, vous jouez à la roulette russe. Le jour où Google modifie son algorithme de détection, votre contenu peut disparaître des SERPs sans préavis. Aucune garantie de stabilité dans le temps.

Deuxième risque : les autres moteurs de recherche. Un site birman avec polices propriétaires peut être invisible sur Bing ou DuckDuckGo. Vous perdez du trafic sans même le savoir, parce que ces crawlers n'ont pas la logique de mapping de Google. Unicode est la seule assurance multi-moteurs.

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

Si votre site cible uniquement un marché domestique avec une langue à alphabet latin standard (français, anglais, espagnol), cette problématique ne vous concerne pas. Unicode est le standard par défaut depuis 20 ans pour ces langues.

En revanche, si vous travaillez sur des contenus arabes, hébreux, thaïs, ou toute langue avec un alphabet non-latin, vérifiez l'encodage. Même des CMS récents peuvent foirer l'UTF-8 si la base de données est mal configurée. Un audit technique doit inclure une vérification d'encodage sur les pages clés, surtout après une migration.

Que faut-il vérifier sur un site existant ?

Premier réflexe : inspecter le code source HTML des pages multilingues. Cherchez la balise <meta charset="UTF-8"> dans le <head>. Si elle est absente ou mentionne un autre encodage (ISO-8859-1, Windows-1252), c'est un red flag.

Deuxième vérification : copiez un bloc de texte depuis le code source et collez-le dans un éditeur de texte brut. Si les caractères affichent correctement sans CSS ni police, vous êtes en Unicode. Si ça donne du charabia, vous avez un problème de mapping de police.

Comment corriger un site en polices propriétaires ?

La migration vers Unicode nécessite une refonte du contenu. Il faut récupérer le texte original, le ré-encoder proprement, et remplacer les anciennes polices par des fonts Unicode (Google Fonts propose des options pour la plupart des langues).

C'est un chantier technique qui touche la base de données, les templates, et potentiellement les URLs si des slugs contenaient des caractères mal encodés. Prévoyez un plan de redirections 301 si les URLs changent, et surveillez l'indexation dans Search Console pendant plusieurs semaines après le déploiement.

Quelles erreurs éviter lors de la migration ?

Erreur classique : changer l'encodage HTML sans toucher à la base de données. Le site affiche alors des caractères corrompus parce que MySQL sert du latin1 alors que le navigateur attend de l'UTF-8. Il faut synchroniser l'encodage sur toute la chaîne : BDD, PHP/Python, HTML.

Autre piège : oublier les anciens contenus. Si vous migrez seulement les pages actuelles, vos archives restent en polices propriétaires. Google peut indexer ces vieilles URLs, créant une incohérence d'encodage sur le site. Faites un inventaire complet via un crawl Screaming Frog ou Botify avant de démarrer.

• Vérifier la balise meta charset sur toutes les langues du site
• Tester l'affichage du texte copié depuis le code source sans CSS
• Auditer l'encodage de la base de données (SHOW CREATE TABLE en MySQL)
• Préparer un plan de redirections 301 si les URLs contiennent des caractères non-Unicode
• Surveiller l'indexation et les snippets dans Search Console post-migration
• Valider que tous les moteurs de recherche (pas seulement Google) indexent correctement