tech stack

CMS erkannt

MetricSpot identifiziert das CMS oder den gehosteten Site-Baukasten hinter der Seite. Informativ — aber es ändert, welches Fix-Rezept der Rest des Audits empfiehlt.

Was diese Prüfung macht

Identifiziert das CMS oder den gehosteten Site-Baukasten, der die Seite ausliefert, aus einem geschichteten Satz von Fingerabdrücken:

  • Generator-Meta-Tag — <meta name="generator" content="WordPress 6.5">, Hugo 0.124, Ghost 5.x usw. Das Erste, was wir lesen.
  • Response-Header — Shopify liefert x-shopify-stage, Wix sendet x-wix-request-id, Squarespace sendet x-served-by mit Edge-IDs.
  • HTML-Signaturen — /wp-content/, /wp-includes/, /_next/static/, cdn.shopify.com, static.parastorage.com, assets.squarespace.com, <html data-wf-domain> (Webflow).
  • JavaScript-Globals, wenn JS-Ausführung aktiv ist — window.Shopify, window.Wix, window.Static, window.Squarespace.
  • DOM-Muster — Klassen-Präfixe (elementor-, wp-block-, wf-, sqs-), Data-Attribute und bekannte Root-Selektoren.

Das erste verlässliche Signal gewinnt. Das Ergebnis ist informativ — diese Regel lässt nie ein Audit durchfallen. Sie ist da, damit der Rest des Berichts seine Empfehlungen anpassen kann.

Warum es zählt

Das CMS ist der einzelne nützlichste Kontext für den Rest des Audits, weil die Fix-Pfade stark auseinandergehen:

  • Eine fehlschlagende HTTPS-Prüfung auf Shopify ist ein Domain-Konfig-Thema (selten); auf WordPress ist es meist ein fehlendes Really-Simple-SSL-Plugin oder eine Apache-Konfig, die nicht weiterleitet.
  • Eine fehlende XML-Sitemap auf Webflow wird in Project Settings → SEO gefixt; auf Ghost wird sie automatisch generiert und der Fix ist “in der robots.txt nicht mehr blockieren”; auf WordPress ist es ein Yoast- / Rank-Math-Schalter.
  • Ein fehlendes Canonical-Tag auf Squarespace ist eine Per-Page-Einstellung; auf Next.js ist es ein <link> in deinem Layout.

Das CMS zu kennen sagt dir auch, was außerhalb deiner Kontrolle liegt. Wix und Squarespace sperren Response-Header — du kannst keinen eigenen HSTS- oder Referrer-Policy-Header hinzufügen. Shopify lässt dich theme.liquid bearbeiten, aber nicht die Server-Konfig. WordPress lässt dich alles tun — Geschenk und Fluch zugleich.

Es hilft auch beim Reasoning über Performance: WordPress + Elementor scheitern routinemäßig an Largest Contentful Paint wegen der CSS-Payload des Page-Builders; Ghost- und Next.js-Seiten selten. Gleicher Inhalt, sehr unterschiedliche Decken.

So behebst du es

Das ist eine informative Regel — es gibt nichts zu “fixen.” Was sich ändert, ist, welches Rezept anderswo in deinem Audit gilt.

Wenn du auf WordPress bist, sind deine häufigsten Hebel:

Wenn du auf Shopify bist, bearbeite theme.liquid, um Open Graph und strukturierte Daten hinzuzufügen; alles auf Header-Level steuert Shopify. Apple Touch Icon und Favicon laufen über Theme-Einstellungen → Favicon.

Wenn du auf Webflow bist, deckt Project Settings → SEO Metadaten, Sitemaps und robots.txt ab; strukturierte Daten gehen in Project Settings → Custom Code → Head Code.

Wenn du auf Squarespace bist, liegen die meisten SEO-Controls im SEO-Panel der Seite (Title, Description, OG-Image). Manche Header lassen sich in Code Injection hinzufügen, aber die meisten Security-Header sind nicht anpassbar.

Wenn du auf Ghost bist, bestehen die meisten Regeln per Default — Ghost liefert moderne strukturierte Daten, Sitemaps, OG-Tags und eine vernünftige Lighthouse-Performance-Baseline ab Werk.

Wenn MetricSpot nichts erkannt hat — dein Stack ist entweder maßgeschneidert, headless oder strippt seine Generator-Signaturen. Das Audit fällt auf “kein CMS erkannt” zurück und behandelt dich als jemand mit voller Server-Kontrolle.

Generator-String straffen oder entfernen, wenn du willst. Manche Teams verstecken <meta name="generator">, um Fingerprinting für Schwachstellen-Scanner geringfügig schwerer zu machen. Es ist Security-Theater — der Rest der Fingerabdrücke verrät dich trotzdem — aber es schadet nicht:

// WordPress functions.php
remove_action('wp_head', 'wp_generator');

Häufig gestellte Fragen

MetricSpot hat das falsche CMS erkannt. Warum?

Zwei häufige Gründe: (1) Dein CMS-of-Record ist von einem headless Renderer umwickelt (Next.js holt Inhalt von Contentful oder WordPress als API) — wir sehen das Frontend-Framework, nicht die Quelle; (2) die Seite ist stark angepasst und die üblichen Signaturen sind entfernt. Die Regel ist informativ, das beeinflusst deinen Score so oder so nicht.

Beeinflusst das erkannte CMS meinen Audit-Score?

Nein. Diese Regel ist rein informativ. Sie beeinflusst aber die Rezepte, die du siehst — Fehler anderswo im Bericht versuchen, einen für deinen erkannten Stack passenden Fix-Pfad zu empfehlen.

Kann ich verbergen, auf welchem CMS ich bin?

Teilweise. Du kannst den <meta name="generator">-Tag entfernen und offensichtliche Pfade umschreiben, aber JS-Globals, Response-Header-Eigenheiten und Asset-Host-Signaturen lecken weiter. Die meisten Erkennungs-Tools (Wappalyzer, BuiltWith, MetricSpot) gleichen mehrere Signale ab — eines zu verstecken versteckt den Rest nicht, und der Aufwand zahlt sich selten aus.

Quellen

Zuletzt aktualisiert 2026-05-11