Regex in der Search Console: Filter, die wirklich helfen

25 Oktober 2026 10 Min. Lesezeit

Der Standardfilter in der Search Console kennt nur „enthält“, „schließt nicht ein“ und „ist genau“. Sobald du Suchanfragen oder URLs nach einem echten Muster trennen willst – Marke von Nicht-Marke, Fragen von Aussagen, ein URL-Verzeichnis vom Rest der Website, kurze von langen Anfragen – reicht das nicht mehr, und die Oberfläche bietet dafür „Benutzerdefiniert (Regex)“ an. Das Problem zeigt sich meistens erst beim Einsatz: Muster, die in einem Regex-Tester oder in einem anderen Analyse-Tool einwandfrei funktionieren, liefern in der Search Console entweder null Treffer oder eine Fehlermeldung.

Der Grund ist, dass die Search Console nicht die vollständige PCRE-Syntax verwendet, sondern Googles eigene Bibliothek RE2. RE2 ist bewusst eingeschränkt, damit kein Muster die Auswertung lahmlegen kann, und genau diese Einschränkung reißt kopierte Muster auseinander. Dieser Text zeigt, welche Muster in der Praxis funktionieren – für die Trennung von Marke und Nicht-Marke, für W-Fragen, für URL-Abschnitte und für die Anfragenlänge – und an welcher Stelle RE2 eine Grenze zieht, die dir kein Regex-Tester vorher anzeigt.

Wo der Regex-Filter sitzt und warum RE2 zählt

Im Bericht „Leistung“ öffnest du das Filter-Symbol über der Tabelle und wählst die Spalte „Suchanfragen“ oder „Seiten“. Neben den vorgegebenen Übereinstimmungstypen steht dort „Benutzerdefiniert (Regex)“ – die einzige Stelle, an der du ein eigenes Muster eingibst statt einer festen Zeichenkette.

Wichtig ist, dass dieses Feld nicht die Regex-Variante deiner Programmiersprache oder deines Editors spricht. Google setzt für die regexbasierte Filterung dieselbe Bibliothek ein: RE2. Sie arbeitet ohne Backtracking und ist deshalb in ihrer Laufzeit garantiert linear – das ist der technische Grund, warum bestimmte Konstrukte fehlen, die du aus PCRE oder aus JavaScript-Regex kennst.

Eine zweite Eigenschaft wird selten erklärt, verändert aber, wie jedes Muster in diesem Text zu lesen ist: Der Regex-Filter prüft standardmäßig auf einen Teilstring-Treffer irgendwo in der Anfrage oder URL, nicht auf eine vollständige Übereinstimmung. Ein Muster ohne ^ und $ matcht also, sobald die Zeichenfolge irgendwo vorkommt – genau deshalb ist Anchoring in fast jedem der folgenden Beispiele kein Stilmittel, sondern der Unterschied zwischen einem präzisen und einem zufällig zu weiten Filter.

Unterstützt: Ankerzeichen ^ und $, Zeichenklassen [...], Alternation mit |, Quantoren *, +, ?, {m,n}, Gruppen mit ( ), Wortgrenzen \b und \B, Inline-Flags wie (?i) für Case-Insensitivität
Nicht unterstützt: Lookahead (?=...) und (?!...), Lookbehind (?<=...) und (?<!...), Rückverweise wie \1, possessive Quantoren, atomare Gruppen, \K
Praktische Folge: Ein Muster mit einem nicht unterstützten Konstrukt liefert meist keinen Treffer oder eine Fehlermeldung, statt eines Teilergebnisses
Praktische Folge Nummer zwei: Ein Muster ohne Anker matcht als Teilstring – für eine vollständige Übereinstimmung sind ^ am Anfang und $ am Ende Pflicht, nicht optional

Marke von Nicht-Marke trennen, ohne negative Lookaheads

Die naheliegende Lösung für „alle Anfragen außer denen mit dem Markennamen“ ist in vielen Regex-Dialekten eine negative Lookahead, etwa ^(?!.*beispielmarke).*$. In der Search Console scheitert das, weil RE2 kein Lookahead kennt – das Muster wird abgelehnt oder liefert keine Treffer, ganz gleich wie die Daten aussehen.

