Google-Such-URL-Parameter: Was 2026 noch funktioniert

Irgendwann um September 2025 herum sind eine ganze Reihe von SEO-Tools und eigenen Skripten still und leise kaputtgegangen. Der Auslöser? Google hat sich nicht mehr zuverlässig an den Parameter num=100 gehalten, auf den Power-User jahrelang gesetzt hatten, um 100 Ergebnisse pro Seite abzurufen. Eine offizielle Abkündigung gab es nicht – lediglich einen Sprecher, der Search Engine Land sagte, der Parameter sei „nicht offiziell unterstützt“. Etwa zur gleichen Zeit führte Google neben den älteren tbm-Vertikalen weitere udm-Modi ein, kündigte an, dass Länderdomains nach und nach auf google.com umgeleitet werden, und meldete, dass AI Overviews über 2,5 Milliarden monatliche Nutzer erreichen.

Wenn Sie Such-URLs bauen, Rankings beobachten oder Recherchen mit den URL-Parametern von Google automatisieren, ist die Wahrscheinlichkeit groß, dass einige Ihrer Workflows gerade unbemerkt schlechter funktionieren. Bei Thunderbit haben wir die aktuelle Google-Dokumentation, jüngste Änderungsmeldungen, Reverse-Engineering-Quellen und Live-Checks ausgewertet, um stabile Steuerungen von kontextabhängigen zu trennen. Das Ergebnis ist eine praxisnahe Referenz mit Stichtagsbezug, die Sie vor dem Einsatz testen sollten – für die Google-Such-URL-Parameter, die 2026 wirklich zählen, einschließlich tbm/udm-Zuordnungen, der uule-Kodierungsformel für Geo-Targeting auf Stadtebene und Parameterkonflikten, die stundenlanges Debugging ersparen können.

Was sind Google-Such-URL-Parameter?

Google-Such-URL-Parameter sind die key=value-Paare, die hinter dem ? in einer Google-Such-URL stehen. Sie steuern alles: wonach gesucht wird, aus welchem Land die Ergebnisse stammen, und ob Bilder, News oder klassische blaue Links angezeigt werden.

Eine typische Google-Such-URL sieht so aus:

https://www.google.com/search?q=best+crm+software&hl=en&gl=us&tbs=qdr:m

• Basis-URL: https://www.google.com/search
• ? beginnt die Query-String-Zeichenkette
• q=best+crm+software ist die Suchanfrage (Leerzeichen werden als + codiert)
• & trennt die einzelnen Parameter
• hl=en stellt die Oberfläche auf Englisch ein
• gl=us signalisiert Google, Ergebnisse so anzuzeigen, als wären Sie in den USA
• tbs=qdr:m filtert auf Ergebnisse aus dem letzten Monat

Eine wichtige Unterscheidung: Suchoperatoren wie site:, filetype: und intitle: stehen innerhalb des q=-Werts. Sie sind Teil Ihrer Suchanfrage. URL-Parameter wie gl, hl und tbs sind separate Schlüssel in der URL, die steuern, wie Google Ergebnisse verarbeitet und darstellt. Beides ist wichtig und greift ineinander – aber es sind unterschiedliche Werkzeuge.

Google hat nie eine einzige, versionierte Spezifikation für diese Parameter veröffentlicht. Einige stammen aus dem erweiterten Suchformular, einige aus der Custom Search API und einige wurden per Reverse Engineering aus Googles eigenen URLs abgeleitet. Das heißt: Dieser Artikel basiert auf Live-Tests und dokumentiertem Verhalten, nicht auf einem offiziellen API-Vertrag.

Warum Google-Such-URL-Parameter 2026 wichtig sind

URL-Parameter sind nicht nur ein Thema für Entwickler. Wer in SEO, Marketing, Sales, Operations oder Produkt versteht, was Google für eine bestimmte Suchanfrage, in einem bestimmten Markt und zu einem bestimmten Zeitpunkt zeigt, für den sind diese Parameter ein zentrales Werkzeug.

Ein kurzer Überblick, wer davon profitiert und wie:

Anwendungsfall	Wer profitiert	Wichtige Parameter
SEO-Rank-Tracking über Länder hinweg	SEO- und Marketing-Teams	gl, hl, uule, pws
Wettbewerbsbeobachtung nach Datum	Strategie- und Ops-Teams	tbs, q mit site:
Anzeigen-Monitoring in bestimmten Märkten	Paid-Media-Teams	gl, hl, udm
Lokale SEO-Audits (Stadtebene)	Lokale Unternehmen	uule, gl
Content-Recherche / Trend-Tracking	Content-Teams	tbs (Datumsfilter), lr
Suchdaten in AI/LLM-Apps einspeisen	Produkt- und Data-Teams	Mehrere Parameter + strukturierte Extraktion

Drei große Veränderungen machen 2026 spürbar anders:

1. num=100 ist nicht mehr verlässlich. Der alte Trick für 100 Ergebnisse pro Seite funktioniert seit September 2025 nicht mehr zuverlässig. Google hat ihn nicht offiziell abgeschafft; ein Sprecher sagte lediglich, er sei nie offiziell unterstützt worden.
2. Weiterleitungen von ccTLDs sind eine Migration, kein abgeschlossener Wechsel. Google kündigte im April 2025 an, dass Länderdomains wie google.co.uk, google.de usw. nach und nach auf google.com umgeleitet werden. Google hat kein Abschlussdatum veröffentlicht – gehen Sie also nicht davon aus, dass schon überall exakt dasselbe Verhalten gilt.
3. AI Overviews haben die SERP verändert. Google meldet, dass AI Overviews über 2,5 Milliarden monatliche Nutzer und mehr als 200 Länder und Gebiete erreichen. Reverse-engineerte udm-Modi können die Ergebnisansicht in manchen Kontexten verändern, sind aber kein garantierter Schalter für AI Overviews.

