CMS Detector

Welches CMS nutzt diese Website? Sehen Sie Plattform, Theme, Plugins und den ganzen Stack hinter jeder Website, jeweils mit der Codezeile, die es belegt.

7.600+ Technologien · Header, HTML und DNS der Website · ein echter Browser auf Wunsch
7.660 Technologien

Eine Domain oder eine vollständige URL mit Pfad. Wir veröffentlichen nie die Websites, die Sie prüfen.

Beispiel
Was wir lesenDNS · Header · HTML · Browser
Wir suchen nachPlattform 1.773Plugins 600Code 718Marketing 2.293Shop 659Chat 341Medien 467Server 212Netzwerk 465Sonstiges 132
DNSNS · MX · TXT
HeaderServer · Cookies · Links
<head>Meta · Skripte · Styles
<body>Markup · Skripte · Kommentare
BrowserJS · Anfragen

Jede Technologie, die wir finden, wird dort markiert, wo ihr Beleg steht: ein DNS-Eintrag, ein Antwort-Header, eine Zeile der Seite oder etwas, das ein echter Browser geladen hat.

CMS-Detector-Ergebnis: techcrunch.com läuft auf WordPress, mit Theme, Plugins und der Stelle jedes Belegs in der SeiteCMS-Detector-Ergebnis: techcrunch.com läuft auf WordPress, mit Theme, Plugins und der Stelle jedes Belegs in der SeiteJede WebsiteEine Domain oder eine vollständige URL mit Pfad: Die Seite wird live gelesen, nie aus einem alten Crawl.Die AntwortDie Plattform, ihre Version (bei WordPress mit dem neuesten Release abgeglichen) und das Theme.Wo wir es gefunden habenJede Technologie ist dort markiert, wo ihr Beleg steht: im DNS, in einem Header, in einer Zeile der Seite oder im Browser.Der BelegDas gewählte Signal genau so, wie die Website es gesendet hat: eine Header-Zeile, ein Tag oder ein Dateipfad; mit ‹ › blättern Sie durch alle.
Ein Ergebnis: die Plattform und ihre Version, das Theme und der Streifen, der jede Technologie dort markiert, wo ihr Beleg steht. Wählen Sie eine Nummer, um zu sehen, was der jeweilige Teil zeigt.

Wie funktioniert ein CMS Detector?

Er ruft die Seite einmal ab und gibt sich dabei mit eigenem Namen zu erkennen, dann sucht er nach den Merkmalen, die jede Plattform hinterlässt: in den Antwort-Headern, den Cookies, dem HTML und den Pfaden ihrer Dateien.

Manche Merkmale setzt die Plattform selbst, und sie lassen sich kaum fälschen oder entfernen: WordPress kündigt seine REST API in einem Link-Header an, Shopify setzt ein _shopify_essential-Cookie. Andere stehen in der Seite selbst und lassen sich entfernen oder kopieren: ein Generator-Tag, ein Klassenname, ein Kommentar.

Deshalb ist ein Merkmal, das jeder kopieren kann, ein Hinweis, während zwei unabhängige Merkmale oder eines, das nur die Plattform selbst setzt, ein Beweis sind. Jede Antwort oben zeigt die Merkmale, auf denen sie beruht, wörtlich so zitiert, wie wir sie gefunden haben, und wie sicher wir uns damit sind: Bestätigt, Wahrscheinlich oder Möglich.

Neben der Seite lesen wir die DNS-Einträge der Domain und bei einer WordPress-Website höchstens zwei weitere Dateien vom selben Host: die style.css des Themes und den /wp-json/-Index, auf den die Seite verweist. Ein echter Browser kommt nur hinzu, wenn Sie ihn anfordern.

Eine Antwort, acht Merkmale · nalgene.com, 24. Oktober 2026
  1. HTTP/2 200 · 23 Header
  2. 1Zeile 3server: cloudflare
  3. 2Zeile 7link: <https://nalgene.com/wp-json/>; rel="https://api.w.org/"
  4. 3Zeile 8link: <https://nalgene.com/wp-json/wp/v2/pages/87>; rel="alternate"; title="JSON"; type="application/json"
  5. 4Zeile 15set-cookie: __cf_bm=BZFgzmA1kpRQ…; HttpOnly; Secure
  6. HTML · 464 KB
  7. 5Byte 1.085<!-- This site is optimized with the Yoast SEO Premium plugin v28.0 (Yoast SEO v28.6) -->
  8. 6Byte 8.283<link rel='stylesheet' href='…/wp-content/themes/nalgene-twentytwenty/style.css?ver=9260242'>
  9. 7Byte 52.255<meta name="generator" content="WP Rocket 3.23.5.1">
  10. 8Byte 432.563<script src="…/wp-includes/js/wp-util.min.js?ver=7.1.3"></script>
  1. 1HeaderCloudflare liefert die Website ausBestätigt
  2. 2HeaderDie REST API von WordPress: von WordPress selbst gesetztBestätigt
  3. 3HeaderDie eigene REST-Adresse der Seite: wieder der WordPress-CoreBestätigt
  4. 4CookieCloudflare Bot ManagementBestätigt
  5. 5KommentarYoast SEO und seine VersionWahrscheinlich
  6. 6DateipfadDer Ordner des Themes, dann der Header seiner style.cssBestätigt
  7. 7GeneratorWP Rocket: selbst deklariert, leicht zu entfernenWahrscheinlich
  8. 8?ver=WordPress 7.1.3 an seinem eigenen Core-SkriptWahrscheinlich
