PnP Such-Webpart in SharePoint konfigurieren: Search Box, Results und Suchseite sauber verbinden

Wie lässt sich das PnP Such-Webpart konfigurieren, damit Suchbox, Ergebnisseite und URL-Parameter zuverlässig zusammenspielen? Für eine funktionierende Suchseite müssen vor allem drei Dinge stimmen: Das richtige PnP-Webpart-Paket muss bereitgestellt sein, die Search Results müssen ihren Suchtext aus der Search Box erhalten und das Query Template muss diesen Suchtext tatsächlich an die SharePoint-Suche übergeben.

Die häufigsten Fehler entstehen nicht im Ergebnis-Layout, sondern im Datenfluss zwischen den Webparts. Eine Suchbox kann sichtbar funktionieren, ohne dass der eingegebene Begriff die Ergebnisliste erreicht. Ebenso kann ein Results-Webpart korrekt eingerichtet sein, aber aufgrund einer zu engen Abfrage, fehlender Berechtigungen oder einer nicht verbundenen URL-Variable keine Treffer anzeigen.

Dieser Ratgeber zeigt, wie Sie das PnP Such-Webpart konfigurieren, eine Suchseite schrittweise aufbauen und die Konfiguration anschließend mit unterschiedlichen Benutzerkonten testen.

Wann Sie ein PnP Such-Webpart konfigurieren sollten

Die SharePoint-Standardsuche eignet sich für viele allgemeine Suchszenarien. Ein eigenes Suchsetup mit PnP Modern Search wird vor allem dann interessant, wenn die Ergebnisse auf einer modernen SharePoint-Seite gezielt gesteuert und dargestellt werden sollen.

Typische Anwendungsfälle sind:

• eine eigene Suchseite für ein Intranet oder Wissensportal,
• eine Suche, die nur bestimmte Sites, Bibliotheken oder Inhaltstypen berücksichtigt,
• eine Ergebnisdarstellung mit zusätzlichen Metadaten,
• Filter nach Dokumenttyp, Organisationseinheit oder Kategorie,
• getrennte Suchbereiche über sogenannte Verticals,
• eine Suchbox auf der Startseite, die auf eine zentrale Ergebnisseite weiterleitet.

PnP Modern Search ersetzt dabei nicht den SharePoint-Suchindex. Das Results-Webpart sendet eine Abfrage an die ausgewählte Datenquelle und bereitet die zurückgegebenen Treffer für die Darstellung auf. Welche Inhalte gefunden werden, hängt weiterhin von Suchindex, Suchschema, Abfrage und Benutzerberechtigungen ab.

Search Results oder Search Rollup?

Im Webpart-Katalog können je nach installierter Version sowohl PnP – Search Results als auch PnP – Search Rollup erscheinen. Für eine interaktive Suchseite mit Search Box, Filtern oder Verticals muss Search Results verwendet werden.

Search Rollup ist für eigenständige Inhaltsabfragen gedacht, beispielsweise für die neuesten Dokumente oder Nachrichten. Diese Variante wird für eine bessere Ladeleistung verzögert geladen, kann dafür aber nicht dynamisch mit einer Search Box oder einem Filter-Webpart verbunden werden.

Voraussetzungen für die Suchseite

Bevor die eigentliche Seite aufgebaut wird, sollten Paket, Berechtigungen und Zielarchitektur geprüft werden. Dadurch lässt sich vermeiden, dass die Konfiguration später an fehlenden Webparts oder nicht freigegebenen Funktionen scheitert.

Technische Voraussetzungen

• eine moderne SharePoint-Online-Site,
• eine moderne SharePoint-Seite für die Suchoberfläche,
• ein globaler Tenant App Catalog oder ein Site Collection App Catalog,
• das SPFx-Paket pnp-modern-search-parts-v4.sppkg,
• Bearbeitungsrechte auf der Zielseite,
• Leserechte der späteren Nutzer auf der Suchseite und den durchsuchten Inhalten.

Das Paket kann zentral für alle Sites bereitgestellt oder gezielt in einzelnen Sites installiert werden. Die App-Catalog-Bereitstellung ist im Beitrag PnP Search Webparts bereitstellen beschrieben; dieser Artikel konzentriert sich auf die Seitenkonfiguration nach der Installation. Für einen kontrollierten Einstieg empfiehlt sich zunächst eine Test-Site. Erst nach einem erfolgreichen Funktionstest sollte die Lösung tenantweit oder in weiteren produktiven Sites eingesetzt werden.