Wenn Ihre Workflows diese Änderungen noch nicht berücksichtigen, bekommen Sie wahrscheinlich schlechtere oder irreführende Ergebnisse, ohne es zu merken.

Google-Such-URL-Parameter im Überblick (2026)

Bevor wir ins Detail gehen, ist die folgende Schnellreferenz die aktuellste Liste, die ich zusammenstellen konnte. Speichern Sie sie ab.

Parameter	Funktion	Beispielwert	Status
q	Suchanfrage (unterstützt Operatoren im Inneren)	q=best+crm+software	✅ Aktiv
hl	Sprache der Oberfläche	hl=en, hl=ja	✅ Aktiv
gl	Länder-/Marktkontext	gl=us, gl=jp	✅ Aktiv
lr	Ergebnisse auf eine Inhaltssprache einschränken	lr=lang_en	✅ Aktiv
cr	Ergebnisse auf ein Hosting-Land einschränken	cr=countryUS	✅ Aktiv
start	Paginierungs-Offset	start=10 (Seite 2)	✅ Aktiv
num	Ergebnisse pro Seite (früher)	num=100	⚠️ Nicht offiziell unterstützt; seit Sept. 2025 unzuverlässig
udm	Kontextbezogener Inhaltsmodus	udm=14 (klassisches Web)	⚠️ Reverse-engineert; kontextabhängig
tbm	Suchvertikale	tbm=isch (Bilder)	⚠️ Weiterhin beobachtet; zusammen mit udm testen
tbs	Zeitfilter, Sortierung, Verbatim	tbs=qdr:w	✅ Aktiv
safe	SafeSearch-Steuerung	safe=active	✅ Aktiv
filter	Filterung doppelter Ergebnisse	filter=0	✅ Aktiv (beobachtet)
nfpr	Auto-Korrektur deaktivieren	nfpr=1	✅ Aktiv (beobachtet)
pws	Personalisierung deaktivieren	pws=0	✅ Aktiv
uule	Geo-Targeting auf Stadt-/DMA-Ebene	uule=w+CAIQICI...	✅ Aktiv (reverse-engineert)
as_q, as_epq, as_eq, etc.	Felder aus der erweiterten Suche	Verschieden	✅ Aktiv
as_sitesearch	Auf eine Domain einschränken (Erweiterte Suche)	as_sitesearch=example.com	✅ Aktiv
as_filetype	Auf Dateityp einschränken (Erweiterte Suche)	as_filetype=pdf	✅ Aktiv
ie, oe	Eingabe-/Ausgabe-Codierung	ie=UTF-8	✅ Aktiv (selten nötig)
kgmid, si, ibp	Knowledge-Graph-Entity / Feature-Ansicht	Verschieden	⚠️ Kontextabhängig (nicht allgemein nutzen)
ei, ved, sxsrf, sclient	Sitzung/Tracking/Telemetrie	Verschieden	🔒 Intern (ignorieren)
gbv	Einfache HTML-Ansicht (früher)	gbv=1	❌ 2026 unzuverlässig

Entfernen Sie ei, ved, sxsrf und sclient aus allen URLs, die Sie speichern oder weitergeben. Das sind Sitzungs- und Telemetrie-States, die Google automatisch anhängt – für den Aufbau von Such-URLs irrelevant.

Zentrale Google-Such-URL-Parameter, die noch funktionieren

Ich habe jeden dieser Parameter Mitte 2026 live getestet. Das sind die, die Sie am häufigsten brauchen.

q — Ihre Suchanfrage

Der Parameter q enthält Ihre Suchbegriffe. Leerzeichen werden als + oder %20 kodiert. Hier liegen auch Googles dokumentierte Suchoperatoren – sie gehören in den q-Wert, nicht als separate URL-Parameter.

Ein paar Beispiele:

• Exakte Phrase: q=%22google+search+url+parameters%22
• Auf eine Website beschränkt: q=site%3Aexample.com+pricing
• Dateityp: q=filetype%3Apdf+annual+report+2026
• Kombiniert: q=site%3Acompetitor.com+intitle%3Apricing+after%3A2026%2F01%2F01

Kodieren Sie den gesamten Query-Wert immer URL-gerecht. Anführungszeichen, Doppelpunkte und Schrägstriche müssen korrekt codiert werden, sonst wird die URL beschädigt.

hl — Sprache der Oberfläche

hl steuert die Sprache von Googles Oberfläche (Buttons, Labels, Überschriften wie „People also ask“) und beeinflusst, welche Ergebnisse Google priorisiert. Es verwendet ISO-639-1-Codes wie en, fr, de, ja oder BCP-47-Tags wie en-gb oder pt-br.

hl zwingt Dokumente in den Ergebnissen nicht in diese Sprache. Es ist ein starkes Signal, aber Google kann trotzdem andere Sprachen anzeigen, wenn sie besonders relevant sind. Für die Eingrenzung auf eine Inhaltssprache verwenden Sie stattdessen lr.

gl — Land / Geolocation

gl simuliert das Land, aus dem Sie suchen, und nutzt ISO 3166-1 Alpha-2-Codes (us, gb, jp, de). Da ccTLDs schrittweise auf google.com umgeleitet werden, ist gl inzwischen der wichtigste Weg zu länderspezifischen Ergebnissen.

