Paramètres d’URL de recherche Google : ce qui fonctionne encore en 2026

Vers septembre 2025, plusieurs outils SEO et scripts personnalisés ont cessé de fonctionner en douce. La raison ? Google a arrêté de prendre en charge de façon fiable le paramètre num=100, sur lequel les utilisateurs avancés s’appuyaient depuis des années pour afficher 100 résultats par page. Il n’y a eu aucune annonce officielle de dépréciation — seulement un porte-parole disant à Search Engine Land que ce paramètre n’était « pas officiellement pris en charge ». À peu près au même moment, Google a lancé davantage de modes udm en parallèle des verticaux tbm plus anciens, a annoncé que les domaines nationaux redirigeraient progressivement vers google.com, et a indiqué que les Aperçus IA atteignaient plus de 2,5 milliards d’utilisateurs mensuels.

Si tu construis des URL de recherche, suis des positions ou automatises des recherches à l’aide des paramètres d’URL de Google, il y a de fortes chances que certains de tes workflows soient déjà dégradés sans que tu t’en rendes compte. Chez Thunderbit, nous avons passé en revue la documentation actuelle de Google, les annonces récentes, des références rétroconstruites et des vérifications en conditions réelles pour distinguer les contrôles stables des paramètres contextuels. Le résultat : un guide daté et à tester avant déploiement sur les paramètres d’URL de recherche Google qui comptent en 2026, y compris les correspondances tbm/udm, la formule d’encodage uule pour le ciblage géographique au niveau de la ville, et les conflits de paramètres qui peuvent te faire perdre des heures de débogage.

Que sont les paramètres d’URL de recherche Google ?

Diagram of a Google search URL showing the query, language, market, time, and result-type controls

Les paramètres d’URL de recherche Google sont les paires clé=valeur qui apparaissent après le ? dans une URL de recherche Google. Ils contrôlent tout : ce que tu cherches, le pays dont tu vois les résultats, et le type de résultats affichés — images, actualités ou liens bleus classiques.

Voici comment se décompose une URL Google typique :

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

URL de base : https://www.google.com/search
? démarre la chaîne de requête
q=best+crm+software correspond à la requête de recherche (les espaces sont codés en +)
& sépare chaque paramètre
hl=en définit la langue de l’interface en anglais
gl=us indique à Google d’afficher les résultats comme si tu étais aux États-Unis
tbs=qdr:m filtre les résultats du dernier mois

Une distinction importante : les opérateurs de recherche comme site:, filetype: et intitle: s’intègrent dans la valeur de q=. Ils font partie de ta requête. Les paramètres d’URL comme gl, hl et tbs sont des clés séparées dans l’URL qui contrôlent la manière dont Google traite et affiche les résultats. Les deux comptent, et ils fonctionnent ensemble — mais ce sont deux choses différentes.

Google n’a jamais publié de spécification unique et versionnée pour ces paramètres. Certains viennent du formulaire de recherche avancée, d’autres de l’API Custom Search, et d’autres encore ont été rétroconstruits à partir de l’observation des propres URL de Google. Cela veut dire que l’article que tu lis repose sur des tests en direct et sur des comportements documentés, et non sur un contrat d’API officiel.

Pourquoi les paramètres d’URL de recherche Google comptent en 2026

Les paramètres d’URL ne concernent pas seulement les développeurs. Toute personne en SEO, marketing, sales, opérations ou produit qui doit comprendre ce que Google affiche pour une requête précise, dans un marché précis, à un moment précis — ces paramètres sont sa boîte à outils.

Voici un aperçu rapide des profils concernés et de leur intérêt :

Cas d’usage	Qui en profite	Paramètres clés
Suivi de position SEO dans plusieurs pays	Équipes SEO & Marketing	`gl`, `hl`, `uule`, `pws`
Veille concurrentielle par date	Équipes stratégie & opérations	`tbs`, `q` avec `site:`
Suivi publicitaire sur des marchés précis	Équipes média payant	`gl`, `hl`, `udm`
Audits SEO locaux (niveau ville)	Commerçants locaux	`uule`, `gl`
Recherche de contenu / suivi des tendances	Équipes contenu	`tbs` (filtres de date), `lr`
Alimentation d’apps IA/LLM avec des données de recherche	Équipes produit & data	Plusieurs paramètres + extraction structurée

Trois grands changements rendent 2026 nettement différent :

