Repérer la technologie derrière un site n’est pas un détail technique anodin: cela aide à juger sa structure, sa maintenabilité, ses possibilités d’évolution et parfois même sa sécurité. Pour savoir si un site est WordPress, je m’appuie toujours sur plusieurs indices concrets: le code source, certaines adresses classiques, les outils de détection et les cas où le site a volontairement masqué ses traces. Le vrai sujet, ce n’est pas de trouver un seul marqueur, mais de savoir lesquels se recoupent vraiment.
Les vérifications les plus utiles pour reconnaître WordPress
- Les chemins wp-content, wp-includes et wp-admin sont les indices les plus parlants.
- La page de connexion et l’API REST donnent souvent une réponse rapide, même sans accès au back-office.
- Les outils automatiques comme Wappalyzer font gagner du temps, mais ils ne remplacent pas une vérification manuelle.
- Un site peut cacher son générateur, ses plugins et son thème sans sortir de WordPress.
- Les sites headless sont les plus trompeurs, car WordPress n’y sert parfois que de moteur d’administration.
Les indices visibles dès le premier regard
Quand je veux aller vite, je commence par regarder ce que le navigateur montre sans aucun outil spécialisé. Un site WordPress laisse souvent des traces dans les chemins des fichiers, dans certains noms de classes CSS et dans des liens qui pointent vers des dossiers très reconnaissables.| Indice | Ce que cela suggère | Fiabilité |
|---|---|---|
/wp-content/ |
Le site charge probablement des thèmes, images ou scripts WordPress depuis le répertoire standard. | Élevée |
/wp-includes/ |
Des fichiers du noyau WordPress apparaissent dans les ressources ou le code source. | Élevée |
/wp-admin/ |
Le site expose le point d’entrée habituel de l’administration WordPress. | Élevée |
wp-block-* |
Le site utilise souvent l’éditeur de blocs ou des composants natifs WordPress. | Moyenne à élevée |
meta name="generator" |
WordPress peut encore être explicitement mentionné dans le code si le site ne l’a pas masqué. | Moyenne |
Dans la pratique, ce sont surtout les chemins de fichiers qui parlent. Les classes CSS ou le meta generator sont utiles, mais je les considère comme des indices secondaires, pas comme une preuve suffisante. Si tu vois plusieurs marqueurs cohérents, le doute diminue rapidement. Si tu n’en vois qu’un seul, je reste prudent, parce qu’un thème ou un plugin peut très bien réutiliser un préfixe WordPress sans que tout le site repose sur cette plateforme. C’est justement pour éviter les conclusions trop rapides qu’il faut ensuite ouvrir le code source.
Le code source reste la méthode la plus fiable
La vérification manuelle du code source me donne presque toujours une meilleure lecture que l’œil nu. Sur un navigateur, je préfère afficher le code source de la page, puis utiliser la recherche interne pour tester des chaînes simples comme wp-content, wp-includes, wp-json ou wp-block.
- Je cherche les chemins d’assets qui pointent vers un thème ou un plugin WordPress.
- Je vérifie si les fichiers CSS et JS viennent de répertoires standards du CMS.
- Je repère les classes générées par l’éditeur de blocs si le site publie du contenu éditorial classique.
- Je regarde si la page charge des références à l’API REST WordPress.
- Je teste plusieurs pages, car un site très optimisé peut masquer des indices sur la page d’accueil mais pas ailleurs.
Le piège le plus courant, c’est de s’arrêter à une seule page minifiée et cachée derrière un CDN. Le chargement peut être très propre, mais les chemins des ressources finissent souvent par trahir la plateforme. Une fois cette étape faite, il devient utile de tester les adresses WordPress classiques, parce qu’elles donnent souvent une réponse plus directe encore.
Les adresses WordPress qui répondent presque toujours
Quand le code source ne suffit pas, je passe aux URL typiques. C’est simple, rapide, et souvent révélateur. Si le site est bien configuré, certaines de ces adresses renvoient une redirection, une page de connexion ou une réponse JSON caractéristique.
| Adresse à tester | Ce que je cherche | Ce que ça m’apprend |
|---|---|---|
/wp-admin/ |
Redirection vers l’écran de connexion ou le tableau de bord. | Très souvent un signal fort de WordPress. |
/wp-login.php |
Formulaire de connexion WordPress. | Indice très fort, sauf si l’accès a été personnalisé. |
/wp-json/ |
Réponse de l’API REST. | Signal utile, surtout si le site publie du contenu dynamique. |
/wp-content/ |
Ressources publiques du thème ou des extensions. | Très bon indicateur si un fichier CSS ou JS se charge correctement. |
/readme.html |
Fichier d’information parfois laissé accessible. | Ancien indice, encore utile, mais souvent supprimé. |
Je ne confonds jamais une réponse absente avec une preuve d’absence. Un 404, un 403 ou une redirection bizarre peuvent simplement venir d’un plugin de sécurité, d’un pare-feu applicatif ou d’une règle serveur. En clair, si /wp-admin/ ne répond pas comme prévu, cela ne veut pas dire que le site n’est pas WordPress. Cela veut juste dire qu’il protège mieux ses accès. C’est là que les outils automatiques deviennent utiles, mais seulement si on sait les lire avec recul.
Les outils automatiques qui accélèrent le diagnostic
Pour un premier passage, j’aime bien utiliser un détecteur de technologies comme Wappalyzer ou un service du même type. Leur intérêt est simple: ils croisent plusieurs signaux que l’œil humain peut rater, par exemple les en-têtes HTTP, les scripts chargés, les cookies ou certaines signatures HTML.
Je les trouve particulièrement utiles dans trois cas:
- quand je dois vérifier rapidement plusieurs sites d’un coup;
- quand le code source est trop long ou trop minifié pour être lu confortablement;
- quand je veux une deuxième opinion avant de conclure.
En revanche, je ne leur donne jamais le dernier mot. Un outil automatique peut surdétecter WordPress parce qu’un thème tiers réutilise une convention connue, ou sous-détecter un site très bien caché. La bonne méthode, à mon sens, consiste à traiter l’outil comme un raccourci, pas comme une preuve. Si l’extension annonce WordPress mais que le code source ne montre aucun indice cohérent, je vérifie encore. Si le site est difficile à lire, je passe à la question suivante: pourquoi les traces ont-elles disparu?
Pourquoi certains sites WordPress passent sous le radar
Beaucoup de sites WordPress ne se présentent plus de façon évidente. C’est encore plus vrai sur les projets un peu sérieux, où l’équipe technique a volontairement réduit les indices visibles. En 2026, je rencontre souvent des sites qui masquent leurs traces pour des raisons de sécurité, de performance ou de branding.
- Le cache et le CDN peuvent nettoyer le HTML, compresser les fichiers et supprimer les commentaires ou métadonnées inutiles.
- Les plugins de sécurité peuvent cacher la page de connexion, réécrire les chemins ou enlever le meta generator.
- Les thèmes sur mesure peuvent éliminer les signatures habituelles du noyau WordPress dans le front-end.
- Le mode headless est le plus trompeur: WordPress sert alors surtout de back-office, tandis que le site public est rendu par un autre front-end.
- Les exports statiques ou certaines architectures hybrides brouillent encore davantage les pistes.
Je vois souvent la même erreur chez les débutants: ils pensent qu’un site sans wp-content visible n’est pas WordPress. En réalité, c’est simplement un site mieux protégé ou mieux architecturé. L’inverse est vrai aussi: la présence d’un seul chemin qui contient wp- ne suffit pas à prouver quoi que ce soit. Le bon réflexe consiste à distinguer les indices faibles des indices structurels, puis à regarder s’ils racontent la même histoire. C’est exactement ce que j’applique dans une vérification finale.
Quand deux signaux suffisent pour décider
Quand je dois trancher sans perdre de temps, je fonctionne avec une logique de confiance. Un seul indice reste une hypothèse. Deux indices indépendants me donnent déjà une lecture sérieuse. Trois signaux cohérents, surtout s’ils viennent de couches différentes du site, me permettent généralement de conclure.
| Nombre de signaux cohérents | Mon niveau de confiance | Décision pratique |
|---|---|---|
| 1 | Faible | Je note une piste, mais je ne conclus pas. |
| 2 | Bonne | Je considère WordPress comme probable. |
| 3 ou plus | Très bonne | Je considère l’identification comme solide. |
Ma méthode la plus fiable reste simple: je combine la source, une ou deux URL typiques et un outil automatique. Si les trois racontent la même chose, je n’ai pas besoin d’insister davantage. Si le site est volontairement masqué, j’accepte l’incertitude plutôt que de forcer une réponse. C’est souvent la différence entre une supposition rapide et un diagnostic réellement utile.