Benötigte Rollen und Berechtigungen

Für die einzelnen Schritte werden unterschiedliche Rechte benötigt:

• SharePoint-Administrator: Bereitstellung des Pakets im globalen App Catalog und gegebenenfalls Freigabe angeforderter API-Berechtigungen.
• Site-Collection-Administrator oder Site Owner: Installation der App in der Site, sofern keine tenantweite Bereitstellung verwendet wird.
• Seitenbearbeiter: Hinzufügen und Konfigurieren der Webparts.
• Endanwender: Leserechte auf der Suchseite und auf den Inhalten, die als Treffer erscheinen sollen.

Die vom Paket angeforderten Microsoft-Graph-Berechtigungen werden nicht für jedes Suchszenario benötigt. Eine reine SharePoint-Suche sollte deshalb zunächst mit den tatsächlich erforderlichen Berechtigungen umgesetzt werden. Zusätzliche Berechtigungen sind erst dann zu genehmigen, wenn Funktionen wie die Suche in Microsoft-Graph-Entitäten, Personeninformationen oder weitere Microsoft-Search-Datenquellen verwendet werden.

Der Datenfluss zwischen Search Box und Search Results

Eine PnP-Suchseite besteht technisch aus mehreren getrennten Komponenten. Die Search Box führt die Suche nicht selbst aus. Sie stellt lediglich den eingegebenen Suchtext bereit. Das Search-Results-Webpart übernimmt diesen Wert und sendet daraus eine Abfrage an die konfigurierte Datenquelle.

Der vereinfachte Datenfluss sieht so aus:

1. Ein Benutzer gibt einen Begriff in die Search Box ein.
2. Die Search Box veröffentlicht den Suchtext als dynamischen Wert.
3. Search Results empfängt diesen Wert über eine Webpart-Verbindung.
4. Der Suchtext wird im Query Template an der Stelle von {searchTerms} eingesetzt.
5. Die SharePoint-Suche verarbeitet die daraus entstandene KQL-Abfrage.
6. Das Webpart formatiert und zeigt die zurückgegebenen Treffer an.

Fehlt einer dieser Schritte, kann die Suchbox zwar sichtbar reagieren, die Ergebnisliste bleibt jedoch unverändert oder leer.

PnP Such-Webpart konfigurieren: Search Box und Results verbinden

Für den ersten Funktionstest sollten Search Box und Search Results auf derselben modernen SharePoint-Seite eingerichtet werden. Damit lassen sich Fehler durch Weiterleitungen und URL-Parameter zunächst ausschließen.

1. Suchseite erstellen

1. Erstellen Sie eine neue moderne SharePoint-Seite.
2. Vergeben Sie einen eindeutigen Namen, beispielsweise Suche.aspx.
3. Fügen Sie im oberen Bereich das Webpart PnP – Search Box ein.
4. Fügen Sie darunter das Webpart PnP – Search Results ein.

Verwenden Sie für diesen Aufbau nicht Search Rollup, da diese Variante keine dynamische Verbindung zur Search Box unterstützt.

2. Datenquelle in Search Results auswählen

Öffnen Sie die Einstellungen des Search-Results-Webparts und wählen Sie als Datenquelle zunächst SharePoint Search. Für einen einfachen Test sind folgende Grundeinstellungen ausreichend:

Einstellung	Empfohlener Startwert
Datenquelle	SharePoint Search
Query Template	{searchTerms}
Result Source	LocalSharePointResults
Treffer pro Seite	10
Layout	Einfaches Standardlayout

Das Query Template {searchTerms} ist für den Basistest entscheidend. Fehlt dieser Token, kann der von der Search Box übergebene Begriff nicht in die Abfrage eingesetzt werden.

3. Eingabesuchtext dynamisch verbinden

1. Öffnen Sie im Search-Results-Webpart den Bereich Connections beziehungsweise Verbindungen.
2. Aktivieren Sie die Verwendung eines Eingabesuchtexts.
3. Wählen Sie einen dynamischen Wert.
4. Wählen Sie als Quelle die Search Box auf derselben Seite.
5. Wählen Sie den von der Search Box bereitgestellten Suchtext als Eigenschaft.
6. Übernehmen Sie die Einstellungen und veröffentlichen Sie die Seite.

Die Bezeichnungen der dynamischen Eigenschaft können sich zwischen Paketversionen geringfügig unterscheiden. Entscheidend ist, dass nicht die Seitenumgebung, sondern die auf der Seite vorhandene Search Box als Quelle ausgewählt wird.

