PnP Search Filter in SharePoint bauen: Verfeinerer, Managed Properties und KQL

Wie baut man einen PnP Search Filter in SharePoint, der tatsächlich die richtigen Werte anzeigt und beim Anklicken verlässlich filtert?

Die kurze Antwort: Ein funktionierender Filter beginnt im SharePoint-Suchschema. Die betreffende Spalte muss im Suchindex vorhanden, einer refinierbaren Managed Property zugeordnet und im PnP Search Filters Webpart mit dem richtigen Search Results Webpart verbunden sein. Die KQL-Abfrage grenzt anschließend nur den grundsätzlichen Suchbereich ein. Die auswählbaren Facetten sollten dagegen über Refiners und nicht über eine immer komplexere Abfrage aufgebaut werden.

Fehlt eine dieser Ebenen, bleibt der Filter leer, zeigt unvollständige Werte oder liefert nach der Auswahl plötzlich keine Treffer mehr. Dieser Ratgeber zeigt, wie die einzelnen Komponenten zusammenspielen und wie sich Fehler systematisch eingrenzen lassen.

Was PnP Search Filter leisten und wo sie häufig falsch eingesetzt werden

Das PnP Search Filters Webpart ist kein eigenständiger Suchindex und durchsucht SharePoint nicht selbst. Es erhält mögliche Filterwerte vom verbundenen Search Results Webpart, stellt diese als Facetten dar und gibt die Auswahl wieder an die Ergebnisabfrage zurück.

Der typische Datenfluss sieht so aus:

1. Das Search Results Webpart sendet eine Abfrage an die konfigurierte Suchquelle.
2. Die Suchquelle liefert Treffer und verfügbare Refiner-Werte zurück.
3. Das Filters Webpart stellt diese Werte beispielsweise als Kontrollkästchen, Auswahlliste, Datumsbereich oder Taxonomiebaum dar.
4. Der Benutzer wählt einen Wert aus.
5. Die Auswahl wird als zusätzliche Filterbedingung an das Results Webpart übergeben.
6. Treffer, Filterwerte und Trefferzahlen werden neu berechnet.

Ein Refiner ist damit keine frei definierte Liste von Suchbegriffen. Seine Werte stammen normalerweise aus den Metadaten der aktuell gefundenen und für den Benutzer sichtbaren Inhalte.

Refiner und statische Filter unterscheiden

PnP Modern Search unterscheidet grundsätzlich zwischen dynamischen Refinern und statischen Filtern:

• Refiner: Die Werte werden aus der Suchquelle und dem aktuellen Ergebnisbestand geladen. Gibt es keine Treffer, gibt es normalerweise auch keine Refiner-Werte.
• Statischer Filter: Die auswählbaren Werte werden unabhängig von den aktuellen Suchergebnissen vorgegeben. Ein typisches Beispiel ist ein fest definierter Datumsbereich.

Für Spalten wie Abteilung, Dokumentart, Standort, Fachbereich oder Status ist meist ein Refiner sinnvoll. Statische Filter eignen sich eher für bewusst vorgegebene Bereiche, die nicht direkt aus dem Index abgeleitet werden sollen.

Wann Filter falsch eingesetzt werden

Probleme entstehen häufig, wenn eine grundlegende Suchabgrenzung als Benutzerfilter modelliert wird. Soll eine Suchseite beispielsweise ausschließlich Dokumente aus einem bestimmten Bereich anzeigen, gehört diese Einschränkung normalerweise in die Basisabfrage des Results Webparts. Sie sollte nicht als abwählbare Facette erscheinen.

Eine praktikable Aufteilung ist:

• KQL-Basisabfrage: definiert den festen Suchraum, etwa Site, Pfad, Inhaltstyp oder Dokumentklasse.
• Suchtext: enthält die Eingabe des Benutzers.
• Refiner: ermöglichen die interaktive Eingrenzung innerhalb des bereits definierten Suchraums.

