Parmi les nombreux fichiers situés à la racine d’une installation WordPress, certains sont discrets mais remplissent des fonctions historiques bien spécifiques. C’est le cas de wp-links-opml.php, un fichier peu connu du grand public mais qui a joué un rôle important dans l’interopérabilité des contenus entre sites au début des années 2000. Aujourd’hui largement obsolète dans les pratiques modernes, il reste toutefois présent par défaut dans WordPress. Alors à quoi sert-il exactement ? Faut-il le garder ou le supprimer ? Explorons son origine, son fonctionnement, ses usages et les considérations de sécurité qu’il soulève.

L’histoire et le rôle du fichier wp-links-opml.php dans WordPress

Le fichier wp-links-opml.php est un composant historique de WordPress, présent depuis les toutes premières versions du CMS (à commencer par la version 0.71 sortie en juin 2003), à peine quelques mois après le fork de b2/cafelog par Matt Mullenweg et Mike Little. À cette époque, WordPress se positionnait avant tout comme une plateforme de publication pour les blogueurs, fortement influencée par les standards du web libre et interconnecté. Dans ce contexte, WordPress intégrait en natif un système appelé blogroll, terme hérité de la culture blog. Il s’agissait d’une liste de liens externes affichée sur le site, en général dans la colonne latérale, pointant vers d’autres blogs ou sites considérés comme amis, partenaires, sources d’inspiration ou références. Ces liens étaient gérés depuis le back-office WordPress, dans un module dédié accessible via Liens → Tous les liens, et enregistrés dans la base de données, dans la table wp_links.

Pour favoriser le partage, la synchronisation et la portabilité de ces blogrolls entre sites, WordPress a introduit le fichier wp-links-opml.php. Sa mission : exposer dynamiquement la liste des liens au format OPML (Outline Processor Markup Language), un format XML structuré conçu pour l’échange de listes de données arborescentes — très utilisé à l’époque pour partager des abonnements RSS entre agrégateurs. Ce fichier permettait ainsi à n’importe quelle plateforme compatible (lecteur RSS, agrégateur, autre blog WordPress ou CMS tiers) de lire automatiquement et à jour la liste des liens d’un site WordPress, simplement en accédant à une URL comme :

https://example.com/wp-links-opml.php

Concrètement, chaque lien créé via le gestionnaire de liens WordPress (titre, description, URL, catégorie) était converti en une balise <outline> dans la structure OPML, offrant un format lisible par les machines et exportable par des outils tiers.

La popularité de OPML dans les années 2000

Dans les années 2000, l’écosystème des flux RSS et Atom battait son plein. De nombreux services proposaient aux utilisateurs de s’abonner à des contenus, de les suivre, d’organiser leurs sources d’actualité. Des plateformes comme Netvibes, Bloglines, FeedDemon ou encore Google Reader permettaient d’importer/exporter des listes de flux RSS au format OPML — y compris les blogrolls.

Le fichier wp-links-opml.php s’inscrivait pleinement dans cette logique d’interopérabilité : il ne s’agissait pas seulement d’afficher des liens en HTML, mais de les rendre disponibles pour d’autres outils de lecture, d’agrégation ou de synchronisation entre blogs. Il était notamment utilisé dans des extensions qui créaient des blogrolls dynamiques, basées sur le contenu OPML de sites tiers.

Un héritage de la philosophie du web décentralisé

Ce fichier symbolise aussi une époque où le web fonctionnait davantage en réseau pair-à-pair de blogs que via des plateformes centralisées. Le blogroll n’était pas qu’une liste de liens : c’était une manière de manifester une appartenance, une communauté éditoriale ou une affinité thématique. L’automatisation de cette liste via OPML visait à encourager la circulation des lecteurs, des idées et des ressources à travers les sites — dans un esprit très proche de celui des « Webrings » des années 90.

Pourquoi ce fichier est toujours présent aujourd’hui

