SharePoint-Spalten durchsuchbar machen: Crawled Properties, Managed Properties und Refiners

Wie lassen sich SharePoint-Spalten durchsuchbar machen, wenn sie in Suche, Filter oder Sortierung fehlen? Meist liegt das nicht an der Liste oder am Such-Webpart, sondern am SharePoint-Suchschema. Ein Feld muss zunächst vom Suchdienst erfasst, als Crawled Property erkannt und anschließend einer passenden Managed Property zugeordnet werden.

Erst die Managed Property entscheidet, ob ein Feld gezielt abgefragt, in Suchergebnissen ausgegeben, als Refiner verwendet oder für die Sortierung genutzt werden kann. Nach Änderungen am Suchschema müssen die betroffenen Inhalte erneut indexiert werden.

SharePoint-Spalten durchsuchbar machen: warum der Index entscheidet

SharePoint-Suche arbeitet nicht direkt auf den aktuellen Daten einer Liste oder Dokumentbibliothek. Eine Suchanfrage liest stattdessen aus einem separaten Suchindex. Dieser Index wird durch einen Hintergrundprozess aufgebaut, der Inhalte und Metadaten aus SharePoint erfasst.

Der vereinfachte Datenfluss sieht so aus:

1. Ein Benutzer speichert ein Listenelement oder ein Dokument mit Metadaten.
2. Der SharePoint-Crawler erkennt den neuen oder geänderten Inhalt.
3. Die gefundenen Feldwerte werden als Crawled Properties verarbeitet.
4. Die Crawled Properties werden Managed Properties zugeordnet.
5. Die Managed Properties stehen anschließend für Suchabfragen, Ergebnisdarstellung, Filter und Sortierungen zur Verfügung.

Eine neu erstellte Spalte ist deshalb nicht automatisch sofort als Filtereigenschaft verfügbar. Damit SharePoint sie im Suchschema erkennen kann, sollte mindestens ein Element einen gültigen Wert in dieser Spalte enthalten. Danach muss der betreffende Inhalt durch den Suchdienst verarbeitet werden.

Auch eine in der Listenansicht funktionierende Spalte ist nicht zwangsläufig bereits im Suchindex nutzbar. Listenansichten greifen direkt auf die Listendaten zu. Such-Webparts, Microsoft Search, KQL-Abfragen und PnP-Search-Komponenten verwenden dagegen den Suchindex.

Listenfilter und Suchfilter sind zwei unterschiedliche Mechanismen

Ein Filter in einer normalen SharePoint-Listenansicht wird direkt gegen die Liste ausgeführt. Dafür ist keine Managed Property erforderlich. Ein Refiner in einer Suchoberfläche arbeitet dagegen mit aggregierten Werten aus dem Suchindex und benötigt eine Managed Property, die als Refinable konfiguriert ist.

Das erklärt ein häufiges Fehlerbild: Eine Spalte lässt sich in der Liste problemlos filtern, taucht aber nicht in der Konfiguration eines Suchfilters auf.

Crawled Properties und Managed Properties verständlich erklärt

Was ist eine Crawled Property?

Eine Crawled Property ist eine vom Suchdienst erkannte Roh-Eigenschaft. Sie repräsentiert einen Feldwert, den SharePoint während der Indexierung aus einer Seite, einem Dokument oder einem Listenelement gelesen hat.

Bei SharePoint-Spalten enthalten die Namen häufig den internen Spaltennamen und beginnen beispielsweise mit:

• ows_
• ows_q_TEXT_
• ows_q_CHCS_
• ows_taxId_

Der konkrete Name hängt unter anderem vom Spaltentyp, vom internen Namen und davon ab, ob eine lokale Spalte oder eine Websitespalte verwendet wird.

Eine Spalte mit dem sichtbaren Namen Kundenstatus könnte beispielsweise einen internen Namen wie Kundenstatus oder Kunden_x0020_status besitzen. Die dazugehörige Crawled Property kann entsprechend anders heißen als die sichtbare Spaltenbezeichnung.

