vSie übernehmen eine bestehende Website, das Team ist neu zusammengesetzt, der Relaunch steht im Raum, und plötzlich fehlt die Grundlage für jede vernünftige Entscheidung. Bevor Sie Aufwand schätzen, Risiken bewerten oder Entwicklerprofile definieren, müssen Sie zuerst eine einfache, aber kritische Frage klären: welches content management system wird verwendet.

Das ist keine reine Technik-Neugier. Die Antwort beeinflusst, wie Sie Security-Audits aufsetzen, wie realistisch ein Migrationsplan ist und ob Sie Generalisten oder Spezialisten brauchen. Gerade bei Projektübernahmen zeigt sich schnell, dass falsche Annahmen über das CMS zu teuren Fehlentscheidungen führen.

Warum die CMS-Frage für jedes Webprojekt entscheidend ist

Eine Website sieht von außen oft harmlos aus. Innen kann sie sauber strukturiert, historisch gewachsen oder technisch verschleppt sein. Wenn Sie das zugrunde liegende CMS nicht kennen, bewerten Sie Aufwand und Risiko praktisch im Blindflug.

In Deutschland ist diese Frage auch deshalb relevant, weil die CMS-Landschaft klar geprägt ist. WordPress hält hierzulande einen Marktanteil von über 63 % unter allen Web-CMS, laut HubSpot über CMS-Systeme in Deutschland. Für eine erste Einordnung heißt das: Wenn Sie eine beliebige Unternehmensseite prüfen, ist WordPress statistisch ein naheliegender Kandidat.

Was die CMS-Erkennung konkret beeinflusst

Die CMS-Erkennung ist der Startpunkt für mehrere Entscheidungen gleichzeitig:

• Ressourcenplanung: Ein WordPress-Projekt mit vielen Plugins braucht oft andere Profile als ein TYPO3-Portal mit individuellen Extensions.
• Sicherheitsbewertung: Das Risiko liegt selten nur im Core. Meist stecken Probleme in Themes, Plugins, Modulen, Altlasten oder ungepflegten Deployments.
• Migrationsstrategie: Ohne Kenntnis des Systems können Sie weder Content-Struktur noch Integrationen noch redaktionelle Prozesse sauber bewerten.
• Betriebsmodell: Manche Systeme lassen sich im bestehenden Team gut weiterführen. Andere brauchen erfahrene Spezialisten und klarere Release-Prozesse.

Praktische Regel: Wenn das CMS unklar ist, ist jede Aufwandsschätzung vorläufig.

Warum das auch für Business-Entscheidungen zählt

CTOs und Product Owner fragen oft zuerst nach Features, Roadmap und Budget. Technisch ist die bessere Reihenfolge meist anders. Erst Plattform verstehen, dann Konsequenzen ableiten.

Ein einfaches Beispiel: Eine Website mit vielen Landingpages kann in WordPress stabil laufen. Ein mehrsprachiges Unternehmensportal mit komplexen Rollen, Freigaben und langen Wartungszyklen hat andere Anforderungen. Die CMS-Wahl wirkt direkt auf Time-to-Change, Governance und laufende Betriebskosten.

Wer die Systeme im Markt besser einordnen will, findet in diesen Content-Management-Systeme-Beispielen eine nützliche Übersicht als Ergänzung zur technischen Prüfung.

Schnelle Erkennung mit automatisierten Tools

Für den ersten Durchlauf müssen Sie nicht sofort in Requests, Header und Quelltext abtauchen. In vielen Fällen liefern automatisierte Tools innerhalb weniger Sekunden eine belastbare erste Antwort. Das spart Zeit, besonders wenn Sie mehrere Websites in einer Due-Diligence, bei einer Sicherheitsprüfung oder im Rahmen einer Migration sichten.

Welche Tools sich für den ersten Pass eignen

Ein sinnvoller Start besteht aus zwei Klassen von Werkzeugen:

• Browser-Erweiterungen: Wappalyzer ist praktisch, wenn Sie direkt beim Besuch einer Seite erste Hinweise sehen wollen.
• Webbasierte Scanner: CMS-Checker wie der von p1commerce eignen sich gut für einzelne Audits ohne Browser-Setup.
• Technologie-Profiler: BuiltWith wird häufig genutzt, wenn Sie zusätzlich Hosting, Libraries oder Tracking-Setups betrachten wollen.

Technisch arbeiten diese Tools mit Fingerprints. Sie prüfen zum Beispiel Metatags, typische Dateipfade, Server-Signaturen oder clientseitige Artefakte. Nach Angaben von p1commerce zum CMS Checker scannen solche Tools Metatags, Pfade und Server-Signaturen mit über 95 % Genauigkeit für Top-CMS wie WordPress. Browser-Erweiterungen wie Wappalyzer erreichen bei bekannten Open-Source-Systemen bis zu 98 % Erfolgsrate.

