Tech Stack Detector
Erkennt 655 Technologien in 31 Kategorien, darunter KI-Builder (v0, Lovable), Code-Assistenten (Claude, Cursor), BaaS (Supabase, Firebase), Feature Flags und Realtime. Vier Quellen: HTML, Header, Cookies und DNS.
Was dieser Tech Stack Detector findet
Dieser Tech Stack Detector prüft vier Datenquellen gleichzeitig: das HTML der Seite, die HTTP-Response-Header, Cookies und DNS-Einträge. Das HTML kommt nach Möglichkeit aus einem Headless-Browser, damit auch per JavaScript nachgeladene Skripte auftauchen. Klappt das Rendern nicht, nimmt das Tool den rohen Quelltext. Abgedeckt sind 655 Signaturen in 31 Kategorien: CMS, Analytics, Tag Manager, Consent-Tools, SEO-Plugins, A/B-Testing, Frameworks, CDNs, Hosting, Domain-Verifizierungen, Backend-as-a-Service (Supabase, Firebase, Convex), Feature Flags (LaunchDarkly, Statsig), Buchungstools (Calendly, Cal.com), Realtime (Pusher, Liveblocks), KI-Site-Builder und Code-Assistenten (v0, Lovable, Claude, Cursor) sowie CSS-Frameworks (Tailwind, UnoCSS, Panda).
Wurde die Seite mit KI gebaut?
Eine berechtigte Frage, seit KI-Site-Builder (v0.dev, Lovable, Bolt.new) und KI-Code-Assistenten (Claude Code, Cursor, Copilot) echte Produktivseiten ausliefern. Das Tool sucht zwei Arten von Hinweisen: direkte Builder-Signaturen (v0-Deployment-Marker, Lovable-Hostnamen, explizite HTML-Kommentare wie <!-- generated with Claude -->) und Heuristiken (shadcn/ui + Radix + lucide-react, auffällig lange Tailwind-Klassenketten, KI-typische Marketingfloskeln). Das Panel „AI Build Signals“ wertet eine explizite Signatur als Treffer, zwei oder mehr Heuristiken als „wahrscheinlich teilweise KI-gebaut“ und eine einzelne als schwaches Signal. Wer als Mensch sauber mit shadcn/ui baut, erfüllt dieselben Heuristiken. Nimm sie also als „vielleicht“, solange keine explizite Signatur dazukommt.
Warum vier Quellen? Ein reiner HTML-Scanner sieht Skripte, die per <script src> geladen werden. Was in den Response-Headern steht (CDN, Hosting, Server) und in den DNS-Einträgen (SaaS wie Google Workspace, Microsoft 365, Stripe), bleibt ihm verborgen. Cookies liefern eine weitere Ebene: die Namen, die der Server per Set-Cookie setzt, und Namen aus Inline-Aufrufen von document.cookie. Jeder Treffer trägt ein Quellen-Badge (HTML, HDR, CK, DNS), damit du siehst, woher er stammt.
Warum zeigt das Tool Cloudflare für eine Seite auf Netlify oder Vercel?
Weil Cloudflare davor sitzt. Läuft ein DNS-Eintrag über den Cloudflare-Proxy (die orange Wolke), beendet Cloudflare die TLS-Verbindung, setzt eigene Header wie Server: cloudflare und CF-RAY und holt die Seite im Hintergrund von Netlify oder Vercel. Die übrigen Header des Hosters kommen meist trotzdem durch, etwa x-vercel-id. Deshalb listet der Scan oft beide.
Die Cloudflare-Header zählt das Tool nur, wenn der Hostname der Seite auf IP-Adressen von Cloudflare zeigt. Prüfen muss es das, weil der Scanner selbst auf einem Cloudflare Worker läuft: Dessen Anfragen kommen bei jeder Seite mit den Headern Server: cloudflare und CF-RAY zurück. Scans vor dem 30. September 2026 haben diese Header der Seite zugeschrieben und deshalb fast überall Cloudflare gemeldet. Liegt eine Seite nicht hinter Cloudflare, liest das Tool den tatsächlichen Server-Header jetzt direkt beim Server. So tauchen nginx, Apache und LiteSpeed überhaupt erst auf.
Privacy- und Consent-Audit: Was wird wirklich geprüft?
Findet das Tool einen Consent Manager (Cookiebot, OneTrust, Usercentrics, Borlabs usw.) und gleichzeitig Tracking-Skripte, prüft es, ob ein Tracker-Loader im HTML-Quelltext VOR dem CMP-Skript steht. Diese Reihenfolge ist das typische Zeichen dafür, dass Tags feuern, bevor der Besucher eingewilligt hat. Es ist ein statischer Blick auf den Quelltext. Das Verhalten zur Laufzeit (Standardzustand von Consent Mode v2, was beim Laden wirklich feuert) prüfst du weiterhin im Netzwerk-Tab der Chrome DevTools.
Wie genau ist die Versionserkennung?
Versionen kommen aus drei Quellen, sortiert nach Verlässlichkeit: dem <meta name="generator">-Tag, eigenen Regex-Mustern pro Tool (etwa wp-emoji-release.min.js?ver=X.Y.Z für den WordPress-Core) und einem allgemeinen Name-at-Version-Fallback. Für WordPress, jQuery, Elementor, Next.js und React gibt es Mindestversionen. Alles darunter bekommt ein ⚠-Outdated-Badge, praktisch für Security-Audits.
Tech Stack Detector vs. Wappalyzer vs. BuiltWith
Die Browser-Extension von Wappalyzer läuft in deinem Browser und sieht dadurch auch ausgeführtes JavaScript, das ein abgerufener Quelltext verbergen kann. BuiltWith hat historische Daten über Jahre. Dieses Tool braucht keine Installation: Es rendert die Seite wenn möglich in einem Headless-Browser, nimmt DNS-Einträge dazu und legt einen Consent-Reihenfolge-Check und einen GEO-Mini-Score obendrauf. Für einen schnellen Blick auf einen Wettbewerber reicht das. Für die Historie nimm BuiltWith.
Ist ein Tech Stack Detector legal?
Ja. HTML und DNS liefert der Server öffentlich an jeden aus, der danach fragt. Was du lassen solltest: im großen Stil crawlen oder gescrapte Fingerprint-Datenbanken weiterverbreiten. Die Erkennung selbst ist unproblematisch.
Weitere Tools entdecken
Meta Tag Analyzer
Vollständiger Meta-Tag-Check für jede URL.
Crawler Access Checker
Prüft den Zugang von KI- und Such-Crawlern.
Link Analyzer
Interne und externe Links analysieren.
Security Headers
HTTP-Security-Header und Server-Konfiguration prüfen.
PageSpeed Insights
Voller Lighthouse-Audit mit Core Web Vitals.
FAQ
Lumina zeigt Analytics, CMS, Consent-Tools und SEO-Plugins automatisch, auf jeder Seite und kostenlos.
Lumina zu Chrome hinzufügen — Kostenlos