4. Verbindung testen

Öffnen Sie die veröffentlichte Seite in einem neuen Browserfenster und suchen Sie nach einem eindeutigen Begriff, der in einem bekannten Dokumenttitel vorkommt.

Prüfen Sie dabei:

• Wird nach dem Absenden eine neue Abfrage ausgelöst?
• Ändert sich die Ergebnisliste bei einem anderen Suchbegriff?
• Wird das erwartete Dokument gefunden?
• Verschwindet oder aktualisiert sich die Ergebnisliste, wenn das Suchfeld geleert wird?

Erst wenn dieser Aufbau funktioniert, sollte eine Weiterleitung von einer anderen Seite ergänzt werden.

Suchbox auf einer Startseite mit der Ergebnisseite verbinden

In vielen Intranets befindet sich die Search Box auf einer Startseite, während die Ergebnisse auf einer eigenen Suchseite angezeigt werden. In diesem Fall muss der Suchbegriff zwischen beiden Seiten übertragen werden.

Ein Query-String-Parameter ist dafür meist leichter zu testen als ein URL-Fragment. Eine typische Zieladresse sieht so aus:

/sites/intranet/SitePages/Suche.aspx?q=reisekosten

1. Search Box auf der Ausgangsseite konfigurieren

1. Öffnen Sie die Einstellungen der Search Box auf der Startseite.
2. Aktivieren Sie Send the query to a new page.
3. Wählen Sie die zuvor erstellte Suchseite als Ziel.
4. Verwenden Sie als Übertragungsmethode einen Query-String-Parameter.
5. Vergeben Sie als Parameternamen beispielsweise q.
6. Verwenden Sie für die Eingabetransformation {inputQueryText}.

Der Parametername ist frei wählbar. Er muss jedoch auf der Zielseite exakt gleich geschrieben werden. Die Parameter q, query und search sind technisch unterschiedliche Werte.

2. Search Box auf der Zielseite mit dem URL-Parameter verbinden

Die Search Box auf der Ergebnisseite sollte den Wert aus der URL übernehmen. Dadurch bleibt der Suchbegriff nach der Weiterleitung im Eingabefeld sichtbar und kann anschließend verändert werden.

1. Öffnen Sie die Verbindungen der Search Box auf der Ergebnisseite.
2. Aktivieren Sie einen dynamischen Standardwert beziehungsweise Eingabewert.
3. Wählen Sie die Seitenumgebung als Quelle.
4. Wählen Sie den Query-String-Parameter q.
5. Speichern und veröffentlichen Sie die Seite.

Der aus der URL gelesene Wert wird damit in der Search Box angezeigt. Da Search Results bereits mit dieser Search Box verbunden ist, wird der Wert anschließend an die Ergebnisliste weitergegeben.

3. Vollständigen Ablauf testen

Starten Sie den Test nicht direkt auf der Ergebnisseite, sondern auf der ursprünglichen Startseite:

1. Suchbegriff auf der Startseite eingeben.
2. Suche absenden.
3. Zieladresse im Browser prüfen.
4. Kontrollieren, ob ?q=Suchbegriff enthalten ist.
5. Prüfen, ob der Begriff auf der Zielseite im Suchfeld steht.
6. Prüfen, ob passende Ergebnisse geladen werden.
7. Den Begriff auf der Zielseite ändern und erneut suchen.

Damit werden sowohl die Weiterleitung als auch die Verbindung auf der Ergebnisseite geprüft.

Wichtige Einstellungen für Query, Platzhalter und URL

Query Text und Query Template unterscheiden

Der über die Search Box empfangene Wert ist der Query Text. Das Query Template bestimmt, wie dieser Wert in die tatsächliche Suchabfrage eingebaut wird.

Ein einfaches Template lautet:

{searchTerms}

Eine Suche nur innerhalb einer bestimmten Site kann beispielsweise so aufgebaut werden:

{searchTerms} Path:"https://tenant.sharepoint.com/sites/wissen"

Sollen ausschließlich Dokumente angezeigt werden, kann die Abfrage zusätzlich eingeschränkt werden:

{searchTerms} IsDocument:1

Solche Einschränkungen sollten einzeln ergänzt und nach jeder Änderung getestet werden. Eine fehlerhafte Path-Angabe oder eine nicht verfügbare Managed Property kann sonst den Eindruck erwecken, dass die Webpart-Verbindung nicht funktioniert.