Dadurch bleibt nachvollziehbar, welche Einschränkungen immer gelten und welche der Benutzer selbst verändern kann.

Crawled Properties, Managed Properties und refinierbare Felder

Bevor ein Filter konfiguriert wird, muss klar sein, wie SharePoint Metadaten in den Suchindex übernimmt. Die vorbereitenden Schritte für Spalten, Crawled Properties und refinierbare Managed Properties sind im Beitrag Managed Properties für Filter nutzen ausführlicher beschrieben. Für den Filteraufbau sind drei Begriffe entscheidend.

Crawled Property

Eine Crawled Property ist ein beim Crawlen erkanntes Rohsignal. Bei SharePoint-Spalten kann sie beispielsweise aus dem internen Namen einer Site Column entstehen. Häufig sieht ein solcher Name ähnlich wie ows_Dokumentart aus. Bei Managed-Metadata-Spalten können zusätzliche Eigenschaften mit Präfixen wie ows_taxId_ auftreten.

Der konkrete Name sollte immer im Suchschema geprüft werden. Er darf nicht allein aus dem sichtbaren Spaltennamen abgeleitet werden, da Umbenennungen und unterschiedliche Spaltentypen zu abweichenden internen Namen führen können.

Managed Property

Eine Managed Property ist die im Suchindex nutzbare Eigenschaft. Erst über sie kann eine Eigenschaft zuverlässig in einer KQL-Bedingung, einem Ergebnis-Template, einer Sortierung oder einem Refiner verwendet werden.

Die Crawled Property liefert also den Wert. Die Managed Property bestimmt, wie dieser Wert in der Suche eingesetzt werden kann.

Refinierbare Managed Property

Damit eine Eigenschaft als Facette verwendet werden kann, muss die Managed Property refinierbar sein. In SharePoint Online können keine beliebigen neuen refinierbaren Eigenschaften erstellt werden. Stattdessen werden freie, von Microsoft bereitgestellte Eigenschaften wiederverwendet, beispielsweise:

• RefinableString00 bis RefinableString219 für Textwerte
• RefinableInt00 bis RefinableInt49 für Ganzzahlen
• RefinableDate00 bis RefinableDate19 für Datumswerte
• RefinableDecimal00 bis RefinableDecimal09 für Dezimalwerte

Welche Eigenschaft verwendet wird, sollte in einer zentralen Zuordnungsliste dokumentiert werden. Ohne diese Dokumentation wird später möglicherweise dieselbe RefinableStringXX-Eigenschaft für mehrere fachlich unterschiedliche Felder eingesetzt.

Beispiel für eine saubere Zuordnung

Die tatsächlichen Crawled Properties können von diesen Beispielen abweichen und müssen im jeweiligen Tenant geprüft werden.

Managed Property einrichten

1. Erstellen Sie die benötigte Site Column und verwenden Sie sie mindestens in einer Liste oder Bibliothek.
2. Füllen Sie die Spalte testweise bei mehreren Elementen mit unterschiedlichen Werten.
3. Warten Sie, bis SharePoint die Eigenschaft gecrawlt hat, oder fordern Sie eine Neuindizierung an.
4. Öffnen Sie das Suchschema auf Tenant- oder Websitesammlungs-Ebene.
5. Suchen Sie die passende Crawled Property.
6. Wählen Sie eine noch nicht belegte RefinableStringXX-, RefinableDateXX– oder vergleichbare Standard-Property.
7. Ordnen Sie die Crawled Property dieser Managed Property zu.
8. Vergeben Sie optional einen verständlichen Alias.
9. Fordern Sie für die betroffene Liste, Bibliothek oder Website eine erneute Indizierung an.

Die letzte Neuindizierung ist entscheidend. Eine Änderung am Suchschema führt nicht automatisch dazu, dass bereits vorhandene Elemente sofort mit der neuen Zuordnung erneut verarbeitet werden.

Filter-Webpart konfigurieren und mit Search Results verbinden