num=100 n’est plus fiable. L’ancienne astuce pour afficher 100 résultats par page a cessé de fonctionner de façon fiable en septembre 2025. Google ne l’a pas formellement dépréciée ; un porte-parole a simplement indiqué qu’elle n’avait jamais été officiellement prise en charge.
Les redirections des ccTLD sont une migration, pas un basculement terminé. Google a annoncé en avril 2025 que les domaines nationaux (google.co.uk, google.de, etc.) redirigeraient progressivement vers google.com. Google n’a pas publié d’avis de fin de migration, donc il ne faut pas supposer que tous les marchés se comportent déjà de la même façon.
Les Aperçus IA ont changé la SERP. Google indique que les Aperçus IA atteignent plus de 2,5 milliards d’utilisateurs mensuels et sont disponibles dans plus de 200 pays et territoires. Les modes udm rétroconstruits peuvent modifier la surface de résultats dans certains contextes, mais ils ne constituent pas un interrupteur garanti pour les Aperçus IA.

Si tes workflows n’ont pas été mis à jour pour tenir compte de ces changements, tu obtiens probablement des résultats dégradés ou trompeurs sans même t’en rendre compte.

Fiche mémo des paramètres d’URL de recherche Google (2026)

Avant d’entrer dans le détail, le tableau de référence ci-dessous est la liste la plus à jour que j’ai pu rassembler. Garde-la sous la main.

Paramètre	Rôle	Exemple	Statut
`q`	Requête de recherche (accepte des opérateurs à l’intérieur)	`q=best+crm+software`	✅ Actif
`hl`	Langue de l’interface	`hl=en`, `hl=ja`	✅ Actif
`gl`	Contexte pays/marché	`gl=us`, `gl=jp`	✅ Actif
`lr`	Limiter les résultats à une langue de contenu	`lr=lang_en`	✅ Actif
`cr`	Limiter les résultats à un pays d’hébergement	`cr=countryUS`	✅ Actif
`start`	Décalage de pagination	`start=10` (page 2)	✅ Actif
`num`	Nombre de résultats par page (anciennement)	`num=100`	⚠️ Non officiellement pris en charge ; peu fiable depuis sept. 2025
`udm`	Mode de contenu contextuel	`udm=14` (web classique)	⚠️ Rétroconstruit ; varie selon le contexte
`tbm`	Vertical de recherche	`tbm=isch` (images)	⚠️ Encore observé ; à tester avec `udm`
`tbs`	Filtres temporels, tri, verbatim	`tbs=qdr:w`	✅ Actif
`safe`	Contrôle SafeSearch	`safe=active`	✅ Actif
`filter`	Filtrage des résultats dupliqués	`filter=0`	✅ Actif (observé)
`nfpr`	Désactiver l’auto-correction	`nfpr=1`	✅ Actif (observé)
`pws`	Désactiver la personnalisation	`pws=0`	✅ Actif
`uule`	Ciblage géographique au niveau ville/DMA	`uule=w+CAIQICI...`	✅ Actif (rétroconstruit)
`as_q`, `as_epq`, `as_eq`, etc.	Champs du formulaire de recherche avancée	Divers	✅ Actif
`as_sitesearch`	Limiter à un domaine (recherche avancée)	`as_sitesearch=example.com`	✅ Actif
`as_filetype`	Limiter à un type de fichier (recherche avancée)	`as_filetype=pdf`	✅ Actif
`ie`, `oe`	Encodage d’entrée/sortie	`ie=UTF-8`	✅ Actif (rarement nécessaire)
`kgmid`, `si`, `ibp`	Entité Knowledge Graph / vue de fonctionnalité	Divers	⚠️ Contextuel (à éviter en usage général)
`ei`, `ved`, `sxsrf`, `sclient`	Session / suivi / télémétrie	Divers	🔒 Interne (à ignorer)
`gbv`	Vue HTML simplifiée (anciennement)	`gbv=1`	❌ Peu fiable en 2026

Retire ei, ved, sxsrf et sclient de toutes les URL que tu enregistres ou partages. Ce sont des états de session et de télémétrie ajoutés automatiquement par Google — ils n’ont aucune utilité pour construire des URL de recherche.

Les principaux paramètres d’URL de recherche Google qui fonctionnent encore

Je les ai testés en direct à la mi-2026. Ce sont ceux que tu utiliseras le plus souvent.

q — Votre requête de recherche

Le paramètre q contient les termes recherchés. Les espaces sont encodés en + ou %20. C’est ici que se trouvent les opérateurs de recherche documentés par Google : ils vont à l’intérieur de la valeur q, et non comme paramètres d’URL séparés.

Quelques exemples :

Expression exacte : q=%22google+search+url+parameters%22
Restreint à un site : q=site%3Aexample.com+pricing
Type de fichier : q=filetype%3Apdf+annual+report+2026
Combiné : q=site%3Acompetitor.com+intitle%3Apricing+after%3A2026%2F01%2F01