Für die Suche nach der richtigen Crawled Property ist deshalb der interne Name wichtiger als der Anzeigename.

Was ist eine Managed Property?

Eine Managed Property ist die kontrollierte Schnittstelle zwischen dem Suchindex und einer Suchabfrage. Sie legt fest, wie ein indexierter Wert verwendet werden darf.

Wichtige Eigenschaften einer Managed Property sind:

Eigenschaft	Bedeutung
Searchable	Der Inhalt kann in die allgemeine Volltextsuche aufgenommen werden.
Queryable	Die Eigenschaft kann gezielt in einer Abfrage wie Property:Value verwendet werden.
Retrievable	Der Wert kann zusammen mit einem Suchergebnis zurückgegeben und angezeigt werden.
Refinable	Der Wert kann als Suchfilter beziehungsweise Refiner verwendet werden.
Sortable	Suchergebnisse können anhand der Eigenschaft sortiert werden.
Multi-valued	Die Eigenschaft kann mehrere Werte pro Suchergebnis aufnehmen.

Diese Merkmale erfüllen unterschiedliche Aufgaben. Eine Eigenschaft kann beispielsweise abfragbar sein, ohne als Refiner verfügbar zu sein. Ebenso kann ein Wert im Suchergebnis ausgegeben werden, obwohl keine Sortierung danach möglich ist.

Warum die Zuordnung erforderlich ist

Die Crawled Property enthält den vom Crawler gefundenen Rohwert. Die Managed Property definiert, wie dieser Wert von Suchlösungen verwendet werden darf. Die Zuordnung zwischen beiden Eigenschaften wird als Mapping bezeichnet.

Ein typisches Mapping sieht beispielsweise so aus:

Crawled Property:
ows_q_TEXT_Kundenstatus

Managed Property:
RefinableString12

Alias:
KundenstatusSearch

Nach erfolgreicher Indexierung kann eine Suchlösung dann beispielsweise über den Alias oder den Namen der Managed Property auf den Wert zugreifen.

Voraussetzungen für die Konfiguration

Vor Änderungen am Suchschema sollten folgende Voraussetzungen erfüllt sein:

• Die SharePoint-Spalte wurde bereits erstellt.
• Mindestens ein Listenelement oder Dokument enthält einen gültigen Wert.
• Der interne Name der Spalte ist bekannt.
• Der passende Datentyp für die Managed Property wurde festgelegt.
• Es bestehen ausreichende Berechtigungen für das Suchschema.

Für Änderungen am mandantenweiten Suchschema werden entsprechende administrative Rechte benötigt. Änderungen am Suchschema einer Websitesammlung können von Administratoren der jeweiligen Websitesammlung vorgenommen werden. Eine Konfiguration auf Ebene der Websitesammlung gilt nur innerhalb dieses Bereichs.

Mandantenweite Zuordnungen sind sinnvoll, wenn dieselbe Spaltendefinition in mehreren Websites und Suchlösungen verwendet wird. Lokale Zuordnungen begrenzen dagegen die Auswirkungen und eignen sich für klar abgegrenzte Lösungen.

Den internen Namen einer SharePoint-Spalte ermitteln

Der interne Name wird beim Erstellen einer Spalte festgelegt und später nicht mehr geändert, auch wenn der sichtbare Anzeigename angepasst wird.

So lässt sich der interne Name über die Benutzeroberfläche ermitteln:

1. Öffnen Sie die Einstellungen der Liste oder Dokumentbibliothek.
2. Wählen Sie die betreffende Spalte aus.
3. Prüfen Sie in der Browseradresse den Parameter Field=.

Bei einer URL mit folgendem Ausschnitt:

Field=Kunden_x0020_status

lautet der interne Name der Spalte Kunden_x0020_status.

Dieser Name kann anschließend verwendet werden, um im Suchschema nach einer passenden Crawled Property zu suchen. Suchen Sie zusätzlich nach einem eindeutigen Bestandteil, falls der vollständige Name nicht sofort Treffer liefert.

Die passende Crawled Property finden