Vier der 23 Antwort-Header von nalgene.com und vier Zeilen seiner 464 KB großen Seite. Das Generator-Tag von WordPress fehlt (es lässt sich abschalten), doch der REST-Header, die Dateipfade und die Version an den Core-Skripten nennen weiterhin WordPress 7.1.3.

CMS, Website-Baukasten, Headless CMS oder Framework?

Mit allen entstehen Websites, aber nur manche hinterlassen ihren Namen in der Seite. Wo die Inhalte liegen, entscheidet darüber, was ein CMS Detector sehen kann.

Ein klassisches CMS wie WordPress speichert die Inhalte und erzeugt jede Seite selbst, daher finden sich seine Merkmale überall. Ein Website-Baukasten wie Wix hostet die Website zusätzlich, daher verraten ihn seine Datei-Hosts.

Ein Headless CMS wie Contentful speichert nur Inhalte; ein separates Frontend, oft Next.js, rendert die Seite, sodass höchstens der Bild-Host des CMS zu sehen ist. Ein statischer Website-Generator wie Hugo erzeugt vorab reines HTML und hinterlässt höchstens ein Generator-Tag auf der Startseite.

Wo die Inhalte liegen und was die Seite erreicht
Klassisches CMSWordPress
  1. Inhalte + Theme
  2. von WordPress gerendert
  3. auf eigenem Server
  4. Die Seite

Was die Seite zeigt

/wp-content/rel="https://api.w.org/"<meta name="generator">

Der Detector meldetWordPressBestätigt

Website-BaukastenWix
  1. Inhalte
  2. von Wix gerendert
  3. von Wix gehostet
  4. Die Seite

Was die Seite zeigt

static.wixstatic.com/mediax-wix-request-idserver: Pepyaka

Der Detector meldetWixBestätigt

Headless CMSContentful + Next.js
  1. Inhalte in Contentful
  2. über eine API abgerufen
  3. von Next.js gerendert
  4. Die Seite

Was die Seite zeigt

/_next/static/images.ctfassets.net

Der Detector meldetKein CMS in der SeiteMöglich

Statischer Website-GeneratorHugo
  1. Markdown-Dateien
  2. einmal zu HTML gebaut
  3. als einfache Dateien ausgeliefert
  4. Die Seite

Was die Seite zeigt

<meta name="generator" content="Hugo …">nur Startseite

Der Detector meldetHugoWahrscheinlich

Was jede Art von System im HTML hinterlässt, das ein Besucher erhält. W3Techs zählt in seiner Erhebung alle vier als CMS; ein Detector kann nur die benennen, die ein Merkmal hinterlassen.

Welches WordPress-Theme und welche Plugins nutzt eine Website?

Lesen Sie die Ordnernamen in den Dateipfaden der Seite. Ein WordPress-Theme-Detector entnimmt den Ordner des Themes aus /wp-content/themes/<name>/ und öffnet dann die style.css dieses Themes, deren Header das Theme, seinen Autor, seine Version und bei einem Child-Theme auch das Eltern-Theme nennt.

Der Header ist der Ausweis des Themes, festgelegt im Theme-Handbuch von WordPress. Ein Child-Theme ergänzt Template: mit dem Ordner seines Eltern-Themes, sodass eine Seite zwei Themes zeigen kann: nalgene.com nutzt sein eigenes Nalgene Twenty Twenty auf Genesis 3.5.0.

Plugins zeigen sich auf dieselbe Weise, als Ordner /wp-content/plugins/<name>/, oft mit einer ?ver=-Nummer. Diese Nummer ist nur dann die Version des Plugins, wenn sie zu einem Release passt: Die Skripte von WooCommerce auf nalgene.com tragen 11.2.1, den Stable tag in seiner Readme auf WordPress.org, während die Datei eines anderen Plugins einen Zeitstempel trägt.

Sichtbar sind nur Plugins, die etwas in die Seite schreiben. Backups, Sicherheits-Tools oder ein Formular auf der Kontaktseite hinterlassen nichts im HTML der Startseite, daher kann kein Detector jedes Plugin einer Website auflisten.

Ein Theme-Paar und 15 Plugin-Ordner · nalgene.com, 24. Oktober 2026

