Websites herunterladen, die GraphQL nutzen

Über GraphQL

GraphQL ist eine Spezifikation und kein Produkt, was sie zu einem ungewöhnlichen Eintrag für einen Datensatz auf Website-Ebene macht. Niemand installiert sie so, wie man ein Plugin installiert. Ein Team entscheidet, dass sein Frontend Daten über eine typisierte Abfragesprache von einem einzigen Endpunkt abruft, und was wir erkennen, sind die Spuren dieser Entscheidung im Code, den der Browser herunterlädt.

Die Entscheidung betrifft die Architektur, also ist auch das Signal ein architektonisches. Eine Website, die die Abfragesprache nutzt, hat ein von der Datenschicht entkoppeltes Frontend, eine Build-Pipeline, die JavaScript bündelt, und Entwickler, die sich für einen API-Stil entschieden haben, statt hinzunehmen, was ein CMS ausgab. Headless-Commerce, anwendungsähnliche Oberflächen und Content-Plattformen, die mehrere Frontends versorgen, landen meist hier. Einfache Visitenkarten-Websites, die auf dem Server gerendert werden, gehören dagegen nicht dazu. Der Einsatz der Abfragesprache kennzeichnet eine Website, die von einem Entwicklungsteam gebaut wurde, und für einen Anbieter, der an Entwicklungsteams verkauft, ist diese Unterscheidung mehr wert als die reine Zahl.

Die Governance liegt bei der Organisation GraphQL Foundation unter dem Dach einer größeren Open-Source-Stiftung. Die Spezifikation steht unter der Lizenz MIT, und die Referenzimplementierung und die Client-Bibliotheken, die sie verbreitet haben, sind in JavaScript geschrieben. Die Abfragesprache wurde im Jahr 2015 veröffentlicht, nachdem sie innerhalb einer großen sozialen Plattform entwickelt worden war. Eine aussagekräftige Versionsnummer gibt es im Einsatz nicht, denn die Spezifikation wächst durch Ergänzungen, und kein Client meldet einer Seite ein Release, weshalb unser Eintrag keine Versionsdaten zeigt.

Stand Oktober 2026 erkennen wir GraphQL auf 66.948 Websites. 57.822 davon verorten wir in Deutschland, und bei den Domains liegt der Schwerpunkt auf der Endung .com. Eine Konzentration dieser Größe in einem einzigen Land entsteht meist durch eine kleine Zahl großer Plattformen, Hoster oder Website-Generatoren, die dasselbe Bundle über viele Kundenwebsites ausliefern, und nicht durch ebenso viele unabhängige technische Entscheidungen. Wer mit der Länderspalte über die nationale Verbreitung argumentieren will, sollte zuerst prüfen, auf welchen Plattformen die Domains laufen, denn ein einziges weit verbreitetes Shopsystem oder ein Website-Baukasten kann eine Länderzahl allein verschieben.

Die Erkennung hat eine harte Obergrenze, die man vor dem Kauf verstehen sollte. Wir sehen die Abfragesprache, wenn im ausgelieferten JavaScript ein Endpunkt referenziert wird, wenn eine bekannte Client-Bibliothek im Bundle steckt oder wenn ein öffentlicher Endpunkt in der erwarteten Weise antwortet. Ein großer Teil der echten Nutzung bleibt unsichtbar, denn vieles davon spielt sich zwischen Servern ab, in mobilen Apps oder hinter einem Gateway, das dem Browser etwas völlig anderes liefert. Die Zahl misst die im Browser sichtbare Nutzung, und der Browser ist nur ein Abnehmer unter mehreren.

Gerade diese Lücke ist der Grund, warum die Liste als Ganzes nützlich ist und nicht Fall für Fall. Für die Bestätigung einer einzelnen Domain genügt eine Anfrage. Den Bestand an API-getriebenen Frontends zu beziffern, ihn nach Plattform und Land aufzuteilen, sein Wachstum gegenüber serverseitig gerenderten Alternativen zu beobachten und die Teilmenge herauszuziehen, die zusätzlich ein bestimmtes Framework oder Commerce-System einsetzt, sind allesamt Fragen, die den gesamten Bestand betreffen. Anbieter von Entwicklerwerkzeugen, Unternehmen für API-Infrastruktur und Analysten, die Frontend-Architektur beobachten, wollen wissen, wie dieser Bestand insgesamt aussieht, nicht eine einzelne Zeile darin.