// stack · schnittstelle
Perplexity ist ein Antwortsystem mit Websuche: Eine Frage geht hinein, heraus kommt eine Antwort — und die Quellen, auf denen sie beruht. Für siteway hat das zwei Seiten. Man kann diese Schnittstelle in eine Website einbauen. Und man kann eine Website so bauen, dass sie in solchen Antworten selbst als Quelle auftaucht. Diese Seite beschreibt beide Richtungen.
// definition
antwort · plus beleg
Perplexity ist ein Antwortsystem mit Websuche. Eine Frage geht hinein, heraus kommt eine Antwort in Prosa — und dazu die Seiten, auf denen sie beruht. Über die Schnittstelle läuft dasselbe automatisiert: Die Frage wird als JSON gesendet, die Antwort kommt als JSON zurück, und in dieser Antwort stehen laut Dokumentation neben dem Text auch die verwendeten Quellen sowie die Suchtreffer mit Titel, Adresse, Auszug und Datum.
Das Kernmerkmal ist die Aktualität. Grundlage der Antwort ist nicht allein das, was ein Modell einmal gelernt hat, sondern das, was zum Zeitpunkt der Anfrage im Web steht. Genau daraus folgt die Besonderheit dieser Schnittstelle gegenüber den beiden Nachbarn im Stack: Anthropic und OpenAI arbeiten mit dem, was man ihnen mitgibt — Perplexity ist darauf ausgelegt, selbst zu recherchieren und die Fundstellen zu benennen. Das ist keine Rangliste, sondern eine Zuordnung nach Aufgabe.
Und daraus folgt die Erwartung, die vorher geklärt sein sollte: Eine Antwort mit Quellen ist ein gut belegter Vorschlag, kein Faktenbeweis. Die Quellen machen sie prüfbar — prüfen muss trotzdem jemand. Wie wir das in der Umsetzung behandeln, steht weiter unten unter Wofür wir Perplexity einsetzen.
// praxis
recherche · mit beleg
Am tragfähigsten ist diese Schnittstelle dort, wo ein Mensch das Ergebnis prüft, bevor es jemand anderes sieht. Drei Fälle bewähren sich in Projekten. Der erste ist die Recherche-Unterstützung im Redaktions-Backend: Die Redaktion gibt eine Frage ein und bekommt eine Sammlung belegter Fundstellen mit einer kurzen Einordnung — als Startpunkt für einen eigenen Text, nicht als fertiger Text.
Der zweite ist die Marktbeobachtung: öffentlich verfügbare Entwicklungen zu einem Thema, gebündelt und intern ausgegeben, damit jemand sie liest statt sie zu suchen. Der dritte ist die Zusammenfassung öffentlicher Quellen — Normen, Behördenseiten, Fachtexte — immer mit dem Link daneben. Alle drei haben dasselbe Muster: Sie sparen den Weg zur Information, nicht die Beurteilung.
Und dann gibt es eine Zuordnung, die wir früh treffen, weil sie sonst später Ärger macht: Für Auskünfte über die eigenen Produkte ist ein Modell mit Websuche der falsche Weg. Es kennt deine Preisliste nicht besser, als das Web sie kennt. Dafür gehören die eigenen Inhalte in den Kontext — über eine Schnittstelle ohne Websuche wie Anthropic oder OpenAI, oder über die Suche auf der eigenen Website. Zwei Aufgaben, zwei Wege, beide im Werkzeugkasten.
Bleibt die Verlässlichkeit, und dazu gehört Klartext. Drei Dinge können auseinanderlaufen: Die Quelle kann selbst falsch oder veraltet sein. Die Zusammenfassung kann eine Aussage schärfer machen, als sie im Original steht. Und eine Quelle kann genannt sein, ohne den Satz zu tragen, neben dem sie steht. Deshalb zeigen wir die Quellen immer an, damit man sie öffnen kann — und wo eine Aussage öffentlich sichtbar wird, sieht ein Mensch sie vorher an. Wo das nicht möglich ist, gehört die Ausgabe ins Backend und nicht auf die Website. Die Leistung dahinter ist KI-Automation, die Anbindung selbst gehört zur Schnittstellenentwicklung.
// technik · 6 details
belegt aus der doku
Was hier steht, stammt aus der öffentlichen Dokumentation von Perplexity — Begriffe und Felder im Original. Modellbezeichnungen mit Versionsständen, Grenzwerte und Preise lassen wir bewusst weg: Sie ändern sich, und was für dein Projekt gilt, steht in deinem Vertrag und nicht auf einer Agenturseite.
// d-01zugang
Der Zugang läuft über einen API-Schlüssel, der als Bearer-Token im Authorization-Header mitgeschickt wird. Ein Header, ein Geheimnis — und genau deshalb entscheidet sich hier, ob eine Anbindung sauber gebaut ist: Der Schlüssel darf nirgends landen, wo ein Browser ihn lesen kann.
zweck: wer darf fragen
// d-02anfrage
Gesendet wird ein JSON-Objekt mit dem gewünschten Modell und einer Liste von Nachrichten. Jede Nachricht trägt eine Rolle — System, Benutzer, Assistent — und ihren Inhalt. Der Verlauf einer Unterhaltung entsteht dadurch, dass die bisherigen Nachrichten mitgesendet werden.
zweck: was gefragt wird
// d-03quellen
Die Antwort enthält den erzeugten Text — und laut Dokumentation zusätzlich die verwendeten Quellen sowie die Suchtreffer mit Titel, Adresse, Auszug und Datum. Das ist der Teil, der diese Schnittstelle ausmacht: Der Beleg kommt mit, man muss ihn nur ausgeben.
zweck: antwort wird prüfbar
// d-04suche
Die Dokumentation beschreibt einen Suchmodus, der bestimmt, worin gesucht wird — im offenen Web oder in engeren Beständen wie akademischen Quellen. Ebenso lässt sich die Websuche für eine Anfrage abschalten. Damit wird steuerbar, wie weit die Recherche für einen Anwendungsfall reichen soll.
zweck: worin recherchiert wird
// d-05ausgabe
Neben freiem Text ist eine Ausgabe nach einem JSON-Schema dokumentiert — nützlich, wenn das Ergebnis nicht gelesen, sondern weiterverarbeitet wird. Dazu kommen Streaming für eine Antwort, die während der Erzeugung erscheint, und optional vorgeschlagene Anschlussfragen.
zweck: form des ergebnisses
// d-06grenze
Eine Quelle neben einem Satz belegt nicht automatisch diesen Satz. Sie kann veraltet sein, sie kann etwas anderes sagen, und die Zusammenfassung kann zuspitzen. Deshalb ist die Anzeige der Quellen bei uns kein Zierrat, sondern die Voraussetzung dafür, dass jemand nachsehen kann.
zweck: ehrlicher umgang
// integration
drei systeme · ein muster
Der Weg ist in jedem System derselbe, weil er sich aus der Aufgabe ergibt und nicht aus dem CMS. Der API-Schlüssel bleibt ausschließlich serverseitig. Das Frontend spricht nie mit dem Anbieter, sondern mit einem eigenen Endpunkt auf deinem Server — und dieser Endpunkt tut mehr, als weiterzureichen: Er prüft, wer fragen darf und was gefragt wird, er begrenzt Länge und Anzahl der Anfragen pro Besucher und Zeitraum, er protokolliert Fehler, und er hat einen Zustand für den Fall, dass der Dienst nicht antwortet. Missbrauchsschutz und Kostenkontrolle sind dasselbe Bauteil: Wer eine Schnittstelle ungebremst ins Frontend legt, bezahlt am Ende fremde Anfragen.
Dazu kommt eine Besonderheit, die es bei anderen Schnittstellen so nicht gibt. Weil die Antworten aus dem Web stammen, gehören die Quellenangaben mit ausgegeben — sonst steht eine Behauptung ohne Beleg auf deiner Seite, für die du geradestehst. Unser Endpunkt reicht die Quellenliste deshalb immer mit an das Frontend weiter, und die Ausgabe zeigt sie sichtbar und anklickbar neben oder unter der Antwort. Das ist der Kern dieser Einbindung und keine Feinheit für später. Was das CMS darunter unterscheidet, ist nur, wo Route, Controller und Schlüssel jeweils hingehören.
// cms-01typo3
Wir bauen die Anbindung als eigene Extension. Darin liegt eine Controller-Route, die die Anfrage aus dem Frontend entgegennimmt, prüft und begrenzt und erst dann die Schnittstelle aufruft. Der Schlüssel steht in der Extension-Konfiguration oder als Umgebungsvariable und wird nie an ein Template gereicht. Die Ausgabe rendert Fluid — Antwort und Quellenliste als eigene Teilbereiche, damit die Belege im Design der Website stehen und nicht daneben. Wo eine Redaktion mit dem Ergebnis arbeitet, sitzt die Oberfläche im Backend-Modul statt im Frontend.
// cms-02wordpress
Die Anbindung entsteht als eigenes Plugin und nicht als Theme-Code — so überlebt sie einen Theme-Wechsel. Darin registrieren wir eine eigene REST-Route mit Rechteprüfung und Begrenzung; sie ist die einzige Stelle, die die Schnittstelle aufruft. Der Schlüssel steht in der wp-config.php oder als Umgebungsvariable, nicht in der Datenbank und nicht in einem Frontend-Skript. Für die Redaktion kommt eine Ansicht im Adminbereich dazu, in der Antwort und Quellen nebeneinander stehen und sich einzeln in den Beitrag übernehmen lassen.
// cms-03statamic
Unter Statamic liegt Laravel, und das macht die Anbindung geradlinig: eine Route plus Controller, davor die Middleware für Begrenzung und Rechte, dahinter ein Service, der die Schnittstelle aufruft und Antwort samt Quellen zurückgibt. Der Schlüssel liegt in der .env und wird über die Konfiguration gelesen, nie direkt im Code. Die Ausgabe rendern Antlers oder Blade. Längere Recherchen laufen als Queue-Job, damit die Seite nicht auf die Antwort wartet — und das Ergebnis erscheint, sobald es da ist.
// zweite blickrichtung
nicht nur einbauen · vorkommen
Perplexity ist nicht nur eine Schnittstelle, die man einbauen kann — es ist auch ein Antwortsystem, in dem die eigene Website als Quelle auftauchen kann. Für viele Unternehmen ist das die wichtigere Richtung. Und sie funktioniert anders als klassische Suche: Antwortsysteme übernehmen selten eine ganze Seite, sondern die Passage, die eine Frage beantwortet. Was man beeinflussen kann, ist deshalb die Zitierfähigkeit der eigenen Inhalte. Welche Quelle ein System am Ende auswählt, entscheidet das System — ein Versprechen ist das hier ausdrücklich nicht.
// z-01struktur
Eine Überschriftenhierarchie, die dem Inhalt folgt, statt der Optik. Abschnitte, die genau ein Thema behandeln und sich einzeln zitieren lassen. Wer eine Passage aus dem Zusammenhang nehmen kann, ohne dass sie unverständlich wird, hat die halbe Arbeit erledigt.
überschriften mit inhalt
// z-02antwort
Die Kernaussage steht im ersten Satz eines Abschnitts, die Begründung danach. Fragen, die Kunden tatsächlich stellen, werden als Frage benannt und beantwortet — als Definition, als FAQ, als klarer Satz. Was erst im dritten Absatz beantwortet wird, wird selten zitiert.
antwort vor argument
// z-03belege
Zahlen mit Quelle, Standards mit Namen, Schwellenwerte statt „schnell“. Ein System, das Belege ausgibt, greift lieber auf Inhalte zurück, die selbst belegen. Das ist dieselbe Disziplin, die diese Seite von sich verlangt — nachzulesen an den Stellen, an denen hier „laut Dokumentation“ steht.
fakten statt adjektive
// z-04markup
Schema.org-JSON-LD je Seitentyp sagt einer Maschine, was sie vor sich hat: Organisation, Leistung, Artikel, FAQ, Brotkrumen. Damit muss ein System nicht aus dem Layout raten, wer du bist. Wie wir das aufbauen, steht im Stack unter Strukturierte Daten.
json-ld je seitentyp
// z-05textfassung
Neben der gestalteten Seite eine schlichte Textfassung derselben Inhalte, dazu eine kuratierte Übersicht der wichtigsten Seiten für Sprachmodelle. Das nimmt Systemen die Arbeit ab, aus Layout und Skripten den Inhalt zu rekonstruieren — diese Website liefert beides mit aus.
text neben layout
// z-06zugang
Zitiert werden kann nur, was gelesen werden darf und ohne Umwege ausgeliefert wird. Und ob es passiert, lässt sich prüfen: mit einem festen Fragenset, regelmäßig gestellt und protokolliert. Der Ist-Zustand dafür ist ein GEO-Audit.
lesbar · messbar
Wer eine Schnittstelle einbaut, die Quellen ausgibt, versteht schnell, was eine Quelle brauchbar macht: eine klare Aussage an einer auffindbaren Stelle, mit Datum und Beleg. Dieselbe Einsicht gilt für die eigene Website, nur andersherum. Deshalb behandeln wir bei siteway beides als eine Denkbewegung und nicht als zwei Projekte.
Die laufende Arbeit daran ist eine eigene Leistung: SEO & GEO — technisches SEO für Rankings, Generative Engine Optimization für Zitate in Antwortsystemen. Die Diagnose davor ist das GEO-Audit: gemessen wird mit einem festen Fragenset, ob und wie deine Inhalte in KI-Antworten auftauchen. Und die technische Grundlage für beides liegt im Stack unter Strukturierte Daten.
// datenschutz
sachlich · keine rechtsberatung
Sachlich passiert eines: Jede Anfrage verlässt deinen Server und geht zu einem externen Anbieter. Das ist kein Ausschlussgrund, aber es gehört vor dem Start auf den Tisch — nicht in die Datenschutzerklärung nach dem Launch.
Der erste Punkt ist Datensparsamkeit, und er ist der wirksamste. In die Anfrage geht die Frage und der Kontext, der für die Antwort gebraucht wird — und sonst nichts. Namen, Adressen, Kundennummern, Inhalte aus geschützten Bereichen und interne Notizen haben darin nichts verloren. Wo Besucher selbst etwas eintippen können, gehört an das Eingabefeld ein deutlicher Hinweis, wohin diese Eingabe geht.
Der zweite Punkt ist die Auftragsverarbeitung: Wer im Auftrag verarbeitet, braucht einen Vertrag darüber, genauso wie der Hoster. Der dritte ist die Transparenz — die Nennung des Dienstes in der Datenschutzerklärung, samt der Angabe, welche Daten dabei übermittelt werden. Wie das mit dem Rest der Auslieferung zusammenpasst, steht im Stack unter Sicherheit & Datenschutz. Eine Rechtsberatung ist das ausdrücklich nicht — die Bewertung im Einzelfall gehört zu deinem Datenschutzbeauftragten oder deiner Rechtsberatung.
// faq
Perplexity ist ein Antwortsystem mit Websuche. Eine Frage geht hinein, heraus kommt eine Antwort in Prosa — und dazu die Seiten, auf denen sie beruht. Über die Schnittstelle wird die Frage als JSON gesendet; die Dokumentation beschreibt in der Antwort neben dem Text auch Felder für die verwendeten Quellen und für die Suchtreffer mit Titel, Adresse, Auszug und Datum. Das Kernmerkmal ist die Aktualität: Grundlage ist nicht allein das, was ein Modell einmal gelernt hat, sondern das, was zum Zeitpunkt der Anfrage im Web steht. Genau deshalb gehören die Quellen zur Antwort dazu und nicht in eine Fußnote, die man weglassen kann.
Die Richtung, aus der die Information kommt. Die Schnittstellen von Anthropic und OpenAI arbeiten mit dem, was man ihnen mitgibt: Text, Daten, Dokumente aus dem eigenen Bestand. Perplexity ist darauf ausgelegt, im Web zu recherchieren und die gefundenen Seiten zu benennen. Das ist keine Rangliste, sondern eine Zuordnung nach Aufgabe. Geht es um Inhalte, die im eigenen Haus liegen, ist der Weg über den eigenen Kontext der passende. Geht es um öffentlich zugängliche, aktuelle Information mit Beleg, ist eine Schnittstelle mit Websuche der passende. In vielen Projekten stehen beide Wege nebeneinander.
Am tragfähigsten ist sie dort, wo ein Mensch das Ergebnis prüft, bevor es jemand anderes sieht. Drei Fälle bewähren sich: Recherche-Unterstützung im Redaktions-Backend, damit die Redaktion beim Schreiben eine Sammlung belegter Fundstellen bekommt statt einer leeren Seite. Marktbeobachtung, die öffentlich verfügbare Entwicklungen zu einem Thema bündelt und intern ausgibt. Und die Zusammenfassung öffentlicher Quellen — Normen, Behördenseiten, Fachtexte —, immer mit dem Link daneben. Für Auskünfte über die eigenen Produkte ist der passende Weg ein anderer: Dafür gehören die eigenen Inhalte in den Kontext, über eine Schnittstelle ohne Websuche oder über die eigene Suche auf der Website. Ein Modell, das im Web recherchiert, kennt deine Preisliste nicht besser als das Web sie kennt.
Indem wir sie von Anfang an mit ausgeben. Die Antwort der Schnittstelle enthält laut Dokumentation neben dem Text die verwendeten Quellen sowie die Suchtreffer mit Titel, Adresse, Auszug und Datum. Unser Endpunkt reicht diese Angaben mit an das Frontend weiter, und die Ausgabe zeigt sie sichtbar unter oder neben der Antwort — als anklickbare Liste, nicht als grauer Hinweis. Der Grund ist schlicht: Ohne Beleg steht eine Behauptung auf deiner Seite, für die du geradestehst. Mit Beleg steht dort eine nachprüfbare Aussage. Deshalb behandeln wir die Quellenliste als Pflichtbestandteil der Ausgabe und nicht als optionales Extra, das im Redesign herausfällt.
Verlässlich genug, um damit zu arbeiten — nicht verlässlich genug, um sie ungeprüft zu veröffentlichen. Eine Antwort mit Quellen ist ein gut belegter Vorschlag, kein Faktenbeweis. Drei Dinge können auseinanderlaufen: Die Quelle kann selbst falsch oder veraltet sein, die Zusammenfassung kann eine Aussage schärfer machen, als sie im Original steht, und eine Quelle kann genannt sein, ohne den Satz zu tragen, neben dem sie steht. Unsere Konsequenz im Bau ist deshalb immer dieselbe: Die Quellen werden angezeigt, damit man sie öffnen kann, und dort, wo eine Aussage öffentlich sichtbar wird, sieht ein Mensch sie vorher an. Wo das nicht möglich ist, gehört die Ausgabe ins Backend und nicht auf die Website.
Über Inhalte, die sich zitieren lassen. Antwortsysteme übernehmen selten eine ganze Seite, sondern die Passage, die eine Frage beantwortet. Das lässt sich vorbereiten: eine klare Struktur mit sprechenden Überschriften, Abschnitte, die die Kernaussage im ersten Satz nennen, belegte Zahlen statt Behauptungen, saubere strukturierte Daten und maschinenlesbare Textfassungen der wichtigen Seiten. Dazu gehört der technische Zugang — ein Antwortsystem kann nur zitieren, was es lesen darf. Ein Versprechen ist das ausdrücklich nicht: Welche Quelle ein System auswählt, entscheidet das System. Was man beeinflussen kann, ist die Zitierfähigkeit der eigenen Inhalte. Der Ist-Zustand lässt sich messen, und die laufende Arbeit daran ist eine eigene Leistung.
Sachlich passiert eines: Jede Anfrage verlässt deinen Server und geht zu einem externen Anbieter. Daraus folgen drei Punkte, die vor dem Start auf den Tisch gehören. Erstens Datensparsamkeit — in die Anfrage geht die Frage und der Kontext, der für die Antwort gebraucht wird, und sonst nichts; Namen, Adressen, Kundennummern und Inhalte aus geschützten Bereichen haben darin nichts verloren. Zweitens die Auftragsverarbeitung: Wer im Auftrag verarbeitet, braucht einen Vertrag darüber, genauso wie der Hoster. Drittens die Transparenz gegenüber den Besuchern — wo eine Eingabe zu einem Dritten geht, gehört das in die Datenschutzerklärung und an die Stelle, an der eingegeben wird. Eine Rechtsberatung ist das ausdrücklich nicht.
Ja, in allen drei Systemen — und wir bauen die Anbindung jeweils selbst mit den Bordmitteln des Systems. Die Kette ist überall dieselbe: Das Frontend spricht mit einem eigenen Endpunkt auf deinem Server, dieser Endpunkt prüft und begrenzt die Anfrage, ruft die Schnittstelle mit dem Schlüssel auf und gibt Antwort samt Quellen zurück. In TYPO3 entsteht dafür eine eigene Extension mit einer Controller-Route; der Schlüssel liegt in der Extension-Konfiguration oder als Umgebungsvariable, die Ausgabe rendert Fluid. In WordPress bauen wir ein eigenes Plugin statt Theme-Code, mit einer eigenen REST-Route und dem Schlüssel in der wp-config.php oder als Umgebungsvariable. In Statamic liegt Laravel darunter: eine Route plus Controller, der Schlüssel in der .env, die Ausgabe in Antlers oder Blade. Im Browser landet der Schlüssel in keinem der drei Systeme.
// womit das zusammenhängt
technik, sichtbarkeit & leistung
// leistung · sichtbarkeit
Die andere Blickrichtung als laufende Leistung: technisches SEO für Rankings, Generative Engine Optimization für Zitate in Antwortsystemen.
zur leistung →
// audit · diagnose
Der Ist-Zustand vorher: Mit einem festen Fragenset messen wir, ob deine Marke genannt und deine Seiten als Quelle zitiert werden.
zum audit →
// stack · schnittstelle
Die Schnittstelle für Aufgaben, bei denen der Kontext mitgegeben wird — eigene Texte, eigene Daten, eigene Dokumente.
zur technik →
// stack · schnittstelle
Ebenfalls eine Schnittstelle, die mit dem arbeitet, was man ihr mitgibt — mit demselben Grundsatz beim Schlüssel: serverseitig.
zur technik →
// stack · grundlage
Schema.org-JSON-LD je Seitentyp: die Grundlage dafür, dass Maschinen eine Seite nicht nur lesen, sondern einordnen können.
zur technik →
// leistung · buchbar
Die buchbare Leistung dahinter: KI-gestützte Abläufe in Website und Backend — mit Prüfschritt statt Automatik ohne Aufsicht.
zur leistung →
Die Anbindung selbst — eigener Endpunkt, Prüfung, Begrenzung, Fehlerfall — gehört zur Schnittstellenentwicklung. Was zu deinem Projekt passt, klären wir vorher und mit Begründung.
// Antworten mit Quellen — eingebaut oder selbst zitiert?
Projekt anfragen