Ein korrektes Suchschema allein reicht nicht aus. Das PnP Search Filters Webpart und das PnP Search Results Webpart müssen miteinander verbunden werden. Die Grundkonfiguration der Suchseite mit Search Box und Results sollte bereits funktionieren; die dafür nötigen Schritte stehen im Beitrag PnP Such-Webpart konfigurieren.

Voraussetzungen

• PnP Modern Search ist im App Catalog bereitgestellt und auf der Website verfügbar.
• Auf der Seite befindet sich ein PnP Search Results Webpart.
• Die Suchquelle des Results Webparts liefert bereits Treffer.
• Die benötigte Managed Property enthält für diese Treffer Werte.
• Die Property ist refinierbar und wurde nach dem Mapping neu indexiert.

1. Search Results vorbereiten

Konfigurieren Sie zuerst das Results Webpart. Verwenden Sie zunächst eine einfache Basisabfrage, damit Fehler in der KQL-Konfiguration nicht mit Fehlern im Filter verwechselt werden.

Eine feste Eingrenzung auf Dokumente innerhalb einer bestimmten Website kann beispielsweise so aussehen:

Path:"https://tenant.sharepoint.com/sites/wissen" AND IsDocument:1

Prüfen Sie anschließend, ob die erwarteten Inhalte angezeigt werden. Erst wenn die Grundabfrage funktioniert, sollte das Filter-Webpart ergänzt werden.

2. Search Filters hinzufügen

Fügen Sie das PnP Search Filters Webpart auf derselben modernen SharePoint-Seite ein. Öffnen Sie dessen Eigenschaften und wählen Sie das Results Webpart als verbundene Ergebnisquelle aus.

3. Verbindung in beide Richtungen herstellen

Die Verbindung muss beidseitig eingerichtet sein:

• Das Filters Webpart bezieht seine Filterwerte aus dem Search Results Webpart.
• Das Search Results Webpart nimmt die ausgewählten Werte des Filters Webparts entgegen.

Ist nur eine Richtung konfiguriert, kann der Filter leer bleiben oder eine Auswahl anzeigen, ohne dass sich die Trefferliste verändert.

4. Filterzeile konfigurieren

Für einen Filter auf die Dokumentart könnte die Konfiguration beispielsweise so aussehen:

Einstellung	Beispiel
Anzeigename	Dokumentart
Filterfeld	RefinableString20
Darstellung	Kontrollkästchen
Mehrfachauswahl	Aktiviert
Operator zwischen Werten	OR
Werte sortieren nach	Name
Anzahl anzeigen	Aktiviert

Für die technische Konfiguration ist der reale Name der Managed Property meist eindeutiger als ein frei gewählter Anzeigename. Wird ein Alias verwendet, sollten Alias und ursprüngliche Managed Property gemeinsam dokumentiert werden.

AND oder OR richtig einsetzen

Die Operatoren sollten der erwarteten Benutzerlogik entsprechen:

• OR innerhalb eines Filters: Dokumentart ist „Vertrag“ oder „Richtlinie“.
• AND innerhalb eines Filters: Ein Element müsste mehrere ausgewählte Werte gleichzeitig besitzen. Das ist vor allem bei mehrwertigen Spalten sinnvoll.
• AND zwischen verschiedenen Filtern: Dokumentart ist „Vertrag“ und Fachbereich ist „Einkauf“.
• OR zwischen verschiedenen Filtern: Dokumentart ist „Vertrag“ oder Fachbereich ist „Einkauf“. Diese Einstellung führt häufig zu unerwartet breiten Ergebnissen.

Für klassische Facettennavigation ist meist OR zwischen mehreren Werten derselben Facette und AND zwischen unterschiedlichen Facetten nachvollziehbar.

Geeignete Darstellungen auswählen

• Kontrollkästchen: für wenige, verständliche Kategorien.
• Combo-Auswahl: für längere Wertelisten, in denen Benutzer direkt suchen sollen.
• Datumsbereich: für Von-bis-Eingrenzungen.
• Datumsintervalle: für feste Zeiträume wie heute, letzte Woche oder letztes Jahr.
• Personenansicht: für Autoren oder verantwortliche Personen.
• Hierarchischer Refiner: für Taxonomien mit Eltern- und Unterbegriffen.