So nutze ich die Tools in der Praxis

Für einen belastbaren Schnelltest reicht ein kurzes Schema:

1. Seite im normalen Browser öffnen
   Nicht eingeloggt, ohne spezielle Parameter, ohne Admin-Kontext.
2. Wappalyzer oder ein ähnliches Plugin prüfen
   Das liefert oft sofort Kandidaten für CMS, Framework, CDN oder Shop-System.
3. URL zusätzlich in einen CMS-Checker eingeben
   Wenn beide Werkzeuge dasselbe melden, ist das ein starkes Signal.
4. Nur das Ergebnis notieren, nicht sofort glauben
   Ein Tool-Treffer ist ein Hinweis. Noch kein Beweis.

Wenn zwei unterschiedliche Fingerprinting-Methoden auf dasselbe CMS zeigen, reicht das oft für eine erste Projektklassifikation. Für Security- oder Migrationsentscheidungen sollten Sie trotzdem manuell verifizieren.

Wo automatisierte Erkennung scheitert

Automatisierte Tools sind schnell, aber nicht unfehlbar. Probleme entstehen vor allem in drei Situationen:

Gerade im Enterprise-Umfeld werden Generator-Tags entfernt, Pfade umgeschrieben oder Assets über Build-Prozesse ausgeliefert. Dann wirkt die Website bewusst neutral. Für einen Audit heißt das: Tools sind der Einstieg, nicht die abschließende Wahrheit.

Manuelle Analyse für präzise Ergebnisse

Wenn Sie eine definitive Antwort brauchen, führt kein Weg an manueller Analyse vorbei. Das gilt besonders bei Projektübernahmen, Security Reviews und Migrationsvorhaben mit Budgetverantwortung. Erfahrene Entwickler verlassen sich in solchen Fällen nicht auf ein einzelnes Tool, sondern auf eine Kette von Indizien.

Im Quelltext beginnen

Der Browser-Quelltext ist oft der schnellste Ort für belastbare Hinweise. Suchen Sie nicht wahllos, sondern zielgerichtet nach Markern.

Typische Kandidaten sind:

• Meta-Tags: Ein generator-Tag kann direkt auf WordPress oder ein anderes System hindeuten.
• Asset-Pfade: /wp-content/, /typo3conf/, /sites/default/ oder ähnliche Muster verraten häufig das CMS.
• JavaScript-Spuren: Initialisierungsobjekte, globale Variablen oder CMS-spezifische Snippets helfen weiter.
• Kommentarblöcke: Manche Themes, Templates oder Integratoren hinterlassen erkennbare Hinweise.

Öffnen Sie danach die Entwicklertools und durchsuchen Sie geladene Assets. Viele Hinweise stehen nicht im initialen HTML, sondern tauchen erst in CSS-, JS- oder Medienpfaden auf.

Netzwerk und Header prüfen

Wenn der Quelltext wenig hergibt, kommt der Network-Tab ins Spiel. Dort sehen Sie, welche Dateien geladen werden, wie Cookies gesetzt sind und welche Header vom Server zurückkommen.

Achten Sie auf:

• Response-Header: Manche Server verraten Frameworks oder Middleware indirekt.
• Cookie-Namen: Session- oder Backend-Cookies können auf bestimmte Systeme hindeuten.
• Redirect-Verhalten: Login- oder Sprachumschaltungen verraten oft die technische Struktur.
• Admin-nahe Requests: Selbst ohne Login sehen Sie manchmal Verweise auf Backend-Routen oder API-Endpunkte.

Ein einzelner Header ist selten aussagekräftig. Mehrere kleine Hinweise zusammen sind deutlich wertvoller.

Dateipfade und Login-Routen als letzter Test

Wenn Sie genug Indizien haben, prüfen Sie Standard-Routen vorsichtig und ohne aggressive Scans. Dabei geht es nicht um Angriffe, sondern um normale HTTP-Aufrufe auf öffentlich erreichbare Login- oder Strukturpfade.

Ein paar typische Beispiele:

• WordPress: /wp-admin oder /wp-login.php
• TYPO3: Backend-Routen und klassische Verzeichnisse wie /typo3temp/
• Drupal: Strukturen rund um /sites/default/

Gerade TYPO3 ist in Deutschland relevanter, als ein rein globaler Blick vermuten lässt. Laut fuer-gruender.de im CMS-Vergleich hat TYPO3 international nur einen geringen globalen Marktanteil, ist in Deutschland aber insbesondere im Enterprise-Segment stark vertreten und hinterlässt oft eindeutige Spuren wie den Pfad /typo3temp/.