Encode toujours l’intégralité de la valeur de requête. Les guillemets, deux-points et barres obliques doivent être correctement encodés pour éviter de casser l’URL.

hl — Langue de l’interface

hl contrôle la langue de l’interface Google (boutons, libellés, titres « People also ask ») et influence les résultats que Google privilégie. Il utilise des codes ISO 639-1 comme en, fr, de, ja, ou des balises BCP 47 comme en-gb ou pt-br.

hl ne force pas tous les documents de résultats à être dans cette langue. C’est un signal fort, mais Google peut toujours afficher des résultats dans d’autres langues s’ils sont très pertinents. Pour restreindre la langue du contenu, utilise lr.

gl — Pays / géolocalisation

gl simule le pays depuis lequel tu effectues la recherche, à l’aide des codes ISO 3166-1 alpha-2 (us, gb, jp, de). Avec la migration progressive des ccTLD vers google.com, gl devient désormais le principal moyen d’obtenir des résultats spécifiques à un pays.

Une même requête avec différentes valeurs de gl peut renvoyer des résultats, des extraits optimisés et des packs locaux totalement différents. Par exemple, q=best+bank&gl=us et q=best+bank&gl=jp n’afficheront pas du tout les mêmes banques.

Astuce : associe toujours gl à hl pour obtenir des résultats localisés plus fiables. Utiliser gl=jp avec hl=en donne des résultats du marché japonais dans une interface anglaise — très utile pour les audits SEO internationaux.

lr et cr — Restriction de langue et restriction par pays

On les confond tout le temps, pourtant la différence est importante :

lr=lang_en limite les résultats aux pages rédigées en anglais (langue du contenu)
cr=countryUS limite les résultats aux pages hébergées aux États-Unis (localisation du serveur / rattachement pays)
gl=us simule une recherche depuis les États-Unis (impacte le classement, les résultats locaux, les annonces)

lr et cr sont tous deux disponibles via le formulaire de recherche avancée. Attention aux combinaisons : lr=lang_en + cr=countryJP signifie « pages en anglais hébergées au Japon », un ensemble très restreint. On y revient dans la section des conflits.

start — Pagination

start=10 demande des résultats à partir de la 11e position (page 2), start=20 pour la page 3, et ainsi de suite. Comme num=100 n’est plus fiable, incrémenter start par 10 reste l’option la plus sûre — mais Google peut encore réécrire ou limiter la pagination.

L’ancienne astuce num=100&start=0 pour récupérer une page complète de 100 résultats ne fonctionne plus. Si tes scripts contiennent encore num, supprime-le : il est ignoré en silence.

pws — Désactiver la personnalisation

pws=0 demande à Google de désactiver la personnalisation liée au compte. C’est essentiel pour le suivi de position SEO, où tu veux des résultats qui ne soient pas biaisés par ton historique, tes clics passés ou tes préférences de compte.

Attention : pws=0 réduit la personnalisation mais ne supprime pas tous les facteurs contextuels. Google indique que les résultats peuvent encore varier selon le moment, la localisation, la langue et l’appareil. Il n’existe pas de SERP Google totalement « neutre ».

safe et filter — SafeSearch et filtrage des doublons

safe=active active SafeSearch ; safe=off le désactive. Note que les paramètres du compte, les règles administratives, la configuration réseau ou les lois locales peuvent passer avant ce paramètre.
filter=0 désactive le filtrage des résultats dupliqués de Google. Utile lorsque tu veux voir tous les résultats disponibles, y compris les quasi-doublons que Google regrouperait normalement.

nfpr — Désactiver l’auto-correction

nfpr=1 empêche Google de réécrire de force ta requête lorsqu’il pense que tu as fait une faute. C’est pratique pour suivre des noms de marque avec une orthographe atypique, du jargon technique ou des requêtes volontairement mal orthographiées que des concurrents ciblent.

Note que nfpr=1 ne bloque que la réécriture forcée. Pour un contrôle plus large — désactivation des synonymes, des corrections orthographiques et d’autres modifications automatiques — utilise tbs=li:1 (mode verbatim), que je détaille plus bas dans la section tbs.

La migration de tbm vers udm : ce qui a changé et quoi utiliser maintenant

C’est l’un des plus gros changements de paramètres de ces dernières années — et l’un des plus faciles à mal interpréter.

tbm a longtemps servi à basculer entre les verticaux de recherche Google — images, actualités, vidéo, shopping — pendant plus d’une décennie. Google a aussi introduit un système numérique udm avec des modes qui se recoupent et d’autres supplémentaires. Comme Google n’a pas publié de registre stable destiné aux utilisateurs, considère cela comme un mapping contextuel plutôt que comme un remplacement propre et achevé.

