L'une des questions les plus fréquentes est : „J'ai le plugin X installé, mais le rapport ne le liste pas.“ C'est presque toujours un comportement attendu, pas un bug. InspectWP effectue une seule visite anonyme de votre site, comme n'importe quel visiteur, et travaille uniquement avec ce qui est publiquement visible. Cet article explique ce que cela signifie en pratique.
1. Comment fonctionne la détection en principe
InspectWP charge l'URL que vous fournissez, exactement une fois, avec un véritable navigateur headless. Nous regardons ensuite :
- Le HTML rendu et les scripts inline.
- Tous les fichiers CSS et JavaScript chargés par la page.
- Les URL d'images et de polices, en particulier leurs chemins.
- Les en-têtes de réponse HTTP et les cookies.
- Les balises meta et les données structurées.
À partir de ces signaux, nous déduisons quel plugin ou thème est utilisé. Nous ne nous connectons pas à votre site, nous n'accédons pas à wp-admin, et nous ne lisons pas directement votre répertoire wp-content. Nous voyons seulement ce que n'importe quel visiteur anonyme verrait.
2. Pourquoi un plugin peut être invisible
Plusieurs raisons légitimes peuvent expliquer qu'un plugin n'apparaisse pas :
- C'est un plugin uniquement back-office. De nombreux plugins (outils d'administration, plugins de sauvegarde, outils de préproduction, vérificateurs SEO internes, gestionnaires de rôles) ne produisent jamais rien sur le frontend. Il n'y a rien à détecter.
- Il ne se charge que sur certaines pages. Un plugin de réservation peut ne charger ses ressources que sur la page de réservation. Si vous analysez votre page d'accueil, il n'apparaîtra pas. Essayez d'analyser la page où le plugin est réellement utilisé.
- Il ne se charge que pour les utilisateurs connectés. Un plugin d'espace membres peut ne rien charger pour les visiteurs anonymes. Même effet que ci-dessus.
- Une optimisation agressive le masque. Les plugins de cache et d'optimisation peuvent combiner, minifier ou renommer les ressources au point que le nom original du plugin n'est plus reconnaissable. Voir section 4.
- C'est un plugin très récent ou très de niche. La détection fonctionne mieux pour les plugins qui laissent une empreinte reconnaissable et stable. Les nouvelles versions ou les plugins faits maison peuvent ne pas encore figurer dans nos règles de reconnaissance.
- Le plugin était désactivé. Un plugin désactivé ne charge rien sur le frontend. À vérifier dans Extensions → Extensions installées.
3. Pourquoi un thème peut être mal identifié
La détection de thème est généralement assez fiable, car les thèmes laissent typiquement des traces claires dans les chemins des ressources (/wp-content/themes/votre-theme/...). Cela peut quand même mal se passer :
- Thèmes enfants : Si vous utilisez un thème enfant, vous pouvez voir à la fois le parent et l'enfant listés. C'est correct : WordPress charge les deux.
- Thèmes renommés : Certaines agences renomment un dossier de thème parent pour des raisons de marque. Si le nouveau nom de dossier ne correspond à rien dans nos règles de reconnaissance, le thème apparaît comme „inconnu“ ou avec le slug renommé.
- Page builders qui livrent leur propre thème : Certains page builders remplacent effectivement le thème. Le thème détecté est alors le thème de base du builder, pas ce à quoi vous pourriez vous attendre.
- Multisite avec surcharges de thèmes : Sur un multisite, le thème actif peut différer par sous-site. Assurez-vous d'avoir analysé la bonne URL.
4. Le piège de l'optimisation des ressources
C'est la raison la plus fréquente de plugins manquants sur des sites par ailleurs normaux. Des plugins comme WP Rocket, LiteSpeed Cache, Autoptimize, W3 Total Cache, Perfmatters ou les optimiseurs CDN intégrés peuvent faire tout ce qui suit :
- Combiner de nombreux fichiers CSS en un seul gros fichier avec un nom générique comme
combined-abc123.css. - Combiner de nombreux fichiers JavaScript de la même manière.
- Minifier et obscurcir le contenu des fichiers.
- Réécrire les chemins des ressources vers un CDN, en supprimant le préfixe
/wp-content/plugins/.... - Inliner le CSS critique pour que la feuille de style originale ne soit plus demandée.
Quand tout cela tourne en même temps, les signatures individuelles des plugins disparaissent. Le plugin fonctionne toujours parfaitement sur votre site, nous ne pouvons simplement pas le voir de l'extérieur.
5. CDN, reverse proxy et caches edge
Si votre site est derrière Cloudflare, BunnyCDN, KeyCDN ou un cache edge d'hébergeur géré, la réponse que nous voyons peut déjà être fortement transformée. Certaines fonctionnalités de CDN (Rocket Loader, minification automatique, Mirage, Polish) modifient en outre le HTML et les ressources. Les plugins sont toujours là, l'empreinte publique a simplement changé.
6. Rendu côté serveur et applications JavaScript
Les sites construits avec un WordPress headless (un frontend JavaScript qui dialogue avec WordPress via REST ou GraphQL) exposent généralement très peu de signaux WordPress traditionnels. Le frontend est essentiellement une application personnalisée. Dans ces cas, la détection de WordPress lui-même, sans parler des plugins individuels, est limitée ou impossible depuis l'extérieur.
7. Que faire quand quelque chose manque
- Analysez la page où le plugin est réellement utilisé, pas seulement la page d'accueil.
- Analysez en tant que visiteur déconnecté, dans un onglet de navigation privée, pour voir la même vue qu'InspectWP voit.
- Désactivez temporairement la combinaison de fichiers dans votre plugin de cache et relancez l'analyse.
- Vérifiez si le plugin produit réellement quelque chose sur le frontend (Voir le code source dans votre navigateur).
- Si vous êtes certain que le plugin produit une sortie frontend et qu'il manque toujours, écrivez-nous à hello@inspectwp.com avec l'URL du rapport et le nom du plugin. Nous étendons continuellement nos règles de reconnaissance.