Theme

In der Seite

/wp-content/themes/nalgene-twentytwenty/style.css?ver=9260242/wp-content/themes/genesis/lib/js/skip-links.min.js?ver=3.5.0class="… wp-child-theme-nalgene-twentytwenty …"

Child-ThemeNalgene Twenty Twenty

  1. /wp-content/themes/nalgene-twentytwenty/style.css
  2. Theme Name: Nalgene Twenty TwentyName
  3. Author: Scout DigitalAutor
  4. Version: 9260242Version · eine Build-Nummer
  5. Template: genesisEltern-Ordner

Eltern-ThemeGenesis 3.5.0 · StudioPress

  1. Theme Name: GenesisName
  2. Author: StudioPressAutor
  3. Version: 3.5.0Version

Plugins

  • /plugins/woocommerce/?ver=11.2.1

    WooCommerce 11.2.1: der Stable tag in seiner Readme auf WordPress.org

  • /plugins/woocommerce/…/jquery-blockui/?ver=2.7.0-wc.11.2.1

    Eine Bibliothek, die WooCommerce mitliefert (jQuery BlockUI 2.7.0), mit der Version von WooCommerce versehen

  • /plugins/elasticpress/?ver=1792138636

    Ein Zeitstempel (16. Oktober 2026), nicht die Version von ElasticPress

  • + 13 weitere Plugin-Ordnerinstagram-feed-prowoo-discount-ruleswoo-discount-rules-prowoo-variation-swatcheswoocommerce-back-in-stock-notificationswp-rocketsimple-cloudflare-turnstilekount-fraud-preventiondatalayer-for-woocommerceaddify-advanced-split-ordernalgene-customizervital-theme-modificationsvital-message-bar-master

Plugins, die nichts in die Seite schreiben: für jeden Detector unsichtbar

Die style.css des Child-Themes nennt Genesis als Eltern-Theme (Template: genesis), und der Header von Genesis selbst gibt dessen Version an, 3.5.0. Von den drei ?ver=-Werten ist einer die Version des Plugins, einer die einer mitgelieferten Bibliothek und einer ein Zeitstempel.

Wie finden Sie heraus, welches Shopify-Theme ein Shop nutzt?

Durchsuchen Sie den Quelltext der Seite nach Shopify.theme. Jeder Shopify-Shop, den wir geprüft haben, gibt dieses Objekt aus, und ein Shopify-Theme-Detector liest es: den Namen des Themes in diesem Shop, das Theme, auf dem es aufbaut, mit dessen Version, seine Nummer im Theme Store und ob es das veröffentlichte Theme ist.

Der Name ist das, was der Händler seiner Kopie gegeben hat, und kann daher wenig aussagen: Der Museumsshop des LACMA nennt sein Theme „Updated copy of Kingdom“. schema_name und schema_version nennen das Theme darunter, Kingdom 4.3.1, und theme_store_id ist seine Nummer im Theme Store von Shopify.

Große Marken nutzen oft ein eigenes Theme: Das von allbirds.com baut auf allbirds-theme 1.231.12 auf, ohne Nummer im Theme Store. Die Plattform selbst bestätigen andere Merkmale von Shopify, etwa der Header powered-by: Shopify und das Cookie _shopify_essential.

Shopify.theme, zerlegt · allbirds.com, 24. Oktober 2026
  1. Shopify.theme = {
  2. 1"name": "[DNAM Theme July 2026]",
  3. 2"id": 130450260048,
  4. 3"schema_name": "allbirds-theme",
  5. "schema_version": "1.231.12",
  6. 4"theme_store_id": null,
  7. 5"role": "main"
  8. }
  1. 1Der Name, den der Händler dieser Kopie des Themes gegeben hat
  2. 2Die ID des Themes in diesem Shop
  3. 3Das Theme, auf dem es aufbaut, und dessen Version
  4. 4Seine Nummer im Theme Store von Shopify: hier keine
  5. 5main: das veröffentlichte Theme, das Kunden sehen

Drei Shops, drei Arten von Theme

ShopName im ShopBasiert aufTheme Store
allbirds.comEigenes Theme[DNAM Theme July 2026]allbirds-theme 1.231.12keine
theme-dawn-demo.myshopify.comDemo-Shop von ShopifyDawnDawn 15.0.0#887
thelacmastore.orgMuseumsshopUpdated copy of KingdomKingdom 4.3.1#725
Shopify dokumentiert das Objekt Shopify.theme nicht, daher lesen wir es so, wie es in diesen Shops zu sehen ist (die Demo von Dawn trägt Dawn 15.0.0, Theme-Store-Nummer 887). Die Werte von role stammen von Shopify: main ist das veröffentlichte Theme.

Warum meldet ein CMS Detector „nicht gefunden“?

Meist, weil die gelesene Seite die Merkmale des CMS nicht trägt, und nicht, weil es kein CMS gibt. Vier Fälle erklären die meisten davon.