Verhalten bei leerem Suchfeld festlegen

Für eine leere Search Box gibt es zwei sinnvolle Varianten:

• Leere Ergebnisliste: Geeignet für eine klassische Suche, bei der erst nach einer Eingabe Inhalte erscheinen sollen.
• Vordefinierte Treffer: Geeignet für eine kombinierte Such- und Übersichtsseite, beispielsweise mit aktuellen Dokumenten.

Ein dynamischer Eingabesuchtext kann im Search-Results-Webpart mit einem Standardwert ergänzt werden. Als Standardabfrage kann je nach gewünschtem Inhalt beispielsweise eine allgemeine KQL-Abfrage oder eine feste Einschränkung verwendet werden.

Das Verhalten beim Leeren des Suchfelds sollte ebenfalls geprüft werden. Ist Reset query on clear aktiviert, wird beim Entfernen des Suchbegriffs eine neue Abfrage ausgelöst.

Platzhalter verständlich formulieren

Der Platzhalter sollte den Suchbereich beschreiben. Beispiele sind:

• Dokumente und Seiten durchsuchen
• In der Wissensdatenbank suchen
• Richtlinien, Vorlagen und Anleitungen suchen

Ein präziser Platzhalter verhindert falsche Erwartungen, wenn die Abfrage absichtlich auf bestimmte Inhalte oder Sites beschränkt wurde.

URL-Parameter konsistent halten

Verwenden Sie für alle Einstiegspunkte denselben Parameternamen. Wenn eine Search Box q sendet, die Ergebnisseite aber query erwartet, wird die Seite zwar geöffnet, der Suchbegriff jedoch nicht übernommen.

Prüfen Sie nach Änderungen außerdem, ob:

• der Pfad der Zielseite noch korrekt ist,
• die Seite verschoben oder umbenannt wurde,
• alte Links noch auf eine frühere Suchseite zeigen,
• mehrere Suchseiten unterschiedliche Parameternamen verwenden.

Typische Fehler und ihre Ursachen

Die Search Box reagiert, aber die Ergebnisse ändern sich nicht

In diesem Fall liegt der Fehler meist in der Verbindung zum Search-Results-Webpart.

Prüfen Sie:

• Wurde PnP – Search Results statt Search Rollup verwendet?
• Ist unter Connections ein dynamischer Eingabesuchtext aktiviert?
• Ist die richtige Search-Box-Instanz ausgewählt?
• Enthält das Query Template den Token {searchTerms}?
• Wurde die Seite nach der Änderung erneut veröffentlicht?

Die Suchseite zeigt keine Treffer

Eine leere Ergebnisliste kann mehrere Ursachen haben:

• Die Abfrage ist durch Path, Inhaltstyp oder Dateityp zu stark eingeschränkt.
• Der gesuchte Inhalt wurde noch nicht in den Suchindex aufgenommen.
• Der angemeldete Benutzer besitzt keine Leserechte auf den Inhalt.
• Es wurde eine falsche Datenquelle oder Result Source ausgewählt.
• Eine verwendete Managed Property ist nicht verfügbar oder nicht durchsuchbar.
• Der Suchbegriff wurde nicht aus der URL oder Search Box übernommen.

Entfernen Sie für die Fehlersuche zunächst alle zusätzlichen Einschränkungen und testen Sie nur mit {searchTerms}. Funktioniert die Basissuche, können die Einschränkungen anschließend einzeln wieder ergänzt werden.

Administratoren sehen Treffer, normale Benutzer aber nicht

Dieses Verhalten ist häufig kein Webpart-Fehler. SharePoint Search berücksichtigt die Zugriffsrechte des angemeldeten Benutzers. Ein Treffer wird nur angezeigt, wenn der Benutzer auf das zugrunde liegende Element zugreifen darf.

Testen Sie deshalb immer mit mindestens zwei Konten:

• einem administrativen oder weitreichend berechtigten Konto,
• einem typischen Benutzerkonto mit den vorgesehenen Standardrechten.

Werden Inhalte nur für das administrative Konto gefunden, sollten Bibliotheks-, Ordner-, Element- und Site-Berechtigungen geprüft werden.

Der Suchbegriff erscheint nicht auf der Zielseite

Prüfen Sie zuerst die Browseradresse. Fehlt der Parameter bereits dort, liegt der Fehler in der Search Box auf der Ausgangsseite. Ist der Parameter vorhanden, wird aber nicht im Suchfeld angezeigt, ist die Verbindung der Ziel-Search-Box mit der Seitenumgebung nicht korrekt.

