Graphql

Was ist GraphQL?

GraphQL ist eine Abfragesprache und Laufzeitumgebung für Programmierschnittstellen. Clients fordern über ein typisiertes Schema genau die benötigten Felder an und erhalten eine entsprechend strukturierte Antwort. Meist laufen Abfragen über einen zentralen Endpunkt. Neben lesenden Queries unterstützt GraphQL schreibende Mutations und, je nach Implementierung, laufende Aktualisierungen über Subscriptions.

GraphQL (sinngemäß: graphbasierte Abfragesprache) beschreibt, welche Daten ein Client von einer API benötigt. Der Server veröffentlicht dafür ein Schema mit verfügbaren Datentypen, Feldern und Beziehungen. Eine Anwendung kann dadurch beispielsweise den Namen, den Preis und das Bild eines Produkts in einer einzigen Anfrage abrufen, ohne weitere Produktdaten übertragen zu müssen.

Facebook entwickelte GraphQL ab 2012 für mobile Anwendungen und veröffentlichte die Technologie 2015. GraphQL ist weder eine Datenbank noch ein festes Übertragungsprotokoll. Die Abfragesprache bildet eine Schnittstelle zwischen Clients und bestehenden Datenquellen wie Datenbanken, Microservices, Warenwirtschaftssystemen oder externen APIs.

So funktioniert GraphQL

Das Schema bildet den Vertrag zwischen Client und Server. Es definiert beispielsweise, dass der Typ Product die Felder name, price und category besitzt. Jeder Feldtyp ist festgelegt. Ein Preis kann etwa als Fließkommazahl und ein Produktname als nicht leerer Text definiert sein. Der Server kann eine ungültige Anfrage deshalb ablehnen, bevor er Daten verarbeitet.

Eine typische GraphQL-API stellt drei Operationsarten bereit:

Query: Eine Query liest Daten, etwa Produktinformationen oder Kundendaten.
Mutation: Eine Mutation verändert Daten, etwa durch das Anlegen einer Bestellung oder Aktualisieren eines Profils.
Subscription: Eine Subscription überträgt neue Ereignisse fortlaufend, etwa Statusänderungen oder eingehende Nachrichten.

Resolver verbinden die Felder des Schemas mit den tatsächlichen Datenquellen. Fragt ein Client das Feld price ab, bestimmt der zugehörige Resolver, aus welcher Datenbank oder welchem Dienst der Wert stammt. Authentifizierung, Berechtigungen und Geschäftsregeln werden ebenfalls auf Serverebene geprüft.

Eine Abfrage wie { product(id: 42) { name price } } fordert für das Produkt mit der ID 42 ausschließlich den Namen und den Preis an. Die Antwort folgt derselben Struktur, beispielsweise { data: { product: { name: 'Schreibtisch', price: 399 } } }. Diese Vorhersehbarkeit erleichtert die Verarbeitung im Client.

GraphQL und REST im Vergleich

Der Unterschied zwischen GraphQL und REST liegt vor allem in der Steuerung der Datenauswahl. Bei REST legt der Server fest, welche Struktur ein Endpunkt zurückgibt. Bei GraphQL wählt der Client innerhalb des veröffentlichten Schemas selbst die benötigten Felder aus. GraphQL ersetzt REST deshalb nicht automatisch. Die bessere Wahl hängt von Datenmodell, Caching, Teamkompetenz und Anwendung ab.

Kriterium	GraphQL	REST
Endpunkte	Häufig ein zentraler Endpunkt	Meist mehrere ressourcenbezogene Endpunkte
Datenauswahl	Der Client bestimmt die Felder	Der Server bestimmt die Antwortstruktur
Versionierung	Schema kann um Felder erweitert und über veraltete Felder weiterentwickelt werden	Neue Versionen werden häufig über neue Endpunkte bereitgestellt
HTTP-Caching	Erfordert oft zusätzliche Konzepte wie persistierte Abfragen	Lässt sich bei GET-Anfragen direkt über URLs und HTTP-Header steuern
Fehlerbehandlung	Daten und einzelne Feldfehler können gemeinsam auftreten	Fehler werden meist über HTTP-Statuscodes und Antwortkörper abgebildet