Wir nennen den Fall, wenn wir ihn erkennen: eine Bot-Prüfung statt der Website, ein Framework ohne CMS-Merkmale, Merkmale, die der Inhaber abgeschaltet hat, oder eine Seite, auf der ein anderes System läuft als auf dem Rest der Website.

Und manchmal gibt es wirklich keines: W3Techs findet auf 32,1 % der Websites kein CMS, das es kennt; ein Detector, der auf etwa jeder dritten Website nichts findet, arbeitet also normal.

Vier echte Gründe, gesehen am 23. und 24. Oktober 2026
Vom Bot-Schutz blockiert

drupal.org

3 KB · nicht die Website

Fastly antwortete mit einer 3 KB großen „Client Challenge“-Seite statt der Website: kein Drupal-Markup zum Lesen. Wir melden „blockiert“ und bieten einen Browser-Scan an.

Ein Frontend ohne CMS-Merkmale

openai.com

Framework · CMS: Möglich

Next.js auf Vercel. Die Texte stammen vielleicht aus einem Headless CMS; nur der Bild-Host von Contentful deutet darauf hin, daher bleibt es bei „Möglich“.

Merkmale abgeschaltet

nalgene.com

Generator entfernt · trotzdem Bestätigt

Kein Generator-Tag von WordPress, doch der REST-Header Link, die Pfade /wp-content/ und ?ver=7.1.3 nennen weiterhin WordPress. Alle Merkmale zu verbergen, gelingt selten vollständig.

Ein anderes System auf einer anderen Seite

ghost.org

/ = Hugo · /blog/ = Ghost

Die Startseite von ghost.org ist mit Hugo gebaut; unter /blog/ läuft Ghost 6.73. Wir prüfen eine URL: Fügen Sie die Seite ein, die Sie meinen, auch einen Shop- oder Blog-Bereich.

Der Streifen jeder Karte ist dieselbe Art von Auswertung wie die des Tools, klein gezeichnet: wo die Merkmale waren und was fehlte.

Was findet ein Browser-Scan, das eine normale Prüfung übersieht?

Alles, was nach dem HTML ankommt: Tags, die ein Tag-Manager einfügt, Analyse- und Werbepixel, Chat- und Consent-Tools sowie Skripte, die erst existieren, wenn JavaScript läuft. Auf allbirds.com fand ein echter Chrome-Browser 15 Technologien, die beim Lesen des HTML der Seite fehlten.

Eine normale Prüfung liest, was der Server sendet. Sie ist schnell und zeigt die Plattform, das Theme und den größten Teil des Stacks. Ein Browser-Scan lädt die Seite für ein paar Sekunden in Chrome, lässt ihre Skripte laufen und liest, was sie nachladen.

In unserem Test mit fünf Websites hat der Browser nie eine Technologie verloren, die das Lesen auf dem Server gefunden hatte, und er fügte zwischen 2 (Wikipedia) und 27 (TechCrunch) hinzu. Am meisten gewinnen Websites, die über einen Tag-Manager laufen; eine schlichte Wiki-Seite ändert sich kaum.

Server-Abfrage und echter Browser · fünf Websites, 24. Oktober 2026
  • allbirds.com10+15389 Anfragen · 8,1 s
  • bbc.com14+19201 Anfragen · 6,3 s
  • nextjs.org6+883 Anfragen · 3,6 s
  • techcrunch.com17+27237 Anfragen · 6,8 s
  • wikipedia.org7+240 Anfragen · 3,8 s
  • Im HTML
  • Nur im Browser

Auf allbirds.com nur im Browser gefunden

Analyse & Marketing

  • Google Analytics
  • Facebook Pixel
  • Microsoft Clarity
  • OneTrust
  • Attentive
  • Impact
  • DoubleClick Floodlight

Frameworks & Bibliotheken

  • Vue.js
  • GSAP
  • Framer Motion
  • core-js
  • Datadog
  • Goober

Schriften

  • Google Font API

E-Commerce

  • Shop Pay
Ein Seitenaufruf pro Website in Chrome aus Indien (Laden plus 3 Sekunden), abgeglichen mit denselben Regeln wie das HTML; die Zahlen ändern sich mit Consent-Bannern, Region und Uhrzeit. Manche Funde nur im Browser hinterlassen eine Spur, die eine umfassendere Regel lesen könnte: Das Preload-Skript von Shop Pay steht im HTML von allbirds.com.

Kann eine Website ihr CMS verbergen?

Teilweise. Bei einem selbst gehosteten CMS kann der Inhaber das Generator-Tag abschalten und ein oder zwei Pfade umbenennen, aber die Plattform prägt die Seite weiterhin; gehostete Plattformen wie Shopify und Wix können ihre Merkmale überhaupt nicht verbergen.