Öffnen Sie das Suchschema im SharePoint Admin Center oder in den Websiteeinstellungen der betreffenden Websitesammlung. Wechseln Sie dort zur Ansicht der Crawled Properties.

Suchen Sie nach dem internen Namen der Spalte. Abhängig vom Feldtyp können mehrere ähnlich benannte Eigenschaften erscheinen.

Prüfen Sie dabei:

• den vollständigen Namen der Crawled Property,
• die Kategorie, häufig SharePoint,
• den erkannten Datentyp,
• bereits vorhandene Zuordnungen zu Managed Properties.

Falls die Crawled Property nicht erscheint, sollte zuerst geprüft werden, ob die Spalte tatsächlich Werte enthält. Danach kann eine erneute Indexierung der Liste oder Bibliothek angefordert werden.

Das wiederholte Reindexieren ohne befüllte Testdaten löst das Problem in der Regel nicht. Der Suchdienst muss einen verwertbaren Feldwert vorfinden können.

RefinableString und andere Managed Properties richtig auswählen

In SharePoint Online können nicht beliebig neue Managed Properties mit aktivierter Refiner- oder Sortierfunktion erstellt werden. Für solche Szenarien stehen vordefinierte, noch nicht verwendete Eigenschaften zur Verfügung.

Dazu gehören unter anderem:

• RefinableString00 bis RefinableString219
• RefinableInt00 und weitere Integer-Eigenschaften
• RefinableDecimal00 und weitere Dezimal-Eigenschaften
• RefinableDouble00 und weitere Double-Eigenschaften
• RefinableDate00 und weitere Datumseigenschaften

Die Managed Property muss zum Datentyp und zum späteren Verwendungszweck passen.

Ein Zahlenfeld sollte nicht vorschnell einer RefinableString-Eigenschaft zugeordnet werden. Eine textuelle Darstellung kann zwar Treffer liefern, führt aber bei numerischer Sortierung zu falschen Reihenfolgen. So kann der Wert 100 vor 20 erscheinen, weil Zeichenfolgen alphabetisch statt numerisch sortiert werden.

Alias statt technischem Namen verwenden

Eine vordefinierte Managed Property wie RefinableString12 sagt nichts über ihren fachlichen Zweck aus. Deshalb sollte ein eindeutiger Alias vergeben werden, beispielsweise:

KundenstatusSearch
ProjektphaseSearch
VertragsartSearch
AblaufdatumSearch

Für Eigenschaftsnamen und Aliase sind Buchstaben und Ziffern am robustesten. Sonderzeichen können in Suchabfragen als Operatoren interpretiert werden und müssen dann teilweise gesondert maskiert werden.

Ein konsistentes Suffix wie Search erleichtert außerdem die Unterscheidung zwischen dem SharePoint-Feld, seiner Crawled Property und der verwendeten Managed Property.

SharePoint-Spalte einer Managed Property zuordnen

Die eigentliche Zuordnung erfolgt im Suchschema:

1. Öffnen Sie die Managed Properties.
2. Suchen Sie eine noch nicht verwendete Eigenschaft mit passendem Datentyp.
3. Öffnen Sie die Eigenschaft zur Bearbeitung.
4. Vergeben Sie einen verständlichen Alias.
5. Wählen Sie unter den Zuordnungen die passende Crawled Property aus.
6. Speichern Sie die Konfiguration.

Eine Managed Property gilt nur dann als frei, wenn sie noch keiner Crawled Property zugeordnet ist. Bereits verwendete Eigenschaften sollten nicht ohne Prüfung neu belegt werden. Andernfalls können bestehende Suchseiten, Filter oder Abfragen unbemerkt verändert werden.

Mandantenweite oder lokale Zuordnung?

Die Ebene der Konfiguration beeinflusst Wartbarkeit und Reichweite:

• Mandantenweites Suchschema: geeignet für standardisierte Metadaten, zentrale Websitespalten und wiederverwendbare Suchlösungen.
• Suchschema der Websitesammlung: geeignet für lokale Lösungen mit begrenztem Einsatzbereich.