Ein hierarchischer Filter sollte nur für tatsächlich hierarchisch gepflegte Taxonomiewerte verwendet werden. Eine flache Auswahl mit vielen unabhängigen Begriffen wird durch eine Baumdarstellung nicht automatisch übersichtlicher.

KQL sauber eingrenzen statt überladen

KQL, die Keyword Query Language, sollte im Results Webpart die stabile Grundmenge der Suche definieren. Sie ist nicht der richtige Ort, um jede mögliche Benutzerauswahl dauerhaft abzubilden.

Eigenschaftsabfragen korrekt schreiben

Eine Property-Einschränkung folgt grundsätzlich diesem Muster:

ManagedProperty:Wert

Zwischen Eigenschaft, Operator und Wert darf kein Leerzeichen stehen. Werte mit Leerzeichen werden in Anführungszeichen gesetzt:

Author:"Max Mustermann"

Mehrere Bedingungen werden mit großgeschriebenen Operatoren kombiniert:

Path:"https://tenant.sharepoint.com/sites/wissen"
AND IsDocument:1
AND ContentTypeId:0x0101*

Was in die Basisabfrage gehört

Geeignete feste Einschränkungen sind beispielsweise:

• ein definierter Website- oder Bibliothekspfad,
• Dokumente statt Websites oder Listenelemente,
• ein bestimmter Inhaltstyp,
• eine feste organisatorische Suchquelle,
• technische Ausschlüsse, die Benutzer nicht verändern sollen.

Was nicht dauerhaft in die Basisabfrage gehört

Interaktive Kategorien wie Fachbereich, Dokumentart, Sprache oder Status sollten nicht gleichzeitig als fest codierte KQL-Bedingung und als auswählbarer Refiner vorkommen. Andernfalls kann eine Filterauswahl der Basisabfrage widersprechen.

Ein problematisches Beispiel wäre:

RefinableString20:"Vertrag"

Wird dieselbe Property als Filter „Dokumentart“ angeboten, können Benutzer zwar „Richtlinie“ auswählen, die feste KQL-Bedingung lässt aber weiterhin nur Verträge zu. Das Ergebnis ist eine leere Trefferliste, obwohl der Filter technisch korrekt arbeitet.

KQL schrittweise testen

Bauen Sie komplexere Abfragen schrittweise auf:

1. Nur Suchtext oder Platzhalter testen.
2. Pfadbedingung ergänzen.
3. Dokument- oder Inhaltstyp ergänzen.
4. Jede weitere Property-Bedingung einzeln hinzufügen.
5. Erst danach Refiner aktivieren.

So lässt sich erkennen, welche Bedingung die Treffermenge unerwartet reduziert.

Typische Fehlerbilder bei leeren oder falschen Facetten

Der Filter zeigt überhaupt keine Werte

Prüfen Sie in dieser Reihenfolge:

1. Liefert das Search Results Webpart Treffer?
2. Ist das Filters Webpart mit dem richtigen Results Webpart verbunden?
3. Ist auch im Results Webpart die Verbindung zum Filters Webpart aktiviert?
4. Ist im Filterfeld der korrekte Managed-Property-Name eingetragen?
5. Ist die Managed Property refinierbar?
6. Ist die richtige Crawled Property gemappt?
7. Wurde die Liste oder Bibliothek nach dem Mapping neu indexiert?
8. Besitzen die gefundenen Elemente tatsächlich Werte in der betreffenden Spalte?

Die Property funktioniert in KQL, aber nicht als Refiner

Eine Property kann abfragbar sein, ohne refinierbar zu sein. Eine selbst erstellte Managed Property vom Typ Text reicht deshalb nicht automatisch als Filterfeld aus. Für einen Refiner muss eine geeignete RefinableStringXX– oder vergleichbare Standard-Property verwendet werden.

