It all started with a LinkedIn post I was preparing about a trick built on inurl:… except inurl: was no longer responding. Fine, I cobbled together a workaround with -intitle: and -intext: exclusions. Except intext: was no longer responding either. Nor was allintext:. Right. So I pulled out the full list of operators and tested every one of them, one by one, on the night of 7 to 8 September 2026. From France, under real conditions, straight in the browser.
If I was going to lose sleep, it might as well be useful. And the outcome does not fit into a “works / doesn’t work” box. Out of 16 syntaxes: 10 are still very much alive, 4 have gone inert (Google reads them as plain text), and above all 2 zombies pretend to exclude. That last family is the one that should worry you.
A quiet dismantling (and nobody re-tests)
A quick recap of the timeline, because it is worth it. In February 2026, Jonathan Kiekbusch reported on LinkedIn inconsistent behaviour of inurl: and intext: depending on the region: partial results, empty screens, matching drowned in broad match. In June, the tech press recorded the shutdown of inurl: (in French), with no notice from Google. In July, SEOmator put all 41 operators on the bench: only 12 still apply the filter they promise. One detail in their verdict matters: they count as “dead” the operators whose prefix Google ignores in order to run a plain text search. Remember that sentence, it describes exactly what I am about to show you. And in August, a French course page put its finger on the true nature of the phenomenon: some operators no longer work as filters but as mere “intent hints”. In plain words, Google reads them, nods, and does whatever it wants.
“It’s just regional”, really? I tested from a US IP
A point of honesty before going further, because it sits at the heart of the matter: not everyone sees the same thing. Several recent guides still claim, screenshots included, that inurl: or intext: work perfectly well in 2026. They are not necessarily wrong: the dismantling happened gradually, and an article published early in the year may well have observed an operator that was still alive and has since fallen. The first explanation that comes to mind is a regional rollout: Google would be deploying the change country by country. I believed it, so I went and checked rather than assuming.
I replayed my key queries behind a US VPN, US IP, to compare with my French results. Verdict: strictly identical. site:www.yapasdequoi.com -intext:seo still returns my “Consultant SEO technique” home page at the top, exactly as in France, even though the exclusion should knock it out. inurl:category combined with site: returns the same “did not match any documents”. And inurl:category on its own drifts to the same “URL categories” topic (IBM, Zscaler, Fortinet…), proof that the operator is read as two keywords on both sides of the Atlantic.
I even pushed it further: forcing the US market with &gl=us&hl=en, then the French market with &gl=fr&hl=fr, still from my US IP. The interface does switch from one language to the other, but the operators do not flinch: same zombie, same non-parsing in both cases. The regional rollout theory does not hold from any angle: not the IP, not the targeted country, not the language. The real variable is elsewhere, out of reach of a simple geo change: the rollout timing, the account type, or an A/B test on Google’s side. A US IP resurrects nothing.
One caveat, because a VPN does not turn me into a genuine American user: my Google account, my system language and my history may still weigh on the outcome. So I am not saying “it works nowhere in the United States”, I am saying “from a US IP, I observe exactly the same behaviour as in France”. Situated, dated, reproducible. Redo it from where you are, that is the whole point of the exercise.
Meanwhile? Most cheat sheets published in 2026 keep quietly listing intext:, allintext: or inurl: among the “reliable” operators. Nobody re-tests before publishing. So let’s do it together.
The protocol (reproducible at home in 10 minutes)
Tests run on the night of 7 to 8 September 2026, from France, on google.com. Mostly on this blog, since you might as well use your own playground, and cross-checked on a large multi-locale e-commerce site for the international cases. Strict syntax, obviously: no space after the colon, no protocol in site:. I stress it because half of the “dead operators” people report to me are actually syntax errors, and the symptoms are exactly the same. Two more rules, which several sources recall (in French) and which I confirm. The OR operator must be written in capitals, otherwise it is read as a plain word. And beyond three or four combined operators, results become unpredictable. So we test one thing at a time.
For each doubtful operator I set up a discriminating test, meaning a query whose verdict is binary. Example: site:www.yapasdequoi.com -intitle:seo. A good share of my pages have “SEO” in their title. If the exclusion works, the home page and the contact page must vanish from the results. If they stay, the exclusion is ignored. No room for interpretation.
Redo these tests from where you are: Google’s rollout was gradual, and your results may differ from mine depending on timing and context. That is the whole problem, in fact, and we come back to it below. One piece of advice learned the hard way: space out your queries. Thirty operator tests in a row earned me the “unusual traffic detected” page and its captcha. Google also keeps an eye on the people auditing it. 😅
The matrix: alive, not parsed, zombies
| Operator / syntax | Verdict | Observed behaviour |
|---|---|---|
site: | ✅ Alive | Filters normally (including with a path prefix) |
| Single word | ✅ Alive | Normal matching |
"exact phrase" | ✅ Alive | Strict match, including two combined phrases |
intitle:word | ✅ Alive | Really filters on the title |
-word | ✅ Alive | Effective exclusion |
-"exact phrase" | ✅ Alive | Effective exclusion: the page whose title it is disappears from the results |
-intitle:word | ✅ Alive | Effective exclusion (discriminating test passed) |
filetype: | ✅ Alive | Really filters by file type |
before: / after: | ✅ Alive | Effective filter, but on the last updated date, not the publication date |
OR | ✅ Alive | Working alternative between two terms |
intext: | ☠️ Not parsed | Like inurl:: zero with site: if the string is not in the content, otherwise misleading fuzzy matching |
allintext: | ☠️ Not parsed | Zero results with site:; on its own, treated as plain text |
inurl: | ☠️ Not parsed | Zero results with site:; on its own, treated as plain text |
allintitle: | ☠️ Not parsed | Zero results with site: (while intitle: works, go figure) |
-intext: | 🧟 Zombie | Query accepted, exclusion silently ignored |
-inurl: | 🧟 Zombie | Query accepted, exclusion silently ignored |
“Dead”? No: demoted to plain text
An important clarification about the operators marked “not parsed”, because the mechanism is sneakier than a plain shutdown. Take allintext:seo or inurl:category on their own, without site:: the query does return results… but without the slightest highlighting of the searched term, and for the second one it flatly drifts to the topic of URL categorisation. Google no longer parses the operator: it treats “allintext:seo” as an ordinary text string and does fuzzy matching on it. That is why, combined with site:, the verdict drops to zero results: no page on the domain literally contains the text “allintext:seo”. These operators are not dead, they have been demoted to keywords. Which matches the “intent hints” wording noted in August perfectly: the syntax has become query content like any other.
Zombies, or the art of pretending
A dead operator, you spot right away: zero results, error message, move along. A zombie operator, you do not see. Look at this query:
site:www.yapasdequoi.com -intext:seoLogically, it should discard every one of my pages that mentions “SEO” in its content, in other words… pretty much the whole site. Actual result: my “Consultant SEO technique” home page comes first, with SEO on every line. The exclusion is accepted, then silently ignored. No message, no signal. Same verdict for -inurl:. Two exclusions built on the same pattern, both a sham, and for the same underlying reason: the operator being negated (intext:, inurl:) is no longer parsed in the first place, so negating it changes nothing.
Good news on the other hand, and it is a trap to avoid: excluding an exact phrase works perfectly well. site:www.yapasdequoi.com -"consultant SEO" does make my home page disappear, since that is its title. Do not confuse the two: -"phrase" filters, -intext: pretends. The difference is that the first relies on quotation marks (alive) and the second on a dead operator.
While at the same time, the discriminating test on -intitle: passes without a hitch:
Concretely, what does that mean? That every audit query containing -intext: or -inurl: now produces potentially false conclusions, with every appearance of reliability. If you have saved queries, monitoring scripts or processes that rely on them, they have been telling you stories for weeks without changing their looks. I will let you check yours, I have already cleaned up mine…
The intext: case, or the false-friend trap
The intext: case deserves its own paragraph, because it drove me round the bend for a good part of the night. On a large sports e-commerce site that nonetheless sells shoes by the thousand, site:www.decathlon.fr intext:chaussures (“chaussures” is French for shoes) returns no shoes at all… but swimming pools and clothing from the INTEX brand. Google read “intext” as “intex”! On this blog, at the very same minute: site:www.yapasdequoi.com intext:robots gives me three perfectly relevant results. Enough to believe in a moody operator that works every other time…
Except that, digging in, the truth lies elsewhere, and it is more devious. intext: is not parsed either, exactly like inurl:. What changes from one site to the next is not the operator, it is the indexed content. Google treats “intext:robots” as a text string to search for. On my blog, plenty of articles talk about robots.txt and that kind of syntax: it finds something to hang on to, and returns three pages. Elsewhere, it falls back on the closest token it knows, even if that means confusing “intext” with a swimming pool brand. Proof by counter-test: site:www.yapasdequoi.com robots (without the operator) returns twice as many results as the version with intext:. If the operator really filtered on body text, it would be the other way round.
That is why I file it under false friends. It keeps up appearances on sites whose content happens to be about SEO or technical topics. And it lets you down flat on the others. It may be the most dangerous of the lot: it gives the impression of working. Into the cupboard, with the others.
Along the way, I tested the remedies doing the rounds: neither the &udm=14 parameter (the famous “Web” mode without AI layers) nor Verbatim mode (&tbs=li:1) resurrects anything. The myth of the Web mode that restores operators does not hold up.
The official documentation, a quiet admission
A tasty detail found while cross-checking my matrix against the official “Refine Google searches” page (consulted on 10 September 2026): Google now documents only five families of operators. Quotation marks, site:, the -word exclusion, before:/after: and filetype:. That’s all. The related: and cache: of old have vanished from the page, and neither intitle:, nor inurl:, nor intext: appear on it. Compare with the table above: the official documentation almost exactly matches the list of survivors. Google announced nothing, but its own documentation has been quietly pruned to keep only what works. A few undocumented survivors remain: intitle: / -intitle:, but also OR, which still work without appearing anywhere on the page. Unofficially tolerated, then. Next on the list? I will re-test.
A small trap along the way on before:/after:, and here it is the official documentation itself that says so: the filter applies to the last updated date, in other words the document’s last modification, not its publication date. Verified on my site: before:2015-01-01 returns only one of my articles from the 2011 to 2014 period, a 2011 post never touched since. The others, edited during a redesign, crossed over to the other side of the time barrier. In a freshness or history audit, keep it in mind, otherwise the conclusions go sideways. Note that both date formats work: before:2015-01-01 as well as before:2015/01/01, and the year alone (before:2015) is enough.
Replacing inurl: : the technique that holds up
A classic need: isolating a page type through its URL folder, without crawling. Take this blog, a WordPress site with its archives under /category/. The query inurl:category is dead, as we saw. But this one works:
site:www.yapasdequoi.com category
Why this query works
Why does it work? Because “category” is a technical token in English on a site written in French. The word exists neither in my titles nor in my content. The only place where Google can match it is the URL. We have just rebuilt an inurl: that does not say its name.
The rule to remember: this technique is reliable insofar as the URL token is foreign to the language of the content. The technical folders of CMSs are perfect candidates: /category/, /tag/ and /author/ under WordPress, /products/, /collections/ and /pages/ under Shopify. On an English-language site, the trick works less well with English tokens, but any folder name absent from the copy will do. And a small bonus for multi-locale sites. site:domain.com/products only works as a path prefix, and therefore misses every /fr-fr/products/. My approach does not care where the folder sits in the URL.
The limits to know about
The limits, because there are some. One, as soon as a page contains text in the token’s language, it invites itself into the results. In my test, my Schema.org monitoring page aggregates English labels containing “category”: it shows up in the middle of the archives. Two, on a partly English-language site, the EN pages where the word appears in the title pollute the first results. A -intitle:keyword removes them, and it is the only guardrail still working since -intext: is a zombie (see above). Three, do not expect exhaustiveness: Google caps the display at a few hundred results and its counters are estimates. For the full inventory, it is crawl, sitemap or Search Console, as always.
Template fingerprinting, my new best friend
Second approach, which depends on no in* operator at all: identifying a page type by its template invariants rather than by its URL. Exact phrases in quotation marks still do their job, including combined. On this blog, to isolate the article pages, two strings from the French template, “Laisser un commentaire” (leave a comment) and “min de lecture” (min read):
site:www.yapasdequoi.com "Laisser un commentaire" "min de lecture"
Ten results out of ten: articles, nothing but articles. The second string is not decorative. A single phrase would also return the pages that talk about comments, whereas two combined template strings remove most of the noise. On an e-commerce site, the pair "Add to cart" "Secure payment" isolates product pages with the same precision.
The surviving toolbox
In the end, the reliable toolbox is better stocked than I feared. We keep: site:, "exact phrases", intitle: / -intitle:, the -word exclusion, filetype:, before: / after: and good old OR. Properly combined, these building blocks cover most of the quick reconnaissance work: competitor analysis, audit preparation, indexing checks. Provided you rebuild your queries around those blocks, and purge the zombies from your habits. For advanced dorking, inurl: still answers on Yandex. And for anything that claims to be exhaustive, a crawler remains a crawler: Google Search has never been an inventory tool, and that is truer today than ever.
A word on OR, since it is often forgotten: it lets you search for either of two terms in a single query. To spot in one go everything I have written about two technologies, for example:
site:www.yapasdequoi.com (drupal OR varnish)The parentheses group the alternative, and I get my Drupal pages as well as my Varnish pages in a single pass. One constraint, and it is strict: OR must be in capitals. In lower case, Google takes it for the word “or” and your query no longer means anything. The pipe | does the same job if you prefer: drupal | varnish.
To conclude, beware of your old saved queries. Between the operators that die in silence and those that pretend to work, the ground is shifting under our feet. Without the slightest changelog. Re-test, date your findings, and do not take cheat sheets at their word. Mine included: redo my tests!
Sources: February 2026 reports (J. Kiekbusch, LinkedIn), shutdown of inurl: (Informaticien.be, June 2026, in French), test of the 41 operators (SEOmator, July 2026), operators demoted to “intent hints” (Atom-Business, August 2026, in French), syntax rules and operator instability (AW-i, April 2026, in French).
Last check of the tests: 9 September 2026, from France. This article will be updated as things evolve. This is the English version of an article first published in French on 10 September 2026. If you observe a different behaviour on your side, say so in the comments, I am interested (and so will be the next readers).
PS: yes, this post was born from a LinkedIn post that derailed into an hour-long testing session… 😀