Wird dieselbe fachliche Spalte in mehreren Websites benötigt, sollte sie möglichst über eine einheitliche Websitespalte oder einen zentral verwalteten Inhaltstyp bereitgestellt werden. Unabhängig voneinander erstellte lokale Spalten können trotz identischer Anzeigenamen unterschiedliche interne Namen und Crawled Properties erzeugen.

Reindexing nach der Änderung korrekt durchführen

Das Speichern des Mappings ändert den bestehenden Suchindex nicht rückwirkend. Die betroffenen Inhalte müssen erneut verarbeitet werden.

Für eine Liste oder Dokumentbibliothek erfolgt dies in der Regel über:

1. Listen- oder Bibliothekseinstellungen öffnen.
2. Erweiterte Einstellungen auswählen.
3. Liste neu indizieren oder Dokumentbibliothek neu indizieren ausführen.

Die Funktion startet keine sofortige synchrone Verarbeitung. Sie markiert die Inhalte für einen späteren Crawl. Wann die Werte tatsächlich im Suchindex erscheinen, wird durch die von Microsoft verwalteten Indexierungsprozesse bestimmt.

Änderungen können deshalb zeitversetzt sichtbar werden. Ein erneutes Auslösen des Reindexings beschleunigt diesen Hintergrundprozess normalerweise nicht.

Nicht vorschnell eine ganze Website reindexieren

Wenn nur eine einzelne Liste oder Bibliothek betroffen ist, sollte auch nur dieser Bereich neu indexiert werden. Eine vollständige Reindexierung einer Website erzeugt mehr Last und erschwert die Fehlersuche, weil deutlich mehr Inhalte erneut verarbeitet werden.

Eine Reindexierung der gesamten Website ist vor allem dann sinnvoll, wenn:

• dieselbe Spalte in mehreren Listen oder Bibliotheken verwendet wird,
• ein zentraler Inhaltstyp geändert wurde,
• mehrere Suchschema-Zuordnungen gleichzeitig angepasst wurden.

Managed Properties mit KQL testen

Nach der Indexierung sollte die Eigenschaft unabhängig vom späteren Such-Webpart getestet werden. Dafür eignet sich eine gezielte Abfrage mit der Keyword Query Language, kurz KQL.

Eine einfache Eigenschaftsabfrage sieht beispielsweise so aus:

KundenstatusSearch:Aktiv

Enthält der Wert Leerzeichen, sollte er in Anführungszeichen gesetzt werden:

KundenstatusSearch:"In Bearbeitung"

Die Abfrage kann zusätzlich auf eine Website oder einen Inhaltstyp eingeschränkt werden:

Path:"https://contoso.sharepoint.com/sites/projekte"
AND KundenstatusSearch:Aktiv

Oder auf einen bestimmten Listenpfad:

Path:"https://contoso.sharepoint.com/sites/projekte/Lists/Kunden"
AND KundenstatusSearch:Aktiv

Für Textfelder kann außerdem geprüft werden, ob überhaupt ein Wert indexiert wurde:

KundenstatusSearch:*

Der Test sollte mit einem bekannten Listenelement durchgeführt werden, dessen Feldwert eindeutig ist. Allgemeine Begriffe wie Neu, Offen oder Intern können auch an anderen Stellen vorkommen und erschweren die Auswertung.

Eine sinnvolle Testreihenfolge

1. Prüfen, ob das bekannte Element über seinen Titel gefunden wird.
2. Die Suche über Path auf die betroffene Liste oder Bibliothek begrenzen.
3. Die Managed Property mit einem exakten Testwert abfragen.
4. Die Managed Property als zurückgegebene Eigenschaft auslesen.
5. Erst danach Refiner oder Sortierung im Such-Webpart konfigurieren.

Wenn bereits die KQL-Abfrage keine Treffer liefert, liegt das Problem meist noch im Index, im Mapping oder im verwendeten Eigenschaftsnamen. Die Konfiguration des Webparts sollte erst untersucht werden, wenn die Managed Property auf Suchebene korrekt funktioniert.

Typische Fehler und ihre Ursachen

Die Crawled Property wird nicht angezeigt

Häufige Ursachen sind:

