Opérateurs Google : le grand tri entre les vivants, les morts… et les zombies

Tout est parti d’un post LinkedIn que je préparais sur une astuce à base de inurl:… sauf que inurl: ne répondait plus. Qu’à cela ne tienne, je bricole un contournement avec des exclusions -intitle: et -intext:. Sauf que intext: ne répondait plus non plus. Ni allintext:. Bon. Ni une, ni deux, j’ai sorti la liste complète des opérateurs et j’ai tout testé, un par un, dans la nuit du 8 au 9 septembre 2026. Depuis la France, en conditions réelles, directement dans le navigateur.

Quitte à ne pas dormir, autant que ça serve. Et le bilan ne tient pas dans un « ça marche / ça marche plus ». Sur 16 syntaxes : 10 encore bien vivantes, 4 devenues inertes (Google les lit comme du texte brut), et surtout 2 zombies qui font semblant d’exclure. C’est cette dernière famille qui doit vous inquiéter.

Un démantèlement en douce (et personne ne re-teste)

Petit rappel de la chronologie, parce qu’elle vaut le détour. En février 2026, Jonathan Kiekbusch signalait sur LinkedIn des comportements incohérents de inurl: et intext: selon les régions : résultats partiels, écrans vides, matching noyé dans du broad match. En juin, la presse tech actait la désactivation de inurl:, sans préavis de Google. En juillet, SEOmator passait les 41 opérateurs au banc d’essai : seuls 12 appliquent encore le filtre promis. Un détail compte dans leur verdict : ils classent parmi les « morts » les opérateurs dont Google ignore le préfixe pour lancer une simple recherche en texte. Retenez cette phrase, elle décrit exactement ce que je vais vous montrer. Et en août, une documentation française mettait le doigt sur la vraie nature du phénomène : certains opérateurs ne fonctionnent plus comme des filtres, mais comme de simples « indices d’intention ». En clair, Google les lit, hoche la tête, et fait ce qu’il veut.

« C’est juste régional », vraiment ? J’ai testé sous IP US

Un point d’honnêteté avant d’aller plus loin, parce qu’il est au cœur du sujet : tout le monde n’observe pas la même chose. Plusieurs guides récents affirment encore, captures à l’appui, que inurl: ou intext: fonctionnent très bien en 2026. Ils n’ont pas forcément tort : le démantèlement s’est fait progressivement, et un article publié en début d’année a très bien pu constater un opérateur encore vivant qui, depuis, est tombé. La première explication qui vient à l’esprit, c’est une bascule régionale : Google déploierait le changement pays par pays. J’y ai cru, alors je suis allé vérifier plutôt que de le supposer.

J’ai rejoué mes requêtes-clés derrière un VPN américain, IP US, pour comparer avec mes résultats français. Verdict : rigoureusement identique. site:www.yapasdequoi.com -intext:seo me ressort ma page d’accueil « Consultant SEO technique » en tête, exactement comme en France, alors que l’exclusion devrait la faire sauter. inurl:category combiné à site: renvoie le même « did not match any documents ». Et inurl:category seul part sur le même thème « URL categories » (IBM, Zscaler, Fortinet…), preuve que l’opérateur est lu comme deux mots-clés des deux côtés de l’Atlantique.

J’ai même poussé le vice plus loin : forcer le marché américain avec &gl=us&hl=en, puis le marché français avec &gl=fr&hl=fr, toujours depuis mon IP US.L’interface bascule bien d’une langue à l’autre, mais les opérateurs ne bronchent pas : même zombie, même non-parsing dans les deux cas. La bascule régionale ne tient donc sous aucun angle : ni l’IP, ni le pays ciblé, ni la langue. La vraie variable est ailleurs, hors de portée d’un simple changement de géo : le moment du déploiement, le type de compte, ou un test A/B côté Google. Une IP américaine ne ressuscite rien.

Une réserve, parce qu’un VPN ne fait pas de moi un vrai internaute américain : mon compte Google, ma langue système et mon historique pèsent peut-être encore dans la balance. Donc je ne dis pas « ça ne marche nulle part aux États-Unis », je dis « depuis une IP US, je constate exactement le même comportement qu’en France ». Situé, daté, reproductible. Refaites-le chez vous, c’est tout l’intérêt de la démarche.

Pendant ce temps ? La majorité des cheat sheets publiées en 2026 continuent tranquillement de lister intext:, allintext: ou inurl: parmi les opérateurs « fiables ». Personne ne re-teste avant de publier. Alors on va le faire ensemble.

