Regex dans Search Console : filtrer sans se tromper

Le filtre standard de Search Console — « contient », « correspond exactement », « ne contient pas » — suffit pour une recherche ponctuelle, mais il devient vite insuffisant dès qu'on veut isoler un ensemble de requêtes qui partagent une logique plutôt qu'une chaîne de caractères précise. C'est là qu'intervient l'option « Personnalisé (regex) », disponible sur les dimensions Requête et Page du rapport Performances. Bien utilisée, elle transforme une exploration approximative en analyse répétable : le trafic de marque isolé en un clic, toutes les requêtes formulées comme une question, toutes les URL d'une même famille de pages, ou l'inverse — tout ce qui n'entre dans aucune de ces catégories.

Le problème n'est pas de savoir qu'un filtre regex existe : c'est que le moteur qui l'interprète, RE2, n'est pas un moteur de regex complet. Il refuse silencieusement certaines syntaxes qu'on utiliserait par réflexe dans un éditeur de texte ou un script, et rien dans l'interface ne le signale autrement qu'en renvoyant zéro résultat. Cet article couvre les motifs qui fonctionnent réellement dans ce rapport, pas la syntaxe regex en général.

Le moteur regex de Search Console n'est pas celui que vous connaissez

Search Console utilise RE2, la bibliothèque d'expressions régulières développée par Google et employée dans plusieurs de ses produits internes. RE2 a été conçue pour garantir un temps d'exécution prévisible sur de gros volumes de données, ce qui a un prix : elle n'implémente pas certaines constructions présentes dans PCRE, le moteur derrière la plupart des langages de script.

Concrètement, dans le filtre Requête ou Page de Search Console, les conséquences pratiques sont les suivantes.

• Pas de références arrière (du type \1, \2) : impossible de repérer une chaîne qui se répète deux fois dans la même requête.
• Pas d'assertions anticipées ou rétrospectives (lookahead, lookbehind) : impossible de dire « ce mot, seulement s'il est suivi de tel autre ».
• Les groupes non capturants, l'alternance avec |, les classes de caractères entre crochets, les quantificateurs *, + et {2,4}, ainsi que les ancres ^ et $ fonctionnent normalement.
• La correspondance n'exige pas de couvrir toute la chaîne : un motif sans ancre matche dès qu'il trouve la sous-chaîne quelque part dans la requête ou l'URL, exactement comme un « contient » élargi.

Séparer le trafic de marque du trafic hors marque

Le motif le plus utile du rapport est aussi le plus simple : une alternance des variantes de votre marque, ancrée en début de chaîne pour éviter les correspondances partielles, du type ^(marque|marque\.com|ma marque)\b.

Si votre marque est un mot courant du champ lexical — une agence appelée « Signal », par exemple — l'ancre de début seule ne suffit pas : une requête comme « signal faible seo » matchera aussi. Ajoutez une limite de mot (\b) après le dernier terme, et testez le motif inverse pour vérifier qu'il n'attrape rien d'indésirable. Pour obtenir le hors-marque, inutile de chercher une négation en regex : appliquez le même motif avec le sélecteur « Exclut » plutôt que « Correspond à ». C'est l'approche qui contourne l'absence de lookahead négatif dans RE2, et elle revient plus loin dans cet article.

Une variante utile : repérer les fautes de frappe et variantes orthographiques de la marque avec une classe de caractères, par exemple marqu[eé] pour couvrir « marque » et une graphie accentuée voisine, ou une alternance explicite si les variantes sont trop éloignées pour un motif court.

Isoler les requêtes formulées comme des questions

Les requêtes conversationnelles — assistants vocaux, recherches formulées à voix haute, autocomplétion — ont souvent une structure reconnaissable même sans point d'interrogation dans les données de Search Console : les mots interrogatifs suffisent à eux seuls à les repérer.