Häufige Ursachen sind:

• unterschiedliche Parameternamen,
• Verwendung eines URL-Fragments auf der Ausgangsseite und eines Query-String-Parameters auf der Zielseite,
• falsche Zielseite,
• nicht veröffentlichte Änderungen,
• eine Verbindung zu einer anderen Search-Box-Instanz.

Ergebnisse werden doppelt angezeigt

Das SharePoint-Search-Datenquellenmodul bietet eine Einstellung zum Entfernen von Duplikaten. Diese ist standardmäßig nicht zwingend aktiviert. Das Aktivieren von Trim duplicates kann Treffer reduzieren, die von der Suchmaschine als Duplikate erkannt werden.

Nicht jede doppelte Anzeige ist jedoch ein technisches Duplikat. Häufig existieren tatsächlich mehrere Objekte, beispielsweise:

• Kopien desselben Dokuments in mehreren Bibliotheken,
• eine Datei und eine veröffentlichte Seite mit ähnlichem Inhalt,
• unterschiedliche URLs für verschiedene Inhaltsvarianten,
• Migrationen, bei denen das Original und die neue Kopie indexiert wurden.

Prüfen Sie deshalb im Debug-Layout Eigenschaften wie Path, UniqueID, NormUniqueID, SiteTitle und ContentTypeId, bevor Ergebnisse pauschal ausgeblendet werden.

Eigenschaften fehlen im Layout

Eine Managed Property muss als ausgewählte Eigenschaft von der Datenquelle zurückgegeben werden, bevor sie zuverlässig in einem Layout verwendet werden kann. Erscheint die gewünschte Eigenschaft nicht in der Auswahlliste, kann ihr interner Name häufig manuell eingegeben und mit der Eingabetaste bestätigt werden.

Für die Fehlersuche eignet sich zunächst das Debug-Layout. Es zeigt, welche Eigenschaften ein Treffer tatsächlich enthält. Erst danach sollte ein individuelles Ergebnis-Template angepasst werden.

Tests und Rückfallweg vor der Veröffentlichung

Eine Suchseite sollte mit mehreren bekannten Begriffen getestet werden. Verwenden Sie eine kleine Testmatrix mit erwarteten Ergebnissen.

Test: Eindeutiger Dokumenttitel

Erwartetes Verhalten: Das bekannte Dokument erscheint weit oben.

Test: Begriff aus dem Dokumentinhalt

Erwartetes Verhalten: Das Dokument wird gefunden, sofern der Inhalt indexiert ist.

Test: Leeres Suchfeld

Erwartetes Verhalten: Das festgelegte Standardverhalten wird ausgeführt.

Test: Ungültiger Begriff

Erwartetes Verhalten: Eine leere Ergebnisanzeige erscheint ohne Seitenfehler.

Test: Benutzer ohne Zugriff

Erwartetes Verhalten: Geschützte Inhalte erscheinen nicht.

Test: Weiterleitung von der Startseite

Erwartetes Verhalten: URL, Suchfeld und Ergebnisse enthalten denselben Begriff.

Test: Browser-Zurück-Funktion

Erwartetes Verhalten: Die Navigation bleibt nachvollziehbar.

Test: Mobile Ansicht

Erwartetes Verhalten: Suchfeld, Schaltfläche und Ergebnisse bleiben bedienbar.

Rückfallweg vorbereiten

Vor größeren Änderungen sollte die bisherige Suchseite erhalten bleiben. Ein einfacher Rückfallweg besteht darin, eine neue Seite parallel aufzubauen und bestehende Navigationseinträge erst nach Abschluss der Tests umzustellen.

Dokumentieren Sie mindestens:

• installierte Paketversion,
• Name und URL der Suchseite,
• verwendeter URL-Parameter,
• Datenquelle und Result Source,
• Query Template,
• ausgewählte Eigenschaften,
• verbundene Webparts,
• zusätzlich genehmigte API-Berechtigungen.

Schlägt eine Änderung fehl, kann die Navigation wieder auf die bisherige Seite verweisen, ohne dass die gesamte App-Bereitstellung zurückgenommen werden muss.

Wartbarkeit und Rollout in weiteren Sites

Für eine einzelne Suchseite ist eine manuelle Konfiguration ausreichend. Bei mehreren Sites sollten Einstellungen und Verantwortlichkeiten standardisiert werden.