Le protocole (reproductible chez vous en 10 minutes)

Tests réalisés dans la nuit du 8 au 9 septembre 2026, depuis la France, sur google.com. Surtout sur ce blog, autant se servir de son propre terrain de jeu, et recoupés sur un gros e-commerce multi-locales pour les cas internationaux. Syntaxe stricte évidemment : aucun espace après les deux-points, pas de protocole dans site:. Je précise, car la moitié des « opérateurs morts » qu’on me signale sont en réalité des erreurs de syntaxe, et les symptômes sont exactement les mêmes. Deux autres règles, que plusieurs sources rappellent et que je confirme. L’opérateur OR s’écrit en majuscules, sous peine d’être lu comme un simple mot. Et au-delà de trois ou quatre opérateurs combinés, les résultats deviennent imprévisibles. On teste donc une chose à la fois.

Pour chaque opérateur douteux, j’ai prévu un test discriminant, c’est-à-dire une requête dont le verdict est binaire. Exemple : site:www.yapasdequoi.com -intitle:seo. Une bonne partie de mes pages ont « SEO » dans leur title. Si l’exclusion fonctionne, la home et la page contact doivent disparaître des résultats. Si elles restent, l’exclusion est ignorée. Pas d’interprétation possible.

Refaites ces tests depuis chez vous : le déploiement de Google s’est fait progressivement, vos résultats peuvent différer des miens selon le moment et le contexte. C’est même tout le problème, on y revient plus bas. Et petit conseil vécu : espacez vos requêtes. Une trentaine de tests d’opérateurs enchaînés m’ont valu la page « trafic exceptionnel détecté » et son captcha. Google surveille aussi ceux qui l’auditent. 😅

La matrice : vivants, non parsés, zombies

« Morts » ? Non : rétrogradés en texte brut

Précision importante sur les opérateurs marqués « non parsés », parce que le mécanisme est plus sournois qu’une simple désactivation. Prenez allintext:seo ou inurl:category tout seuls, sans site: : la requête remonte des résultats… mais sans la moindre mise en exergue du terme cherché, et en partant carrément sur le thème de la catégorisation d’URL pour le second. Google ne parse plus l’opérateur : il traite « allintext:seo » comme une chaîne de texte ordinaire et fait du matching flou dessus. Voilà pourquoi, combiné à site:, le verdict tombe à zéro résultat : aucune page du domaine ne contient littéralement le texte « allintext:seo ». Ces opérateurs ne sont pas morts, ils ont été rétrogradés en mots-clés. Ce qui rejoint parfaitement la formule « indices d’intention » relevée en août : la syntaxe est devenue du contenu de requête comme un autre.

Les zombies, ou l’art de faire semblant

Un opérateur mort, vous le voyez tout de suite : zéro résultat, message d’erreur, circulez. Un opérateur zombie, vous ne le voyez pas. Regardez cette requête :

site:www.yapasdequoi.com -intext:seo

En toute logique, elle devrait écarter toutes mes pages qui mentionnent « SEO » dans leur contenu, autrement dit… à peu près tout le site. Résultat réel : ma page d’accueil « Consultant SEO technique » arrive en première position, avec du SEO à toutes les lignes. L’exclusion est acceptée, puis silencieusement ignorée. Aucun message, aucun signal. Même verdict pour -inurl:. Deux exclusions sur le même modèle, toutes deux en trompe-l’œil, et pour la même raison de fond : l’opérateur qu’on nie (intext:, inurl:) n’est déjà plus parsé, donc le nier ne change rien.

Bonne nouvelle en revanche, et c’est un piège à éviter : l’exclusion d’une phrase exacte, elle, fonctionne très bien. site:www.yapasdequoi.com -"consultant SEO" fait bien disparaître ma page d’accueil, dont c’est le titre. Ne confondez pas les deux : -"phrase" filtre, -intext: fait semblant. La différence, c’est que la première s’appuie sur les guillemets (vivants) et la seconde sur un opérateur mort.

Alors que dans le même temps, le test discriminant sur -intitle: passe sans problème :

Concrètement, ça veut dire quoi ? Que chaque requête d’audit contenant -intext: ou -inurl: produit aujourd’hui des conclusions potentiellement fausses, avec toutes les apparences de la fiabilité. Si vous avez des requêtes sauvegardées, des scripts de veille ou des process qui s’appuient dessus, ils vous racontent des histoires depuis des semaines sans avoir changé d’apparence. Je vous laisse vérifier les vôtres, moi j’ai déjà fait le ménage dans les miens…