Das Verbergen ist selten vollständig. Das übliche WordPress-Snippet entfernt das Generator-Tag aus der Seite, aber nicht aus dem RSS-Feed, das Umbenennen von /wp-json/ lässt den Link rel="https://api.w.org/" stehen, und wer wp-content verschiebt, hat trotzdem einen Ordner /themes/ und ?ver=-Nummern in der Seite.

Deshalb heißt „nicht gefunden“ nie „kein CMS“: Auch auf einer Seite ohne sichtbare Merkmale kann jedes davon laufen. Verbirgt eine Website ihr CMS gut, sinkt unsere Antwort auf Wahrscheinlich oder Möglich und zeigt die Merkmale, die übrig bleiben.

Abschalten, und was trotzdem sichtbar bleibt
  • Generator-Tag von WordPress<meta name="generator" content="WordPress 7.1.3">Abgeschaltet mitremove_action( 'wp_head', 'wp_generator' )Was sichtbar bleibtDie Generator-Zeile im RSS-Feed<generator>https://wordpress.org/?v=7.1.3</generator>
  • REST-Pfad von WordPress/wp-json/Abgeschaltet mitadd_filter( 'rest_url_prefix', … )Was sichtbar bleibtDie Relation des Linksrel="https://api.w.org/"
  • Der Ordner wp-content/wp-content/Abgeschaltet mitWP_CONTENT_DIR · WP_CONTENT_URLWas sichtbar bleibtDer Ordner themes darin und ?ver=-Nummern…/themes/<name>/?ver=
  • Next.js-Headerx-powered-by: Next.jsAbgeschaltet mitpoweredByHeader: falseWas sichtbar bleibtSeine Dateipfade/_next/static/
  • Generator-Tag von Hugo<meta name="generator" content="Hugo …">Abgeschaltet mitdisableHugoGeneratorInject = trueWas sichtbar bleibtNichts: Auf einer statischen Website läuft kein CMS
  • Joomla-Version<meta name="generator" content="Joomla! …">Abgeschaltet mitMetaVersionStandardmäßig ausWas sichtbar bleibtDas Generator-Tag, ohne VersionJoomla! - Open Source Content Management
  • Shopify{{ content_for_header }}Abgeschaltet mitKein SchalterWas sichtbar bleibtSeine Skripte und Cookies auf jeder Seite_shopify_essentialpowered-by: Shopify
  • Wixstatic.wixstatic.com/mediaAbgeschaltet mitKein SchalterWas sichtbar bleibtSein Medien-Hoststatic.wixstatic.com/media
Jeder Schalter ist eine eigene Einstellung der Plattform, aus ihrer Dokumentation oder ihrem Quellcode. Selbst gehostete Systeme können verstummen; gehostete Plattformen setzen ihre eigenen Skripte und Datei-Hosts voraus.

Warum ist eine sichtbare CMS-Version wichtig?

Weil alte Versionen Lücken haben, die bereits öffentlich bekannt sind. Der Hardening-Leitfaden von WordPress sagt selbst, dass ältere Versionen nicht mit Sicherheitsupdates gepflegt werden und dass, sobald ein Fix erscheint, fast sicher öffentlich ist, wie sich die Lücke ausnutzen lässt.

Eine Versionsnummer allein beweist aber noch nicht, dass eine Website gefährdet ist. Offiziell unterstützt wird nur WordPress 7.1, dennoch hat WordPress am 6. Oktober 2026 auf jedem Zweig bis zurück zu 4.7 eine neue Version veröffentlicht; eine Website mit 6.9.10 hat also das neueste Release ihres Zweigs.

Daher zeigen wir die Version, die eine Seite trägt, markieren sie nur dann als „aktuell“, wenn sie dem neuesten Release auf WordPress.org entspricht, und bezeichnen eine Website nie als verwundbar. Drupal zeigt nur seine Hauptversion, was reicht, um eine alte zu erkennen: Drupal 7 hat am 5. Januar 2025 den Sicherheitssupport verloren.

Das neueste Release jedes WordPress-Zweigs · Stand 24. Oktober 2026
Anteil an den WordPress-Websites (W3Techs)
  • Version 7
    • 7.1.3 aktuell · der einzige unterstützte Zweig
    • 7.0.7
    66,9 %
  • Version 6
    • 6.9.10
    • 6.8.11
    • 6.7.10
    • 6.6.10
    • 6.5.13
    • 6.4.13
    • 6.3.13
    • 6.2.14
    • 6.1.15
    • 6.0.17
    26,3 %
  • Version 5
    • 5.9.19
    • 5.8.18
    • 5.7.20
    • 5.6.22
    • 5.5.23
    • 5.4.24
    • 5.3.26
    • 5.2.29
    • 5.1.27
    • 5.0.30
    4,7 %
  • Version 4
    • 4.9.34
    • 4.8.33
    • 4.7.38
    • 4.6.30
    • 4.5.33
    • 4.4.34
    • 4.3.35
    • 4.2.39
    • 4.1.42
    • 4.0.38
    2,0 %
  • Version 3
    • 3.9.40
    • 3.8.41
    • 3.7.41
    • 3.6 und älter
    0,2 %
  • Veröffentlicht am 6. Oktober 2026
  • Letztes Release Juli 2025
  • Letztes Release 30. November 2022
  • Kein Release seit 2013