Malgré l’abandon progressif du gestionnaire de liens (désactivé par défaut depuis WordPress 3.5 en décembre 2012), le fichier wp-links-opml.php est encore présent dans le noyau WordPress pour garantir la rétrocompatibilité. Cela signifie que les sites créés avant cette version, ou ceux qui utilisent encore le plugin Link Manager, peuvent continuer à exposer leurs liens au format OPML sans rien changer à leur configuration. Dans les faits, il est donc peu utilisé aujourd’hui, mais reste activé sur de nombreux sites anciens — et potentiellement exposé à l’indexation ou à des appels extérieurs. Son maintien reflète aussi la volonté de WordPress de rester un CMS universel, soucieux de ne pas casser les usages existants, même lorsqu’ils sont en voie de disparition.

L’affichage du lien vers wp-linksèopml.php :

La structure technique et le fonctionnement du fichier wp-links-opml.php

Le fichier wp-links-opml.php est un script PHP très léger, mais parfaitement fonctionnel. Son objectif est de produire dynamiquement une réponse XML conforme à la spécification OPML 1.0 afin de fournir une représentation externe des liens du site WordPress (aussi appelés « bookmarks »).

Contrairement à des fichiers plus complexes comme wp-login.php ou xmlrpc.php, il n’implémente ni interface HTML, ni système d’authentification, ni logique conditionnelle avancée. Il s’agit d’un simple point d’accès public qui agit comme un exporteur automatique de blogroll.

Étapes techniques exécutées par wp-links-opml.php

Pour mieux comprendre les éléments techniques exécutés du fichier, voyons les différentes étapes :

1. Chargement de l’environnement WordPress

   La toute première ligne du fichier inclut wp-load.php :

   require_once __DIR__ . '/wp-load.php';

   Ce chargement permet d’accéder aux fonctions internes de WordPress, aux variables globales, et notamment à get_bookmarks() — une fonction native qui interroge la base de données pour récupérer la liste des liens (s’ils existent).

2. Définition du type de contenu

   Ensuite, le fichier modifie l’en-tête HTTP de la réponse pour indiquer qu’il renvoie du XML :

   header( 'Content-Type: text/xml; charset=' . get_option( 'blog_charset' ), true );

   Cette directive est importante car elle assure la compatibilité avec les navigateurs, les agrégateurs de flux, les outils d’importation OPML, etc. Le charset utilisé correspond à celui défini dans les réglages du site WordPress (blog_charset), généralement UTF-8.

3. Construction de la structure OPML

   Le code commence ensuite à produire du contenu XML, conforme à la spécification OPML. La structure de base se compose de trois éléments :

   • <opml version="1.0"> : la balise racine du fichier OPML ;
   • <head> : qui contient des métadonnées comme le titre du blog et la date de création du document ;
   • <body> : qui regroupe tous les liens, chacun représenté par une balise <outline />.

   Chaque lien (ou « bookmark ») est généré par une boucle foreach sur les résultats de get_bookmarks(). Voici un exemple typique de balise <outline> produite pour un lien :

   <outline text="Facem Web" type="link" 
            xmlUrl="https://facemweb.com/feed/" 
            description="SEO WordPress" 
            title="Facem Web" 
            htmlUrl="https://facemweb.com" />

   Les attributs utilisés dans cette balise <outline /> sont :

   Attribut	Description
   text	Le nom du lien (identique à title dans ce cas).
   type	Toujours défini à link, conforme à la spécification OPML pour les liens externes.
   xmlUrl	Adresse du flux RSS ou Atom si défini dans le lien.
   description	Description textuelle du lien.
   title	Titre du lien affiché dans les interfaces utilisateurs.
   htmlUrl	Adresse HTTP principale du lien.

Précisions techniques sur get_bookmarks()

La fonction get_bookmarks() est une fonction native de WordPress définie dans wp-includes/bookmark.php. Elle interroge la table wp_links à l’aide de wpdb pour retourner un tableau d’objets PHP contenant tous les champs définis dans l’administration des liens (nom, URL, description, rel, notes, RSS, etc.).

Exemple de requête SQL simplifiée utilisée en interne :

SELECT * FROM wp_links WHERE link_visible = 'Y' ORDER BY link_name ASC;

Le fichier wp-links-opml.php ne filtre pas explicitement les liens visibles, mais la fonction get_bookmarks() le fait automatiquement. Seuls les liens visibles et publiés sont donc affichés dans la sortie OPML.

Spécificité importante : export dynamique sans cache