Le cas intext:, ou le piège du faux ami

Le cas intext: mérite son paragraphe, parce qu’il m’a fait tourner en bourrique une bonne partie de la nuit. Sur un gros e-commerce sportif qui vend pourtant des chaussures par milliers, site:www.decathlon.fr intext:chaussures ne me remonte aucune chaussure… mais des piscines et des vêtements de la marque INTEX. Google a lu « intext » comme « intex » ! Sur ce blog, à la même minute : site:www.yapasdequoi.com intext:robots me sort trois résultats parfaitement pertinents. De quoi croire à un opérateur capricieux qui marche un coup sur deux…

Sauf qu’en creusant, la vérité est ailleurs, et elle est plus retorse. intext: n’est pas parsé non plus, exactement comme inurl:. Ce qui change d’un site à l’autre, ce n’est pas l’opérateur, c’est le contenu indexé. Google traite « intext:robots » comme une chaîne de texte à chercher. Sur mon blog, plein d’articles parlent de robots.txt et de ce genre de syntaxe : il trouve à quoi raccrocher, et me remonte trois pages. Ailleurs, il se rabat sur le token le plus proche qu’il connaît, quitte à confondre « intext » avec une marque de piscines. La preuve par le contre-test : site:www.yapasdequoi.com robots (sans l’opérateur) me remonte deux fois plus de résultats que la version avec intext:. Si l’opérateur filtrait vraiment sur le corps de texte, ce serait l’inverse.

Voilà pourquoi je le classe dans les faux amis. Il fait illusion sur les sites dont le contenu parle justement de SEO ou de technique. Et il vous plante sec sur les autres. C’est peut-être le plus dangereux du lot : il donne l’impression de fonctionner. Au placard, comme les autres.

Au passage, j’ai testé les remèdes qui circulent : ni le paramètre &udm=14 (le fameux mode « Web » sans couches IA), ni le mode Verbatim (&tbs=li:1) ne ressuscitent quoi que ce soit. Le mythe du mode Web qui restaure les opérateurs ne tient pas la route.

La doc officielle, cet aveu discret

Détail savoureux découvert en croisant ma matrice avec la page officielle « Refine Google searches » (consultée le 10 septembre 2026) : Google n’y documente plus que cinq familles d’opérateurs. Les guillemets, site:, l’exclusion -mot, before:/after: et filetype:. C’est tout. Les related: et cache: d’autrefois ont disparu de la page, et ni intitle:, ni inurl:, ni intext: n’y figurent. Comparez avec le tableau ci-dessus : la doc officielle colle presque exactement à la liste des survivants. Google n’a rien annoncé, mais sa propre documentation a été élaguée en silence pour ne garder que ce qui marche. Restent quelques survivants non documentés : intitle: / -intitle:, mais aussi le OR, qui fonctionnent encore sans figurer nulle part dans la page. Officieusement tolérés, donc. Les prochains sur la liste ? Je re-testerai.

Petit piège au passage sur before:/after:, et là c’est la doc officielle elle-même qui le dit : le filtre porte sur la date de last updated, autrement dit la dernière mise à jour du document, pas sa date de publication. Vérifié sur mon site : before:2015-01-01 ne remonte qu’un seul de mes articles de la période 2011-2014, un billet de 2011 jamais retouché depuis. Les autres, modifiés lors d’une refonte, sont passés de l’autre côté de la barrière temporelle. En audit de fraîcheur ou d’historique, gardez-le en tête, sinon les conclusions partent de travers. À noter, les deux formats de date fonctionnent : before:2015-01-01 comme before:2015/01/01, et l’année seule (before:2015) suffit.

Remplacer inurl: : la technique qui tient la route

Besoin classique : isoler un type de page via son dossier d’URL, sans crawler. Prenons ce blog, un WordPress avec ses archives dans /category/. La requête inurl:category est morte, on l’a vu. Mais celle-ci fonctionne :

site:www.yapasdequoi.com category

Pourquoi cette requête fonctionne

Pourquoi ça marche ? Parce que « category » est un token technique en anglais sur un site rédigé en français. Le mot n’existe ni dans mes titles, ni dans mes contenus. Le seul endroit où Google peut le matcher, c’est l’URL. On vient de reconstruire un inurl: qui ne dit pas son nom.