• Die Spalte enthält noch keine Werte.
• Die Liste oder Bibliothek wurde nach dem Anlegen der Spalte noch nicht indexiert.
• Es wird nach dem Anzeigenamen statt nach dem internen Namen gesucht.
• Der tatsächliche Name enthält einen feldtypspezifischen Präfix.
• Die Suche wird im falschen Suchschema durchgeführt.

Als Rückfallweg sollte ein eindeutiger Testwert in einem Element gespeichert und anschließend nur die betreffende Liste oder Bibliothek neu indexiert werden.

Die Abfrage liefert eine leere Trefferliste

Eine leere Trefferliste bedeutet nicht automatisch, dass das Mapping falsch ist. Prüfen Sie zusätzlich:

• ob das Testelement veröffentlicht oder freigegeben werden muss,
• ob der angemeldete Benutzer Leseberechtigung besitzt,
• ob die Suche auf einen falschen Pfad eingeschränkt ist,
• ob der Alias exakt geschrieben wurde,
• ob der abgefragte Wert dem indexierten Format entspricht.

SharePoint-Suche ist sicherheitsbereinigt. Ein Element kann korrekt indexiert sein und trotzdem nicht erscheinen, wenn der testende Benutzer keinen Zugriff darauf hat.

Der Wert wird gefunden, erscheint aber nicht im Ergebnis

In diesem Fall ist die Eigenschaft möglicherweise abfragbar, aber nicht abrufbar. Für die Ausgabe in einer Suchergebnisvorlage oder einem PnP-Search-Layout muss die Managed Property als Retrievable verfügbar sein und vom jeweiligen Suchclient als zurückzugebende Eigenschaft angefordert werden.

Der Refiner bleibt leer

Ein Refiner benötigt eine Managed Property, die mindestens als Queryable und Refinable nutzbar ist. Nach dem Mapping muss der Inhalt erneut indexiert werden.

Zusätzlich sollte geprüft werden, ob:

• die Managed Property tatsächlich Werte enthält,
• der Refiner mit dem richtigen Eigenschaftsnamen konfiguriert wurde,
• die aktuelle Suchabfrage überhaupt Ergebnisse mit dieser Eigenschaft liefert,
• die Filterwerte nicht durch eine andere Query-Einschränkung ausgeschlossen werden.

Die Sortierung funktioniert nicht

Für eine Sortierung muss die Managed Property als Sortable verfügbar sein. Der Datentyp muss außerdem zur fachlichen Sortierung passen.

Typische Probleme entstehen durch:

• Zahlenwerte in einer String-Eigenschaft,
• Datumswerte in einer Texteigenschaft,
• mehrwertige Felder ohne eindeutige Sortierlogik,
• leere Werte in einem großen Teil der Treffer,
• eine Verwechslung von Alias und technischem Eigenschaftsnamen.

Mehrfachwerte führen zu unerwarteten Filtern

Mehrfachauswahl-, Personen-, Lookup- und Taxonomiefelder können mehrere Werte oder zusätzliche technische Informationen im Index enthalten. Bei solchen Feldern muss geprüft werden, welche Crawled Property tatsächlich den gewünschten Wert repräsentiert.

Bei verwalteten Metadaten kann beispielsweise entweder das sichtbare Label oder eine Term-ID relevant sein. Ein Filter nach dem Label ist besser lesbar, während eine stabile ID bei umbenannten Begriffen robuster sein kann.

Die falsche Crawled Property wurde zugeordnet

Bei komplexeren Spaltentypen können mehrere Crawled Properties mit ähnlichen Namen existieren. Eine davon kann den sichtbaren Text enthalten, eine andere eine ID oder eine intern formatierte Darstellung.

In diesem Fall sollte die Zuordnung nicht mehrfach auf Verdacht geändert werden. Besser ist ein kontrollierter Test mit einem eindeutigen Feldwert und einer Prüfung der zurückgegebenen Managed Property.

Besonderheiten einzelner SharePoint-Feldtypen

Auswahlfelder