Un motif d'alternance ancré en début de chaîne, ^(comment|pourquoi|quand|où|combien|quel|quelle|qui|que|est-ce que)\b, capture les requêtes qui commencent par un marqueur interrogatif. Il en manque volontairement une partie : « seo combien de temps » ne commence pas par un mot interrogatif, alors qu'elle formule bien une question. Pour ce cas, retirez l'ancre de début et acceptez que le motif devienne plus permissif — vous échangez de la précision contre du rappel, un compromis à faire consciemment plutôt qu'à découvrir après coup dans les chiffres.

Le point d'interrogation littéral lui-même est utilisable comme motif, mais il doit être échappé : \?. Sans l'échappement, ce caractère est interprété comme un quantificateur — zéro ou une occurrence du caractère précédent — pas comme le symbole. C'est l'erreur la plus fréquente chez qui découvre ce filtre.

Une question annexe se pose vite pour du français : de nombreux utilisateurs tapent sans accents, par habitude de clavier ou par vitesse d'usage mobile. Une requête réellement saisie comme « ou trouver un freelance seo » n'a pas de ù, et un motif qui n'attend que « où » avec l'accent la manque entièrement. La parade la plus fiable est d'inclure les deux graphies dans l'alternance, par exemple une classe de caractères [uù] à la position concernée, plutôt que de multiplier les alternances complètes. C'est un ajustement mineur en apparence, mais il change sensiblement le volume de requêtes captées sur les mots interrogatifs qui portent un accent en français, où en tête de liste.

Regrouper les URL par famille de pages

Sur la dimension Page, le même principe sert à comparer des familles de contenu entre elles sans les exporter une par une. Trois usages reviennent constamment.

Le point qu'on oublie presque toujours : le point (.) dans un nom de domaine est un métacaractère en regex, il matche n'importe quel caractère, donc exemple.com non échappé matche aussi des variantes à un caractère de distance qui n'existent pas vraiment. Ça ne casse rien dans la plupart des cas d'usage — le domaine réel n'a pas de variante à un caractère de distance — mais ça vaut la peine d'échapper systématiquement le point (exemple\.com) dès que le motif sert de base à un filtre réutilisé plusieurs fois.

• Comparer un dossier à un autre : ^https://exemple\.com/blog/ face à ^https://exemple\.com/produits/.
• Isoler une profondeur d'URL, par exemple les pages à trois niveaux : ^https://exemple\.com/[^/]+/[^/]+/[^/]+/?$ — chaque [^/]+ consomme un segment de chemin sans franchir de slash.
• Repérer un paramètre d'URL précis, en échappant le point d'interrogation qui introduit la query string : \?utm_source= ou \?p=\d+ pour les pages qui exposent un identifiant numérique dans l'URL.

Construire et tester un motif avant de l'appliquer

Search Console n'affiche aucun aperçu du nombre de résultats pendant la saisie du motif : il faut valider le filtre pour voir s'il retient une ligne ou mille. Itérer directement dans l'interface coûte donc un aller-retour à chaque ajustement, ce qui devient pénible dès qu'un motif comporte plusieurs alternances ou plusieurs groupes.

La méthode la plus rapide consiste à préparer le motif dans un testeur regex externe configuré sur le mode Go plutôt que PCRE ou JavaScript, puisque RE2 est la bibliothèque d'expressions régulières du langage Go et en partage exactement les règles. Coller quelques dizaines de requêtes ou d'URL réelles, extraites d'un export du même rapport, permet de vérifier en quelques secondes qu'un motif capture ce qui est attendu et rien de plus, avant de le reporter dans Search Console où il s'appliquera à l'ensemble des données.

Ce détour évite aussi une confusion fréquente : un testeur en mode PCRE accepte des motifs avec lookahead ou référence arrière qui semblent fonctionner localement, mais qui échoueront silencieusement une fois collés dans Search Console. Choisir le bon mode de test dès le départ élimine ce décalage plutôt que de le découvrir après coup dans un rapport qui renvoie zéro résultat sans qu'aucun message n'explique pourquoi.

