En référencement, une des recommandations fréquentes « facile » à pousser, c’est le retravail du maillage interne pour un site web.
J’ai écrit récemment un article sur le maillage interne, et son usage par un moteur de recherche comme Google, et comment ou le faire de façon efficace, et aujourd’hui je vais vous partager un code pour le faire facilement et rapidement.
Pour cela on va utiliser l’api Babbar, qui va nous permettre d’obtenir la proximité sémantique des pages en interne assez rapidement.
Comment fonctionne le script ?
Le crawl et les informations stockées
L’automatisation du maillage commence par un prérequis évident : disposer d’une cartographie minimale du site, incluant les pages internes et les liens qui les relient. Le script commence donc par un crawl récursif à partir d’une URL racine, en respectant les directives du robots.txt.
Le crawl s’effectue jusqu’à une profondeur définie (par défaut : 4 niveaux), avec une limite sur le nombre de liens explorés par page. Pour chaque page rencontrée, le script collecte :
- son URL canonique si elle est définie,
- la liste des liens internes présents dans le HTML (jusqu’à la limite imposée de 100 liens par page),
- pour chaque lien : sa position dans la page, son type (suivi ou nofollow), et sa validité (même host, autorisé par les robots).
Ces données sont stockées sous forme de DataFrame, avec pour chaque lien :
- source, target (les URLs),
- link_position (index dans la page),
- total_links (nombre total de liens sur la page).
Ces deux dernières données servent à calculer un poids de position : un lien plus haut dans la page, parmi un nombre raisonnable de liens, aura plus de poids qu’un lien en bas de page parmi 200 autres.
En parallèle, le contenu textuel brut de chaque page est extrait (via BeautifulSoup ou Trafilatura), puis normalisé et stocké localement. Cela permet d’éviter de redemander plusieurs fois le même contenu si l’URL est sollicitée plusieurs fois en aval.
Enfin, pour chaque page collectée, le script effectue un appel à l’API Babbar en lui fournissant le texte de la page et le host. Babbar renvoie alors une liste d’URLs internes jugées proches sémantiquement, avec un score de similarité associé (on retire juste l’URL identique de la liste). Ces scores permettent ensuite de construire un graphe sémantique interne, qui sert de base à l’optimisation.
Ce premier bloc de traitement constitue donc la base observable du site : une topologie réelle (liens), des contenus disponibles, et une estimation quantitative des proximités entre pages. Le reste du traitement s’appuiera sur cette structure pour proposer des ajustements.
La récupération des priorités
Le script ne cherche pas à “améliorer” le maillage de manière globale, mais à réorganiser l’attention structurelle autour d’un ensemble restreint de pages jugées prioritaires. Ces pages sont listées manuellement par l’utilisateur dans un fichier prios.txt.
L’approche repose sur un principe simple :
Dans un site, toutes les pages ne méritent pas le même niveau d’exposition interne. Pour diverses raisons (business, politique, stratégique…), certaines doivent être rendues plus accessibles, mieux reliées, ou simplement mieux intégrées dans le graphe. Ce sont ces pages que l’on désigne comme “prioritaires”.
À ce stade, le script :
- lit la liste des pages dans prios.txt ou demande la liste si le fichier prios.txt n’existe pas ou n’est pas à jour,
- vérifie si elles figurent déjà dans le graphe collecté lors du crawl,
- et télécharge leur contenu si elles étaient absentes du crawl initial.
Cette dernière étape permet de forcer leur intégration dans l’analyse, même si elles ne sont pas naturellement liées ou atteignables depuis l’URL de départ. On garantit ainsi que les pages que l’on souhaite renforcer seront effectivement considérées dans les calculs de maillage, même si elles sont orphelines ou profondes.
En somme, cette phase est un moment crucial pour l’optimisation à venir : le reste du traitement visera à faire en sorte que ces pages occupent une position plus importante dans le graphe du site, en modifiant ou en ajoutant des liens internes vers elles.
Le calcul de PageRank Interne adapté
Pour mesurer la visibilité structurelle de chaque page au sein du site, le script s’appuie sur une adaptation du PageRank, ajustée pour intégrer deux types de pondérations :
- la position du lien dans la page source,
- la proximité sémantique entre source et cible.
Chaque lien est donc pondéré par un score composite, défini comme suit :
poids_total = ((1 – α) + α × score_sémantique) × ((1 – β) + β × poids_position)
Les coefficients α (pour la sémantique) et β (pour la position) sont définis en tête de script et peuvent être modifiés selon les cas d’usage. Par défaut, ils privilégient légèrement la position (β = 0.65) tout en prenant en compte la proximité thématique (α = 0.35), mais vous pouvez ajuster si la sémantique vous semble plus importante que la position.
Ce modèle permet de rééquilibrer l’analyse en faveur :
- des liens visuellement mis en avant (plus haut dans le HTML, moins nombreux),
- et des liens contextuellement justifiés, c’est-à-dire entre pages proches sur le plan sémantique.
Une fois les poids appliqués à l’ensemble des liens, le script calcule un PageRank standard (avec facteur d’amortissement d = 0.85), en itérant jusqu’à convergence. Le résultat est un score de centralité pondérée pour chaque page, représentatif de son importance structurelle dans le graphe réel du site.
Ce calcul sert à deux choses :
- il fournit un état de référence initial, pour comparer l’avant et l’après optimisation,
- et il permet d’identifier les pages sous-exposées, c’est-à-dire prioritaires mais mal positionnées dans le graphe actuel.
C’est à partir de cette analyse que le script enclenchera les propositions de modifications, ajouts ou suppressions de liens internes.
La phase de propositions :
Une fois le graphe constitué et les pages prioritaires identifiées, le script entre dans une phase active : proposer des modifications du maillage interne visant à faire progresser ces pages dans le graphe.
Cette phase s’organise en trois types d’actions, appliquées de façon itérative :
1. Modification des liens existants
Le script commence par ajuster les positions des liens existants vers les pages prioritaires.
L’objectif est simple : lorsqu’un lien vers une page prioritaire est déjà présent dans une page source, on le remonte dans le HTML, c’est-à-dire qu’on lui assigne une position plus haute et donc un poids de position plus fort.
Cela permet d’augmenter sa contribution dans le calcul du PageRank, sans créer de nouveaux liens.
2. Création de nouveaux liens
Si les pages prioritaires restent insuffisamment visibles malgré ces ajustements, le script suggère de nouveaux liens internes.
Pour cela, il interroge l’API Babbar afin de récupérer jusqu’à 50 pages du même site jugées proches sémantiquement de chaque page prioritaire.
Parmi ces suggestions, il identifie les pages qui ne pointent pas encore vers la priorité concernée, puis ajoute un lien virtuel, en haut de page, pour tester son impact.
L’ajout est fait de façon itérative : on ne crée qu’un lien à la fois, on recalcule le PageRank, et on s’arrête dès que la page prioritaire atteint le niveau souhaité (par défaut : figurer dans le top N des pages, N étant le nombre de priorités définies).
3. Suppression de liens
Enfin, si certaines pages non prioritaires captent un PageRank plus élevé que la moins bien classée des pages prioritaires, et qu’elles reçoivent des liens internes, le script propose leur suppression. Cette suppression n’est jamais automatique : elle ne concerne que des cas où un lien favorise une page qui concurrence structurellement les priorités.
Cela permet de rééquilibrer la distribution interne au profit des cibles définies.
L’ensemble des modifications proposées (liens à créer, liens à modifier, liens à supprimer) est exporté dans des fichiers distincts pour validation humaine.
Cette phase est donc déterministe, contrôlée, et progressive. Elle vise à réallouer le capital de visibilité interne du site en faveur de pages considérées comme stratégiques, sans bouleverser l’architecture ni surcharger les contenus.
Enfin, tous les résultats sont exportés dans des fichiers distincts pour inspection : maillage recommandé, liens à créer ou modifier, comparaison des PageRank. La version finale du graphe peut ainsi être comparée à l’état initial, pour évaluer l’impact réel des ajustements proposés.
Quelles sont les limites du script ?
Les limites de l’existence des pages dans l’index
L’API Babbar repose sur une indexation préalable des pages, c’est-à-dire que seules les pages connues de l’outil peuvent être utilisées pour effectuer des analyses sémantiques et obtenir des recommandations. Autrement dit, une page qui n’a pas été indexée par Babbar, ou qui ne fait pas partie de son graphe sémantique, ne pourra pas être utilisée pour générer des suggestions de liens internes.
Cela pose une vraie limite en l’absence d’indexation de certaines pages.
Si une page n’est pas connue de l’outil (par exemple, une page inexistante, une page récemment ajoutée ou une page isolée ou trop profonde qui n’a pas encore été crawlée par Babbar), il sera impossible d’obtenir des recommandations sémantiques pour cette page. En d’autres termes, l’outil ne pourra pas proposer de liens pertinents vers elle ou depuis elle, et son rôle dans l’optimisation du maillage interne sera limité.
Cette situation est particulièrement problématique pour les pages récentes ou peu visibles qui n’ont pas encore reçu de liens externes ou interne significatifs.
Cela étant dit, ces limites ne compromettent pas l’efficacité globale du script, car l’approche reste largement basée sur l’analyse du site dans son ensemble. Le manque de recommandations pour certaines pages peut être comblé manuellement si nécessaire, en ajustant les priorités ou en réévaluant les liens déjà existants.
Pour résoudre ce sujet, n’hésitez pas à contacter le support pour demander le passage de Babbar sur l’intégralité de votre site (soit en fournissant le site, soit en fournissant la liste complète des urls du site, c’est mieux).
L’outil pourra crawler alors vos pages et vous pourrez utiliser le script sous une dizaine de jours (le temps que les métriques se mettent à jour).
Il est également possible que Babbar ne puisse pas crawler votre site. C’est un autre sujet, qui nécessite de votre part une action pour autoriser le Barkrowler à parcourir vos urls. Contactez nous au support si vous ne savez pas ce qui bloque !
La modification du maillage a des limites
Le script a pour objectif de renforcer la visibilité structurelle d’un ensemble de pages prioritaires. Pour cela, il agit sur les leviers disponibles : modification de la position des liens existants, ajout de liens pertinents, et réduction de la dispersion vers des pages non prioritaires.
Mais il ne peut travailler que dans les limites du graphe existant.
Il arrive que certaines pages prioritaires, même après plusieurs itérations, ne parviennent pas à atteindre les premières positions du PageRank interne. Ce phénomène n’est pas lié à une erreur du script, mais à une contrainte structurelle : la distance sémantique entre ces pages et le reste du site.
Si une page prioritaire est trop éloignée du contenu global — par son sujet par exemple— les pages internes n’auront pas suffisamment de proximité thématique pour que des liens vers elle soient jugés pertinents.
Dans ces cas, le script n’ajoute pas de lien “de force”. Il arrête les itérations dès qu’il estime que les conditions de propagation du PageRank sont structurellement défavorables.
Autrement dit, on ne peut pas rapprocher artificiellement une page du reste du site si aucun lien contextuel ne le justifie.
Dans ces situations, une action éditoriale peut être nécessaire :
Il peut être pertinent de créer des pages intermédiaires, mieux reliées aux contenus existants, et qui permettront d’établir des ponts thématiques vers la page prioritaire.
Ce sont ces pages “pivot” qui joueront alors le rôle de relais sémantiques, et permettront au graphe de s’ouvrir de manière plus fluide.
Exemple d’usage : le cas de whisky.glass
Le PRI avant
Avant l’exécution du script, le crawl permet d’identifier la distribution du PageRank à travers le maillage interne. On peut voir rapidement si ce maillage nous convient ou s’il y a des pages à mettre en avant.
Pour les besoins de l’exemple, nous allons imaginer que certaines urls (prises au hasard), correspondent à nos priorités.
Nous en prendrons 4 articles en exemple, (ça peut marcher pour plus d’urls mais il est préférable d’avoir une liste restreinte) :
On garde donc juste ces urls et on va les intégrer au fichier prios.txt (ou les indiquer quand la ligne de commande les demande).
Le PRI après
Après avoir laissé l’outil tourner tout seul, on en sort avec les fichiers suivants :
– comparaison_pagerank.csv
– maillage_actuel.csv
– maillage_recommande.csv
– liens_a_creer.csv
– liens_existants_a_modifier.csv
– liens_existants_a_supprimer.csv
On regarde le nouveau classement :
Les pages qui nous intéressent :
Nos pages prioritaires sont dans le top 5 des pages selon le classement par PageRank Interne. Mais qu’est-ce que cela signifie ? Combien de modifications devons-nous faire ? Est-ce qu’il faut créer beaucoup de liens ?
Ici, le script nous fournit la liste des liens à créer : il recommande la création de 125 nouveaux liens pour pousser les pages qui sont le plus loin dans le classement (spécifiquement https://whisky.glass/comment-choisir-un-whisky/ https://whisky.glass/la-tournee-des-distilleries-francaises/ et https://whisky.glass/deux-livres-pour-une-passion-le-whisky/).
En revanche, il y a plus de recommandations sur le nombre de liens à modifier : 13382 liens à corriger (peut être que certaines recommandations sont automatisables car il va souvent s’agir de décaler des liens qui n’apportent pas grand-chose et qui sont toujours dans les premiers du point de vue graphique).
Enfin, il y a un besoin de suppression de 15378 liens, pour limiter l’impact du maillage vers les pages non prioritaires (suppression, ou obfuscation, comme vous l’entendez). L’idée est de retirer ces liens du crawl pour éviter qu’ils n’attribuent plus de poids qu’on le souhaiterait vers des pages non prioritaires.
En conclusion, c’est assez simple : Ce script de maillage interne s’adapte à vos besoins de priorités, mais vous devrez vous préparer à une tâche assez lourde de mise en production pour la création, modification et la suppression des liens. Il y a sans doute quelques ajustements à faire pour améliorer le rendu (je pense notamment à l’actualisation des positions lorsqu’on crée de nouveaux liens ou qu’on en modifie) mais globalement la recommandation fonctionnera, sur le principe.
On peut essayer d’assouplir les règles (par exemple sur la suppression de liens) pour améliorer globalement le maillage interne des pages prioritaires sans forcer leur mise en haut de la liste, et ainsi réduire la liste des tâches.
Pour ceux que ça intéresse, le code est accessible ici.