Dieselbe Suchanfrage mit unterschiedlichen gl-Werten kann komplett andere Ergebnisse, Featured Snippets und lokale Ergebnisboxen liefern. Zum Beispiel zeigen q=best+bank&gl=us und q=best+bank&gl=jp sehr unterschiedliche Banken.

Praxis-Tipp: Kombinieren Sie gl immer mit hl, um sauber lokalisierte Ergebnisse zu erhalten. gl=jp mit hl=en liefert Ergebnisse für den japanischen Markt in einer englischen Oberfläche – nützlich für internationale SEO-Audits.

lr und cr — Sprach- und Länderfilter

Diese beiden werden ständig verwechselt. Die Unterscheidung ist wichtig:

• lr=lang_en beschränkt Ergebnisse auf englischsprachige Seiten (Inhaltssprache)
• cr=countryUS beschränkt Ergebnisse auf Seiten, die in den USA gehostet werden (Serverstandort / Länderzuordnung)
• gl=us simuliert eine Suche aus den USA heraus (beeinflusst Ranking, lokale Ergebnisse, Anzeigen)

Sowohl lr als auch cr sind über Googles erweitertes Suchformular verfügbar. Seien Sie vorsichtig bei der Kombination – lr=lang_en + cr=countryJP bedeutet „nur englischsprachige Seiten, die in Japan gehostet werden“, also eine sehr kleine Teilmenge. Mehr dazu im Abschnitt zu Konflikten.

start — Paginierung

start=10 fordert Ergebnisse ab Position 11 an (Seite 2), start=20 für Seite 3 usw. Weil num=100 nicht mehr verlässlich ist, ist das Erhöhen von start in 10er-Schritten die sicherere Standardlösung – Google kann die Paginierung aber trotzdem umschreiben oder einschränken.

Der alte Trick num=100&start=0, um eine komplette Seite mit 100 Ergebnissen zu laden, funktioniert nicht mehr. Wenn Ihre Skripte num noch enthalten, entfernen Sie es – der Parameter wird stillschweigend ignoriert.

pws — Personalisierung deaktivieren

pws=0 fordert Google dazu auf, die kontoabhängige Personalisierung auszuschalten. Das ist entscheidend für SEO-Rank-Tracking, wenn Sie Ergebnisse möchten, die nicht durch eigene Suchhistorie, Klicks oder Kontoeinstellungen verzerrt sind.

Wichtiger Hinweis: pws=0 reduziert die Personalisierung, beseitigt aber nicht alle kontextuellen Faktoren. Google sagt, dass sich Ergebnisse trotzdem nach Zeit, Standort, Sprache und Gerät unterscheiden können. Eine wirklich „neutrale“ Google-SERP gibt es nicht.

safe und filter — SafeSearch und Duplikatfilter

• safe=active aktiviert SafeSearch; safe=off deaktiviert es. Beachten Sie, dass Kontoeinstellungen, Admin-Richtlinien, Netzwerkkonfigurationen oder regionale Gesetze diesen Parameter überschreiben können.
• filter=0 deaktiviert Googles Filterung doppelter Ergebnisse. Das ist nützlich, wenn Sie jedes Ergebnis sehen möchten, einschließlich nahezu identischer Treffer, die sonst zusammengefasst würden.

nfpr — Auto-Korrektur deaktivieren

nfpr=1 verhindert, dass Google Ihre Suchanfrage zwangsweise umschreibt, wenn es einen Tippfehler vermutet. Das ist hilfreich, um Markenbegriffe mit ungewöhnlicher Schreibweise, Fachjargon oder bewusst falsch geschriebene Suchbegriffe zu tracken, auf die Wettbewerber abzielen.

Beachten Sie: nfpr=1 unterdrückt nur die erzwungene Umschreibung. Für weitergehende Kontrolle – also das Abschalten von Synonymen, Rechtschreibkorrekturen und anderen automatischen Änderungen – nutzen Sie tbs=li:1 (Verbatim-Modus), den ich unten im tbs-Abschnitt erläutere.

Die Migration von tbm zu udm: Was sich geändert hat und was Sie jetzt verwenden sollten

Das ist eine der größten Parameteränderungen der letzten Jahre – und eine der leichtesten, sie zu übertreiben.

tbm war über mehr als ein Jahrzehnt eine gängige Methode, zwischen Googles Suchvertikalen zu wechseln – also Bilder, News, Videos, Shopping. Google hat außerdem ein numerisches udm-System mit überlappenden und zusätzlichen Modi eingeführt. Da Google kein stabiles öffentliches Verzeichnis veröffentlicht hat, sollten Sie das als kontextabhängige Zuordnung verstehen, nicht als saubere, abgeschlossene Ersetzung.

Die vollständige tbm-zu-udm-Zuordnung

Die folgenden Zuordnungen basieren auf beobachtetem UI-Verhalten und Live-Checks vom 12. August 2026. Mehrere Werte wurden bei anonymen Anfragen entfernt oder umgeschrieben. Deshalb sollte jede Zeile in genau dem Konto-, Regions- und Client-Kontext getestet werden, in dem sie später verwendet wird:

