Hoe de detector van RevealTheme werkt
Wanneer u een URL in een van onze detectoren invoert, gebeurt er veel in de twee seconden voordat u de resultaten ziet. Hier is de technische rondleiding voor de nieuwsgierigen, inclusief de beperkingen die wij niet met techniek kunnen oplossen.
Stap 1: De openbare HTML ophalen
Wanneer u een URL verzendt, haalt onze server de openbare webpagina van die URL op met een standaard browser-User-Agent. Het is dezelfde HTML die uw browser zou ontvangen als u de website rechtstreeks zou bezoeken. Wij omzeilen geen betaalmuren, halen geen content op die door een login wordt beschermd en gebruiken geen enkele vorm van authenticatie.
Het ophalen gebruikt een time-out van 20 seconden. Wij volgen tot 10 omleidingen (wat de omleidingen HTTP → HTTPS, www → zonder-www en de landomleidingen dekt). Als de website een 4xx- of 5xx-respons retourneert, of niet binnen het time-outvenster reageert, geven wij een duidelijke fout «niet bereikbaar» terug in plaats van te gokken.
Stap 2: Het platform detecteren
Voordat wij proberen een specifiek thema te identificeren, controleren wij welk CMS de website draait. Wij zoeken naar vingerafdrukken van de 7 ondersteunde platforms — WordPress, Shopify, Magento, Joomla, Drupal, Moodle en PrestaShop — en kiezen de sterkste overeenkomst.
Als u een Shopify-URL naar onze WordPress-detector stuurt (of andersom), vertellen wij u dat en linken wij naar de juiste detector. Geen gokwerk, geen valse positieven.
Stap 3: Themadetectie
Specifiek voor WordPress verschijnen verwijzingen naar het thema doorgaans in de HTML van de pagina in paden zoals wp-content/themes/THEMANAAM/style.css. Wij halen elk van die verwijzingen uit elk deel van het document: link-tags, script-tags, inline JavaScript, JSON-LD-blokken en zelfs de tekstinhoud. Zo detecteren wij thema's die sterk geoptimaliseerde websites voor standaard detectietools hebben verborgen.
Voor elk gedetecteerd thema proberen wij het bestand style.css van het thema op te halen. De header van dat bestand bevat de officiële naam van het thema, de auteur, de versie, de URI en de beschrijving, rechtstreeks van de ontwikkelaar van het thema. Dat is de bron van de rijke thema-informatie die wij naast het detectieresultaat tonen.
Stap 4: Plugindetectie
De plugindetectie gebruikt twee parallelle benaderingen. Ten eerste halen wij elk bestandspad eruit dat overeenkomt met wp-content/plugins/PLUGINNAAM/. Ten tweede voeren wij tientallen op handtekeningen gebaseerde controles uit: wij zoeken naar specifieke HTML-structuren, CSS-klassennamen, inline JavaScript-variabelen en HTTP-responsheaders die populaire plugins zoals Elementor, Yoast SEO, WPForms, WooCommerce, Wordfence en meer uniek identificeren.
Het ontwerp met de dubbele benadering detecteert plugins die hun bestandspaden verbergen (via caching of het bundelen van bronnen) maar toch onderscheidende handtekeningen achterlaten. Voor elke gedetecteerde plugin zoeken wij deze op in de WordPress.org-pluginmap om het resultaat te verrijken met de officiële naam van de plugin, de beschrijving, de auteur en de schermafbeeldingen.
Stap 5: Hosting- + DNS-opzoekingen
Om de hostingaanbieder te identificeren, doen wij een DNS-opzoeking op het domein en inspecteren wij het IP-adres, het ASN en de reverse-DNS. Wij koppelen dit aan een database met bekende IP-bereiken van hostingaanbieders om de aanbieder te identificeren. De nauwkeurigheid is hoog voor de grote hostingpartijen (AWS, Cloudflare, Hostinger, SiteGround, enz.) en lager voor nicheaanbieders.
Wat wij niet kunnen doen
Enkele gevallen waarin de detectie niet zal werken, hoe goed onze code ook is:
- Cloudflare-botuitdaging. Websites met strikte Cloudflare-botbescherming (het scherm «Bezig met beveiligingscontrole...») blokkeren onze ophaler net zoals ze elk geautomatiseerd verzoek zouden blokkeren. Er is geen nette manier om dit te omzeilen.
- Intensief aangepaste thema's. Als een thema zo sterk is gewijzigd dat elke verwijzing naar de oorspronkelijke themanaam uit de HTML is verwijderd, hebben wij niets om te detecteren.
- Agressieve caching met herschreven bronpaden. Plugins zoals LiteSpeed Cache, WP Rocket en Cloudflare Rocket Loader herschrijven soms de URL's van de bronnen om de bron te verbergen. Onze op handtekeningen gebaseerde detectie vangt de meeste hiervan op, maar niet alle.
- Statisch geëxporteerde websites. Een WordPress-website die naar statische HTML is geëxporteerd, verliest de meeste runtime-handtekeningen die detectie mogelijk maken.
Wat wij niet doen
Men heeft het ons gevraagd. De antwoorden zijn nee:
- Wij slaan de URL's die u verzendt niet op
- Wij registreren geen IP-adressen voor marketingdoeleinden
- Wij delen geen detectiegegevens met aanbieders
- Wij omzeilen geen authenticatie, robots.txt of andere toegangscontroles
- Wij draaien de detector niet op interne/privé-IP's (127.0.0.1, 10.x.x.x, enz.) om veiligheidsredenen
De volledige privacydetails staan in onze Privacybeleid.
API-toegang
Momenteel bieden wij geen openbare API, maar er is op verzoek beperkte programmatische toegang beschikbaar voor bureaus en onderzoekers. Schrijf naar hello@revealtheme.com met uw toepassing en het verwachte aanvraagvolume.
Waarom is het geen opensource?
De detectieregels zijn de kern van het product, en wij werken ze regelmatig bij naarmate thema's en plugins evolueren. Het opensource maken ervan zou onze updatesnelheid vertragen. Dat gezegd hebbende, publiceren wij gedetailleerde berichten over detectietechnieken op onze blog: zoek op «detectie» om ze te vinden.
Klaar om het te proberen?
Gebruik de detector die past bij de website die u wilt inspecteren: