Websites herunterladen, die Strapi nutzen

Über Strapi

Wer Strapi in einer Technologieerhebung betrachtet, muss zuerst verstehen, dass das Produkt darauf ausgelegt ist, unsichtbar zu sein. Ein Headless-Content-System läuft als Backend. Redakteure arbeiten in einem Admin-Panel, Inhalte verlassen das System über eine API, und was auch immer die öffentliche Website rendert, ist eine eigene Anwendung, die in jedem beliebigen Framework geschrieben sein kann. Nichts verpflichtet ein Frontend dazu, offenzulegen, woher seine Inhalte stammen, und deshalb erfasst eine Erhebung, die auf Erkennung beruht, ein Headless-System über Nebeneffekte statt über eine Signatur, die die Plattform in die Seite schreibt.

In der Praxis erkennen wir Strapi an Spuren, die eine Installation hinterlässt, wenn sie nicht vollständig entkoppelt ist. Mediendateien, die über den Upload-Pfad des Backends ausgeliefert werden, eine API-Route auf einer Subdomain, ein Admin-Panel unter einer Standardadresse, ein offen gelassener Vorschau- oder Plugin-Endpunkt. Jedes davon ist ein echtes Indiz. Keines davon ist garantiert vorhanden, und eine sorgfältig aufgesetzte Instanz hinter einem statischen Build und einem CDN kann überhaupt nichts hinterlassen. Jede Zahl zu einem Headless-Produkt sollte man in diesem Licht lesen, und unsere ist eine Untergrenze, keine Marktgröße.

Ist dieser Vorbehalt klar ausgesprochen, lohnt sich der Bestand trotzdem. Stand Oktober 2026 sehen wir Strapi auf 466 Websites. Das Produkt stammt von Strapi Solutions, wird im Lizenzmodell Open Source angeboten, ist in JavaScript geschrieben und geht auf 2015 zurück, womit es zu den Systemen gehört, die aufkamen, als Teams begannen, Publishing und Darstellung standardmäßig zu trennen und nicht mehr nur als Experiment. Eine Website, auf der das System läuft, verrät gleich mehrere Dinge. Es ist ein Entwicklungsteam oder eine Agentur beteiligt, denn einen Headless-Stack installiert kein Marketingmanager an einem Freitagnachmittag. Das Inhaltsmodell wurde bewusst entworfen und nicht von einem Theme geerbt. Und die Organisation hat ein Content-Backend gewählt, das sie auf eigenen Servern oder in der verwalteten Cloud des Anbieters betreiben kann, was ebenso eine Beschaffungsentscheidung ist wie eine technische.

Gerade dieses Profil macht den Export kommerziell nützlich. Hosting- und Plattformanbieter wollen die selbst gehosteten Installationen, denn aus ihnen gewinnt ein Managed-Cloud-Angebot seine Kunden. Anbieter von Komponenten und APIs wollen die Frontends, die an diesen Backends hängen und erst sichtbar werden, wenn man die Liste mit den Framework-Erkennungen in derselben Datei abgleicht. Agenturen und Sicherheitsforscher wollen die Websites, bei denen ein Admin-Panel oder eine API unter einem Standardpfad liegt, denn das ist zugleich ein Verkaufsanlass und ein Befund. Eine Abfrage pro Domain klärt keine dieser Fragen, denn bei jeder geht es um eine Menge und nicht um eine einzelne Domain.