// stack · search
Die Suche im Stack von siteway ist eine statische Volltextsuche mit Pagefind: Der Index entsteht beim Build, die Suche läuft als WebAssembly komplett im Browser — ohne Suchserver, ohne Datenbank, ohne externes Tracking. Für große Kataloge binden wir stattdessen einen echten Suchdienst an.
// definition
Pagefind ist eine Open-Source-Bibliothek für statische Volltextsuche: Sie indexiert nach dem Build das fertig gerenderte HTML einer Website und macht daraus eine Suche, die vollständig im Browser läuft — ohne Suchserver und ohne Datenbank. Der Index liegt als statische Dateien direkt neben der Seite, jede Anfrage wird lokal beantwortet.
Statische Suche heißt: Die Arbeit passiert einmal beim Build, nicht bei jeder Anfrage. Ein klassischer Suchserver hält einen Dienst am Laufen, den er bei jeder Eingabe befragt. Pagefind kehrt das um — es baut den Index vor und liefert die Suchlogik als WebAssembly mit aus. Das macht die Suche schnell, günstig im Betrieb und unabhängig von einem Dienst, der ausfallen kann.
// praxis
diese seite sucht damit
Das beste Beispiel ist die Seite, die du gerade liest. Die Command-Palette oben (⌘K) durchsucht diese Website mit Pagefind — kein Fremddienst, keine externe Anfrage, alles aus den ausgelieferten Dateien. Wir bauen die Suche als letzten Build-Schritt: erst entsteht das HTML aller Seiten, dann läuft Pagefind darüber und legt den Index an.
Damit im Index nur steht, was zählt, markieren wir den durchsuchbaren Bereich mit
data-pagefind-body
am Hauptinhalt. Navigation, Footer und Command-Palette bleiben draußen — sonst würde jede
Seite denselben Rahmen als Treffer melden. Die Runtime liegt lokal auf demselben Host wie die
Website, damit sie zur trackingfreien Auslieferung und einer strengen
Content-Security-Policy passt.
Weil Pagefind statisch ist, gibt es nichts extra zu betreiben: Der Index wird bei jedem Deploy neu gebaut und über dieselbe Pipeline ausgeliefert wie der Rest der Seite. Das ist der Grund, warum wir Pagefind für die meisten inhaltsgetriebenen Projekte zur ersten Wahl machen — es kostet im Betrieb nichts und hat keine bewegten Teile. Buchen lässt sich die fertige Suchfunktion als Komponente Suche.
// technik · 6 details
index vor · nur nötiges laden
Sechs Bausteine erklären, warum eine statische Suche klein bleibt und trotzdem skaliert. Jeder hat eine konkrete technische Folge.
// t-01build
Pagefind läuft als CLI nach dem Build und indexiert das gerenderte HTML — egal ob aus TYPO3-Export, Statamic, einem Generator oder plain HTML. Es braucht keine Anbindung an das CMS, nur die fertigen Seiten.
input: gerendertes html
// t-02runtime
Die Suchlogik ist als WebAssembly kompiliert und läuft direkt im Browser. Eingaben werden lokal ausgewertet, es geht keine Anfrage an einen Server. Schnell, weil kein Netzweg zwischen Tastendruck und Ergebnis liegt.
laufzeit: clientseitig
// t-03chunks
Statt eines Monolithen wird der Index in viele geordnete Chunks zerlegt. Beim Suchen lädt der Browser nur die Teile, die die Anfrage betrifft — so skaliert die Suche bis in den Bereich von zehntausenden Seiten.
laden: nur nötige chunks
// t-04last
Weil nur passende Chunks geladen werden, bleibt die Gesamtlast gering: rund 100 kB bei den meisten Seiten, unter 300 kB selbst bei 10.000 Seiten — jeweils inklusive der Bibliothek. Das schont Ladezeit und Core Web Vitals.
payload: ~100 kb typisch
// t-05i18n
Pagefind liest das lang-Attribut und baut je Sprache einen eigenen Index. Deutsche und englische Inhalte werden getrennt durchsucht, ohne dass beide Indizes gleichzeitig laden — praktisch bei Seiten mit vielen Sprachen.
sprachen: index je locale
// t-06relevanz
Über data-pagefind-filter entstehen Facetten, über data-pagefind-weight steuern wir, was schwerer wiegt — etwa Überschriften vor Fließtext. Dazu Tippfehler-Toleranz, Stemming und exakte Phrasen in Anführungszeichen.
ranking: filter · weight · fuzzy
// netzlast
gesamtlast · inkl. bibliothek
Der übliche Reflex bei Suche lautet: „Das braucht doch einen Server, sonst lädt der Browser den ganzen Index." Genau das umgeht der gechunkte Aufbau. Pagefind lädt beim ersten Tastendruck die Bibliothek und danach nur die Chunks, die zur Anfrage gehören.
Das Ergebnis ist eine Suche, deren Gesamtlast bei den meisten Websites bei rund 100 kB liegt — Bibliothek inbegriffen. Selbst über eine Website mit 10.000 Seiten bleibt eine Volltextsuche unter 300 kB. Für Performance heißt das: kein schwerer Vorab-Download, keine Blockade beim ersten Rendern.
// entscheidung
nach projekt · nicht nach trend
Statische Suche ist stark, aber nicht für alles gemacht. Pagefind arbeitet mit dem Index vom letzten Build und macht klassische Volltextsuche mit Tippfehler-Toleranz — es kennt keine Semantik und aktualisiert sich nicht in Echtzeit. Wo das an Grenzen stößt, wechseln wir bewusst auf einen Suchdienst. Zwei Wege, klar getrennt:
Unsere erste Wahl für inhaltsgetriebene Websites: schnell, privat und ohne bewegte Teile im Betrieb.
Wenn ein großer Produktkatalog, facettierte Filter oder Echtzeit-Daten gebraucht werden: Algolia gehostet oder Meilisearch selbst betrieben — als angebundener Dienst.
// faq
Pagefind ist eine Open-Source-Bibliothek für statische Volltextsuche. Sie läuft als CLI nach dem Build einer Website, indexiert das fertig gerenderte HTML und legt den Suchindex als statische Dateien neben die Seite. Die Suche selbst läuft komplett im Browser, ohne Suchserver und ohne externen Dienst. siteway nutzt Pagefind als Standard für statische und kleinere bis mittlere Websites.
Der Index entsteht einmalig beim Build, nicht zur Laufzeit. Pagefind zerlegt ihn in viele kleine Chunks und lädt beim Suchen nur die Teile, die die Anfrage wirklich braucht. Die Suchlogik ist als WebAssembly im Browser eingebaut. Es gibt keine Datenbank und keinen laufenden Dienst — die Suche ist Teil der ausgelieferten Dateien.
Nein. Pagefind kommt ohne Suchserver, ohne Datenbank und ohne Abo aus. Der Index liegt als statische Dateien beim Rest der Website, jede Anfrage wird lokal im Browser beantwortet. Dadurch verlassen Suchbegriffe das Gerät des Nutzers nicht, es entstehen keine laufenden Kosten und es gibt keinen Dienst, der ausfallen kann. Das passt zu trackingfreien Seiten mit strenger Content-Security-Policy.
Weil nur die benötigten Chunks geladen werden, bleibt die Netzlast klein: Bei den meisten Seiten liegt sie bei rund 100 kB inklusive der Pagefind-Bibliothek. Selbst eine Volltextsuche über eine Website mit 10.000 Seiten kommt mit unter 300 kB Gesamtlast aus. Die erste Eingabe holt die Bibliothek, danach werden nur passende Index-Chunks nachgeladen.
Ja. Pagefind erkennt die Sprache je Seite über das lang-Attribut und baut pro Sprache einen eigenen Index. Ein Besucher im deutschen Teil durchsucht deutsche Inhalte, ein Besucher im englischen Teil englische — ohne dass beide Indizes gleichzeitig geladen werden. Für Websites mit vielen Sprachen ist das ein praktischer Vorteil.
Pagefind ist die erste Wahl für statische und inhaltsgetriebene Websites: Blogs, Magazine, Unternehmensseiten, Dokumentation. Wo ein großer Produktkatalog mit vielen Facetten, Echtzeit-Aktualisierung ohne neuen Build oder KI-gestütztem Ranking gebraucht wird, setzt siteway stattdessen Algolia oder das selbst hostbare Meilisearch ein — dann läuft ein echter Suchdienst, den wir anbinden.
// womit das zusammenhängt
leistung & stack
// suche · im detail
Die Suchtechnik im Detail: Index beim Build, WebAssembly im Browser — ohne Suchserver und ohne Tracking.
weiterlesen →
// leistung · buchbar
Die fertige Suchfunktion für deine Website — mit Instant-Ergebnissen, Filtern und der passenden Technik nach Größe. Einzeln buchbar.
zur leistung →
// stack · performance
Warum die kleine Netzlast der statischen Suche zu unserem Anspruch bei Core Web Vitals passt.
weiterlesen →
// stack · security
Trackingfrei und mit strenger CSP — die Suche ohne externen Dienst braucht keine Ausnahme in der Policy.
weiterlesen →
// Suche für deine Website?
Projekt anfragen