Alter Parameter	Alter Wert	Neuer Parameter	Neuer Wert	Status
tbm=lcl	Orte/Lokal	udm=1	Orte/Lokal	⚠️ Kontextabhängig
tbm=isch	Bilder	udm=2	Bilder	⚠️ Kontextabhängig
tbm=vid	Videos	udm=7	Videos	⚠️ Kontextabhängig
tbm=nws	News	udm=12	News	⚠️ Kontextabhängig
—	—	udm=14	Klassisches Web (kein AI Overview)	🆕 Neu, kein tbm-Äquivalent
—	—	udm=18	Foren	🆕 Neu, kein tbm-Äquivalent
tbm=shop	Shopping	udm=28	Shopping	⚠️ Kontextabhängig
tbm=bks	Bücher	udm=36	Bücher	⚠️ Kontextabhängig
—	—	udm=39	Kurzvideos	🆕 Neu, kein tbm-Äquivalent
—	—	udm=50	AI-Overview-Modus	🆕 Neu, kein tbm-Äquivalent

Google hat kein stabiles udm-Register veröffentlicht – das ist ein entscheidender Vorbehalt. Diese Werte wurden per Reverse Engineering aus dem beobachteten UI-Verhalten abgeleitet. Ob eine URL akzeptiert wird, hängt von Konto, Region, Client, Cookies und Experimentkohorte ab. In meinen Tests wurden einige udm-Werte bei anonymen HTTP-Anfragen entfernt, funktionierten aber in interaktiven Browser-Sitzungen. Gehen Sie nicht davon aus, dass jeder Wert überall funktioniert.

Was udm=14 macht (und warum SEOs es lieben)

udm=14 hat sich in der SEO-Community zu einem regelrechten Favoriten entwickelt. Android Central beschrieb es als Möglichkeit, eine klassische Web-Ergebnisseite ohne AI Overviews anzufordern. In vielen Sitzungen erzeugt es eine traditionelle SERP mit blauen Links, aber es ist keine offizielle oder universelle Garantie.

Warum ist das wichtig? Wenn Sie Rankings messen oder SEO-Audits durchführen, können AI Overviews die organischen Ergebnisse nach unten schieben und die Bewertung von Positionen erschweren. udm=14 kann eine sauberere Ansicht liefern, wenn Google es akzeptiert.

Allerdings funktioniert udm=14 nicht in jedem Kontext garantiert. Bei Live-Stichproben vom 12. August 2026 hat Google udm-Werte je nach Anforderungskontext teilweise entfernt oder umgeschrieben. Das Ergebnis kann also je nach Sitzung, Konto, Region, Client und Experimentkohorte variieren.

udm=50 wurde in AI-Mode-/AI-Ergebnis-Kontexten beobachtet, sollte aber nicht als garantierter Weg beschrieben werden, für eine beliebige Suchanfrage ein AI Overview zu erzwingen.

Was Sie tun sollten: Workflows von tbm auf udm umstellen

Meine Empfehlung:

• Neue Implementierungen: udm als experimentellen / kontextabhängigen Input behandeln und Fallbacks einbauen.
• Bestehende Workflows: Sowohl tbm als auch udm dort unterstützen und testen, wo es relevant ist, statt von einer abgeschlossenen Migration auszugehen.
• Nie beides kombinieren: Wenn tbm und udm in derselben URL vorkommen, ist das Verhalten unvorhersehbar. In meinen Tests hat Google manchmal beide entfernt und eine normale Suchanfrage zurückgegeben. Mehr dazu im Konfliktabschnitt.

Die komplette tbs-Syntax: benutzerdefinierte Datumsbereiche, Sortierung nach Datum und Verbatim

tbs ist einer der mächtigsten Parameter im Google-Such-URL-Toolkit, und die meisten Anleitungen kratzen nur an der Oberfläche. Er steuert Zeitfilter, Sortierung nach Datum, Verbatim-Modus und mehr – alles in einem einzigen, durch Kommas getrennten Wert.

Standard-Zeitfilter

| tbs-Wert | Bedeutung | Beispiel-URL-Fragment | |---|---|---|---| | qdr:h | Letzte Stunde | &tbs=qdr:h | | qdr:d | Letzte 24 Stunden | &tbs=qdr:d | | qdr:w | Letzte Woche | &tbs=qdr:w | | qdr:m | Letzter Monat | &tbs=qdr:m | | qdr:y | Letztes Jahr | &tbs=qdr:y |

Das sind die Grundlagen, die die meisten Ratgeber abdecken. Aber tbs kann noch deutlich mehr.

Benutzerdefinierte Datumsbereiche

Sie brauchen Ergebnisse aus einem bestimmten Zeitfenster? Verwenden Sie die Syntax cdr:1,cd_min:MM/DD/YYYY,cd_max:MM/DD/YYYY:

&tbs=cdr:1,cd_min:01/01/2026,cd_max:06/01/2026

Damit werden Ergebnisse gefiltert, die Google mit einem Datum zwischen dem 1. Januar und dem 1. Juni 2026 verknüpft. Das ist extrem wertvoll für Wettbewerbsrecherchen – zum Beispiel: „Was haben Mitbewerber im ersten Quartal 2026 zu Preisen veröffentlicht?“ Denken Sie daran, den gesamten Wert URL-gerecht zu codieren, da Doppelpunkte und Schrägstriche kodiert werden müssen.

Ein praktischer Hinweis: Googles Datumszuordnung ist nicht immer exakt. Das Datum in den Suchergebnissen ist Googles beste Schätzung und nicht zwingend das tatsächliche Veröffentlichungsdatum. Prüfen Sie das Datum immer auf der Zielseite.

Nach Datum sortieren und Verbatim-Modus

Hier deckt der Leitfaden Bereiche ab, die kein Konkurrenzartikel so erklärt.