Tableau complet de correspondance tbm → udm

Les correspondances ci-dessous combinent le comportement observé de l’interface et des vérifications en direct datées du 12 août 2026. Plusieurs valeurs ont été supprimées ou réécrites dans les requêtes anonymes, donc chaque ligne doit être testée dans le compte, la région et le client où elle sera utilisée :

Ancien paramètre	Ancienne valeur	Nouveau paramètre	Nouvelle valeur	Statut
`tbm=lcl`	Lieux/Local	`udm=1`	Lieux/Local	⚠️ Contextuel
`tbm=isch`	Images	`udm=2`	Images	⚠️ Contextuel
`tbm=vid`	Vidéos	`udm=7`	Vidéos	⚠️ Contextuel
`tbm=nws`	Actualités	`udm=12`	Actualités	⚠️ Contextuel
—	—	`udm=14`	Web classique (sans Aperçus IA)	🆕 Nouveau, pas d’équivalent `tbm`
—	—	`udm=18`	Forums	🆕 Nouveau, pas d’équivalent `tbm`
`tbm=shop`	Shopping	`udm=28`	Shopping	⚠️ Contextuel
`tbm=bks`	Livres	`udm=36`	Livres	⚠️ Contextuel
—	—	`udm=39`	Courtes vidéos	🆕 Nouveau, pas d’équivalent `tbm`
—	—	`udm=50`	Mode IA	🆕 Nouveau, pas d’équivalent `tbm`

Google n’a pas publié de registre stable des udm — c’est une réserve essentielle. Ces valeurs sont rétroconstruites à partir de l’observation du comportement de l’interface Google. L’acceptation des URL varie selon le compte, la région, le client, les cookies et le groupe d’expérimentation. Lors de mes tests, certaines valeurs udm étaient supprimées dans les requêtes HTTP anonymes mais fonctionnaient parfaitement dans des sessions de navigateur interactives. Il ne faut pas supposer qu’une valeur fonctionne partout.

Ce que fait udm=14 (et pourquoi les SEO l’adorent)

udm=14 est devenu une sorte de favori culte dans la communauté SEO. Android Central le décrit comme un moyen de demander une surface de résultats web classique sans Aperçus IA. Dans beaucoup de sessions, il produit une SERP traditionnelle à liens bleus, mais ce n’est ni une garantie officielle ni universelle.

Pourquoi c’est important ? Si tu fais du suivi de position ou des audits SEO, les Aperçus IA peuvent faire passer les résultats organiques sous la ligne de flottaison et compliquer l’évaluation des positions. udm=14 peut offrir une vue plus nette lorsque Google le prend en compte.

Cela dit, udm=14 n’est pas garanti dans tous les contextes. Lors de vérifications en direct le 12 août 2026, Google supprimait ou réécrivait parfois les valeurs udm selon le contexte de la requête. Les résultats varient selon la session, le compte, la région, le client et le groupe d’expérimentation.

udm=50 a été observé dans des contextes de Mode IA / résultats IA, mais il ne doit pas être présenté comme un moyen garanti de forcer un Aperçu IA pour n’importe quelle requête.

Que faire : mettre à jour vos workflows de tbm vers udm

Ma recommandation :

Nouvelles implémentations : traite udm comme une entrée expérimentale/contextuelle et prévois des solutions de repli.
Workflows existants : prends en charge et teste à la fois tbm et udm lorsque c’est pertinent, au lieu de supposer qu’une migration est totalement achevée.
Ne combine jamais les deux : lorsque tbm et udm sont tous deux présents dans une URL, le comportement devient imprévisible. Dans mes tests, Google supprimait parfois les deux et renvoyait une requête web classique. Plus de détails dans la section sur les conflits.

La syntaxe complète de tbs : plages de dates personnalisées, tri par date et mode verbatim

tbs est l’un des paramètres les plus puissants de la boîte à outils des URL de recherche Google, et la plupart des guides n’en effleurent que la surface. Il gère les filtres temporels, le tri par date, le mode verbatim, et plus encore — le tout dans une seule valeur séparée par des virgules.

Filtres temporels standards

Valeur `tbs`	Signification	Fragment d’URL exemple
`qdr:h`	Dernière heure	`&tbs=qdr:h`
`qdr:d`	Dernières 24 heures	`&tbs=qdr:d`
`qdr:w`	Dernière semaine	`&tbs=qdr:w`
`qdr:m`	Dernier mois	`&tbs=qdr:m`
`qdr:y`	Dernière année	`&tbs=qdr:y`

Ce sont les bases que la plupart des guides couvrent. Mais tbs peut aller bien plus loin.

Plages de dates personnalisées