Jeder Zweig von 4.7 bis 7.1 erhielt am 6. Oktober 2026 ein Release, die älteren als freiwillige Backports; offiziell gepflegt wird nur 7.1. Neben jeder Hauptversion: ihr Anteil an den WordPress-Websites, deren Version W3Techs sehen kann (23. Oktober 2026).

Ist er auch ein Schwachstellen-Checker für Websites?

Ein passiver. Für jede exakte Version, die eine Website in ihren Headern, ihrer Seite oder bei einem Browser-Scan zeigt, listet er die veröffentlichten Sicherheitshinweise, die sie betreffen, darunter CVEs, von OSV.dev oder, bei einer JavaScript-Bibliothek, die an ihrer Datei erkannt wurde, von Retire.js; den Support-Status der Release-Linie von endoflife.date; und unsere eigenen Hinweise, etwa zu PHP2Shell. Er sendet nie aktive Testanfragen oder Angriffsanfragen.

Eine Versionsnummer hat Grenzen. Das Paket einer Linux-Distribution kann zurückportierte Fixes unter einer alten Nummer enthalten, ein Sicherheitshinweis kann eine Funktion voraussetzen, die die Website nicht nutzt, und viele Websites verbergen ihre Versionen. Deshalb nennt die Antwort Fakten zu einer Version („36 veröffentlichte Sicherheitshinweise betreffen Next.js 14.1.0“) und sagt nie, eine Website sei verwundbar.

Hinter Cloudflare lautet der Server-Header „cloudflare“, daher ist die Version des eigentlichen Webservers nicht zu sehen, aber die übrigen Header der Website kommen durch: Eine PHP-Version in X-Powered-By ist weiterhin sichtbar. Um Ihre eigene Website richtig zu testen, nutzen Sie einen Schwachstellenscanner, den Sie gegen sie einsetzen dürfen.

Von einer Version zu drei Antworten · drei echte Muster, 24. Oktober 2026
  1. 1Der Entwicklungsserver einer Flask-Appflask-app.example

    Was die Website sendetServer: Werkzeug/2.0.1 Python/3.8.10

    Werkzeug2.0.1Veröffentlichte Sicherheitshinweise · OSV.dev11 Sicherheitshinweise2 hochSupportzeitraum · endoflife.date–nicht in dieser QuelleUnser Hinweis–nicht in dieser Quelle
    Python3.8.10Veröffentlichte Sicherheitshinweise · OSV.dev–nicht in dieser QuelleSupportzeitraum · endoflife.dateEndete am 7. Okt. 2024Unser Hinweis–nicht in dieser Quelle
  2. 2PHP hinter Cloudflareshop.example

    Was die Website sendetServer: cloudflareWebserver-Version: von Cloudflare verborgenX-Powered-By: PHP/7.4.33

    PHP7.4.33Veröffentlichte Sicherheitshinweise · OSV.dev–nicht in dieser QuelleSupportzeitraum · endoflife.dateEndete am 28. Nov. 2022Unser HinweisPotenziell verwundbarPHP2Shell · kein Release mit Fix vom PHP-Projekt für 7.4
  3. 3Next.js, in einem Browser-Scan gefundenapp.exampleper Browser-Scan gefunden

    Was die Website sendetwindow.next.version → "14.1.0"

    Next.js14.1.0Veröffentlichte Sicherheitshinweise · OSV.dev36 Sicherheitshinweise4 kritischSupportzeitraum · endoflife.dateEndete am 26. Okt. 2025neueste 14.2.35Unser Hinweis–nicht in dieser Quelle
Jede Version so, wie ein Header, die Seite oder ein Browser-Scan sie zeigt, am Tag der Prüfung nachgeschlagen: die Sicherheitshinweise von OSV.dev (eine Lücke, die zwei Datenbanken führen, zählt einmal), die Support-Daten von endoflife.date und unsere eigenen Hinweise. Ein Strich bedeutet, dass diese Quelle das Produkt nicht abdeckt. Die Hosts sind erfunden; die Muster und die Antworten sind echt.

Wie unterscheidet er sich von BuiltWith, Wappalyzer und WhatCMS?

BuiltWith antwortet aus seinem eigenen Index des Webs, Wappalyzer bietet Ergebnisse, die innerhalb der letzten 30 Tage verifiziert wurden, oder ein Live-Ergebnis, das fünf Abfragen kostet, und WhatCMS liest die Seite live, listet aber die letzten Abfragen auf seiner Startseite. Als CMS-Checker und Technologie-Checker für Websites liest dieser Detector die Seite, die Sie angeben, jetzt und zeigt die Zeile hinter jeder Antwort.