GraphQL verhindert Overfetching, wenn eine REST-Antwort mehr Felder liefert als benötigt. GraphQL reduziert außerdem Underfetching, wenn ein Client mehrere REST-Endpunkte aufrufen müsste, um eine Ansicht aufzubauen. Eine einzelne GraphQL-Anfrage kann jedoch intern zahlreiche Datenbankzugriffe verursachen. Weniger Netzwerkanfragen bedeuten daher nicht automatisch weniger Serverarbeit.

GraphQL für SEO und GEO 2026

GraphQL beeinflusst SEO nicht direkt, weil Suchmaschinen die API-Abfragen einer Anwendung üblicherweise nicht als eigenständige Inhalte indexieren. Maßgeblich ist das gerenderte HTML, das ein Crawler unter einer erreichbaren URL erhält. Produkttexte, Überschriften, interne Links, strukturierte Daten und Canonical Tags müssen deshalb unabhängig von der verwendeten API im HTML verfügbar sein.

Bei Headless-Websites liefert GraphQL häufig Inhalte aus einem Content-Management-System an ein getrenntes Frontend. Lädt der Browser diese Inhalte erst nach umfangreicher JavaScript-Ausführung, kann die Darstellung für Nutzer und Crawler verzögert werden. Serverseitiges Rendering oder statische Generierung stellen zentrale Inhalte bereits mit der ersten HTML-Antwort bereit. Diese Architektur sollte deshalb schon bei der Planung eines SEO-orientierten Webdesigns festgelegt werden.

Für GEO, also Generative Engine Optimization, gelten vergleichbare Anforderungen. GraphQL macht Inhalte nicht automatisch für ChatGPT, Perplexity, Gemini oder Grok auffindbar. KI-Systeme benötigen öffentlich erreichbare, klar strukturierte und zitierfähige Seiten. Bleiben Produktdaten ausschließlich hinter einer API oder innerhalb einer nicht gerenderten Benutzeroberfläche, fehlt eine indexierbare Quelle.

Performance belastbar messen

GraphQL kann die übertragene Datenmenge reduzieren, doch ein kleiner Antwortkörper garantiert keine schnelle Seite. Messbar ist das zum Beispiel über API-Antwortzeit, übertragene Kilobyte, Fehlerrate sowie die Core Web Vitals der fertigen Seite. Prüfe besonders den Largest Contentful Paint und die Interaction to Next Paint, wenn sichtbare Inhalte oder Interaktionen von einer GraphQL-Anfrage abhängen. Der kostenlose Ladezeiten-Check zeigt, ob die technische Auslieferung die Seitengeschwindigkeit beeinträchtigt.

Typische Fehler bei GraphQL

Ein verbreiteter Denkfehler lautet, dass eine einzige GraphQL-Anfrage grundsätzlich effizienter als mehrere REST-Anfragen sei. Ein Resolver kann für jedes Element einer Liste eine weitere Datenbankabfrage auslösen. Dieses N+1-Problem erzeugt bei 100 Produkten beispielsweise eine Abfrage für die Produktliste und bis zu 100 zusätzliche Abfragen für zugehörige Kategorien. Batching und Caching auf Resolver-Ebene bündeln solche Zugriffe.

Unbegrenzte Abfragetiefe ist ein weiteres Risiko. Ein Client könnte verschachtelte Beziehungen wie Produkte, Kategorien, verwandte Produkte und deren Kategorien wiederholt anfordern. Der Server sollte deshalb Grenzwerte für Tiefe, Komplexität und Antwortgröße festlegen. Zeitlimits, Ratenbegrenzungen und persistierte Abfragen ergänzen diese Kontrolle.