Tu as besoin de résultats sur une période précise ? Utilise la syntaxe 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

Cela filtre les résultats que Google associe à des dates comprises entre le 1er janvier et le 1er juin 2026. C’est extrêmement utile pour la veille concurrentielle — par exemple, « qu’ont publié les concurrents sur la tarification au T1 2026 ? » Pense simplement à encoder l’intégralité de la valeur, puisque les deux-points et les barres obliques doivent être encodés.

Note pratique : l’association des dates par Google n’est pas toujours exacte. La date affichée dans les résultats est la meilleure estimation de Google, pas nécessairement la vraie date de publication. Vérifie toujours la date sur la page de destination.

Trier par date et mode verbatim

C’est ici que ce guide va plus loin que n’importe quel autre article concurrent.

sbd:1 trie les résultats par date (les plus récents d’abord). Pris seul, c’est utile mais pas révolutionnaire. L’astuce consiste à le combiner avec des filtres de période dans une seule valeur tbs :

&tbs=qdr:m,sbd:1

Tu obtiens ainsi les résultats du dernier mois, triés par date — du plus récent au plus ancien. C’est le moyen le plus rapide de trouver ce qui vient d’être publié sur un sujet. J’utilise cette combinaison en permanence pour surveiller le contenu des concurrents.

li:1 active le mode verbatim — l’équivalent dans l’URL d’un clic sur l’outil « Verbatim » dans l’interface Google. Le mode verbatim désactive l’auto-correction, l’expansion par synonymes, les corrections orthographiques et les autres modifications automatiques de la requête.

La différence entre li:1 et nfpr=1 tient à leur portée :

nfpr=1 : supprime seulement la réécriture forcée de l’orthographe/de la requête (par exemple, empêche Google de changer « teh » en « the »)
tbs=li:1 : désactive toutes les modifications automatiques — orthographe, synonymes, termes associés, ajustements de personnalisation

Tu peux même empiler plusieurs valeurs tbs. Par exemple, tbs=qdr:m,sbd:1,li:1 donne des résultats du dernier mois, triés par date, avec correspondance verbatim. Dans mes tests, cette combinaison fonctionne, mais je recommande de vérifier avec tes requêtes spécifiques puisque la syntaxe tbs n’est pas documentée.

Comment générer un code uule pour un ciblage géographique au niveau ville

Si gl est un zoom au niveau pays, uule est un microscope au niveau ville. Pour le SEO local — vérifier ton classement à Denver par rapport à Dallas, ou ce qu’un utilisateur voit dans le quartier de Shibuya à Tokyo — gl ne suffit pas.

Aucun article de premier plan n’explique vraiment comment construire un code uule — ils mentionnent l’existence du paramètre puis passent à autre chose. Voici le détail complet.

Quand utiliser gl, uule ou cr

Paramètre	Granularité	Cas d’usage typique	Besoin d’encodage ?
`gl=us`	Niveau pays	Simulation rapide d’un pays	Non
`cr=countryUS`	Niveau pays (restriction)	Filtrer selon le pays d’hébergement	Non
`uule=w+CAIQICI...`	Niveau ville/DMA	Vérification du classement SEO local	Oui

L’algorithme d’encodage uule (étape par étape)

Le paramètre uule utilise un signal de localisation nommée encodé. Sa construction a été rétroconstruite, et non documentée officiellement par Google, mais elle a été largement validée par la communauté SEO.

L’approche la plus sûre consiste à encoder un petit payload Protocol Buffers plutôt que de s’appuyer sur le raccourci souvent copié-collé (qui peut échouer avec les caractères non ASCII). Voici la méthode :

Récupère le nom canonique Google de la localisation. Google publie des cibles géographiques avec des noms canoniques via les données de ciblage géographique de l’API Google Ads. Exemple : New York,New York,United States
Encode le nom en octets UTF-8.
Construis un petit payload protobuf avec le nom et sa longueur en octets.
Encode le payload en base64url et préfixe-le avec w+.

Voici un extrait Python qui le fait :

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

# Exemple
print(build_uule("New York,New York,United States"))
# Sortie : w+CAIQICIeTmV3IFlvcmssTmV3IFlvcmssVW5pdGVkIFN0YXRlcw

Lorsque tu l’ajoutes dans une URL, assure-toi que le + littéral de w+ est correctement encodé en %2B par ta bibliothèque URL. La plupart des implémentations URLSearchParams ou urllib.parse.urlencode s’en chargent automatiquement.

Un uule correctement construit n’est qu’un signal de localisation parmi d’autres. Il ne prime pas sur l’adresse IP, les paramètres du compte, l’appareil ou le groupe d’expérimentation. Utilise-le pour des vérifications locales indicatives, pas comme garantie absolue d’un classement exact au niveau de la ville.