Nach der Filterauswahl gibt es null Treffer

Häufige Ursachen sind:

• Die statische KQL-Abfrage widerspricht der ausgewählten Facette.
• Das Filter-Webpart verwendet eine andere Property als die Ergebnisabfrage.
• Ein AND-Operator wurde verwendet, obwohl OR erwartet wurde.
• Der sichtbare Text entspricht nicht dem tatsächlich indexierten Wert.
• Taxonomiewerte werden als Token oder GUID statt als einfacher Text verarbeitet.
• Der Benutzer besitzt keinen Zugriff auf die Inhalte mit dem ausgewählten Wert.

Der Filter zeigt alte oder unerwartete Werte

Kontrollieren Sie, ob mehrere Crawled Properties auf dieselbe Managed Property gemappt wurden. Je nach Mapping-Einstellung können Werte aus mehreren Quellen zusammengeführt oder nach einer definierten Reihenfolge übernommen werden.

Auch bereits indexierte Altwerte können eine Rolle spielen. Nach Änderungen an Spalten, Zuordnungen oder Metadaten sollte eine Neuindizierung angefordert und anschließend mit mehreren Testelementen geprüft werden.

Ein mehrwertiges Feld wird wie ein einzelner Text behandelt

Mehrwertige SharePoint-Spalten müssen als einzelne Werte im Suchindex ankommen. Werden alle Werte als eine zusammenhängende Zeichenfolge indexiert, entstehen Facetten wie „Einkauf;Recht;Finanzen“ statt drei unabhängiger Einträge.

Prüfen Sie in diesem Fall den Spaltentyp, die verwendete Crawled Property und das Mapping. Bei Managed Metadata sollte außerdem die für Taxonomiewerte vorgesehene Eigenschaft verwendet werden.

Taxonomiefilter zeigen GUIDs oder technische Präfixe

Managed-Metadata-Werte können im Index neben der Bezeichnung technische Taxonomieinformationen enthalten. Werden diese Werte mit einer einfachen Textdarstellung ausgegeben, erscheinen möglicherweise IDs oder Token.

Prüfen Sie:

• ob die korrekte Taxonomie-Crawled-Property gemappt wurde,
• ob die Lokalisierungsoption der SharePoint-Suchquelle aktiviert ist,
• ob der hierarchische Refiner dem richtigen Term Set zugeordnet ist,
• ob die Begriffe in den benötigten Sprachen gepflegt sind.

Es fehlen Werte am Ende der Filterliste

PnP Modern Search begrenzt die Anzahl geladener Refiner-Werte. Standardmäßig werden bei umfangreichen Refinern nicht zwingend alle möglichen Werte dargestellt. In der Filterkonfiguration kann die maximale Anzahl erhöht werden; der zulässige Höchstwert liegt bei 1.000.

Das Erhöhen des Limits löst jedoch nicht jedes Problem. Ein Feld mit mehreren hundert oder tausend unterschiedlichen Werten ist meist kein guter Refiner. Für eindeutige IDs, Vorgangsnummern oder Dateinamen ist eine Texteingabe oft geeigneter als eine lange Facettenliste.

Filterzahlen unterscheiden sich zwischen Benutzern

SharePoint Search berücksichtigt Berechtigungen. Benutzer sehen nur Treffer, auf die sie Zugriff haben. Dadurch können auch die verfügbaren Filterwerte und Trefferzahlen unterschiedlich ausfallen.

Testen Sie die Suche deshalb nicht ausschließlich mit einem Administratorkonto. Verwenden Sie zusätzlich mindestens ein reguläres Benutzerkonto mit realistischen Leseberechtigungen.

Filter systematisch testen und zurücksetzen

Direkttest der Managed Property

Prüfen Sie zuerst, ob die Managed Property grundsätzlich Werte liefert:

RefinableString20:"Vertrag"