Exclure le bruit sans négation : le rôle du sélecteur « Exclut »

RE2 n'a pas de lookahead négatif, donc un motif du type « tout sauf X » n'existe pas en une seule expression dans ce moteur. La solution n'est pas syntaxique, elle est dans l'interface : chaque filtre regex propose un sélecteur « Correspond à » ou « Exclut », et c'est ce sélecteur qui porte la négation, pas le motif.

Pour nettoyer un rapport des pages internes de recherche, des pages de test ou des paramètres de tracking, construisez le motif positif qui les décrit, puis appliquez-le en mode « Exclut ».

L'avantage de séparer motif et sélecteur : le même motif positif sert aussi bien à isoler ce trafic pour l'auditer (« Correspond à ») qu'à le retirer d'une vue d'ensemble (« Exclut »), sans jamais le réécrire.

• \?s= ou /recherche\? pour les résultats de recherche interne indexés par erreur.
• /(staging|test|preprod|dev)\. pour un sous-domaine ou dossier d'environnement de préproduction.
• (utm_|gclid|fbclid)= pour les URL suivies avec des paramètres de campagne qui dupliquent une même page en apparence.

Combiner plusieurs filtres regex dans un même rapport

Search Console permet d'empiler plusieurs filtres, et ils s'appliquent en ET logique : un filtre regex sur la Requête et un filtre regex sur la Page réduisent le rapport à l'intersection des deux, pas à leur somme. C'est la méthode pour répondre à des questions à deux dimensions : « quelles requêtes de type question amènent sur les pages du dossier /blog/ » se construit avec un filtre Requête (le motif interrogatif vu plus haut) et un filtre Page ancré sur ce dossier, posés simultanément.

Le mode comparaison (deux périodes ou deux segments côte à côte) conserve les filtres regex actifs, ce qui permet de suivre l'évolution d'un segment précis dans le temps plutôt qu'un instantané. C'est la différence entre « ce segment a-t-il progressé » et « ce segment existe » — la seconde question se répond une fois, la première mérite un filtre qu'on revisite régulièrement.

Les filtres regex ne s'appliquent en revanche qu'aux dimensions Requête et Page : impossible de filtrer l'Appareil ou le Pays avec une expression régulière, ces deux dimensions n'offrant que leurs listes de valeurs fixes.

Les pièges qui faussent silencieusement vos résultats

Trois erreurs reviennent dans la plupart des rapports mal filtrés, et aucune ne produit d'erreur visible : le rapport affiche simplement les mauvais chiffres, avec la même confiance que les bons.

Le réflexe qui évite les trois : après avoir écrit un motif, l'appliquer d'abord seul, regarder la liste des requêtes ou des pages qu'il retient, et vérifier à l'œil qu'aucune n'y figure par accident avant de l'empiler avec d'autres filtres.

• Oublier les ancres. Un motif « marque » sans ^...$ ni \b matche toute requête qui contient la sous-chaîne, y compris à l'intérieur d'un autre mot : « démarque » ou « remarquable » entrent alors dans le trafic de marque sans que rien ne l'indique dans l'interface.
• Ne pas gérer les accents. La classe raccourcie pour les caractères de mot (\w) matche les caractères alphanumériques de base, pas les lettres accentuées : un motif censé isoler un mot français entier via \b peut se comporter de façon inattendue autour d'un é, è ou à en début ou fin de mot. Le plus sûr reste de tester le motif sur un échantillon réel de requêtes plutôt que de faire confiance à la théorie.
• Confondre correspondance partielle et correspondance exacte. Sans ancres, un filtre destiné à isoler « chaussure » au singulier remonte aussi « chaussures », « rechausser » et toute requête qui contient la sous-chaîne. Rarement un problème pour un reporting large, mais ça fausse une comparaison fine entre deux formes précises d'une même requête.