Der praktikablere Weg ist, die Aufgabe gar nicht als ein einziges Muster zu lösen. Regex ist in der Search Console am stärksten für positive Muster – „ist eine von diesen Formen“ – und schwach für eine Negation über eine ganze Teilzeichenkette hinweg. Die Filteroberfläche bietet dafür im Regex-Modus die Umkehrung „stimmt nicht mit Regex überein“: Ein positives Markenmuster wird so einfach als Ausschluss angewendet. Pro Spalte ist allerdings nur eine Bedingung möglich.

Für die Markenseite selbst genügt oft ein einfaches Alternations-Muster mit Wortgrenze, etwa ^(beispielmarke|beispielmarke gmbh)\b, um Schreibvarianten und einen Rechtsformzusatz in einer Bedingung zu erfassen, statt für jede Variante eine eigene „ist genau“-Bedingung anzulegen.

Kommen mehrere unabhängige Markennamen vor – etwa nach einer Fusion oder für ein Portfolio aus mehreren Produktnamen – bleibt das Muster trotzdem eine einzige Alternation: ^(beispielmarke|zweitname|drittname)\b. Der Fehler, den viele an dieser Stelle machen, ist ein Komma statt des Pipe-Zeichens zu setzen; ein Komma ist in RE2 ein literales Zeichen und keine Alternation, das Muster sucht dann nach der Zeichenfolge „beispielmarke,zweitname“ und liefert praktisch nie einen Treffer.

Positiv formulieren statt negieren: „passt auf eines dieser Muster“ statt „passt auf keines“
Negation über die eingebaute Bedingung „schließt nicht ein“ lösen, nicht über Regex erzwingen
Wortgrenze \b verwenden, damit „marke“ nicht auch in Zufallstreffern mitten in einem anderen Wort zuschlägt

W-Fragen als eigene Kategorie herausfiltern

Die Anfragen-Spalte in der Search Console liegt bereits durchgängig kleingeschrieben vor, ein zusätzlicher Groß-/Kleinschreibungs-Check im Muster ist für diese Spalte deshalb nicht nötig – anders als bei der Seiten-Spalte, dazu weiter unten mehr.

Die Grenze dieses Musters ist wichtig zu kennen: Es erfasst die grammatische Form, nicht die Absicht. „Kosten seo audit“ ist eine Frage-Absicht ohne Fragewort und fällt durch das Muster; „wie funktioniert das“ als Einschub mitten in einer längeren Anfrage wird ebenfalls nicht erfasst, weil der Anker ^ nur den Anfang prüft. Ohne diesen Anker (.*\b(wie|was|...)\b.*) erfasst das Muster mehr, lässt dafür aber auch mehr Zufallstreffer durch zusammengesetzte Wörter mit einem Fragewort als Wortteil herein.

Der Nutzen dieses Segments liegt weniger in der reinen Anfragenliste als im Vergleich mit dem Rest: Fragende Anfragen lösen in den Suchergebnissen häufiger ein Featured Snippet oder einen ähnlichen Antwortblock über den organischen Ergebnissen aus. Das senkt die Klickrate auf die eigene Position, ohne dass sich an Ranking oder Sichtbarkeit etwas ändert – ein Muster, das nur auffällt, wenn man Frage-Anfragen isoliert und getrennt von Kurzanfragen betrachtet, statt sie im Gesamtdurchschnitt untergehen zu lassen.

^(wie|was|warum|wieso|weshalb|wann|wo|wer|wessen)\b für Fragen am Satzanfang
welche[rs]? deckt welche, welcher und welches in einem Ausdruck ab
Kombination mit einem Seiten-Filter zeigt, ob Frage-Anfragen eher auf Blog- oder auf Produktseiten landen

URL-Abschnitte in der Seiten-Spalte filtern

