Pour un site internet, comment savoir s’il est fait avec WordPress sans se tromper ?

Vous voulez lever le doute sur la technologie d’un site qui ressemble à WordPress sans l’afficher clairement ? Entre traces discrètes et angles morts, la détection des CMS comme la reconnaissance de WordPress permettent de passer du soupçon à la preuve.

Rien n’est garanti à 100 %, certains sites masquent volontairement leurs empreintes. En recoupant des indices techniques visibles et des méthodes fiables de vérification, vous pouvez confirmer ou écarter WordPress sans deviner trop longtemps ni recourir à des scripts intrusifs. Net.

Indices visibles dans le code source

Ouvrez le code source et cherchez quelques empreintes. Au milieu des meta et des liens, vous pouvez tomber sur la balise meta du générateur qui mentionne WordPress. Les URLs des scripts et feuilles de style trahissent parfois des fichiers dans wp-includes, avec des versions en suffixe. Un contrôle rapide via l’inspecteur réseau confirme ces ressources et leur provenance.

Observez l’HTML et les CSS chargés. Certains motifs, comme des classes CSS typiques du type wp-image-123, alignwide ou menu-item, reviennent. Le balisage des commentaires, des widgets et des galeries peut ajouter d’autres signaux. Croisez plusieurs indices et gardez en tête que des sites bien configurés masquent ces traces via un thème enfant, un plugin d’optimisation ou un proxy de cache.

Quels URL trahissent la présence de WordPress ?

Les URL révèlent parfois la plateforme. L’accès à l’interface d’administration par des chemins vers wp-admin renvoie généralement vers une page de connexion protégée. On remarque aussi une structure de permaliens avec /category/, /tag/ ou /author/ avant des segments lisibles. Voici quelques exemples à tester sans générer de charge inutile sur le site cible.

• /wp-login.php affiche un formulaire d’authentification
• /wp-json/ expose l’API REST si l’accès n’est pas restreint
• /feed/ retourne un flux RSS au format XML
• /readme.html peut révéler la version si le fichier n’a pas été supprimé

Astuce : une réponse JSON valide sur /wp-json/ est un indicateur fort, même si la page /wp-admin/ est filtrée par un WAF.

Inspectez les médias, les scripts et les images. Des liens qui intègrent les dossiers wp-content dans leur chemin pointent vers une installation classique, parfois dissimulée derrière un CDN. Certains liens ajoutent des paramètres de type query vars comme ?s= pour la recherche ou ?paged=2 pour la pagination. Combinez ces pistes avant d’affirmer la présence de WordPress avec certitude.

Reconnaître les signatures de thèmes et d’extensions

Inspectez le code source et l’arborescence /wp-content/themes/ pour repérer la patte d’un thème. Les métadonnées du fichier style révèlent souvent le nom, l’auteur et la version via les en-têtes de style.css, affichées dans la section commentaire. Les thèmes basés sur les blocs laissent des traces par leurs schémas et paramètres, visibles à travers des références à theme.json qui décrivent couleurs, espacements et variations de blocs, très caractéristiques.

Côté extensions, les chemins /wp-content/plugins/ et les noms de scripts ou styles sont parlants. On voit des classes, hooks et text domains portés par des préfixes de plugins reconnaissables, comme yoast, wc, acf ou gforms, intégrés aux handles, fonctions ou namespaces. Un thème enfant mentionnant Template dans sa feuille de style peut aussi pointer vers le thème parent, et faciliter le recoupement.

Les en-têtes HTTP vous parlent-ils ?

Un coup d’œil aux requêtes réseau suffit avec DevTools ou curl -I. La signature PHP apparaît parfois dans le header X-Powered-By, utile mais pas garanti. Le type d’hôte web transparaît via la réponse Server, qu’il s’agisse de Nginx, Apache ou LiteSpeed, tandis que les politiques de cache et de proxy se détectent dans des directives Cache-Control très spécifiques, qui trahissent la présence d’un plugin d’optimisation ou d’une couche reverse proxy.