sbd:1 sortiert Ergebnisse nach Datum (neueste zuerst). Für sich genommen ist das nützlich, aber nicht außergewöhnlich. Der Trick ist, dass Sie es mit Zeitfiltern in einem einzigen tbs-Wert kombinieren können:

&tbs=qdr:m,sbd:1

Damit erhalten Sie Ergebnisse aus dem letzten Monat, nach Datum sortiert – neueste zuerst. Das ist der schnellste Weg, um frisch veröffentlichte Inhalte zu einem Thema zu finden. Ich nutze diese Kombination ständig bei der Beobachtung von Wettbewerbsinhalten.

li:1 aktiviert den Verbatim-Modus – das URL-Pendant zum Klicken auf Googles Tool „Verbatim“ in der Suchoberfläche. Der Verbatim-Modus deaktiviert Auto-Korrekturen, Synonymerweiterungen, Schreibänderungen und andere automatische Veränderungen der Suchanfrage.

Der Unterschied zwischen li:1 und nfpr=1 liegt im Umfang:

• nfpr=1: Unterdrückt nur erzwungene Rechtschreib-/Suchumschreibungen (z. B. wenn Google aus „teh“ automatisch „the“ machen will)
• tbs=li:1: Deaktiviert alle automatischen Änderungen – Rechtschreibung, Synonyme, verwandte Begriffe, Personalisierungsanpassungen

Sie können sogar mehrere tbs-Werte kombinieren. Zum Beispiel liefert tbs=qdr:m,sbd:1,li:1 Ergebnisse aus dem letzten Monat, nach Datum sortiert, mit Verbatim-Abgleich. In meinen Tests funktioniert diese Kombination, aber ich würde empfehlen, sie mit Ihren konkreten Suchanfragen zu verifizieren, da tbs eine undokumentierte Syntax ist.

Wie man einen uule-Code für Geo-Targeting auf Stadtebene erstellt

Wenn gl ein Zoomobjektiv auf Landesebene ist, dann ist uule ein Mikroskop auf Stadtebene. Für lokales SEO – etwa um zu prüfen, wie Ihr Unternehmen in Denver im Vergleich zu Dallas rankt oder was ein Suchender im Tokioter Stadtteil Shibuya sieht – reicht gl allein nicht aus.

Kein Top-Artikel erklärt tatsächlich, wie man einen uule-Code erzeugt – dort wird meist nur erwähnt, dass der Parameter existiert, und dann geht es weiter. Die vollständige Erklärung folgt hier.

Wann man gl, uule oder cr verwendet

Parameter	Genauigkeit	Typischer Anwendungsfall	Muss kodiert werden?
gl=us	Länderebene	Schnelle Ländersimulation	Nein
cr=countryUS	Länderebene (Restriktion)	Nach Hosting-Land filtern	Nein
uule=w+CAIQICI...	Stadt-/DMA-Ebene	Lokales SEO-Rank-Checking	Ja

Der uule-Kodierungsalgorithmus Schritt für Schritt

Der uule-Parameter verwendet ein kodiertes Named-Location-Signal. Die Konstruktion ist reverse-engineert und nicht offiziell von Google dokumentiert, wurde aber von der SEO-Community breit validiert.

Der sicherere Weg ist, ein kleines Protocol-Buffers-Payload zu kodieren, statt sich auf die oft kopierte Kurzform zu verlassen, die bei Nicht-ASCII-Zeichen fehlschlagen kann. So geht es:

1. Holen Sie sich den kanonischen Google-Ortsnamen. Google veröffentlicht geografische Ziele mit kanonischen Namen über die Geodaten der Google-Ads-API. Beispiel: New York,New York,United States
2. Kodieren Sie den Namen als UTF-8-Bytes.
3. Erstellen Sie ein kleines protobuf-Payload mit dem Namen und seiner Byte-Länge.
4. Base64url-kodieren Sie das Payload und setzen Sie w+ davor.

Hier ein Python-Snippet dafür:

import base64

def encode_varint(value: int) -> bytes:
    out = bytearray()
    while True:
        byte = value & 0x7F
        value >>= 7
        if value:
            out.append(byte | 0x80)
        else:
            out.append(byte)
            return bytes(out)

def build_uule(canonical_name: str) -> str:
    name = canonical_name.encode("utf-8")
    payload = b"\x08\x02\x10\x20\x12" + encode_varint(len(name)) + name
    encoded = base64.urlsafe_b64encode(payload).decode().rstrip("=")
    return "w+" + encoded

# Beispiel
print(build_uule("New York,New York,United States"))
# Ausgabe: w+CAIQICIeTmV3IFlvcmssTmV3IFlvcmssVW5pdGVkIFN0YXRlcw

Wenn Sie das in eine URL einbauen, stellen Sie sicher, dass das literale + in w+ von Ihrer URL-Bibliothek korrekt als %2B kodiert wird. Die meisten URLSearchParams- oder urllib.parse.urlencode-Implementierungen erledigen das automatisch.

Ein korrekt aufgebautes uule ist trotzdem nur ein einzelnes Standortsignal. Es überschreibt nicht IP-Adresse, Kontoeinstellungen, Gerät oder Experimentkohorte. Nutzen Sie es für richtungsweisende lokale SEO-Checks, nicht als Garantie für exakt stadtscharfe Rankings.

Wenn Google-Such-URL-Parameter stillschweigend miteinander in Konflikt geraten

Parameterkombinationen können stillschweigend scheitern: Google ignoriert möglicherweise eine Eingabe, schreibt die URL um oder liefert eine andere Oberfläche. Die folgenden Konfliktprüfungen sollten Sie in jeden Workflow mit Suchlinks einbauen.

