Examinez les indices WordPress publics, la découverte REST et les fichiers visibles des thèmes et extensions, sans certitude artificielle sur le serveur.
Examinez les indices WordPress publics, la découverte REST et les fichiers visibles des thèmes et extensions, sans certitude artificielle sur le serveur.
https://clocktools.app/Inspectez seulement une destination autorisée. Les paramètres de l’URL initiale sont retirés ; ne transmettez aucun secret.
wp/v2 · wp-contentComparez espaces de noms REST, métadonnées du générateur et chemins de fichiers. Un échec d’accès n’est pas une preuve d’absence.
JSONExportez le rapport daté pour une migration ou une passation. Les noms visibles ne forment pas un inventaire complet.
Avant de chiffrer une migration, inspectez séparément l’accueil et une page publique représentative. Notez URL finale, preuves REST, chemins de thèmes et slugs de plugins. Demandez ensuite l’inventaire réel et le mode de déploiement au propriétaire. Les indices cadrent les questions sur formulaires et contenus, sans établir l’effort ni toutes les dépendances serveur.
Après un changement de thème ou de plugin, une page peut référencer d’anciens fichiers. Exportez un rapport daté et rapprochez-le de la configuration et du cache actuels. Vérifiez la même page anonymement avant une purge. Un générateur ou stylesheet périmé décrit la réponse servie, pas une nécessité de réinstaller WordPress.
Pour transmettre un incident, gardez JSON plutôt que le seul score. Réponse, sondes échouées et exemples de chemins expliquent ce qui a été observé. Retirez les URL sensibles des tickets. Le partage prépare une nouvelle inspection, sans transmettre votre session ni reproduire automatiquement les anciennes preuves.
WordPress documente la relation https://api.w.org/ dans les liens HTML ou l’en-tête HTTP Link. Elle permet de trouver la racine de l’API même si l’installation est dans un sous-répertoire. Le vérificateur y recherche les espaces de noms du cœur.
wp/v2 est un indice significatif. Un accès REST infructueux ne prouve pourtant pas l’absence de WordPress : pare-feu, restrictions et architecture découplée peuvent le masquer. Le score additionne des poids jusqu’à 100 ; ce n’est pas une probabilité statistique. Guide WordPress de découverte REST.
Un chemin de thème peut révéler un identifiant ; l’en-tête public de style.css peut donner un nom, une version ou un thème parent. Ces valeurs peuvent être anciennes ou modifiées. Un thème enfant ne se confond pas avec son parent.
Les chemins d’extensions n’exposent que les références de la réponse inspectée. Une extension côté serveur, des fichiers regroupés ou des dossiers renommés peuvent rester invisibles. Une version publiée ne prouve ni sécurité, ni licence, ni inventaire complet. Documentation WordPress des feuilles de style.
La page annonce un générateur WordPress et des images wp-content, mais l’API répond 404. Export, cache ou API protégée sont possibles. Demandez au propriétaire comment la page est produite et servie ; ne présentez pas un serveur WordPress actif comme un fait établi.
Chaque signal est trouvé, non trouvé ou indisponible. Non trouvé décrit l’absence de l’indice dans la réponse inspectée. Indisponible signifie que la requête ou réponse n’était pas exploitable. Si un pare-feu sert une erreur, l’absence de chemin de thème renseigne peu sur la véritable page des visiteurs. La vue compacte montre les six premières lignes de signaux et les principaux champs techniques. Exportez JSON pour la liste complète et les métadonnées de stylesheet retournées, y compris les indices absents de cette vue.
Les poids sont explicites : cœur REST 45, générateur WordPress 35, découverte 25, chemins content et includes 20 chacun, scripts reconnus 15, préfixes de cookies 12, découverte de publication 10 et pingback 8. La somme est plafonnée à 100. Dix références d’un plugin ne créent pas dix signaux indépendants ; nombre d’assets et poids d’indice répondent à deux questions.
Le verdict dépend aussi de la page principale. Échec, erreur, troncature ou contenu non HTML restent non concluants malgré des indices. Avec HTML exploitable, cœur REST plus autre indice, ou trois indices au moins totalisant 55, donnent des preuves fortes. Sinon, 30 ou plus peuvent donner probable ; un petit score positif reste non concluant. Ce sont des règles de calcul, pas des probabilités ni un accès au backend.
| Indices observés | Score | Interprétation |
|---|---|---|
wp-content seulement | 20 | Non concluant : un chemin est un indice limité. |
| Générateur seulement | 35 | Probable avec HTML exploitable, sans preuve du backend. |
wp/v2 et découverte | 70 | Preuves publiques fortes avec HTML exploitable. |
| Plusieurs indices sur une page HTTP 403 | Selon les indices | Non concluant : page prévue non entièrement inspectée. |
| Aucun indice dans du HTML exploitable | 0 | Aucun signal public, pas zéro pour cent de probabilité. |
Le vérificateur privilégie l’URL de découverte publiée dans un en-tête Link ou le HTML. Sinon, il dérive un candidat wp-json/ depuis les chemins content visibles ou l’origine. Il ne parcourt pas tous les répertoires. Une publication sous /news/ peut donc différer d’un accueil servi par un autre système, surtout sans relation API utile sur l’accueil.
La documentation de découverte REST définit la relation https://api.w.org/. L’outil vérifie ensuite si le candidat retourne des espaces de noms ou routes du cœur. Un lien API et un index exploitable sont des lignes distinctes : publier une adresse ne prouve pas que son endpoint a fonctionné pendant la vérification.
Les espaces de noms personnalisés restent utiles, sans devenir automatiquement un inventaire de plugins : thèmes et code propre peuvent aussi enregistrer des routes. RSD, Windows Live Writer et X-Pingback apportent des indices plus légers. ClockTools lit leurs références sans envoyer de requête de publication ni tester d’identifiants. Désactiver une interface peut modifier les indices sans changer le CMS.
Un asset sous /wp-content/themes/atelier/ révèle un slug de répertoire. Le candidat principal a le plus de références, avec ordre alphabétique en cas d’égalité ; ce n’est pas le réglage du thème actif. ClockTools peut lire son style.css conventionnel et les champs d’en-tête disponibles. Sans nom publié, le slug reste un slug, pas un produit inventé.
Deux répertoires de thèmes demandent une explication, pas une alerte automatique de conflit. Dans le modèle de thème enfant, Template indique le répertoire parent. Avec atelier-child et atelier, demandez où vivent les personnalisations et les fichiers parent. Cache ou ressource indépendante peuvent aussi expliquer un second slug. Confirmez l’architecture dans l’administration avant une mise à jour.
Les références sous /wp-content/plugins/ et /wp-content/mu-plugins/ sont regroupées par slug et nombre d’assets. La documentation des extensions indispensables explique leur chargement particulier, mais un chemin visible ne révèle pas toute l’installation. Une page de contact peut charger un formulaire absent de l’accueil. Inspectez-la séparément pour une migration, puis rapprochez les résultats de l’inventaire actif et must-use du propriétaire.
Plugins serveur, bundles, chemins personnalisés et réécritures CDN peuvent rester invisibles. Un cache peut au contraire conserver une référence supprimée. Une version de thème concerne le thème ; un ?ver= arbitraire ne donne pas la version du cœur. Cette dernière n’est lue que dans une déclaration explicite de générateur. Un champ vide est donc souvent justifié.
Theme Name est le nom affiché publié ; Author et Theme URI sont des déclarations d’attribution. Text Domain désigne un domaine de traduction, pas l’hôte du site. Ces champs peuvent aider à retrouver la documentation prévue, mais restent du texte modifiable. Ils n’authentifient ni propriété, ni droits de licence, ni disponibilité d’une mise à jour pour les fichiers servis.
Un site traditionnel sert du HTML WordPress, un cache une copie antérieure. Un export statique peut conserver balisage et chemins sans exécuter WordPress à chaque visite. Un frontend headless peut recevoir du contenu d’un service WordPress privé ou distinct sans publier de chemins familiers. L’inspection porte sur la livraison, pas toute la chaîne de production.
Cela explique deux surprises. Un score élevé sur un export peut décrire correctement les indices publics, alors qu’une affirmation sur un backend actif serait fausse. Aucun signal sur un frontend headless peut aussi être correct alors que les rédacteurs utilisent WordPress. Demandez où le contenu est créé, construit et servi ; ces réponses sont plus utiles à un projet qu’une discussion sur une étiquette.
Dans l’exemple fixe d’export, générateur et wp-content sont visibles, sans cœur REST exploitable. Ils totalisent 55, mais deux indices seuls ne remplissent pas la règle des trois indices forts ; avec HTML exploitable, le verdict peut être probable. Si la page est bloquée ou tronquée, il reste non concluant. Des indices de publication copiés peuvent encore augmenter le score sans prouver un backend actif.
Commencez par URL saisie et URL finale. Une redirection peut mener à un autre hôte, une traduction ou une page de contrôle. Comparez statut et quantité inspectée avant les noms de composants. Un HTML tronqué peut cacher les indices plus tardifs ; la liste n’est alors pas exhaustive. Vérifiez quelle réponse publique a réellement été inspectée.
La vérification est anonyme et bornée : une page, un candidat REST et éventuellement un stylesheet de thème. Elle n’exécute pas JavaScript. Les paramètres initiaux sont retirés, donc une page dépendant d’une query peut différer du navigateur. Ne contournez pas cela avec une prévisualisation signée ou un lien de connexion. Utilisez un chemin public normal et testez localement les pages authentifiées.
Gardez la ligne indisponible d’une API bloquée ou limitée, réessayez plus tard et examinez vos règles si nécessaire. Ne désactivez pas une protection pour augmenter le score. Vérifiez versions et mises à jour dans le système authentifié : aucune comparaison de vulnérabilités n’est effectuée ici. Une correction utile contient URL sûre, heure, indice attendu et réponse publique, pas seulement un score contesté.
L’outil inspecte du HTML public anonyme borné, un candidat REST et un stylesheet de thème disponible, avec destinations publiques validées et redirections limitées. Il ne transmet pas votre connexion et n’exécute pas JavaScript. Indices trouvés, absents et indisponibles restent séparés. Les composants décrivent des références exposées ; historique et JSON ne sont pas des inventaires authentifiés.
Des indices forts ne sont pas une certitude. Les contenus peuvent être copiés, mis en cache ou trompeurs. Aucun indice ne permet d’exclure un serveur WordPress caché. Ce n’est ni un scan de vulnérabilités, ni un inventaire des extensions, ni une inspection authentifiée.
Signalez un problème reproductible via la page Contact en indiquant l’URL de l’outil, une entrée non confidentielle, l’heure de vérification, le résultat attendu et la preuve source. Joignez si possible la réponse publique, sans données de compte ni lien secret. Une modification de la source n’est pas forcément une erreur de calcul. Comparez le même nom, la même page et le même instant.
Non. Il additionne des poids explicites avec plafond, et le verdict tient aussi compte de l’exploitabilité du HTML. Lisez preuves et état de réponse. Zéro peut correspondre à un frontend headless ; un score élevé à une copie ou un cache. Aucun n’est une probabilité mesurée.
La page prévue peut être bloquée, tronquée, non HTML ou en erreur. Des indices survivants ne rendent pas les absences interprétables. Gardez le rapport, vérifiez URL finale et statut et inspectez une page publique normale plutôt que d’imposer une réponse oui ou non.
Oui. Générateur, chemins et découverte peuvent survivre à un export ou un cache. Le résultat décrit ces indices. Demandez au propriétaire comment les pages sont produites et servies pour distinguer export et application active ; une chaîne privée de construction n’est pas observable ici.
Non. Il est choisi parmi les répertoires référencés publiquement, pas dans les réglages d’administration. Thème enfant, parent, cache ou ressource annexe peuvent exposer plusieurs slugs. Lisez les métadonnées et confirmez l’organisation avant d’installer, acheter ou mettre à jour un thème de nom similaire.
Non. Seuls les chemins d’assets reconnaissables de la page sont regroupés. Un formulaire peut apparaître sur la page contact, et un plugin serveur jamais. Les espaces de noms REST restent des indices API, pas des affirmations automatiques de plugins.
Ces valeurs peuvent concerner un plugin, un thème ou un build de cache. ClockTools n’en déduit pas le cœur. Une déclaration explicite du générateur peut fournir un indice ; sinon, consultez le système authentifié plutôt que de choisir un numéro d’asset.
Non. Le candidat peut être restreint, indisponible ou inadapté à l’installation. Relation de découverte et espace de noms exploitable sont séparés. Examinez aussi le HTML et, pour votre site, la route prévue et sa politique d’accès sans supprimer une protection pour le détecteur.
Non. Elle ne teste pas les connexions, utilisateurs, exploits ou bases de vulnérabilités. Les noms exposés aident à revoir la divulgation publique, pas à évaluer tout le système. Utilisez un inventaire authentifié et une démarche de sécurité autorisée pour ce travail distinct.
Cookies et autorisation ne sont pas transmis, JavaScript ne tourne pas et la query initiale est supprimée. Votre navigateur peut recevoir une page personnalisée, un autre cache ou une API authentifiée. Comparez le même chemin anonymement et gardez URL finale et heure.