La règle à retenir : cette technique est fiable dans la mesure où le token d’URL est étranger à la langue du contenu. Les dossiers techniques des CMS sont les candidats parfaits : /category/, /tag/ et /author/ sous WordPress, /products/, /collections/ et /pages/ sous Shopify. Et petit bonus pour les sites multi-locales. site:domaine.com/products ne marche qu’en préfixe de chemin, et rate donc tous les /fr-fr/products/. Mon approche, elle, se moque de la position du dossier dans l’URL.

Les limites à connaître

Les limites, parce qu’il y en a. Un, dès qu’une page contient du texte dans la langue du token, elle s’invite dans les résultats. Sur mon test, ma veille Schema.org agrège des libellés anglais contenant « category » : elle remonte au milieu des archives. Deux, sur un site partiellement anglophone, les pages EN où le mot figure dans le title polluent les premiers résultats. Un -intitle:motclé les élimine, et c’est le seul garde-fou encore fonctionnel puisque -intext: est un zombie (on y vient). Trois, n’espérez pas l’exhaustivité : Google plafonne l’affichage à quelques centaines de résultats et ses compteurs sont des estimations. Pour l’inventaire complet, c’est crawl, sitemap ou Search Console, comme toujours.

Le fingerprinting de template, mon nouveau meilleur ami

Deuxième approche, qui ne dépend d’aucun opérateur in* : identifier un type de page par ses invariants de template plutôt que par son URL. Les phrases exactes entre guillemets font toujours leur travail, y compris combinées. Sur ce blog, pour isoler les pages articles :

site:www.yapasdequoi.com "Laisser un commentaire" "min de lecture"

Dix résultats sur dix : des articles, rien que des articles. La deuxième chaîne n’est pas décorative. Une seule phrase remonterait aussi les pages qui parlent de commentaires, alors que deux chaînes de template combinées éliminent l’essentiel du bruit. Sur un e-commerce, le duo "Ajouter au panier" "Paiement sécurisé" isole les fiches produits avec la même précision.

Bonus que inurl: ne vous a jamais offert : la langue des chaînes segmente par locale. "Ajouter au panier" ne remonte que les pages françaises, "In den Warenkorb" que les allemandes. Sur un site international, ça vous fait un inventaire par langue en une requête.

La boîte à outils survivante

Au final, la boîte à outils fiable est plus fournie que je ne le craignais. On garde : site:, les "phrases exactes", intitle: / -intitle:, l’exclusion de mot -mot, filetype:, before: / after: et le bon vieux OR. Bien combinées, ces briques couvrent l’essentiel de la reconnaissance rapide : analyse d’un concurrent, préparation d’audit, vérification d’indexation. À condition de reconstruire vos requêtes autour de ces briques-là, et de purger les zombies de vos habitudes. Pour le dorking pointu, inurl: répond toujours chez Yandex. Et pour tout ce qui prétend à l’exhaustivité, un crawler reste un crawler : Google Search n’a jamais été un outil d’inventaire, et c’est encore plus vrai aujourd’hui.

Un mot sur le OR, puisqu’on l’oublie souvent : il permet de chercher l’un OU l’autre de deux termes dans une même requête. Pour repérer d’un coup tout ce que j’ai écrit sur deux technos, par exemple :

site:www.yapasdequoi.com (drupal OR varnish)

Les parenthèses regroupent l’alternative, et je récupère aussi bien mes pages Drupal que mes pages Varnish en une seule passe. Seule contrainte, mais elle est stricte : OR doit être en majuscules. En minuscules, Google le prend pour le mot « or » et votre requête ne veut plus rien dire. Le pipe | fait le même travail si vous préférez : drupal | varnish.

Pour conclure, méfiez-vous de vos vieilles requêtes sauvegardées. Entre les opérateurs qui meurent en silence et ceux qui font semblant de marcher, le terrain bouge sous nos pieds. Et sans le moindre changelog. Re-testez, datez vos constats, et ne croyez pas les cheat sheets sur parole. La mienne comprise : refaites mes tests !

Sources : signalements de février 2026 (J. Kiekbusch, LinkedIn), désactivation de inurl: (Informaticien.be, juin 2026), test des 41 opérateurs (SEOmator, juillet 2026), opérateurs rétrogradés en « indices d’intention » (Atom-Business, août 2026), règles de syntaxe et instabilité des opérateurs (AW-i, avril 2026).

Dernière vérification des tests : 9 septembre 2026, depuis la France. Cet article sera mis à jour au fil des évolutions. Si vous constatez un comportement différent de votre côté, dites-le en commentaire, ça m’intéresse (et ça intéressera les suivants).

PS : oui, ce billet est né d’un post LinkedIn qui a déraillé en session de tests d’une heure…😀