Die Seiten-Spalte matcht gegen die vollständige URL inklusive Protokoll und Domain, nicht nur gegen den Pfad. Ein Muster für ein Verzeichnis wie /blog/ sollte deshalb entweder unverankert mit .*/blog/.* arbeiten oder, präziser, den Domainteil bewusst mit einschließen: ^https://beispiel\.de/blog/.

Der häufigste Fehler an dieser Stelle ist der Punkt in der Domain. Ein Punkt ist im Regex ein Platzhalter für ein beliebiges Zeichen, nicht für sich selbst – beispiel.de matcht deshalb technisch auch beispielXde. In der Praxis stört das selten, weil solche Zufallstreffer in echten URLs kaum vorkommen, aber \. statt . zu schreiben ist die korrekte Form und verhindert, dass sich der Fehler in einem komplexeren Muster fortsetzt.

Für Detailseiten eines Verzeichnisses, bei denen keine weitere Ebene folgen soll, hilft der Endanker: /produkt/[^/]+$ erfasst /produkt/artikelname, aber nicht /produkt/artikelname/bewertungen. Enthält die URL zusätzlich Tracking-Parameter, blendet ein optionaler Parameterblock (\?.*)?$ am Ende des Musters das aus, ohne dass Parameter-URLs aus dem Filter herausfallen.

Zwei weitere Stolperstellen betreffen die Domain selbst: Läuft eine Website teilweise noch über http:// neben https://, oder existieren mehrere Subdomains wie shop.beispiel.de neben www.beispiel.de, matcht ein zu eng verankertes ^https://beispiel\.de/ keine der Varianten. https?://[a-z0-9-]*\.?beispiel\.de/ deckt Schema- und Subdomain-Varianten in einem Muster ab, ohne für jede Kombination eine eigene Bedingung anzulegen.

Domainpunkte escapen: \. statt .
Endanker [^/]+$ für „genau eine Ebene, nicht tiefer“
(\?.*)?$ am Ende, wenn URLs mit und ohne Parameter gemischt vorkommen
/(de|en|fr)/ als Muster für sprachpräfigierte Verzeichnisse in mehrsprachigen Setups
https?:// statt eines festen Schemas, wenn http und https parallel indexiert sind

Anfragenlänge als Long-Tail-Signal annähern

RE2 hat keine Funktion, die „zähle die Wörter“ ausdrückt, aber eine Mindestanzahl an Tokens lässt sich über eine wiederholte Gruppe annähern: ^(\S+\s+){4,}\S+$ verlangt mindestens fünf durch Leerzeichen getrennte Blöcke und damit fünf oder mehr Wörter – eine brauchbare Definition für „Long-Tail“ innerhalb einer Sprache.

Für deutsche Anfragen ist diese Schwelle mit Vorsicht zu übertragen: Deutsche Komposita packen das, was im Englischen zwei oder drei Wörter wären, in ein zusammengeschriebenes Wort. „Suchmaschinenoptimierungskosten“ ist ein einziges Token, semantisch aber eine mehrteilige Phrase. Eine Wortanzahl-Schwelle, die für englischsprachige Long-Tail-Analysen kalibriert wurde, unterschätzt deshalb im Deutschen systematisch die tatsächliche Länge und Komplexität einer Anfrage.

Kombiniert mit dem Marken-Ausschluss aus dem vorherigen Abschnitt, etwa nach einem Export oder über die API, lässt sich so ein Segment „lange, nicht-brandete Anfragen“ bilden, das für die Priorisierung von Inhalten oft aufschlussreicher ist als die Gesamtliste aller Nicht-Marken-Anfragen.

Das \s im Muster fängt dabei nicht nur das einfache Leerzeichen ab, sondern jede Art von Whitespace, falls eine Anfrage durch Copy-Paste aus einer anderen Quelle mit Tabulatoren oder doppelten Leerzeichen in die Suchmaschine gelangt ist. Wer stattdessen fest ein einzelnes Leerzeichen im Muster verankert, verpasst solche seltenen, aber real vorkommenden Randfälle.