Werden die erwarteten Inhalte gefunden, ist Mapping und Indexierung wahrscheinlich funktionsfähig. Bleiben die Ergebnisse leer, liegt das Problem noch vor dem Filter-Webpart.

Testmatrix verwenden

Test	Erwartetes Ergebnis
Basisabfrage ohne Filter	Alle Inhalte des vorgesehenen Suchraums werden gefunden.
Direkte KQL-Abfrage auf Managed Property	Nur Inhalte mit dem angegebenen Wert erscheinen.
Ein einzelner Refiner-Wert	Trefferliste und Zähler werden konsistent aktualisiert.
Mehrere Werte derselben Facette	OR- oder AND-Verhalten entspricht der Konfiguration.
Zwei unterschiedliche Facetten	Die Ergebnismenge wird logisch weiter eingegrenzt.
Benutzer mit eingeschränkten Rechten	Nur berechtigte Inhalte und dazugehörige Facetten erscheinen.
Zurücksetzen aller Filter	Die ursprüngliche Treffermenge wird wiederhergestellt.

Browser-Konsole kontrollieren

Bei abgeschnittenen Refiner-Listen oder unerwartetem Verhalten lohnt sich ein Blick in die Entwicklerwerkzeuge des Browsers. PnP Modern Search kann dort Hinweise ausgeben, wenn ein konfiguriertes Refiner-Limit erreicht wurde.

Fehlerhafte Verbindungen, nicht verfügbare Properties oder Probleme mit einer benutzerdefinierten Vorlage lassen sich dort ebenfalls häufig schneller erkennen als allein über die sichtbare Oberfläche.

Rückfallweg bei einer fehlerhaften Konfiguration

Wenn eine neue Facette die Suchseite unbrauchbar macht, entfernen oder deaktivieren Sie zunächst nur die betreffende Filterzeile. Die funktionierende Basisabfrage und die übrigen Filter bleiben dadurch erhalten.

Bei einem falschen Suchschema-Mapping sollte die dokumentierte vorherige Zuordnung wiederhergestellt und die betroffene Quelle erneut indexiert werden. Vermeiden Sie es, eine bereits anderweitig verwendete RefinableStringXX-Property spontan umzuwidmen. Das kann andere Suchseiten, Sortierungen oder Ergebnisvorlagen beeinflussen.

Technikblock: Suchschema, Performance und Pflege

Tenant-weites oder lokales Suchschema

Eine Zuordnung auf Tenant-Ebene eignet sich für Metadaten, die organisationsweit dieselbe Bedeutung besitzen. Eine Zuordnung auf Ebene einer Websitesammlung gilt dagegen nur im jeweiligen Bereich.

Für wiederverwendete Filter wie Dokumentart, Organisationseinheit oder Sprache ist eine zentral abgestimmte Tenant-Zuordnung meist leichter wartbar. Lokale Eigenschaften sind sinnvoll, wenn die Metadaten ausschließlich in einem klar abgegrenzten Bereich verwendet werden.

Hohe Kardinalität vermeiden

Ein guter Refiner besitzt eine begrenzte und für Benutzer verständliche Menge wiederkehrender Werte. Ungeeignet sind häufig:

• eindeutige Vorgangsnummern,
• vollständige Dateinamen,
• freie Texteingaben,
• individuelle Zeitstempel,
• technische IDs.

Solche Eigenschaften erzeugen lange Listen, geringe Wiederverwendung und unnötige Abfragen. Sie sollten eher über Suchtext oder gezielte KQL-Eingaben gefunden werden.

Basisabfragen kurz halten

Eine KQL-Abfrage sollte keine über Jahre gewachsene Sammlung aus zahlreichen OR-Blöcken und Einzelausnahmen werden. Lange Abfragen sind schwer testbar und können technische Längenbegrenzungen erreichen.

Wenn dieselbe komplexe Logik auf mehreren Suchseiten benötigt wird, sollte geprüft werden, ob die Inhalte durch konsistente Metadaten, Inhaltstypen, Pfade oder getrennte Suchvertikale sauberer strukturiert werden können.