Quand les paramètres d’URL de recherche Google entrent en conflit sans prévenir

Compatibility guide for combining Google search URL parameters without silent conflicts

Les combinaisons de paramètres peuvent échouer silencieusement : Google peut ignorer une entrée, réécrire l’URL ou afficher une autre surface de résultats. Les vérifications de conflit ci-dessous valent le coup d’être ajoutées à chaque workflow de liens de recherche.

Aucun article concurrent ne couvre les interactions entre paramètres. Mais si tu construis des URL de recherche avec plusieurs paramètres — et c’est probablement ton cas — tu dois savoir quelles combinaisons s’entendent bien et lesquelles se contredisent.

gl + uule : lequel l’emporte ?

Lorsque les deux sont présents, uule fournit un signal de localisation plus précis que gl. Si tu mets gl=uk et un uule pointant vers Tokyo, tu obtiendras des résultats influencés par Tokyo, et non par le Royaume-Uni.

Recommandation : si tu utilises uule, supprime carrément gl ou définis gl sur le pays correspondant à la ville ciblée par ton uule. N’envoie pas de signaux contradictoires.

tbm + udm : n’utilisez pas les deux

Lors de mes tests, quand tbm et udm étaient tous deux présents dans la même URL, Google supprimait parfois les deux et renvoyait une simple requête web. Le comportement varie selon les sessions et les comptes.

Recommandation : utilise seulement udm pour les nouvelles implémentations. Si tu dois prendre en charge d’anciens workflows, choisis l’un ou l’autre — jamais les deux.

lr + cr : un double filtrage peut renvoyer zéro résultat

C’est un piège subtil. lr=lang_en limite aux contenus en anglais. cr=countryJP limite aux pages hébergées au Japon. Les combiner revient à demander des « pages en anglais hébergées au Japon » — un sous-ensemble très réduit du web.

Recommandation : utilise l’un ou l’autre, sauf si tu as spécifiquement besoin de leur intersection. Si tu les combines, attends-toi à nettement moins de résultats.

num + start : pagination cassée

Les anciens scripts utilisant num=100&start=0 ne renvoient plus silencieusement qu’environ 10 résultats. Le paramètre num n’est plus pris en compte, mais il ne génère pas d’erreur — il est simplement ignoré.

Recommandation : retire num de toutes les URL. Fais la pagination avec start par incréments de 10 et déduplique les résultats entre les pages.

Référence rapide des conflits

Combinaison	Ce qui se passe	Recommandation
`gl` + `uule`	`uule` fournit un signal plus précis	Aligne pays et ville, ou supprime `gl`
`tbm` + `udm`	Imprévisible — les deux peuvent être supprimés	Utilise seulement `udm`
`lr` + `cr`	Restriction très forte, souvent presque aucun résultat	Utilise l’un ou l’autre
`num` + `start`	`num` ignoré, seulement ~10 résultats retournés	Supprime `num`, pagine avec `start`
`nfpr=1` + `tbs=li:1`	Contrôles liés mais non identiques	Teste ta requête spécifique
`hl` + `lr`	Langue d’interface ≠ restriction de langue du contenu	Utilise-les intentionnellement ; `hl` n’est pas un filtre de contenu

Des paramètres d’URL de recherche Google à l’extraction structurée de données

Checklist for testing Google search URL parameters before using them in a data workflow

À ce stade, tu as une URL de recherche Google précise — bonne requête, bon pays, bonne plage de dates, résultats web classiques. L’étape suivante consiste à extraire des données structurées à partir des résultats.

Que tu construises un outil de suivi des positions, surveilles des concurrents ou alimentes un workflow de recherche avec des données de recherche, voir les bons résultats n’est que la moitié du travail. Il faut aussi obtenir les titres, URLs, extraits, positions et dates dans un tableur ou une base de données.

Construire une URL de recherche Google ciblée (tout assembler)

Exemple complet combinant plusieurs paramètres :

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

Décryptage :

q=site%3Acompetitor.com+intitle%3Apricing — pages sur competitor.com avec « pricing » dans le titre
hl=en — interface en anglais
gl=us — contexte marché américain
tbs=qdr:m,sbd:1 — dernier mois, trié par date
udm=14 — résultats web classiques (sans Aperçus IA)
pws=0 — personnalisation désactivée

Tu peux construire cela par programmation avec curl :

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'

Ou avec 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)

Les requêtes HTTP anonymes vers Google renvoient souvent des enveloppes JavaScript sans résultats rendus côté serveur, ou des avertissements de trafic inhabituel — ce qui donne justement un avantage à l’extraction basée sur le navigateur.