Kein Konkurrenzartikel behandelt diese Parameter-Interaktionen. Aber wenn Sie Such-URLs mit mehreren Parametern bauen – und das tun Sie wahrscheinlich – müssen Sie wissen, welche Kombinationen harmonieren und welche sich gegenseitig behindern.

gl + uule: Wer setzt sich durch?

Wenn beide vorhanden sind, liefert uule ein spezifischeres Standortsignal als gl. Wenn Sie gl=uk und ein uule für Tokio setzen, erhalten Sie Ergebnisse mit Tokio-Bezug, nicht UK-Ergebnisse.

Empfehlung: Wenn Sie uule verwenden, lassen Sie gl entweder ganz weg oder setzen Sie gl auf das Land, in dem sich die uule-Stadt befindet. Senden Sie keine widersprüchlichen Signale.

tbm + udm: Nicht beides verwenden

In meinen Tests hat Google, wenn tbm und udm in derselben URL vorkamen, manchmal beide entfernt und eine normale Websuche zurückgegeben. Das Verhalten ist je nach Sitzung und Konto inkonsistent.

Empfehlung: Verwenden Sie für neue Implementierungen nur udm. Wenn Sie alte Workflows unterstützen müssen, nutzen Sie entweder das eine oder das andere – niemals beide.

lr + cr: Doppelte Filterung kann null Ergebnisse liefern

Das ist eine subtile Falle. lr=lang_en beschränkt auf englischsprachige Inhalte. cr=countryJP beschränkt auf Seiten, die in Japan gehostet werden. Zusammen bedeutet das „englischsprachige Seiten, die in Japan gehostet werden“ – also einen sehr kleinen Webausschnitt.

Empfehlung: Verwenden Sie nur einen der beiden Filter, außer Sie brauchen genau diese Schnittmenge. Wenn Sie beide kombinieren, erwarten Sie deutlich weniger Ergebnisse.

num + start: Defekte Paginierung

Alte Skripte mit num=100&start=0 liefern inzwischen stillschweigend nur noch etwa 10 Ergebnisse. Der num-Parameter wird nicht mehr berücksichtigt, verursacht aber keinen Fehler – er wird einfach ignoriert.

Empfehlung: Entfernen Sie num aus allen URLs. Nutzen Sie Paginierung mit start in 10er-Schritten und deduplizieren Sie die Ergebnisse über mehrere Seiten hinweg.

Kurzübersicht zu Konflikten

Kombination	Was passiert	Empfehlung
gl + uule	uule liefert das spezifischere Signal	Land und Stadt aufeinander abstimmen oder gl weglassen
tbm + udm	Unvorhersehbar — beide können entfernt werden	Nur udm verwenden
lr + cr	Starke Eingrenzung, oft nahezu keine Ergebnisse	Nur einen der beiden verwenden
num + start	num ignoriert, nur ~10 Ergebnisse zurückgegeben	num entfernen, mit start paginieren
nfpr=1 + tbs=li:1	Verwandte, aber nicht identische Steuerungen	Ihre konkrete Suchanfrage testen
hl + lr	Oberflächensprache ≠ Inhaltssprach-Filter	Bewusst einsetzen; hl ist kein Content-Filter

Von Google-Such-URL-Parametern zu strukturierter Datenerfassung

Jetzt haben Sie eine präzise Google-Such-URL – die richtige Suche, das richtige Land, den richtigen Datumsbereich, klassische Web-Ergebnisse. Der nächste Schritt ist, strukturierte Daten aus den Ergebnissen zu gewinnen.

Egal, ob Sie einen Rank-Tracker bauen, Wettbewerber beobachten oder Suchdaten in einen Research-Workflow einspeisen: Die richtigen Ergebnisse zu sehen, ist nur die halbe Miete. Sie brauchen Titel, URLs, Snippets, Positionen und Datumsangaben in einer Tabellenkalkulation oder Datenbank.

Eine gezielte Google-Such-URL bauen (alles zusammenführen)

Ein vollständiges Beispiel mit mehreren Parametern:

https://www.google.com/search?q=site%3Acompetitor.com+intitle%3Apricing&hl=en&gl=us&tbs=qdr:m,sbd:1&udm=14&pws=0

Aufgeschlüsselt:

• q=site%3Acompetitor.com+intitle%3Apricing — Seiten auf competitor.com mit „pricing“ im Titel
• hl=en — englische Oberfläche
• gl=us — US-Marktkontext
• tbs=qdr:m,sbd:1 — letzter Monat, nach Datum sortiert
• udm=14 — klassische Web-Ergebnisse (keine AI Overviews)
• pws=0 — Personalisierung aus

Programmgesteuert können Sie das mit curl bauen:

curl -L -G 'https://www.google.com/search' \
  --data-urlencode 'q=site:competitor.com intitle:pricing' \
  --data-urlencode 'hl=en' \
  --data-urlencode 'gl=us' \
  --data-urlencode 'tbs=qdr:m,sbd:1' \
  --data-urlencode 'udm=14' \
  --data-urlencode 'pws=0' \
  -H 'User-Agent: Mozilla/5.0'

Oder mit Python:

import requests

params = {
    "q": "site:competitor.com intitle:pricing",
    "hl": "en",
    "gl": "us",
    "tbs": "qdr:m,sbd:1",
    "udm": "14",
    "pws": "0",
}