Konfiguration als technische Basis dokumentieren

Legen Sie eine Referenzkonfiguration fest, die mindestens Search Box, Search Results, URL-Parameter, Query Template und benötigte Managed Properties beschreibt. Dadurch lassen sich Abweichungen zwischen Sites schneller erkennen.

Suchbereich nicht unnötig fest verdrahten

Absolute Site-URLs in Query Templates sind leicht verständlich, müssen bei kopierten Seiten jedoch angepasst werden. Prüfen Sie bei jedem Rollout, ob der Suchbereich zentral, sitebezogen oder bibliotheksbezogen sein soll.

Eine zentrale Suchseite benötigt meist eine tenant- oder intranetweite Abfrage. Eine fachbereichsspezifische Seite sollte dagegen über Path, Inhaltstypen oder verwaltete Eigenschaften klar abgegrenzt werden.

Paketupdates kontrolliert durchführen

Neue Paketversionen sollten zunächst in einer Testumgebung beziehungsweise einer begrenzten Test-Site geprüft werden. Relevant sind besonders:

• bestehende Webpart-Verbindungen,
• benutzerdefinierte Handlebars-Templates,
• Extensibility Libraries,
• verwendete Datenquellen,
• neu angeforderte API-Berechtigungen,
• Darstellung auf veröffentlichten Seiten.

Das Löschen des Pakets aus dem App Catalog ist kein geeigneter Rückfallweg für ein fehlgeschlagenes Update, da bestehende Webpart-Instanzen dadurch nicht mehr geladen werden können. Sinnvoller ist ein getesteter Versionswechsel mit dokumentierter vorheriger Paketversion.

Praxisbeispiel: Eine zentrale Suchseite im Intranet

In vielen Intranets soll die Startseite nur ein kompaktes Suchfeld enthalten, während die eigentliche Ergebnisdarstellung auf einer eigenen Seite liegt. Das wirkt für Anwender einfach, erfordert technisch aber einen sauberen Übergang zwischen Search Box, URL-Parameter, Search Results und optionalen Filtern.

Ein robuster Aufbau trennt die Aufgaben deutlich:

Für die spätere Erweiterung lohnt sich ein Blick auf den Zusammenhang zwischen Suchseite und PnP Search Filtern mit Verfeinerern und KQL. Die Suchseite sollte zuerst ohne Filter stabil laufen, bevor Refiners, Verticals und individuelle Templates ergänzt werden.

Qualitätskriterien für Ergebnislayouts

Ein Ergebnislayout muss Nutzern helfen, Treffer schnell zu bewerten. Dafür reichen oft wenige gut gewählte Eigenschaften: Titel, Pfad oder Bereich, Dokumentart, Änderungsdatum und ein kurzer Textauszug.

• Zeigen Sie nur Metadaten, die bei der Auswahl wirklich helfen.
• Vermeiden Sie technische Property-Namen in sichtbaren Labels.
• Prüfen Sie lange Titel und mobile Ansichten vor der Veröffentlichung.
• Nutzen Sie das Debug-Layout nur für die Konfiguration, nicht für produktive Seiten.
• Dokumentieren Sie benutzerdefinierte Templates, damit Updates später nachvollziehbar bleiben.

Damit verbessert die Suchseite die Trefferquote und die Orientierung im Ergebnisbestand. Das ist ein wichtiger Faktor, wenn Nutzer regelmäßig mit der Suche arbeiten und nach wenigen erfolglosen Versuchen nicht wieder auf Ordnernavigation oder persönliche Linksammlungen ausweichen sollen.

So bleibt die Suchseite auch nach der ersten Konfiguration stabil

Eine stabile PnP-Suchseite beginnt mit einem möglichst einfachen Aufbau: Search Box und Search Results auf derselben Seite, eine SharePoint-Search-Datenquelle und das unveränderte Query Template {searchTerms}. Erst wenn dieser Datenfluss funktioniert, sollten Weiterleitungen, URL-Parameter, Filter, Verticals und individuelle Layouts ergänzt werden.

Für den laufenden Betrieb sind vor allem vier Punkte entscheidend: konsistente Parameternamen, dokumentierte Query Templates, Tests mit realistischen Benutzerberechtigungen und ein kontrollierter Prozess für Paketupdates. Damit lässt sich bei Fehlern schnell unterscheiden, ob die Ursache in der Webpart-Verbindung, der Abfrage, dem Suchindex oder den Zugriffsrechten liegt.