Een van de meest gestelde vragen is „Ik heb plug-in X geïnstalleerd, maar in het rapport staat hij niet.“ Dat is bijna altijd verwacht gedrag, geen bug. InspectWP voert één anoniem bezoek aan uw site uit, net als elke bezoeker, en werkt alleen met wat publiek zichtbaar is. Dit artikel legt uit wat dat in de praktijk betekent.
1. Hoe detectie in beginsel werkt
InspectWP laadt de URL die u opgeeft, precies één keer, met een echte headless browser. Vervolgens kijken we naar:
- De gerenderde HTML en inline scripts.
- Alle CSS- en JavaScript-bestanden die de pagina laadt.
- URL's van afbeeldingen en lettertypen, met name hun paden.
- HTTP-antwoordheaders en cookies.
- Metatags en gestructureerde data.
Op basis van deze signalen leiden we af welke plug-in of welk thema in gebruik is. Wij loggen niet in op uw site, hebben geen toegang tot wp-admin en lezen uw wp-content-map niet rechtstreeks. Wij zien alleen wat een willekeurige anonieme bezoeker zou zien.
2. Waarom een plug-in onzichtbaar kan zijn
Er zijn meerdere legitieme redenen waarom een plug-in niet verschijnt:
- Het is een backend-only plug-in. Veel plug-ins (admintools, back-upplug-ins, stagingtools, interne SEO-checkers, role managers) leveren nooit iets aan de frontend. Er is niets te detecteren.
- Hij laadt alleen op specifieke pagina's. Een boekingsplug-in laadt zijn assets misschien alleen op de boekingspagina. Crawlt u uw homepage, dan verschijnt hij niet. Probeer de pagina te crawlen waar de plug-in daadwerkelijk wordt gebruikt.
- Hij laadt alleen voor ingelogde gebruikers. Een ledenplug-in kan voor anonieme bezoekers niets laden. Hetzelfde effect als hierboven.
- Agressieve optimalisatie verbergt hem. Caching- en optimalisatieplug-ins kunnen assets combineren, minificeren of hernoemen tot de oorspronkelijke plug-in-naam niet meer herkenbaar is. Zie sectie 4.
- Het is een zeer nieuwe of zeer niche-plug-in. Detectie werkt het beste bij plug-ins die een herkenbare, stabiele footprint achterlaten. Nieuwe releases of zelfgemaakte plug-ins zitten mogelijk nog niet in onze herkenningsregels.
- De plug-in was gedeactiveerd. Een gedeactiveerde plug-in laadt niets aan de frontend. De moeite waard om dubbel te checken in Plug-ins → Geïnstalleerde plug-ins.
3. Waarom een thema onjuist kan worden geïdentificeerd
Themadetectie is doorgaans behoorlijk betrouwbaar, omdat thema's meestal duidelijke sporen achterlaten in de assetpaden (/wp-content/themes/uw-thema/...). Toch kan het misgaan:
- Child-thema's: gebruikt u een child-thema, dan ziet u mogelijk zowel het parent- als het child-thema vermeld. Dat klopt: WordPress laadt beide.
- Hernoemde thema's: sommige bureaus hernoemen een parent-themamap om brandingredenen. Komt de nieuwe mapnaam niet voor in onze herkenningsregels, dan verschijnt het thema als „onbekend“ of met de hernoemde slug.
- Page builders die hun eigen thema meeleveren: sommige page builders vervangen het thema feitelijk. Het gedetecteerde thema is dan het basisthema van de builder, niet wat u zou verwachten.
- Multisite met thema-overrides: in een multisite kan het actieve thema per subsite verschillen. Zorg dat u de juiste URL hebt gecrawld.
4. De asset-optimalisatieval
Dit is veruit de meest voorkomende reden voor ontbrekende plug-ins op verder normale sites. Plug-ins als WP Rocket, LiteSpeed Cache, Autoptimize, W3 Total Cache, Perfmatters of ingebouwde CDN-optimizers kunnen al het volgende doen:
- Veel CSS-bestanden combineren in één groot bestand met een generieke naam als
combined-abc123.css. - Veel JavaScript-bestanden op dezelfde manier combineren.
- Bestandsinhoud minificeren en obfusceren.
- Assetpaden herschrijven naar een CDN, waarbij de prefix
/wp-content/plugins/...wegvalt. - Critical CSS inline plaatsen zodat de oorspronkelijke stylesheet niet meer wordt opgevraagd.
Loopt dat allemaal tegelijk, dan verdwijnen individuele plug-in-handtekeningen. De plug-in werkt nog perfect op uw site, wij kunnen hem alleen van buitenaf niet zien.
5. CDN, reverse proxy en edge caches
Zit uw site achter Cloudflare, BunnyCDN, KeyCDN of een managed-host edge cache, dan kan het antwoord dat wij zien al sterk getransformeerd zijn. Sommige CDN-functies (Rocket Loader, automatische minificatie, Mirage, Polish) wijzigen HTML en assets nog verder. De plug-ins zijn er nog steeds, alleen de publieke fingerprint is veranderd.
6. Server-side rendering en JavaScript-apps
Sites die zijn gebouwd met headless WordPress (een JavaScript-frontend die via REST of GraphQL met WordPress communiceert) tonen meestal nauwelijks traditionele WordPress-signalen. De frontend is in feite een eigen app. In zulke gevallen is detectie van WordPress zelf, laat staan van individuele plug-ins, van buitenaf beperkt of onmogelijk.
7. Wat te doen wanneer iets ontbreekt
- Crawl de pagina waar de plug-in daadwerkelijk wordt gebruikt, niet alleen de homepage.
- Crawl als uitgelogde bezoeker, in een privétabblad, om dezelfde weergave te zien als InspectWP.
- Schakel bestandscombinatie in uw cachingplug-in tijdelijk uit en crawl opnieuw.
- Controleer of de plug-in daadwerkelijk iets uitvoert aan de frontend (Bekijk bron in uw browser).
- Bent u er zeker van dat de plug-in frontend-output produceert en toch ontbreekt, schrijf ons dan op hello@inspectwp.com met de URL van het rapport en de naam van de plug-in. Wij breiden onze herkenningsregels voortdurend uit.