SEO : Google utilise les index FULL TEXT de MySQL… La preuve !
30 janvier 2016
Je voudrais apporter ma contribution dans le débat qui agite la blogosphère SEO autour du cocon sémantique et des meta-mots.
La 1ère observation tient au fait que Google fut l’un des 1ers utilisateurs historiques du moteur de bases de données MySQL auquel il a ajouté des tas de modules propriétaires. L’éditeur du moteur de recherche s’est d’ailleurs bien gardé de reverser ses contributions au domaine public.
La 2e observation, c’est que si Google s’est intéressé à MySQL, c’est qu’il en avait besoin. Besoin pour quoi ? Pour ses fonctionnalités d’indexation de contenus en mode FULL TEXT. Ce mode permet d’indexer chaque mot présent dans un champ de type texte et de calculer le poids du texte recherché dans un corpus de mots selon l’algorithme dont vous trouverez la description dans cette page.
Recherche en mode NATURAL LANGUAGE MODE
J’ai donc fait un test simple à monter. J’ai créé trois tables dans lesquels je stocke respectivement les adresses ou urls , les titres – title – et les corps – body – des pages, en y ajoutant des index FULL TEXT. J’ai également créé une table stopwords, comprenant les mots à éliminer de l’indexation. Vous pouvez télécharger la base de test à partir de ce lien !
N’oubliez pas d’exécuter à partir de MySQL la directive suivante pour prendre en compte les mots de la table stopwords à exclure de vos requêtes :
SET GLOBAL innodb_ft_server_stopword_table = 'test/stopwords'J’ai entré dans mon jeu d’essai les adresses, les titres et les corps des textes des sites qui se présentent respectivement en 1, 2, 3, 11, 21, 31, 41 sur la recherche « consultant seo ». J’ai ensuite exécuté la requête en mode langage naturel dans MySQL. J’utilise en fait MariaDB.
SELECT
u.url_id,
u.url_txt,
MATCH (t.title_txt)
AGAINST ('consultant seo' IN NATURAL LANGUAGE MODE)
+
MATCH (b.body_txt)
AGAINST ('consultant seo' IN NATURAL LANGUAGE MODE)
+
MATCH (u.url_txt)
AGAINST ('consultant seo' IN NATURAL LANGUAGE MODE)
FROM
url u
INNER JOIN title t ON u.url_id=t.url_id
INNER JOIN body b ON u.url_id=b.url_id;
Le résultat est spectaculaire : la hiérarchie est globalement respectée par rapport aux résultats fournis par Google, même si nous ne disposons pas des éléments de calcul du ranking et des pénalités effectuées par Google qui viennent pondérer sérieusement ces résultats ! Autre élément : les ancres et les textes associés ne sont pas pris en compte dans ce calcul dans la mesure où je ne dispose pas encore de l’accès à l’index Google. ;+)
L’utilisation des opérateurs site, inanchor (il ne faut pas négliger le rôle des ancres internes), intext, inurl, cache (le stockage de l’historique est un grand mystère), related (je pense qu’il s’agit d’une analyse par liens), link nous en disent long sur la manière dont Google stocke ses données !