Ce fichier ne produit pas un fichier statique ou exportable depuis l’administration. Il s’agit d’un export à la volée, généré à chaque appel. Cela permet une synchronisation temps réel avec les outils distants, mais signifie aussi que chaque visite entraîne une requête en base et un rendu XML complet. Il ne bénéficie d’aucune mise en cache native, ce qui peut être une considération en matière de performance ou de sécurité si le fichier est régulièrement scanné par des bots ou outils automatiques.

Le statut actuel de wp-links-opml.php : Utile ou obsolète ?

Le fichier wp-links-opml.php est toujours inclus par défaut dans les installations WordPress, mais il est aujourd’hui considéré comme une fonctionnalité héritée. Son maintien relève principalement de la volonté de WordPress d’assurer une rétrocompatibilité maximale avec les anciens sites, une philosophie centrale dans l’évolution du CMS.

Pourquoi ce fichier est peu utilisé dans les sites modernes

• Le gestionnaire de liens est désactivé par défaut depuis WordPress 3.5 (sorti en décembre 2012 et ainsi que nous le disions plus haut) : Depuis cette version, l’interface Liens a été masquée dans le back-office pour les nouvelles installations. WordPress ne supprime pas la fonctionnalité, mais elle nécessite désormais l’installation d’un plugin tel que Link Manager pour réactiver l’ancien système de blogroll. Résultat : la majorité des utilisateurs modernes ne la voient même plus ;
• Le format OPML est devenu marginal dans les pratiques actuelles :es lecteurs RSS modernes et applications de veille utilisent désormais des formats comme Atom, RSS 2.0, voire JSON pour les API de flux. OPML, bien qu’encore lisible, est rarement mis en œuvre nativement dans les outils post-2015. La majorité des CMS concurrents n’en génèrent plus automatiquement :
• La base de données n’exploite plus la table wp_links dans les sites récents :La table wp_links est toujours créée lors d’une mise à niveau depuis un ancien site, mais elle n’est plus sollicitée par les nouvelles installations WordPress. De nombreux hébergeurs la suppriment même par défaut dans leurs configurations optimisées, car elle n’est plus nécessaire pour un fonctionnement standard du CMS.

Cas où son utilisation reste pertinente

Bien que de moins en moins courant, certains cas d’usage peuvent justifier le maintien ou la réactivation de wp-links-opml.php :

• Interopérabilité entre blogs d’un même réseau :Dans certains projets éditoriaux multisites ou réseaux de blogs indépendants, l’export OPML permet de synchroniser automatiquement une blogroll commune entre plusieurs sites, sans développer une API maison ;
• Import/export de répertoires dans des applications métiers :Certains intranets, systèmes d’annuaires ou portails d’entreprises utilisent encore OPML pour échanger des listes de ressources, liens partenaires ou bases documentaires — notamment dans des contextes déconnectés du web public.
• Utilisation en tant que flux de découverte machine :Dans des contextes de veille ou de crawling orientés XML, il peut être utile de publier un fichier OPML pour que des robots (internes ou externes) récupèrent une liste maintenue de liens autorisés à suivre ou surveiller.

Dans tous ces cas, le fichier wp-links-opml.php remplit sa fonction de passerelle simple, lisible, interopérable et non-intrusive. Il n’a pas besoin de base de code complexe, d’authentification, ou d’interface utilisateur — ce qui en fait un outil toujours pertinent pour des contextes techniques précis.

La sécurité et les bonnes pratiques autour de wp-links-opml.php

Bien que wp-links-opml.php soit un fichier passif (il ne contient ni formulaire ni logique interactive) il reste un point d’accès public sur votre site. Cela signifie qu’il peut être scanné, indexé, ou exploité dans certains contextes si aucune restriction n’est appliquée. Sa simplicité ne le rend pas inoffensif, surtout sur des installations anciennes ou mal entretenues.

1. Risques liés à l’exposition non contrôlée de ce fichier

• Fuite d’informations internes : bien que le fichier ne révèle pas d’informations sensibles comme des mots de passe ou des utilisateurs, il expose la liste complète de vos liens externes enregistrés dans WordPress. Cela peut inclure :
  • des URL privées ou internes (par exemple des sous-domaines en préproduction, des outils métiers) ajoutées par inadvertance ;
  • des descriptions de liens qui peuvent contenir des informations confidentielles (annotations techniques, commentaires internes) ;
  • la structure logique d’une blogroll ou d’un réseau de partenaires, potentiellement sensible dans certains cas (ex : réseau privé, affiliations commerciales, etc.).