^(\S+\s+){4,}\S+$ für mindestens fünf Wörter
{2,} statt {4,} für eine weniger strenge Long-Tail-Definition
Deutsche Komposita bei der Schwellenwahl berücksichtigen, nicht 1:1 aus englischsprachigen Vorlagen übernehmen
\s statt eines festen Leerzeichens verwenden, damit Tabulatoren oder doppelte Leerzeichen die Zählung nicht verfälschen

RE2-Grenzen, die kopierte Muster zuverlässig brechen

Die folgenden Konstrukte stammen aus PCRE, aus Perl oder aus Tools mit eigener Regex-Engine und tauchen deshalb häufig in kopierten Mustern auf, funktionieren in der Search Console aber nicht:

Lookahead (?=...) und (?!...) sowie Lookbehind (?<=...) und (?<!...) – RE2 hat keine Vorschau-Konstrukte
Rückverweise \1, \2 auf eine frühere Gruppe – RE2 arbeitet ohne Backtracking und kann nicht auf bereits Erfasstes zurückverweisen
Possessive Quantoren (*+, ++, ?+) und atomare Gruppen (?>...) – reine Backtracking-Optimierungen ohne RE2-Äquivalent
\K zum Zurücksetzen des Match-Anfangs – eine PCRE-spezifische Erweiterung
Rekursive und bedingte Muster wie (?(1)ja|nein) – in RE2 nicht vorhanden

Das verlässliche Erkennungsmerkmal: Enthält ein aus einem Regex-Tester oder aus einem anderen Tool kopiertes Muster eines dieser Konstrukte, liefert die Search Console entweder eine Fehlermeldung oder – trügerischer – schlicht null Zeilen, ohne dass erkennbar wäre, ob das an den Daten oder am Muster liegt. Der erste Verdacht sollte deshalb immer dem Muster gelten, nicht den Daten.

Umgekehrt unterstützt RE2 Capturing- und Non-Capturing-Gruppen syntaktisch einwandfrei – sie sind für die Filterung aber ohne praktischen Nutzen, weil die Search Console keine Ersetzung vornimmt und keinen erfassten Teilstring zurückgibt. Ein Muster mit Gruppen zu schreiben ist erlaubt, bringt gegenüber einem gruppenlosen Muster für diesen Zweck aber keinen Mehrwert.

Mehrere Bedingungen kombinieren statt einen Superregex bauen

Der Reflex, ein einziges, möglichst umfassendes Muster zu bauen, führt in der Search Console meist zu einem Muster, das an genau der Stelle bricht, an der RE2 eine Lücke hat. Robuster ist es, die Filteroberfläche ihre eigentliche Stärke ausspielen zu lassen: mehrere einfache Bedingungen, die zusammen als UND verknüpft werden, statt eine komplexe Bedingung.

Ein Beispiel aus den vorherigen Abschnitten zusammengesetzt: eine Bedingung „Seiten – Benutzerdefiniert (Regex)“ mit ^https://beispiel\.de/blog/, und eine zweite Bedingung „Suchanfragen – Benutzerdefiniert (Regex)“ mit ^(\S+\s+){4,}\S+$. Das Ergebnis ist die Schnittmenge: lange Anfragen, die auf Blog-Inhalte führen – eine Fragestellung, für die ein einzelnes Mammut-Muster kaum wartbar wäre.

Jede einzelne Bedingung bleibt dabei klein genug, um sie isoliert zu testen, bevor sie mit den anderen kombiniert wird. Das ist der praktische Vorteil gegenüber einem einzigen komplexen Ausdruck: Bricht das Gesamtergebnis, lässt sich die fehlerhafte Bedingung durch einzelnes Deaktivieren der übrigen sofort isolieren.

Mehrere einfache Bedingungen statt eines komplexen Musters
Jede Bedingung einzeln testen, bevor sie kombiniert wird
Bei unerwartetem Nullergebnis zuerst jede Bedingung einzeln prüfen, dann erst die Kombination

Typische Fehler beim Regex-Filtern in der Search Console

Ein fehlender Anker ist der häufigste stille Fehler: Das Muster berlin ohne ^ oder \b matcht nicht nur „berlin“, sondern auch „oberlin“, „berlinale“ oder jede andere Zeichenkette, die diese Buchstabenfolge irgendwo enthält. \bberlin\b schließt das aus, ohne die Groß-/Kleinschreibung anzufassen.