response = requests.get(
    "https://www.google.com/search",
    params=params,
    headers={"User-Agent": "Mozilla/5.0"},
    timeout=20,
)
print(response.url)

Anonyme HTTP-Anfragen an Google liefern oft JavaScript-Hüllen ohne serverseitig gerenderte Ergebnisse oder Hinweise auf ungewöhnlichen Traffic – genau hier hat browserbasierte Extraktion einen Vorteil.

SERP-Daten extrahieren, ohne einen Parser zu schreiben

Googles HTML zu parsen ist fragil. Die DOM-Struktur ändert sich häufig, Klassennamen sind verschleiert, und was Sie im Browser sehen, ist nicht immer das, was Sie in einer rohen HTTP-Antwort bekommen.

Ein einfacherer Ansatz für Nicht-Entwickler: Öffnen Sie Ihre sauber konstruierte Such-URL in Chrome und verwenden Sie dann ein browserbasiertes Extraktionstool, um strukturierte Daten direkt von der sichtbaren Seite zu ziehen. Bei Thunderbit haben wir unsere Chrome-Erweiterung genau für solche Workflows entwickelt – mit AI Suggest Fields lassen sich Spalten wie Ergebnis-Titel, Ziel-URL, Snippet-Text und sichtbare Position automatisch erkennen und dann ohne Parser in eine Tabelle extrahieren.

Das ist nicht der einzige Weg. Code-basierte Ansätze funktionieren ebenfalls, besonders wenn Sie große oder wiederkehrende Extraktionen brauchen. Aber für Ad-hoc-Recherche, Audits und einmalige Wettbewerbsanalysen vermeidet browserbasierte Extraktion die Fragilität des HTML-Parsens vollständig.

Wann Sie stattdessen eine offizielle API verwenden sollten

Ein wichtiger Hinweis zur verantwortungsvollen Nutzung.

Googles Nutzungsbedingungen verbieten automatisierten Zugriff, der Schutzmechanismen umgeht, und die Google Search Help stuft Such-Scraper und Software, die automatisierte Anfragen zur Positionsbestimmung sendet, ausdrücklich als automatisierten Traffic ein. Der Betrieb eines Google-Scrapers in Produktionsgröße setzt Sie IP-Sperren, CAPTCHAs und möglichen rechtlichen Problemen aus.

Für Suchdaten in Produktionsgröße und hohem Volumen ist der bessere Weg eine offizielle API. Die Custom Search JSON API von Google wird für neue Kunden geschlossen – bestehende Nutzer haben bis zum 1. Januar 2027 Zeit für die Umstellung, mit 100 kostenlosen täglichen Anfragen und danach 5 US-Dollar pro 1.000 Anfragen. Google empfiehlt künftig Vertex AI Search für kontrollierte Website-Suchen.

Für eigene Websites ist die Search Console Search Analytics API die First-Party-Quelle für Klicks, Impressionen, CTR und durchschnittliche Position – ganz ohne Scraping.

Verstehen Sie URL-Parameter als Diagnose- und Recherchewerkzeug: hervorragend für präzise Suchlinks, manuelle Audits und das Verständnis von Googles Suchoberfläche. Aber kein Ersatz für offizielle APIs in großem Maßstab.

Google-Suchoperatoren: Die Parameter innerhalb Ihrer Suchanfrage

Suchoperatoren leben innerhalb des q=-Parameters, sind aber unverzichtbare Begleiter von URL-Parametern. Die folgende Tabelle zeigt die von Google aktuell dokumentierten Operatoren plus einige, die in der Praxis weiterhin funktionieren:

Operator	Funktion	Beispiel
site:	Auf eine Domain beschränken	q=site:example.com+SEO
filetype:	Auf Dateityp beschränken	q=filetype:pdf+annual+report
intitle:	Wort muss im Titel vorkommen	q=intitle:pricing+SaaS
inurl:	Wort muss in der URL vorkommen	q=inurl:blog+marketing
-	Begriff ausschließen	q=apple+-fruit
""	Exakte Wortgruppe	q=%22google+search+url+parameters%22
OR	Einer von beiden Begriffen	q=scraping+OR+crawling
before:	Ergebnisse vor einem Datum	q=AI+before:2026-01-01
after:	Ergebnisse nach einem Datum	q=AI+after:2025-06-01
related:	Ähnliche Sites	q=related:hubspot.com

Die eigentliche Stärke entsteht, wenn Sie Operatoren innerhalb von q mit URL-Parametern außerhalb kombinieren:

q=site:competitor.com+intitle:pricing+after:2026/01/01&tbs=sbd:1&gl=us&udm=14

Das findet Seiten auf competitor.com mit „pricing“ im Titel, veröffentlicht nach Januar 2026, nach Datum sortiert, im US-Markt und mit klassischen Web-Ergebnissen. Eine sehr präzise Competitive-Intelligence-Abfrage, die ausschließlich aus URL-Parametern und Operatoren besteht.

Google weist darauf hin, dass site:-Ergebnisse nicht vollständig garantiert sind – behandeln Sie eine site:-Suche also nicht als vollständiges Inventar indexierter Seiten.

Verantwortungsvolle Nutzung: Googles Nutzungsbedingungen und Ratenlimits

Kurz, aber wichtig.

Googles Nutzungsbedingungen verbieten missbräuchlichen Zugriff und das Umgehen von Schutzmaßnahmen. Google Search Help nennt Such-Scraper und automatisierte Ranking-Software ausdrücklich als Beispiele für automatisierten Traffic. Verstöße können zu IP-Sperren, CAPTCHAs, Kontoeinschränkungen und möglicherweise rechtlichen Schritten führen.