Eine praxistaugliche Prüfreihenfolge

Ich würde die manuelle Analyse in dieser Reihenfolge aufbauen:

1. HTML-Quelltext prüfen
   Schnellster Zugriff auf offensichtliche Fingerprints.
2. Geladene Assets durchsuchen
   Besonders nützlich bei Frontends mit Build-Prozess.
3. Network-Tab auswerten
   Cookies, Redirects, API-Aufrufe, Header.
4. Standardpfade und Login-Routen testen
   Nur lesend, ohne Brute-Force, ohne Last zu erzeugen.
5. Hypothese dokumentieren
   Nicht nur das CMS notieren, sondern auch die Belege.

Das ist wichtig für Teams. Ein sauberer Audit-Eintrag sollte festhalten, warum Sie ein CMS identifiziert haben. Sonst diskutiert das Team später über Vermutungen statt über nachprüfbare Fakten.

Was tun wenn das CMS verborgen ist

Manche Websites sind absichtlich schwer einzuordnen. Der Generator-Tag fehlt, typische Pfade sind kaschiert, und Wappalyzer zeigt nur JavaScript-Frameworks oder ein CDN. Das ist kein Ausnahmefall. Besonders bei über Jahre gewachsenen Plattformen oder sicherheitsbewussten Teams ist das normal.

Warum ein CMS absichtlich verborgen wird

Der häufigste Grund ist eine Form von Verschleierung. Teams entfernen erkennbare Spuren, weil sie Angriffsflächen nicht unnötig offenlegen wollen. Das ersetzt keine echte Sicherheit, kann aber automatisierte Massenangriffe etwas unattraktiver machen.

Es gibt noch zwei andere typische Gründe:

• Headless-Setups: Das Frontend ist entkoppelt und zeigt nur eine API-basierte Oberfläche.
• Custom Builds: Hinter der Website steckt kein klassisches CMS, sondern ein Framework oder eine Eigenentwicklung.

Versteckte Fingerprints sind kein Qualitätsmerkmal. Sie sagen nur, dass Sie tiefer prüfen müssen.

Woran Sie trotzdem weiterkommen

Wenn Standardmerkmale fehlen, schauen Sie auf indirekte Signale. Besonders nützlich sind API-Strukturen, Verhalten beim Routing und Build-Artefakte im Frontend.

Ein paar praxistaugliche Ansätze:

• API-Endpunkte lesen: JSON-Strukturen, Namenskonventionen oder Auth-Flows verraten oft, ob im Hintergrund ein CMS, ein Framework oder ein SaaS-System arbeitet.
• JavaScript-Bundles prüfen: Dateinamen, eingebettete Konfigurationsobjekte oder interne Bezeichner liefern Hinweise auf Rendering- und Content-Layer.
• Formulare analysieren: Hidden Fields, CSRF-Mechanismen und Endpoint-Muster unterscheiden sich zwischen klassischen CMS, Frameworks und Shop-Systemen.
• Fehlerseiten und Sonderrouten testen: 404-Seiten, Suchfunktionen oder Sprachumschalter offenbaren oft mehr als die Startseite.

Wann Sie von einem Custom System ausgehen sollten

Wenn weder Tooling noch manuelle Marker noch typische Backend-Routen etwas Brauchbares liefern, ist ein Custom System oder ein Framework-basierter Build wahrscheinlich. Dann sollten Sie die Frage anders formulieren. Nicht mehr: „Welches CMS ist das?“ Sondern: „Wie wird Content technisch verwaltet und ausgeliefert?“

Für einen Audit ist diese Unterscheidung wichtig. Ein Framework-basiertes System verlangt eine andere Bewertung als WordPress oder TYPO3. Sie prüfen dann eher Architektur, Deployment, Ownership, Dokumentation und Änderbarkeit statt Plugin-Stand, Core-Version oder Modulpflege.

Die Ergebnisse interpretieren und nächste Schritte planen

Die CMS-Erkennung ist nur dann nützlich, wenn daraus Entscheidungen folgen. Ein identifiziertes System sagt zunächst wenig über Qualität. Ein schlecht gepflegtes Standard-CMS kann riskanter sein als eine saubere Eigenentwicklung. Umgekehrt kann ein bekanntes Enterprise-System unnötig teuer werden, wenn es für den tatsächlichen Bedarf überdimensioniert ist.

Drei Fragen nach der Identifikation

Sobald das CMS feststeht, prüfe ich zuerst diese Punkte:

Was die Plattformwahl für Kosten und Risiko bedeutet