Ein Index eignet sich für die Historie: Die API von BuiltWith meldet, wann sie eine Domain zuletzt indexiert hat. Eine Live-Abfrage zeigt genau die Seite, die Sie einfügen, so wie sie jetzt ist, auch einen Shop- oder Blog-Unterordner.

Auch die kostenlose Nutzung unterscheidet sich: Wappalyzer verlangt für 50 Abfragen im Monat ein Konto, die Abfragen einzelner Websites bei BuiltWith sind kostenlos, und der kostenlose API-Tarif von WhatCMS umfasst 500 Erkennungen im Monat, private Abfragen ab 40 US-Dollar im Monat. Diese Seite braucht kein Konto und veröffentlicht nichts.

Vier Wege zur Antwort auf „Womit ist diese Website gebaut?“ · 24. Oktober 2026

DNS RobotDiese Seite

Quelle der Antwort
Die Seite, die Sie einfügen, jetzt gelesen, mit der Zeile hinter jeder Antwort
Kostenlose Nutzung
Kein Konto; nichts wird veröffentlicht
Gut zu wissen
Ein echter Browser-Scan auf Wunsch

BuiltWith

Quelle der Antwort
Ein eigener Index des Webs, gecrawlt wie bei einer Suchmaschine
Kostenlose Nutzung
Abfragen einzelner Websites
Gut zu wissen
Seine API sagt, wann sie eine Domain zuletzt indexiert hat

Wappalyzer

Quelle der Antwort
Ergebnisse, die innerhalb von 30 Tagen verifiziert wurden, oder eine Live-Abfrage
Kostenlose Nutzung
50 Abfragen im Monat mit Konto
Gut zu wissen
Ein Live-Ergebnis zählt als 5 Abfragen

WhatCMS

Quelle der Antwort
Die Seite, abgerufen, wenn Sie fragen
Kostenlose Nutzung
API: 500 Erkennungen im Monat
Gut zu wissen
Listet die letzten Abfragen auf seiner Startseite; private ab 40 US-Dollar im Monat
Von den eigenen Seiten jedes Tools übernommen, am 24. Oktober 2026. Tarife ändern sich; prüfen Sie die aktuellen Angaben, bevor Sie sich entscheiden.

CMS Detector: Fragen und Antworten

Wie kann ich erkennen, welches CMS eine Website nutzt?

Fügen Sie die Adresse der Website oben in den CMS Detector ein. Er analysiert die Header, Cookies und das HTML der Seite sowie die DNS-Einträge der Domain und nennt dann die Plattform mit der Codezeile, die sie belegt, und wie sicher wir uns damit sind. Sie können auch selbst nachsehen: Öffnen Sie den Quelltext der Seite und suchen Sie nach generator, wp-content, Shopify.theme oder wixstatic.

Kann man das WordPress-Theme einer Website herausfinden?

Ja, wenn die Seite eine Datei aus dem Ordner des Themes lädt. Wir entnehmen den Ordnernamen aus /wp-content/themes/<name>/ und lesen den Header der style.css dieses Themes: Name, Autor und Version. Ein Child-Theme nennt sein Eltern-Theme in einer Zeile Template:, sodass Sie beide sehen, etwa Nalgene Twenty Twenty auf Genesis 3.5.0. Blockiert ein Host die Theme-Dateien, bleibt nur der Ordnername.

Kann man herausfinden, welches Shopify-Theme ein Shop nutzt?

Ja. Shopify-Shops geben im HTML ein Objekt Shopify.theme aus, mit dem Namen des Themes in diesem Shop, dem Theme, auf dem es aufbaut (schema_name), und dessen Version, seiner Nummer im Theme Store und seiner Rolle. Der Name kann alles sein, was der Händler eingetippt hat, etwa „Updated copy of Kingdom“, daher zeigen wir auch das Theme darunter. Das eigene Theme einer Marke, wie das von allbirds.com, hat keine Nummer im Theme Store.

Findet er jedes Plugin, das eine WordPress-Website nutzt?

Das kann kein Detector. Ein Plugin taucht nur auf, wenn es etwas in die Seite schreibt: ein Skript oder Stylesheet unter /wp-content/plugins/<name>/, einen Kommentar oder einen Klassennamen. Plugins, die im Dashboard oder auf anderen Seiten arbeiten, etwa für Backups, Sicherheit oder ein Formular auf der Kontaktseite, hinterlassen auf der Startseite keine Spur. Wer die Seite prüft, auf der ein Plugin läuft, findet mehr.

Warum heißt es, eine Website sei kein WordPress, obwohl ich weiß, dass sie es ist?