• Surface d’attaque inutile : plus un fichier est publiquement accessible, plus il est susceptible d’être visité par des bots, des crawlers automatisés, voire des scripts malveillants. Même si wp-links-opml.php ne contient aucune logique d’exécution personnalisée, il peut être utilisé comme indicateur pour détecter un site WordPress ancien, potentiellement vulnérable (notamment si la table wp_links est active).
• Utilisation dans des attaques ciblées : certains scripts d’analyse de surface exploitent la présence de fichiers « rares » comme wp-links-opml.php, xmlrpc.php ou readme.html pour estimer la version, la configuration ou le degré d’exposition d’un site. Cela peut ouvrir la porte à des attaques plus ciblées sur des fichiers réellement sensibles.

2. Recommandations pour sécuriser ce fichier

Si vous n’utilisez pas activement la fonctionnalité de blogroll ou le module de gestion des liens, il est fortement recommandé de restreindre, voire bloquer l’accès à wp-links-opml.php depuis le web.

Bloquer via .htaccess (Apache)

<Files wp-links-opml.php>
  Order allow,deny
  Deny from all
</Files>

Bloquer via Nginx

location = /wp-links-opml.php {
  deny all;
  access_log off;
  log_not_found off;
}

Ces directives permettent de bloquer toutes les requêtes HTTP adressées à ce fichier, tout en conservant son intégrité sur le disque (ce qui évite de rompre la structure du cœur WordPress). Cela vous protège contre les scans automatisés ou les appels parasites.

3. Alternatives : contrôle d’accès plus fin

Dans certains cas, vous pourriez vouloir restreindre l’accès uniquement à des adresses IP spécifiques (comme des outils internes ou des applications tierces). Voici un exemple :

<Files wp-links-opml.php>
  Order deny,allow
  Deny from all
  Allow from 192.168.1.10
  Allow from 203.0.113.5
</Files>

Vous pouvez aussi utiliser un plugin de sécurité comme Wordfence, iThemes Security ou SecuPress pour journaliser les accès à ce fichier et bloquer toute requête suspecte.

4. Cas particuliers d’usage légitime

Si vous exploitez ce fichier dans un contexte réel (par exemple dans un réseau multisite, une application de lecture RSS, ou un projet d’échange OPML), voici quelques bonnes pratiques à adopter :

• Ajoutez un contrôle d’accès conditionnel par clé API ou token dans un wrapper PHP personnalisé. Cela permet de restreindre l’accès sans bloquer totalement.
• Protégez les descriptions de vos liens : n’y incluez jamais de données sensibles, car elles seront visibles publiquement dans la sortie XML.
• Ajoutez une entête HTTP “X-Robots-Tag: noindex” via votre serveur ou plugin SEO pour éviter que Google indexe ce flux OPML :

Header set X-Robots-Tag "noindex, nofollow"

Cette directive évite que le fichier apparaisse dans les résultats de recherche ou les outils d’audit SEO publics.

5. Surveillance et intégrité

Comme tout fichier à la racine de WordPress, wp-links-opml.php doit être surveillé dans votre processus de sécurité. Voici quelques conseils complémentaires :

• Intégrez ce fichier à la liste des fichiers surveillés dans votre solution de sécurité (Wordfence, Sucuri, etc.) ;
• Vérifiez sa signature MD5 ou SHA256 si vous utilisez un outil de monitoring d’intégrité (tripwire, AIDE, etc.) ;
• Conservez une version propre du fichier WordPress pour restaurer en cas de corruption ou injection.

Bien que discret et rarement exploité aujourd’hui, wp-links-opml.php reste un fichier exposé publiquement qui peut révéler des informations inutiles, servir de point d’entrée à des scans automatisés, ou augmenter votre surface d’exposition inutilement. En l’absence d’un besoin réel — comme l’export OPML actif ou le maintien d’un système de blogroll — il est recommandé de restreindre son accès via le serveur web ou un pare-feu applicatif.

Comme toujours avec WordPress, la meilleure approche reste celle du principe du moindre privilège : Ne jamais laisser accessible une ressource dont vous n’avez pas besoin activement.