Managed-Property-Register führen

Dokumentieren Sie mindestens:

• fachliche Bedeutung,
• physische Managed Property,
• Alias,
• Datentyp,
• gemappte Crawled Property,
• Gültigkeitsbereich des Suchschemas,
• verwendende Suchseiten und Webparts,
• Datum der letzten Änderung.

Dieses Register verhindert Doppelbelegungen und macht spätere Fehleranalysen deutlich schneller.

Änderungen kontrolliert ausrollen

Testen Sie neue Filter zunächst auf einer separaten Suchseite oder einer nicht prominent verlinkten Entwurfsseite. Prüfen Sie dort unterschiedliche Metadatenwerte, Benutzerberechtigungen, Mehrfachauswahl und leere Felder.

Erst nach erfolgreicher Prüfung sollte die Konfiguration auf produktive Suchseiten übertragen werden. Bei mehreren Seiten empfiehlt es sich, Konfiguration und Property-Zuordnungen versionskontrolliert zu dokumentieren.

Praxisbeispiel: Filter für eine SharePoint-Wissensdatenbank

Ein typisches Szenario ist eine Wissensdatenbank, in der Richtlinien, Vorlagen, Anleitungen und Projektunterlagen gemeinsam gefunden werden sollen. Die Suche soll Volltexttreffer liefern und Nutzern helfen, aus einer größeren Ergebnismenge schnell den passenden Dokumenttyp, Fachbereich oder Gültigkeitszeitraum herauszufiltern.

Für diesen Fall ist eine klare Trennung der Suchlogik hilfreich: Die Basisabfrage begrenzt die Ergebnisse auf die Wissensdatenbank, während Refiners die fachliche Navigation übernehmen. Eine sinnvolle Ausgangsstruktur kann so aussehen:

Wenn die Wissensdatenbank zusätzlich als Self-Service-Bereich aufgebaut wird, passt der Filteraufbau gut zu einer SharePoint-Wissensdatenbank mit PnP Search. Die Filter sollten dabei nicht isoliert geplant werden, sondern zusammen mit Inhaltstypen, Pflichtmetadaten und redaktioneller Pflege.

Checkliste vor dem produktiven Einsatz

• Jede Filtereigenschaft ist fachlich dokumentiert und genau einer Managed Property zugeordnet.
• Die Basisabfrage enthält nur Einschränkungen, die Benutzer nicht verändern sollen.
• Mehrfachauswahl, leere Werte und unterschiedliche Benutzerrechte wurden getestet.
• Der Filter bleibt auch bei vielen Dokumenten verständlich und zeigt keine technischen IDs.
• Für Änderungen an Managed Properties gibt es einen Rückfallweg.

Diese Prüfung wirkt unspektakulär, verhindert aber viele spätere Suchprobleme. Besonders bei mehreren Suchseiten ist ein gemeinsames Property-Register wichtiger als eine schnelle Einzelkonfiguration im Webpart.

So bleiben Filter logisch, schnell und pflegbar

Ein stabiler PnP Search Filter besteht aus einer klaren Kette: Die SharePoint-Spalte liefert Metadaten, die Crawled Property übernimmt diese beim Crawlen, eine refinierbare Managed Property stellt sie im Index bereit und das Search Filters Webpart verwendet sie als Facette für das verbundene Results Webpart.

Die wichtigste Regel lautet: KQL definiert den festen Suchraum, Refiners übernehmen die interaktive Eingrenzung. Werden beide Aufgaben vermischt, entstehen widersprüchliche Bedingungen und schwer nachvollziehbare Nulltreffer.

Beginnen Sie deshalb mit einer einfachen Ergebnisabfrage, testen Sie die Managed Property direkt, stellen Sie anschließend die beidseitige Webpart-Verbindung her und ergänzen Sie Filter einzeln. So lässt sich jede Ebene getrennt prüfen und bei Problemen gezielt zurücksetzen.