Meist, weil die Seite, die wir bekamen, die Merkmale von WordPress nicht zeigte. Vielleicht hat ein Bot-Schutz mit einer Challenge-Seite statt der Website geantwortet (dann melden wir „blockiert“), der Inhaber hat das Generator-Tag entfernt und wp-content verschoben, oder unter der Adresse läuft etwas anderes: Die Startseite von ghost.org läuft mit Hugo, ihr Blog mit Ghost. Prüfen Sie genau die gemeinte Seite oder versuchen Sie einen Browser-Scan.

Erkennt er das CMS auch hinter Cloudflare?

Meistens ja. Cloudflare reicht die eigenen Header und das HTML der Website durch, daher sind der REST-Header von WordPress, seine Dateipfade und ein X-Powered-By-Header weiterhin sichtbar; nur der Server-Header wird zu „cloudflare“, was die Version des eigentlichen Webservers verbirgt. Die Ausnahme ist eine Bot-Prüfung: Antwortet Cloudflare oder eine andere Firewall mit einer Challenge-Seite statt der Website, melden wir die Prüfung als blockiert, und ein Browser-Scan kommt eventuell durch.

Warum liefern zwei CMS-Finder unterschiedliche Antworten?

Sie lesen Unterschiedliches zu unterschiedlichen Zeiten. BuiltWith antwortet aus seinem Index des Webs, und die gespeicherten Ergebnisse von Wappalyzer können bis zu 30 Tage alt sein, während ein Live-Tool die Seite jetzt liest. Tools prüfen vielleicht auch eine andere Seite, nutzen andere Regeln oder bekommen eine Bot-Prüfung statt der Website. Deshalb zeigt jede unserer Antworten die Zeile, auf der sie beruht.

Wie genau ist dieser CMS Detector?

Jede Antwort trägt ihre Belege und eines von drei Labels. Bestätigt heißt: zwei unabhängige Signale oder eines, das nur diese Plattform erzeugt, etwa ihr eigener Header, ihr Cookie oder ihr Dateipfad. Wahrscheinlich heißt: ein Signal, das jeder kopieren oder entfernen könnte, etwa ein Generator-Tag. Möglich heißt: ein indirekter Hinweis, etwa ein Bild-Host. Eine blockierte oder leere Seite wird als solche gemeldet, nie als „kein CMS“.

Warum fehlt die CMS-Version?

Viele Plattformen geben sie nicht aus. Joomla verbirgt seine Version standardmäßig, der Header von Drupal nennt nur die Hauptversion und Ghost nur Haupt- und Nebenversion. WordPress gibt seine genaue Version aus, sofern der Inhaber sie nicht entfernt, und seine Dateiadressen tragen sie oft noch in ?ver=. Wir zeigen nur eine Version, die ein Signal auf der Seite tatsächlich trägt, und sagen, wo wir sie gefunden haben.

Kann er eine Website auf bekannte Schwachstellen (CVEs) prüfen?

Ja, passiv, für die Versionen, die eine Website zeigt. Nennt ein Header, die Seite oder ein Browser-Scan eine exakte Version, etwa Next.js 14.1.0, listen wir ihre Sicherheitshinweise von OSV.dev auf (oder von Retire.js bei einer an ihrer Datei erkannten JavaScript-Bibliothek), zeigen, ob ihre Release-Linie noch Support erhält (endoflife.date), und nennen unsere eigenen Hinweise wie den zu PHP2Shell. Wir senden nie Testanfragen und nennen eine Website nie verwundbar: Ein zurückportierter Fix ist an keiner Versionsnummer zu erkennen.

Kann er prüfen, ob eine Website von PHP2Shell betroffen ist?

Nur anhand der PHP-Version, die sie angibt. Nennt der X-Powered-By- oder Server-Header der Website PHP, vergleichen wir sie mit den Fixes von php.net vom 21. Oktober 2026 (8.5.12, 8.4.27, 8.3.36 und 8.2.35), wie es der php2shell-checker von OpenAI tut: Ein älteres Release auf diesen Zweigen oder jedes PHP von 5.4 bis 8.1 ist „potenziell verwundbar“. Das Paket einer Distribution kann einen zurückportierten Fix enthalten, und eine Website, die ihre PHP-Version verbirgt, lässt sich so nicht prüfen.

Speichern oder veröffentlichen Sie die Websites, die ich prüfe?

Wir veröffentlichen sie nie: Es gibt keine öffentliche Liste der letzten Abfragen. Ein Ergebnis wird kurz gespeichert, damit eine erneute Prüfung derselben Seite sofort da ist, danach ist es weg. Die geprüfte Website sieht eine Anfrage von unserem Server, nie Ihre IP-Adresse: Die Anfrage gibt sich als CMS Detector von DNS Robot zu erkennen, und ein Browser-Scan lädt die Seite aus dem Netz von Cloudflare.

Fehlt Ihnen etwas?Funktion oder neues Tool vorschlagen