GraphQL übernimmt keine Zugriffsrechte automatisch aus dem Schema. Jeder Resolver muss prüfen, ob der angemeldete Nutzer das angeforderte Objekt und das einzelne Feld lesen oder verändern darf. Eine geschützte Benutzeroberfläche reicht nicht aus, weil API-Anfragen unabhängig vom Frontend gesendet werden können.

Auch das Caching verlangt eine bewusste Architektur. Viele GraphQL-Anfragen verwenden denselben Endpunkt und werden per POST übertragen. Klassische CDN-Caches können Antworten dadurch schlechter anhand der URL unterscheiden. Persistierte Abfragen ordnen vorher freigegebenen Dokumenten eine Kennung zu und erleichtern dadurch Caching, Monitoring und die Begrenzung zulässiger Operationen.

GraphQL im Website-Projekt prüfen

Vor einem Relaunch sollte geklärt sein, welche Inhalte per GraphQL geladen werden und wann sie im HTML erscheinen. Prüfe Templates für Startseite, Kategorien, Produkte, Ratgeber und lokale Landingpages jeweils mit deaktiviertem JavaScript oder anhand der serverseitigen HTML-Antwort. Die SEO-Checkliste für den Website-Relaunch hilft dabei, Indexierung, Weiterleitungen und technische Signale systematisch abzusichern.

Für die technische Bewertung einer GraphQL-Implementierung sind folgende Fragen relevant:

Sind geschäftskritische Inhalte bereits in der initialen HTML-Antwort vorhanden?
Besitzt jede indexierbare Seite eine dauerhafte und intern verlinkte URL?
Begrenzen Serverregeln die Tiefe und Komplexität von Abfragen?
Verhindern Batching und Caching wiederholte Datenbankzugriffe?
Werden API-Latenz, Resolver-Fehler und Core Web Vitals gemeinsam überwacht?

Ein technisches SEO-Audit sollte deshalb nicht nur Quellcode und Statuscodes untersuchen. Bei einer Headless-Architektur müssen zusätzlich Rendering, API-Abhängigkeiten, interne Verlinkung und die Verfügbarkeit zentraler Inhalte geprüft werden.

Häufige Fragen zu GraphQL

Ist GraphQL eine Programmiersprache?

GraphQL ist eine Abfragesprache mit einem Typsystem, aber keine allgemeine Programmiersprache. Die Serverlogik wird weiterhin in einer Sprache wie JavaScript, Java, PHP, Python oder C# implementiert.

Braucht GraphQL immer nur einen Endpunkt?

Viele Implementierungen verwenden einen zentralen Endpunkt wie /graphql. Die Spezifikation schreibt diese Struktur jedoch nicht zwingend vor, sodass Anwendungen mehrere Endpunkte oder getrennte Dienste einsetzen können.

Kann GraphQL mit jeder Datenbank verwendet werden?

GraphQL ist nicht an eine bestimmte Datenbank gebunden. Resolver können Daten aus relationalen Datenbanken, Dokumentendatenbanken, REST-APIs, Microservices oder mehreren Quellen gleichzeitig beziehen.

Ist GraphQL automatisch schneller als REST?

GraphQL ist nicht automatisch schneller. Die Datenauswahl kann Netzwerkanfragen und Übertragung reduzieren, während komplexe Resolver, tiefe Abfragen oder das N+1-Problem die Verarbeitung auf dem Server verlängern können.

Können Suchmaschinen GraphQL-Inhalte indexieren?

Suchmaschinen indexieren die öffentlich erreichbare Webseite und deren gerendertes HTML. Inhalte aus GraphQL können indexiert werden, wenn das Frontend sie zuverlässig ausgibt und jede relevante Seite eine crawlbare URL besitzt.

Was sind persistierte GraphQL-Abfragen?

Persistierte Abfragen sind vorab gespeicherte GraphQL-Dokumente, die ein Client über eine Kennung aufruft. Sie vereinfachen Caching und Monitoring und können verhindern, dass beliebige Abfragen an den Server gesendet werden.