Auswahlfelder eignen sich gut für Refiner, weil sie normalerweise eine begrenzte und kontrollierte Anzahl von Werten besitzen. Unterschiedliche Schreibweisen wie In Bearbeitung und in Bearbeitung sollten vermieden werden, da sie je nach Verarbeitung als getrennte Filterwerte erscheinen können.

Personenfelder

Personenfelder können Anzeigenamen, E-Mail-Adressen, Claims-Werte oder Benutzerkennungen enthalten. Vor dem Mapping muss festgelegt werden, welcher Wert später gesucht oder gefiltert werden soll.

Ein Filter nach Anzeigenamen ist verständlich, kann bei Namensänderungen jedoch instabil sein. E-Mail-Adressen oder eindeutige Benutzerkennungen sind technischer, dafür meist eindeutiger.

Lookup-Felder

Lookup-Felder können neben dem angezeigten Wert auch eine interne Element-ID enthalten. Für einen sichtbaren Suchfilter wird normalerweise der Textwert benötigt. Für technische Verknüpfungen kann dagegen die ID sinnvoller sein.

Verwaltete Metadaten

Taxonomiefelder benötigen besondere Aufmerksamkeit, da SharePoint sowohl Begriffsbezeichnungen als auch Term-IDs indexieren kann. Bei mehrsprachigen Termsets sollte außerdem geprüft werden, welche Bezeichnung im jeweiligen Nutzungskontext ausgegeben wird.

Mehrzeilige Textfelder

Mehrzeilige Textfelder können für Volltextsuche geeignet sein, sind aber selten gute Refiner. Freitext erzeugt viele unterschiedliche Werte und damit unübersichtliche Filterlisten. Für strukturierte Filter sollte besser eine separate Auswahl-, Taxonomie- oder Statusspalte verwendet werden.

Berechnete Spalten

Bei berechneten Spalten muss geprüft werden, in welchem Datentyp das berechnete Ergebnis indexiert wird. Ein in der Oberfläche wie ein Datum dargestellter Wert kann im Suchindex anders verarbeitet werden. Für geschäftskritische Suchlogik ist eine explizit befüllte Spalte oft besser kontrollierbar.

Spaltenformatierung mit JSON

Eine JSON-Spaltenformatierung verändert nur die visuelle Darstellung in der Liste. Sie ändert weder den gespeicherten Feldwert noch automatisch die Darstellung im Suchindex. Für Suchabfragen ist weiterhin der tatsächliche gespeicherte Wert maßgeblich.

Suchschema dokumentieren und wartbar halten

Die vordefinierten Refinable Properties sind eine begrenzte und gemeinsam genutzte Ressource. Ohne Dokumentation ist später kaum nachvollziehbar, welche Eigenschaft für welchen Zweck reserviert wurde.

Eine einfache Dokumentation sollte mindestens folgende Informationen enthalten:

Dokumentationsfeld: Fachliche Bedeutung

Beispiel: Kundenstatus

Dokumentationsfeld: SharePoint-Spalte

Beispiel: Kundenstatus

Dokumentationsfeld: Interner Feldname

Beispiel: Kundenstatus

Dokumentationsfeld: Crawled Property

Beispiel: ows_q_TEXT_Kundenstatus

Dokumentationsfeld: Managed Property

Beispiel: RefinableString12

Dokumentationsfeld: Alias

Beispiel: KundenstatusSearch

Dokumentationsfeld: Gültigkeitsbereich

Beispiel: Tenant

Dokumentationsfeld: Verwendung

Beispiel: KQL, Refiner und Ergebnisanzeige

Dokumentationsfeld: Verantwortliche Lösung

Beispiel: Zentrale Kundensuche

Vor dem Ändern oder Entfernen eines Mappings sollte geprüft werden, ob die Managed Property in folgenden Komponenten verwendet wird:

• PnP-Search-Webparts,
• Microsoft-Search-Konfigurationen,
• SPFx-Webparts,
• Power-Automate-Flows mit Suchabfragen,
• individuellen REST- oder Graph-basierten Suchlösungen,
• Ergebnisvorlagen und Sortierkonfigurationen.