Bei Migrationen sollten Sie Technik und Wirtschaft nicht trennen. Laut OMT zum CMS-Vergleich sollten bei der Evaluierung technische Spezifikationen und Total Cost of Ownership berücksichtigt werden. Dort wird auch beschrieben, dass ein TYPO3-Setup initial 20.000 bis 50.000 € kosten kann, sich bei hohem Traffic aber durch Skalierbarkeit rentieren kann. Für WordPress gilt im selben Kontext, dass etwa 30 % der Websites aufgrund veralteter Plugins anfällig sein können, was die laufende Wartung verteuert.

Das ist der entscheidende Punkt für technische Leiter. Das identifizierte CMS ist kein Etikett, sondern ein Hinweis auf den wahrscheinlichen Betriebsaufwand. Ein System kann günstig starten und teuer in der Pflege werden. Ein anderes wirkt anfangs schwergewichtig, passt aber besser zu Governance, Mehrsprachigkeit und Freigabeprozessen.

Konkrete nächste Schritte nach dem Audit

Nach der Erkennung lohnt sich eine kurze, harte Priorisierung:

• Sicherheitslage erfassen: Plugins, Extensions, Themes, Rollenmodell, Update-Praxis, Admin-Zugänge.
• Betriebsfähigkeit prüfen: Wer kann das System heute zuverlässig weiterentwickeln und deployen?
• Content-Struktur dokumentieren: Inhalte, Seitentypen, Medien, Mehrsprachigkeit, Formulare, Integrationen.
• Migrationsdruck ehrlich bewerten: Nicht jedes alte System muss sofort ersetzt werden. Manche brauchen zuerst Stabilisierung.

Die häufigste Fehlentscheidung ist eine Migration aus Frust. Erst wenn Betrieb, Sicherheit und Änderbarkeit geprüft sind, lässt sich seriös entscheiden, ob Weiterentwicklung oder Neuaufbau sinnvoller ist.

Wer an dieser Stelle tiefer in die Auswahl und Umsetzung einsteigen will, findet in diesem Leitfaden zum Website-Erstellen mit CMS eine gute Ergänzung zur strategischen Bewertung.

Häufig gestellte Fragen zur CMS-Erkennung

Was bedeutet es, wenn überhaupt kein CMS erkannt wird

Dann gibt es mehrere plausible Erklärungen. Die Website kann statisch sein, also ohne klassisches Backend auskommen. Sie kann auf einem Framework wie Laravel, Django oder Ruby on Rails basieren. Oder es handelt sich um eine Eigenentwicklung mit individueller Content-Verwaltung.

Wichtig ist dabei die Konsequenz. Wenn kein klassisches CMS erkennbar ist, sollten Sie nicht weiter auf WordPress-, TYPO3- oder Drupal-Marker starren. Prüfen Sie stattdessen, wie Content gepflegt wird, wo die Admin-Oberfläche liegt und wie Deployments ablaufen.

Ist es legal, die Technologie einer fremden Website zu analysieren

Ja, solange Sie bei passiver oder normaler technischer Analyse bleiben. Sie werten Informationen aus, die Ihr Browser beim regulären Seitenaufruf ohnehin erhält. Dazu gehören HTML, geladene Assets, Header, öffentlich erreichbare Routen und sichtbare Client-Side-Artefakte.

Nicht dazu gehört aggressives Testing, automatisiertes Ausreizen von Login-Schnittstellen oder jede Form von Zugriff auf nicht öffentliche Bereiche.

Wie zuverlässig ist der Generator-Tag im Quelltext

Er ist nützlich, aber nicht belastbar genug für eine alleinige Entscheidung. Entwickler können ihn entfernen, überschreiben oder bewusst neutral halten. Wenn er vorhanden ist, beschleunigt er die Identifikation. Wenn er fehlt, sagt das fast nichts.

Für eine saubere Einordnung sollten Sie immer mehrere Signale kombinieren. Quelltext, Asset-Pfade, Network-Tab, Cookies und Standardrouten ergeben zusammen ein deutlich verlässlicheres Bild.

Wenn Sie speziell WordPress und TYPO3 gegeneinander einordnen wollen, hilft dieser Vergleich zu WordPress vs TYPO3 als gute Ergänzung zur technischen Erkennung.

‍

Wenn Sie nach der CMS-Erkennung den nächsten Schritt gehen wollen, unterstützt PandaNerds Teams dabei, bestehende Webplattformen technisch sauber zu bewerten, Senior-Entwickler für WordPress, TYPO3 und individuelle Stacks zu finden und Übernahmen oder Relaunches ohne unnötige Fehlstarts umzusetzen.