Extraire des données SERP sans écrire de parseur

Parser le HTML de Google est un travail fragile. La structure du DOM change souvent, les noms de classes sont obscurcis, et ce que tu vois dans le navigateur n’est pas toujours ce que tu obtiens dans une réponse HTTP brute.

Une approche plus simple pour les non-développeurs : ouvre ton URL de recherche soigneusement construite dans Chrome, puis utilise un outil d’extraction basé sur le navigateur pour récupérer des données structurées depuis la page visible. Chez Thunderbit, nous avons conçu notre extension Chrome pour gérer exactement ce type de workflow — tu peux utiliser AI Suggest Fields pour identifier des colonnes comme le titre du résultat, l’URL de destination, le texte de l’extrait et la position visible, puis les extraire dans un tableur sans écrire de parseur.

Ce n’est pas la seule voie. Les approches basées sur du code fonctionnent aussi, surtout si tu dois gérer des extractions volumineuses ou répétées. Mais pour la recherche ponctuelle, les audits et l’analyse concurrentielle unique, l’extraction dans le navigateur évite complètement la fragilité du parsing HTML.

Quand utiliser plutôt une API officielle

Rappel de bon usage — et c’est important.

Les conditions d’utilisation de Google interdisent l’accès automatisé qui contourne les mesures de protection, et l’aide Google Search classe explicitement les scrapers de recherche et les logiciels envoyant des requêtes automatisées pour déterminer le classement comme du trafic automatisé. L’exploitation d’un scraper Google à l’échelle de la production t’expose à des blocages IP, des CAPTCHA et d’éventuels problèmes juridiques.

Pour des besoins de données de recherche à grande échelle, la meilleure voie est une API officielle. L’API Google Custom Search JSON n’accepte plus de nouveaux clients — les utilisateurs existants ont jusqu’au 1er janvier 2027 pour migrer, avec 100 requêtes gratuites par jour et $5 par 1 000 requêtes ensuite. Google recommande désormais Vertex AI Search pour la recherche sur site contrôlée.

Pour les sites que tu possèdes, l’API Search Analytics de Search Console est la source native pour les clics, impressions, CTR et position moyenne — sans scraping.

Considère la connaissance des paramètres d’URL comme un outil de diagnostic et de recherche : excellent pour construire des liens de recherche précis, réaliser des audits manuels et comprendre ce que Google affiche. Pas comme remplacement des API officielles à grande échelle.

Opérateurs de recherche Google : les paramètres à l’intérieur de votre requête

Les opérateurs de recherche vivent à l’intérieur du paramètre q=, mais ils sont des compagnons essentiels des paramètres d’URL. Le tableau ci-dessous couvre ceux que Google documente actuellement ainsi que quelques-uns qui fonctionnent encore en pratique :

Opérateur	Rôle	Exemple
`site:`	Limiter à un domaine	`q=site:example.com+SEO`
`filetype:`	Limiter à un type de fichier	`q=filetype:pdf+annual+report`
`intitle:`	Le terme doit apparaître dans le titre	`q=intitle:pricing+SaaS`
`inurl:`	Le terme doit apparaître dans l’URL	`q=inurl:blog+marketing`
`-`	Exclure un terme	`q=apple+-fruit`
`""`	Correspondance exacte	`q=%22google+search+url+parameters%22`
`OR`	L’un ou l’autre des termes	`q=scraping+OR+crawling`
`before:`	Résultats antérieurs à une date	`q=AI+before:2026-01-01`
`after:`	Résultats postérieurs à une date	`q=AI+after:2025-06-01`
`related:`	Sites similaires	`q=related:hubspot.com`

La vraie puissance vient du fait de combiner les opérateurs à l’intérieur de q avec les paramètres d’URL à l’extérieur :

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

Cela trouve les pages de competitor.com avec « pricing » dans le titre, publiées après janvier 2026, triées par date, sur le marché américain, avec des résultats web classiques. C’est une requête de veille concurrentielle très précise, construite entièrement à partir de paramètres d’URL et d’opérateurs.

Google précise que les résultats site: ne sont pas garantis comme exhaustifs — ne considère pas une requête site: comme un inventaire complet des pages indexées.

Bon usage : conditions d’utilisation de Google et limites de requêtes

Un rappel bref mais essentiel.

Les conditions d’utilisation de Google interdisent les accès abusifs et le contournement des mesures de protection. L’aide Google Search cite explicitement les scrapers de recherche et les logiciels d’automatisation du classement comme exemples de trafic automatisé. Enfreindre ces règles peut entraîner des blocages IP, des CAPTCHA, des restrictions de compte et éventuellement des actions juridiques.