Ein zweiter, seltener genannter Punkt: Die Seiten-Spalte behandelt Groß-/Kleinschreibung anders als die Anfragen-Spalte. Anfragen kommen wie erwähnt bereits kleingeschrieben an; URL-Pfade können dagegen groß- und kleinschreibungssensitiv sein, je nachdem, wie der Server sie ausliefert. Ein Muster, das für die Anfragen-Spalte ohne Rücksicht auf Groß-/Kleinschreibung funktioniert hat, kann auf der Seiten-Spalte stillschweigend Treffer verpassen, wenn URLs uneinheitlich geschrieben sind. Die Abhilfe ist das Inline-Flag aus Abschnitt eins: (?i)/blog/ am Musteranfang schaltet die Case-Insensitivität für den gesamten Ausdruck ein, ohne dass jede Buchstabenvariante einzeln in eine Zeichenklasse geschrieben werden muss.

Drittens: Ein Nulltreffer nach dem Anlegen eines neuen Musters wird zu oft als „keine Daten für diesen Zeitraum“ gelesen, während in Wirklichkeit das Muster selbst fehlerhaft ist – etwa weil es ein nicht unterstütztes Konstrukt aus dem vorherigen Abschnitt enthält. Vor jeder Schlussfolgerung aus einem leeren Ergebnis lohnt sich ein Test mit einem bewusst sehr breiten Platzhaltermuster wie .*, um zu bestätigen, dass für den gewählten Zeitraum überhaupt Daten vorliegen.

Fehlende Anker oder Wortgrenzen führen zu Zufallstreffern in unerwarteten Wörtern
Seiten-Spalte kann groß-/kleinschreibungssensitiv sein, die Anfragen-Spalte ist es praktisch nicht
Nullergebnis erst mit einem breiten Testmuster (.*) gegen „keine Daten“ abgrenzen, dann erst gegen „Muster fehlerhaft“

Häufige Fragen

Ist der Regex-Filter in der Search Console case-sensitive?

Für die Anfragen-Spalte praktisch nicht, weil Google Suchanfragen im Bericht bereits kleingeschrieben ausliefert. Für die Seiten-Spalte kommt es auf die tatsächliche Schreibweise der URLs auf dem Server an, ein Muster sollte dort im Zweifel beide Schreibvarianten abdecken.

Warum liefert mein aus einem anderen Tool kopiertes Muster in der Search Console keine Treffer?

Meist, weil das Muster ein Konstrukt enthält, das RE2 nicht kennt – Lookahead, Lookbehind oder Rückverweise sind die häufigsten Fälle. RE2 lehnt solche Muster ab oder liefert ein leeres Ergebnis, statt eine Fehlermeldung mit klarer Ursache anzuzeigen.

Kann ich mehrere Regex-Bedingungen gleichzeitig auf denselben Bericht anwenden?

Ja, je eine Bedingung für Suchanfragen und für Seiten, die als UND verknüpft werden; pro Spalte ist in der Oberfläche nur eine Bedingung möglich. Das ist oft robuster, als zu versuchen, alles in ein einziges komplexes Muster zu packen.

Gilt die RE2-Einschränkung auch für die Search-Console-API oder nur für die Weboberfläche?

Die Einschränkung betrifft die Regex-Funktion grundsätzlich, da beide auf derselben zugrunde liegenden Bibliothek aufbauen. Ein Muster, das in der Oberfläche wegen eines nicht unterstützten Konstrukts scheitert, scheitert aus demselben Grund auch bei einer entsprechenden Filterabfrage.

Wie finde ich heraus, ob ein Nullergebnis an fehlenden Daten oder an einem fehlerhaften Muster liegt?

Teste zuerst mit einem bewusst sehr breiten Muster wie .* im selben Zeitraum und derselben Spalte. Liefert das ebenfalls null Zeilen, liegt es am Zeitraum oder der Datenbasis; liefert es Treffer, liegt der Fehler im ursprünglichen Muster.