Reconnaître un site WordPress n’a rien d’un jeu de devinettes réservé aux développeurs chevronnés. Avec quelques réflexes et deux ou trois outils bien choisis, tu peux vérifier si un site a été créé avec WordPress en moins d’une minute, sans écrire une seule ligne de code. Entre les indices visibles à l’écran, les traces dans le code source, les URL qui trahissent un thème WordPress ou des plug-ins WordPress bien connus, les signaux ne manquent pas. L’enjeu dépasse la simple curiosité : détecter un CMS aide à analyser un concurrent, préparer une refonte, estimer la maintenance ou anticiper les failles de sécurité potentielles.
Pour que ce soit concret, on va suivre le parcours d’Alex, freelance qui hésite à migrer le site de son client vers WordPress. À force d’inspecter des sites concurrents, Alex commence à reconnaître les mêmes patterns : chemins « wp-content », formulaire de connexion en « /wp-login.php », balise generator dans les en-tête HTTP, outils comme Wappalyzer qui affichent en un clic « WordPress ». En recoupant ces éléments, Alex finit par établir une méthode fiable, réutilisable sur tous ses projets. C’est cette méthode qui sert de fil rouge à l’article : passer de « j’ai un doute » à « j’ai des preuves ».
En bref
- Premier réflexe : regarder les URL, le formulaire de connexion et les indices visuels typiques d’un site WordPress.
- Vérification technique : ouvrir le code source, chercher « wp-content », « wp-admin » ou la mention « WordPress » dans les balises meta.
- Outils automatisés : utiliser un outil détection de CMS (Wappalyzer, BuiltWith, IsItWP…) pour confirmer le diagnostic.
- Cas avancés : analyser les en-tête HTTP, les fichiers de thème et les traces de plug-ins WordPress quand le site est bien camouflé.
- Limites : certains développeurs masquent volontairement les caractéristiques WordPress, il faut donc croiser plusieurs méthodes avant de conclure.
Inspecter visuellement un site pour repérer WordPress sans toucher au code
Avant d’ouvrir les outils de développeur, Alex commence toujours par ce qui saute aux yeux. Beaucoup de sites laissent transparaître des caractéristiques WordPress évidentes juste en naviguant normalement. C’est la partie la plus accessible pour un client, un marketeur ou un créateur de contenu qui veut simplement vérifier site sans se perdre dans des lignes de code.
Premier réflexe : regarder l’URL quand tu te balades dans le site. La présence de chemins du type « /category/ », « /tag/ » ou « /author/nom » est fréquente sur les blogs WordPress configurés par défaut. Ce n’est pas une preuve absolue, mais combiné à d’autres signaux, cela commence à peser dans la balance.
Deuxième indice, souvent décisif : tester la page de connexion. Il suffit d’ajouter /wp-admin/ ou /wp-login.php après le nom de domaine. Si tu tombes sur un écran de connexion avec le logo WordPress, quelques champs d’authentification et parfois le lien « Mot de passe oublié », tu tiens un argument très solide. Alex l’utilise systématiquement quand un client lui demande si son site repose sur WordPress ou non.
L’interface du back-office a elle aussi une signature très reconnaissable. Quand Alex demande à un client de lui envoyer une capture de l’espace d’administration, le fameux menu latéral avec « Tableau de bord », « Articles », « Médias », « Pages », « Extensions » apparaît souvent. Aucun besoin de fouiller le serveur pour en déduire le CMS.
Certaines mises en page front rendent aussi la détection assez simple. Des sections construites avec Elementor ou Divi laissent souvent des indices dans les classes CSS ou dans le comportement de l’éditeur côté client. Quand tu vois des popups, sliders et formulaires qui suivent des patterns très proches de ces constructeurs, la probabilité de WordPress grimpe d’un cran.
Alex regarde aussi le pied de page. Sur pas mal de sites, on trouve encore des mentions du type « Propulsé par WordPress » ou le nom d’un « thème WordPress » premium non masqué. C’est un peu comme oublier l’étiquette sur un t-shirt neuf : très pratique quand tu cherches à savoir d’où il vient.
Pour les sites e-commerce, certains éléments de WooCommerce sont presque des signatures. Le chemin « /panier/ », les pages « Mon compte » et « Boutique » avec un certain style de boutons et de formulaires sont autant d’indices. Là encore, ce n’est pas une preuve isolée, mais combinée au test « /wp-admin/ », ça donne un diagnostic très fiable.
Ce premier tour d’horizon permet déjà à Alex de classer un site dans trois catégories : fortement suspecté d’être WordPress, probablement autre chose, ou cas douteux qui mérite une analyse plus technique. Ce tri simple fait gagner du temps avant de sortir l’artillerie lourde.
Analyser le code source pour confirmer la présence de WordPress
Quand les indices visuels ne suffisent pas, Alex passe à l’étape suivante : l’analyse du code source. C’est là que les choses deviennent vraiment intéressantes, parce qu’un site peut se maquiller visuellement, mais il laisse presque toujours des traces techniques en arrière-plan.
Premier geste : clic droit sur la page, puis « Afficher le code source » ou « Afficher le code de la page » selon le navigateur. Une nouvelle fenêtre s’ouvre avec le HTML. Dans la barre de recherche, taper « wp-content » donne souvent la réponse en une seconde. Si tu trouves des chemins du type /wp-content/themes/nom-du-theme/ ou /wp-content/plugins/, tu peux quasiment cocher la case WordPress.
Alex cherche aussi « wp-includes » et « wp-admin ». Ces répertoires sont typiques du cœur WordPress. Même si l’hébergeur ou le développeur a légèrement personnalisé la structure, il reste rare de les voir sur d’autres CMS. C’est ce qui rend cette méthode solide pour vérifier site en mode très technique.
Autre vérification rapide : la balise meta generator. Dans certains projets, le thème ou un plugin ne la masque pas. Elle ressemble à ceci :
<meta name= »generator » content= »WordPress 6.x »>
Si tu tombes là-dessus, tu connais le CMS et parfois même la version. Alex s’en sert pour jauger la maturité d’un site : une version trop ancienne suggère souvent une dette de maintenance, ce qui rejoint les problématiques abordées dans des sujets comme le coût de la maintenance WordPress.
En décortiquant le code, tu peux aussi remonter au thème WordPress utilisé. Souvent, la feuille de style principale s’appelle « style.css » et se trouve dans un dossier « /wp-content/themes/nom-du-theme/ ». Le nom du dossier donne directement le nom du thème. Sur les sites d’Alex, c’est devenu un réflexe : un rapide Ctrl+F sur « themes/ » et la curiosité est servie.
Les plug-ins WordPress laissent également leur empreinte. Un formulaire de contact généré par Contact Form 7, par exemple, expose souvent une classe « wpcf7 » dans le HTML. Les plugins de cache, eux, ajoutent des commentaires HTML avec leur nom. Ces détails, pris un par un, semblent anecdotiques, mais mis bout à bout, ils composent une vraie signature technique.
Pour les curieux, les navigateurs modernes permettent même de repérer des indices côté réseau. En ouvrant les outils de développement (F12), puis l’onglet « Réseau », tu peux observer les fichiers chargés par le site. Les scripts et feuilles de style provenant de « wp-content » ou « wp-includes » terminent de lever le doute.
Alex garde une règle simple : s’il trouve au moins deux éléments forts parmi « wp-content », « wp-admin », balise generator WordPress, fichiers de thème et traces d’extensions, il considère le diagnostic comme confirmé. Cette approche par faisceau d’indices évite les conclusions hâtives.
Utiliser un outil de détection de CMS pour gagner du temps
Dans la vraie vie de projet, Alex n’a pas toujours dix minutes à consacrer à chaque audit. Pour un benchmark rapide ou un tour d’horizon de plusieurs concurrents, un outil détection de CMS fait gagner un temps précieux. L’idée est simple : tu saisis l’URL du site, l’outil scanne son infrastructure et te renvoie les technos détectées.
Parmi les plus connus, Wappalyzer s’utilise en extension de navigateur ou via un site web. Une fois installé, un simple clic sur l’icône pendant que tu visites un site affiche les technologies en cours : WordPress, Nginx ou Apache, Google Analytics, frameworks JavaScript… Pour Alex, c’est un peu l’équivalent d’une fiche d’identité technique instantanée.
BuiltWith joue dans la même catégorie, avec un niveau de détail souvent supérieur sur les scripts publicitaires, les CDN ou les solutions de tracking. C’est utile quand tu veux comprendre la stack d’un gros site avant de proposer une prestation de développement sur mesure ou une refonte.
Des outils spécialisés comme IsItWP ou WPThemeDetector se concentrent plus sur WordPress. Ils peuvent détecter le thème WordPress actif, certains plug-ins WordPress visibles et la version du CMS quand elle est accessible. Alex les sort surtout quand un client demande « quel thème utilise ce site, je veux le même point de départ ».
Ces services fonctionnent en combinant plusieurs techniques : inspection du code source, analyse des en-tête HTTP, détection de fichiers spécifiques, reconnaissance de patterns d’URL, etc. Leur force vient de la somme de signaux qu’ils croisent en arrière-plan, bien plus vite qu’un humain.
Pour autant, Alex garde un regard critique sur les résultats. Certains propriétaires de sites masquent méticuleusement les traces de WordPress, au point de piéger les détecteurs automatiques. Il arrive que Wappalyzer n’annonce aucun CMS alors qu’un « /wp-admin/ » répond toujours. D’où l’intérêt de ne jamais s’en remettre à un seul outil.
Quand il prépare un audit complet, Alex combine souvent ces approches. Un passage rapide par Wappalyzer pour le panorama global, puis une vérification à la main sur les points sensibles. Ce croisement évite les faux négatifs et donne une vue nuancée de la stack.
Pour résumer cette partie, on peut dresser un petit tableau comparatif des principaux services utilisés pour vérifier site et son CMS :
| Outil | Fonction principale | Atout pour détecter WordPress | Niveau de détail |
|---|---|---|---|
| Wappalyzer | Extension et site d’analyse de technologies web | Affiche « WordPress » si le CMS est repéré, plus les principales extensions front | Moyen à élevé |
| BuiltWith | Cartographie technique complète d’un domaine | Repère WordPress, les scripts tiers, parfois certains plugins marquants | Élevé |
| IsItWP | Vérification ciblée sur WordPress | Indique si le site tourne sous WordPress et donne le thème détecté | Moyen |
| WPThemeDetector | Identification des thèmes et plugins WordPress | Liste le thème actif et quelques extensions visibles | Ciblé sur WordPress |
Pour Alex, ces outils sont un peu comme un stéthoscope pour un médecin généraliste. Ils donnent un premier diagnostic de l’état du site, libre ensuite d’entrer dans le détail si quelque chose intrigue.
Signaux avancés dans les en-tête HTTP et les fichiers WordPress
Sur certains projets, le propriétaire du site a tout fait pour effacer les marques de WordPress. URL réécrites, feuilles de style renommées, scripts fusionnés… C’est souvent le cas des plateformes à fort trafic ou des sites sensibles côté sécurité. C’est là qu’Alex sort sa casquette de dev full stack et va creuser dans les couches moins visibles, comme les en-tête HTTP ou les réponses du serveur.
En ouvrant les outils de développement du navigateur, puis l’onglet « Réseau », tu peux observer chaque requête HTTP. Certaines réponses embarquent encore une signature WordPress, par exemple un chemin interne qui mentionne « wp-content » ou des entêtes ajoutés par des plugins de sécurité ou de cache dédiés à ce CMS.
Alex regarde aussi les codes de statut et les redirections. Par exemple, une requête sur « /wp-login.php » qui redirige systématiquement vers la page d’accueil peut signifier que WordPress est bien là, mais que l’accès est filtré par une extension de sécurité. Ce genre de détail apparaît clairement dans le tableau des requêtes réseau.
Autre piste : les fichiers CSS et JS concaténés. Même quand ils sont combinés et renommés, certains chemins internes ou commentaires restent visibles. Une feuille de style générée par Gutenberg comporte souvent des classes au format « wp-block-… », assez caractéristiques de l’éditeur de blocs qui structure désormais le contenu WordPress.
Sur les sites où Alex a dû assurer une refonte complète, la présence de ces classes a été un signal précieux pour comprendre comment les blocs étaient utilisés, ce qui rejoint les bonnes pratiques détaillées dans les stratégies de maillage interne sous WordPress. Savoir comment le contenu est découpé aide ensuite à réorganiser l’architecture.
Dans certains cas, Alex va jusqu’à interroger directement certains fichiers. Une tentative sur « /xmlrpc.php » ou « /wp-json/ » donne parfois des réponses parlantes. L’API REST native, accessible via « /wp-json/wp/v2/posts », trahit littéralement la présence de WordPress si elle n’est pas désactivée ou filtrée.
Sur les sites multilingues ou très custom, Alex a également repéré des traces de plugins comme WPML, Polylang, Yoast ou Rank Math, via des classes, des commentaires ou des scripts chargés en front. Même si le cœur WordPress est masqué, ces briques satellites le trahissent souvent.
On peut résumer les vérifications avancées qu’Alex garde dans sa boîte à outils :
- Analyser les requêtes réseau pour repérer des chemins « wp-* » ou des headers propres à des plugins de sécurité.
- Tester des endpoints d’API comme « /wp-json/ » pour repérer les structures standard de WordPress.
- Inspecter les classes CSS générées par Gutenberg ou certains page builders très liés à WordPress.
- Observer les redirections de « /wp-login.php » ou « /wp-admin/ » pour détecter une protection renforcée.
Cette approche demande un peu plus d’aisance technique, mais elle permet à Alex de trancher même quand tout paraît obfusqué. C’est souvent ce niveau d’analyse qui convainc un client hésitant sur l’ampleur d’une refonte, notamment quand une migration sort du simple relooking visuel.
Relier la détection de WordPress aux enjeux de projet et à la pratique au quotidien
Savoir si un site tourne sur WordPress n’est pas juste un exercice de curiosité. Alex l’utilise pour prendre plusieurs décisions structurantes sur ses projets. Quand il découvre qu’un concurrent s’appuie sur le même CMS, cela donne des indices sur le budget, l’équipe technique et la capacité à faire évoluer le produit dans le temps.
Pour un client qui prépare une refonte, reconnaître WordPress en amont permet de choisir la bonne approche. Si le site actuel est déjà sur ce CMS, une refonte peut s’appuyer sur les contenus existants, parfois sur une partie des plug-ins WordPress encore à jour. À l’inverse, migrer depuis un autre système demande davantage de travail d’import et de mapping de données.
Alex se sert aussi de ces méthodes de détection pour évaluer la difficulté de maintenance. Un site sous WordPress mais resté plusieurs années sans mise à jour, avec une vieille version de PHP ou des extensions abandonnées, représente un risque. C’est typiquement le genre d’analyse qu’il partage avant de chiffrer un contrat de suivi ou de correction de bugs.
Sur le plan éditorial, connaître le CMS aide à accompagner les équipes de contenu. Un site WordPress bien configuré avec l’éditeur Gutenberg, des blocs personnalisés et un bon maillage interne donne une base confortable pour publier régulièrement. À l’inverse, un montage bricolé autour d’un constructeur mal maîtrisé peut transformer chaque mise à jour en parcours du combattant.
La distinction entre articles et pages illustre bien cet enjeu. Les articles servent à publier des contenus réguliers, datés, souvent listés sur un blog ou une section « actualités ». Les pages, elles, structurent les contenus plus stables : accueil, à propos, services, contact. Quand Alex audite un site, il regarde comment cette différence est gérée. Un usage confus entraîne souvent des problèmes de navigation, de SEO et de cohérence éditoriale.
Les blocs Gutenberg changent aussi la donne. Chaque paragraphe, image, citation, galerie ou bouton devient un bloc déplaçable. Pour un rédacteur, cela donne de la liberté. Pour un développeur, cela impose de penser en briques réutilisables. Alex voit d’ailleurs de plus en plus de projets où les équipes non techniques gèrent elles-mêmes des mises en page complexes, à condition que la base ait été conçue proprement.
En filigrane, la question de la sécurité n’est jamais loin. Un site WordPress détectable, surtout s’il affiche une version ancienne, attire les robots qui scannent le web en continu. D’où l’intérêt de coupler cette connaissance à des pratiques de durcissement : gestion des mises à jour, restriction d’accès à « /wp-admin/ », masquage de certains fichiers, politique de sauvegarde sérieuse.
Alex le rappelle souvent à ses clients : identifier WordPress est un début, pas une fin. Ce qui compte derrière, c’est l’usage concret qu’on en fait, la qualité de l’architecture, le niveau d’attention porté aux contenus et à la maintenance. Le CMS offre un terrain de jeu, à chacun d’en faire soit un jardin organisé, soit une jungle impénétrable.
Comment savoir rapidement si un site utilise WordPress sans être développeur ?
Le plus simple consiste à ajouter /wp-admin/ ou /wp-login.php à la fin du nom de domaine et voir si une page de connexion WordPress apparaît. Tu peux aussi regarder le code source en cherchant « wp-content » ou utiliser une extension de navigateur comme Wappalyzer qui affiche directement le CMS détecté.
Un site peut-il cacher totalement qu’il tourne sous WordPress ?
Il est possible de masquer beaucoup d’indices visibles grâce à des plugins de sécurité, des règles de réécriture d’URL et des thèmes très personnalisés. En pratique, toutefois, il reste souvent des traces dans les fichiers chargés, les en-tête HTTP ou certains endpoints comme /wp-json/. En croisant plusieurs méthodes, on parvient presque toujours à se faire une idée solide.
Pourquoi vérifier le CMS utilisé par un site concurrent ou un client ?
Identifier le CMS aide à estimer la complexité d’une refonte, le coût de maintenance, les marges d’évolution et même la maturité technique d’un projet. Pour un freelance ou une agence, cela sert aussi à proposer un accompagnement adapté, par exemple une optimisation ciblée sur WordPress plutôt qu’un changement complet de technologie.
Peut-on connaître le thème WordPress exact utilisé par un site ?
Souvent oui. En inspectant le code source, repère la feuille de style principale qui ressemble à /wp-content/themes/nom-du-theme/style.css. Des outils comme WPThemeDetector ou IsItWP peuvent aussi remonter le nom du thème et certains plugins, à condition qu’ils n’aient pas été renommés ou cachés.
Est-ce légal d’analyser le code source et les technologies d’un site ?
Oui, tant que tu te limites à ce qui est public : code source envoyé au navigateur, en-tête HTTP, ressources statiques, outils de détection de CMS. Ce qui est interdit, c’est de tenter de forcer l’accès à des zones protégées, d’exploiter des failles ou d’utiliser ces informations pour nuire au site.