La connaissance des paramètres d’URL est surtout utile pour : construire manuellement des URL de recherche précises, créer des liens de recherche partageables pour ton équipe, lancer des audits de petite ampleur dans un navigateur et comprendre le fonctionnement de l’interface de recherche Google. Pour l’automatisation à l’échelle de la production, utilise les API officielles de Google — ou un fournisseur tiers sous licence de données de recherche comme Brave Search API.

Chez Thunderbit, notre extension de navigateur est conçue pour l’extraction visible et initiée par l’utilisateur — pas pour l’interrogation automatisée massive de Google. C’est une distinction importante.

Points clés à retenir : votre boîte à outils 2026 des paramètres d’URL de recherche Google

Version condensée :

Utilise gl + hl pour les signaux de localisation et ne te fie pas uniquement aux ccTLD pendant la migration des redirections de Google
Teste udm et tbm lorsque c’est pertinent — aucun des deux n’est une API consommateur stable et versionnée
udm=14 peut demander des résultats web classiques sans Aperçus IA, mais Google peut le supprimer ou le réécrire
Utilise uule pour un ciblage géographique au niveau de la ville avec la formule d’encodage protobuf ci-dessus
Maîtrise tbs pour les filtres de date précis (cdr:1,cd_min:...,cd_max:...), le tri par date (sbd:1) et la recherche verbatim (li:1)
Méfie-toi des conflits de paramètres : gl contre uule, tbm contre udm, lr contre cr
num=100 est peu fiable et n’a jamais été officiellement pris en charge — utilise start par incréments de 10 comme base plus sûre
Pour des données SERP structurées, utilise des outils basés sur le navigateur comme Thunderbit pour les besoins ponctuels, ou les API officielles pour la production
Respecte les conditions d’utilisation de Google — les paramètres d’URL sont un outil de recherche, pas une autorisation de scraping

Google continue de modifier ses paramètres sans annonce. Je garderai cette référence à jour au fil des évolutions — ajoute-la à tes favoris et reviens-y régulièrement.

En savoir plus

FAQ

Que fait udm=14 dans une URL de recherche Google ?

udm=14 peut demander une surface de résultats web classique sans Aperçus IA, ce qui explique sa popularité auprès des professionnels SEO. Il s’agit d’un comportement rétroconstruit, pas d’un contrat officiel documenté par Google, et Google peut le supprimer ou le réécrire selon la session, le compte, la région, le client et le groupe d’expérimentation.

Le paramètre num fonctionne-t-il encore en 2026 ?

Ne compte pas dessus. Google a cessé de prendre en charge de manière fiable num=100 en septembre 2025, et un porte-parole a déclaré que ce paramètre n’avait jamais été officiellement pris en charge. Utilise start par incréments de 10 comme option de pagination plus sûre, et vérifie le nombre de résultats renvoyés car Google peut toujours réécrire ou limiter la réponse.

Comment simuler une recherche Google depuis une ville précise ?

Utilise le paramètre uule avec un nom de ville encodé. La section d’encodage ci-dessus fournit l’algorithme basé sur protobuf ainsi qu’un exemple Python. Il te faut le nom canonique Google de la localisation (disponible dans les données de ciblage géographique de Google Ads), que tu encodes dans une valeur uule comme uule=w+CAIQICIeNew+York,New+York,United+States.

Quelle est la différence entre gl, lr et cr ?

Ces trois paramètres contrôlent différents aspects du ciblage géographique et linguistique. gl simule ton pays de recherche au niveau national (impacte le classement et les résultats locaux). lr limite les résultats aux pages rédigées dans une langue de contenu donnée. cr limite les résultats aux pages hébergées dans un pays spécifique. Ils peuvent être combinés, mais des combinaisons contradictoires (comme lr=lang_en + cr=countryJP) réduiront fortement les résultats.

Puis-je combiner plusieurs valeurs tbs dans une seule URL ?

Oui — sépare-les par des virgules dans un seul paramètre tbs. Par exemple, tbs=qdr:m,sbd:1 filtre sur le dernier mois et trie par date (du plus récent au plus ancien). Tu peux aussi ajouter li:1 pour le mode verbatim : tbs=qdr:m,sbd:1,li:1. La syntaxe tbs n’étant pas documentée, teste tes combinaisons pour vérifier qu’elles fonctionnent comme prévu.

De la page web au tableur

Décrivez ce dont vous avez besoin — l'agent IA de Thunderbit l'extrait et l'exporte vers Excel, Google Sheets, Airtable ou Notion. Gratuit pour commencer.

Chrome Store Rating

PRODUCT HUNT#1 Product of the Week

Paramètres d’URL de Google Search : ce qui fonctionne encore en 2026