Das Überschreiben einer bestehenden Zuordnung kann mehrere Suchlösungen gleichzeitig beeinflussen. Änderungen sollten deshalb zunächst in einer Testumgebung oder mit einer ungenutzten Managed Property geprüft werden.

Rückfallweg bei einer fehlerhaften Zuordnung

Falls eine Änderung unerwartete Auswirkungen hat, sollte nicht sofort die gesamte Suchkonfiguration umgebaut werden. Ein kontrollierter Rückfall besteht aus folgenden Schritten:

1. Die zuletzt geänderte Managed Property identifizieren.
2. Das neue Mapping entfernen oder auf die vorherige Crawled Property zurücksetzen.
3. Die betroffene Liste oder Bibliothek erneut indexieren.
4. Die ursprüngliche KQL-Abfrage erneut testen.
5. Erst danach Refiner und Sortierungen wieder aktivieren.

Da auch das Zurücksetzen einer Zuordnung erst nach einer erneuten Indexierung wirksam wird, sollte die vorherige Konfiguration vor jeder Änderung dokumentiert werden.

Praxisbeispiel: Projektstatus als Suchfilter nutzen

Ein häufiges Beispiel ist eine Projektbibliothek, in der Dokumente nach Projektstatus gefiltert werden sollen. In der Listenansicht funktioniert der Statusfilter sofort, in einer Suchseite bleibt der entsprechende Refiner jedoch leer. Die Ursache liegt meist darin, dass die Spalte zwar gespeichert, aber noch nicht als refinierbare Managed Property nutzbar ist.

Der Weg vom Listenfeld zum Suchfilter lässt sich fachlich so planen:

Wenn die Spalte später in PnP Modern Search als Facette genutzt wird, hängt sie direkt mit dem Aufbau von PnP Search Filtern mit Verfeinerern und KQL zusammen. Ein sauberes Suchschema ist deshalb die Grundlage für eine stabile Suchoberfläche.

Qualitätsregeln für suchbare Metadaten

• Filterspalten sollten kontrollierte, wiederkehrende Werte enthalten.
• Freitext eignet sich eher für Volltextsuche als für Refiners.
• Datentyp und Managed Property müssen zur späteren Sortier- oder Filterlogik passen.
• Mehrsprachige Taxonomien brauchen einen Test mit den tatsächlich verwendeten Sprachen.
• Jede reservierte Refinable Property sollte in einem gemeinsamen Register stehen.

Diese Regeln reduzieren technische Fehler und verbessern die Pflegequalität der Inhalte. Je klarer Metadaten vorgegeben sind, desto verlässlicher werden Suchfilter, Ergebnisdarstellungen und spätere Auswertungen.

So wird aus einem Listenfeld eine wirklich nutzbare Sucheigenschaft

Eine eigene SharePoint-Spalte wird nicht allein dadurch zu einer nutzbaren Sucheigenschaft, dass sie in einer Liste vorhanden ist. Entscheidend ist die vollständige Kette aus gespeichertem Feldwert, Crawled Property, passender Managed Property, korrektem Mapping und erneuter Indexierung.

Für eine belastbare Konfiguration empfiehlt sich folgende Reihenfolge:

1. Spalte anlegen und mit eindeutigen Testwerten befüllen.
2. Internen Feldnamen ermitteln.
3. Liste oder Bibliothek bei Bedarf initial neu indexieren.
4. Passende Crawled Property identifizieren.
5. Eine freie Managed Property mit geeignetem Datentyp auswählen.
6. Einen verständlichen Alias vergeben und das Mapping speichern.
7. Die betroffenen Inhalte erneut indexieren.
8. Die Eigenschaft zuerst mit einer eingeschränkten KQL-Abfrage testen.
9. Danach Ergebnisanzeige, Refiner und Sortierung konfigurieren.
10. Die Zuordnung zentral dokumentieren.

Mit dieser Vorgehensweise lässt sich klar unterscheiden, ob ein Fehler in den Listendaten, im Suchindex, im Suchschema oder in der verwendeten Suchoberfläche liegt.