URL-Parameterwissen ist am besten geeignet für: präzise Such-URLs manuell bauen, bookmarkbare Suchlinks für Ihr Team erstellen, kleine Audits im Browser durchführen und verstehen, wie Googles Suchoberfläche funktioniert. Für automatisierte Arbeit in Produktionsgröße nutzen Sie Googles offizielle APIs – oder einen lizenzierten Drittanbieter für Suchdaten wie die Brave Search API.

Bei Thunderbit ist unsere Browser-Erweiterung für nutzerinitiierte Extraktion sichtbarer Seiten gebaut – nicht für automatisierte Google-Abfragen in hohem Volumen. Das ist ein wichtiger Unterschied.

Zentrale Erkenntnisse: Ihr Google-Such-URL-Toolkit für 2026

Die Kurzfassung:

• Nutzen Sie gl + hl für Lokalisierungssignale und verlassen Sie sich während der Weiterleitungs-Migration von Google nicht nur auf ccTLDs
• Testen Sie udm und tbm, wo es relevant ist – keines von beiden ist eine stabile, versionierte Consumer-API
• udm=14 kann klassische Web-Ergebnisse ohne AI Overviews anfordern, aber Google kann den Parameter entfernen oder umschreiben
• Verwenden Sie uule für Geo-Targeting auf Stadtebene mit der oben beschriebenen protobuf-Kodierungsformel
• Beherrschen Sie tbs für präzise Datumsfilter (cdr:1,cd_min:...,cd_max:...), Sortierung nach Datum (sbd:1) und Verbatim-Suche (li:1)
• Achten Sie auf Parameterkonflikte: gl vs. uule, tbm vs. udm, lr vs. cr
• num=100 ist unzuverlässig und nie offiziell unterstützt worden – verwenden Sie start in 10er-Schritten als sicherere Standardlösung
• Für strukturierte SERP-Daten nutzen Sie browserbasierte Tools wie Thunderbit für Ad-hoc-Arbeiten oder offizielle APIs für den Produktionsmaßstab
• Beachten Sie Googles Nutzungsbedingungen – URL-Parameter sind ein Recherchewerkzeug, keine Scraping-Lizenz

Google verändert Parameter weiterhin ohne Ankündigung. Ich halte diese Referenz aktuell, wenn sich etwas ändert – speichern Sie sie und schauen Sie wieder vorbei.

Mehr erfahren

• 9 beste SEO-APIs für 2026 (mit realen Kosten pro Anfrage)
• Wie man Search-Engine-Scraping meistert: Ein vollständiger Leitfaden
• Die 27 besten Tools zur Analyse und Überwachung von Website-Rankings
• Wie man Web-Scraper-Paginierung für effiziente Extraktion nutzt
• Was ist Search Automation? Vorteile, Tools und Strategien

FAQs

Was macht udm=14 in einer Google-Such-URL?

udm=14 kann eine klassische Web-Ergebnisseite ohne AI Overviews anfordern, weshalb es bei SEO-Profis so beliebt ist. Es ist reverse-engineert und kein offiziell dokumentierter Google-Vertrag; je nach Sitzung, Konto, Region, Client und Experimentkohorte kann Google den Parameter entfernen oder umschreiben.

Funktioniert der num-Parameter 2026 noch?

Verlassen Sie sich nicht darauf. Google hat num=100 seit September 2025 nicht mehr zuverlässig berücksichtigt, und ein Sprecher sagte, der Parameter sei nie offiziell unterstützt worden. Verwenden Sie start in 10er-Schritten als sicherere Standardlösung für die Paginierung und prüfen Sie die zurückgegebene Trefferzahl, da Google die Antwort weiterhin umschreiben oder einschränken kann.

Wie simuliere ich eine Google-Suche aus einer bestimmten Stadt?

Verwenden Sie den uule-Parameter mit einem kodierten Städtenamen. Der Kodierungsabschnitt oben enthält den protobuf-basierten Algorithmus und ein Python-Beispiel. Sie benötigen den kanonischen Google-Ortsnamen (verfügbar über die Geo-Targeting-Daten der Google-Ads-API), den Sie in einen uule-Wert wie uule=w+CAIQICIeNew+York,New+York,United+States kodieren.

Was ist der Unterschied zwischen gl, lr und cr?

Diese drei Parameter steuern unterschiedliche Aspekte von Geo- und Sprach-Targeting. gl simuliert Ihren Suchstandort auf Länderebene (beeinflusst Ranking und lokale Ergebnisse). lr beschränkt Ergebnisse auf Seiten, die in einer bestimmten Inhaltssprache geschrieben sind. cr beschränkt Ergebnisse auf Seiten, die in einem bestimmten Land gehostet werden. Sie können kombiniert werden, aber widersprüchliche Kombinationen wie lr=lang_en + cr=countryJP reduzieren die Ergebnisse drastisch.

Kann ich mehrere tbs-Werte in einer URL kombinieren?

Ja – trennen Sie sie mit Kommas innerhalb eines einzelnen tbs-Parameters. Zum Beispiel filtert tbs=qdr:m,sbd:1 auf den letzten Monat und sortiert nach Datum (neueste zuerst). Sie können auch li:1 für den Verbatim-Modus hinzufügen: tbs=qdr:m,sbd:1,li:1. Die tbs-Syntax ist undokumentiert, daher sollten Sie Ihre spezifischen Kombinationen testen, um sicherzugehen, dass sie wie erwartet funktionieren.