Quand un proxy se place devant l’hébergement, cherchez des marqueurs propres aux réseaux de distribution, par exemple des empreintes de CDN telles que cf-cache-status, x-cache ou via. Croisez toujours ces indices avec le HTML et les URLs, car certains hébergeurs filtrent les headers, ce qui rend la détection moins directe mais encore fiable avec plusieurs signaux.

Outils en ligne et extensions de navigateur utiles

Pour identifier WordPress, commencez par des détecteurs technologiques simples. Installez une extension de reconnaissance et ouvrez l’inspecteur réseau afin d’observer les requêtes et scripts. Sur desktop, testez plusieurs pages du même site et comparez les résultats pour éviter un faux positif lié au cache ou à un CDN. Les extensions Wappalyzer aident à repérer le CMS et les bibliothèques front, tandis que le service BuiltWith dresse un inventaire des scripts, en-têtes et widgets chargés.

Pour valider, confrontez ces informations à une seconde source. Lancez une analyse en ligne sur un autre outil et contrôlez la présence de chemins wp-content, de thèmes ou de plugins dans les ressources. Si un outil ne détecte rien, testez une URL interne ou une page article, parfois plus bavarde.

Astuce : testez en navigation privée pour contourner des bandeaux ou optimisations de cache qui masquent des indices techniques.

Cas particuliers : site headless ou éléments masqués ?

Certains sites ne révèlent aucune trace de CMS côté front. Dans ces configurations, WordPress peut n’être utilisé que pour la gestion de contenu. Cette approche, dite architecture headless, expose le contenu via des API tandis qu’un framework moderne sert l’interface. Le code remis au navigateur apparaît minimal et les URLs n’affichent pas de chemins WordPress classiques.

Pour trancher, surveillez les appels réseau et les réponses JSON. La présence d’une API REST WP accessible sur /wp-json/ constitue un indice fort. Avec un rendu côté client, le HTML initial est dépouillé puis enrichi par JavaScript : contrôlez le premier chargement et les scripts qui reconstruisent la page après l’affichage initial.

Pistes côté contenu : flux RSS, sitemap et pages de connexion

Des indices ressortent du contenu rendu public. Les URL finissant par /feed/ ou ?feed=rss2 mènent parfois vers un flux standard, où l’entête generator et des chemins /wp-includes/ trahissent le CMS, proche du flux RSS WordPress. Des archives par catégorie ou des permaliens datés renforcent la piste, sans certitude absolue.

Un test simple consiste à contrôler les pages publiques connues. Après robots.txt, vérifiez si le fichier sitemap.xml référence /wp-sitemap.xml ou des sitemaps par taxonomie. Essayez aussi /wp-login.php : la page de connexion wp-login peut apparaître avec le logo WordPress, sauf si elle a été déplacée, masquée, ou protégée.

Éthique et limites des techniques de détection

Détecter un CMS reste un exercice d’observation, pas d’intrusion. La collecte doit se limiter aux ressources publiques, dans le respect de la vie privée, sans forcer d’endpoints ni décoder des zones protégées. Réduisez la charge envoyée au serveur, tenez compte du robots.txt et des consignes affichées par le propriétaire du site.

Le cadre juridique varie selon les pays et les hébergeurs. Restez du côté de l’audit passif : des scans agressifs, des tentatives d’accès ou le contournement de protections peuvent franchir les limites légales. Vérifiez aussi la politique de sécurité publiée par l’entreprise, qui peut interdire les outils d’analyse automatisés et les tests de charge non sollicités.

Checklist finale pour valider sans ambiguïté

Commencez par un parcours rapide : URL, code source, en-têtes, puis un outil tiers. Pour éviter les biais, définissez un ordre de priorité clair qui classe les signaux, des plus fiables aux plus discutables. Confirmez chaque indice par des vérifications croisées entre méthodes manuelles et services automatisés, afin d’écarter les pistes fragiles.

Avant de conclure que le site tourne sous WordPress, exigez au moins trois marqueurs concordants. Par exemple, un chemin /wp-content/, une balise generator, et un scan externe. Ajustez votre tolérance aux faux positifs selon la situation, puis validez avec des preuves multiples plutôt qu’un unique indice technique.

FAQ à propos de l’identification d’un site WordPress