Advanced search operators explained

What an operator actually is

An advanced search operator is a piece of syntax the engine's query parser recognises before ranking begins. Ordinary query words are signals: the engine weighs them, expands them into synonyms, corrects apparent spelling mistakes, and infers what you probably meant. An operator is meant to be read literally — a constraint on which documents are eligible to be ranked at all, rather than a hint about which ones you would prefer.

That distinction explains almost everything about how operators behave. Adding site:example.com does not push results from that domain upwards. It is supposed to remove everything else from consideration. Putting a phrase in quotation marks is not a request for pages about that topic; it is a request for pages containing those words in that order. When operators work, they work by subtraction, and that is why they remain the most effective way to rescue a query that is returning plausible-looking rubbish.

Two cautions belong at the front, because both are routinely misunderstood. First, an operator is a request, not a command: engines reserve the right to relax constraints when a strict reading returns very little, and they do. Second, operator support is mostly undocumented. A small number of operators appear in each engine's official help pages; a much larger number circulate in guides and half of those stopped working years ago without any announcement. There is no versioning, no deprecation notice and no changelog for search syntax.

The five that work almost everywhere

These are the ones worth knowing, because they behave consistently across Google, Bing and most engines built on top of either, and they cover the great majority of real research needs.

• Quotation marks — exact phrase. "velvet worm" asks for those words adjacent and in that order. This is the single most useful operator, because it suppresses the synonym expansion and query rewriting that otherwise silently changes what you asked for.
• Minus sign — exclusion. jaguar -car removes documents containing the excluded term. Attach it directly to the word with no space. Exclusion is usually more powerful than addition: one well-chosen exclusion often does more than three extra keywords.
• site: — restrict to a domain. site:nasa.gov limits results to that host. It also accepts a bare top-level domain, so site:.gov or site:.ac.uk restricts by category of publisher, which is one of the fastest ways to change the character of a result set.
• OR — alternatives. Must be capitalised on Google, which reads lowercase "or" as an ordinary word. vaccine (efficacy OR effectiveness) covers both phrasings in one query.
• filetype: — restrict by document type. filetype:pdf is the classic use, and it changes what you find dramatically: reports, standards documents, government publications and academic material are disproportionately PDFs and disproportionately buried under web pages about them.

Two more are worth adding if you use Google. before: and after: take dates in YYYY-MM-DD form and bound results by date — genuinely valuable for anything where the last two years of coverage has buried the original event. And a bare asterisk acts as a wildcard for an unknown word inside a quoted phrase.

Where the engines diverge

Beyond that shared core, support fragments, and the fragmentation follows directly from whether an engine owns an index.

Google documents a fairly short list publicly and supports a longer one unofficially. intitle:, inurl:, allintitle: and allinurl: are widely used and have worked for many years, but they sit in the undocumented category, which means they can change without notice — and periodically do. Google also offers a Verbatim setting under its search tools, which is arguably more useful than any single operator: it turns off much of the automatic interpretation of your query in one click.

Bing publishes a comparatively generous list of advanced keywords and supports several that Google does not, including contains: for pages linking to a given file type, inbody: for terms in the body text specifically, ip: for pages hosted at an address, and Boolean expressions with parentheses using AND, OR and NOT. If you need genuine Boolean logic rather than approximate Boolean behaviour, Bing is usually the better parser.

DuckDuckGo supports the common core and adds bang commands, which are a different idea entirely: typing !w velvet worm sends you to Wikipedia's own search rather than returning DuckDuckGo results. There are thousands of them, listed at duckduckgo.com/bangs. Note the trade-off nobody mentions: a bang is a redirect, so your query goes to the destination site rather than staying with the engine you chose for privacy reasons.

Engines with no index of their own cannot promise much. A metasearch engine passes your query to upstream suppliers whose parsers differ, so complex syntax may be honoured by one source, ignored by another, and mangled in the merge. This is a documented weakness of the category rather than a bug: the legacy metasearch brands cannot reliably support advanced syntax and do not claim to. The same caution applies to any front end reselling someone else's results — what actually reaches the parser is whatever the reseller chose to forward.

The independent smaller engines take operators seriously, which is one of the more interesting facts in this area. Marginalia is a keyword engine on purpose, with operators and filters — including filters that exclude pages carrying affiliate links, trackers or heavy JavaScript — aimed at people who want to steer a query rather than ask a question. Kagi's product is largely a control layer: it lets a user raise, lower, pin or permanently block any domain in their own results, which is a per-user persistent operator in everything but name. Brave's Goggles go further still, letting anyone write and share a re-ranking filter over Brave's index, boosting or excluding whole sets of sites. All three are only possible because those engines control their own ranking — which is why this kind of feature never appears on a reseller.

Operators that no longer work

A large fraction of the search-operator guides in circulation are describing a version of Google that has not existed for over a decade. These are the notable retirements, and knowing them saves a lot of wasted effort:

• cache: — retired by Google in 2024. It used to show Google's stored copy of a page and was the fastest way to see a version of something that had changed or gone. Google's stated reasoning was that the feature had been built for an era of unreliable page loading. There is no replacement operator.
• link: — long dead. It was supposed to list pages linking to a URL and never returned a meaningful sample even when it worked; Google confirmed years ago that it no longer functions.
• + before a word — retired in 2011 to free the symbol for Google+. Its function, forcing a term to appear, was absorbed by quotation marks around a single word.
• ~ for synonyms — retired in the early 2010s. Synonym expansion is now automatic and not user-controllable, which is precisely why quotation marks matter more than they used to.
• related: — still recognised but much less useful than it once was, and inconsistent across queries. Treat any result from it as suggestive rather than systematic.

The general lesson is more important than the list: test an operator before relying on it. Run a query you know the answer to, with and without the syntax, and compare. Because there is no deprecation notice, a retired operator does not produce an error message — it is simply parsed as ordinary text, quietly widening your search while you believe you have narrowed it. That failure is silent and it is the reason people end up trusting result sets that never had the constraint they thought they applied.

What operators cannot do

Three limits are worth internalising, because each is a common source of confidently wrong conclusions.

Result counts are estimates, not measurements. The "about 4,120,000 results" figure at the top of a page is a projection produced before the engine has enumerated anything, and it changes between page one and page four of the same query. It is not a corpus statistic and cannot be used to compare the frequency of two phrases, however tempting that is. Any argument built on comparing two result counts is built on nothing.

site: is not an inventory. Restricting to a domain returns a sample of what the engine chose to show for that query, not a complete listing of everything it holds. Engines do not offer, and have never offered, a way to enumerate their index.

Operators do not survive the answer layer. Where a query is routed into a generative answer rather than a ranked list of documents, the syntax is at best a hint to a retrieval step you cannot see. Operators are a feature of document retrieval, and the more an engine moves toward answering rather than finding, the less reliably they apply. If you need precision, the engines that still put a ranked list of links first are the ones where precision is still available.

A last practical note. Operators are portable in spirit but not in detail, and every engine's behaviour drifts. Because none of this is standardised or versioned, the only durable habit is to check the engine's own help documentation when something stops behaving as expected — and to distrust any operator guide, including this one, that does not tell you when it was written. This page describes behaviour as of August 2026.

Frequently asked questions

Sources

• support.google.com/websearch
• duckduckgo.com/bangs
• help.kagi.com/kagi/why-kagi/kagi-vs-competition.html
• about.marginalia-search.com/article/about/
• en.wikipedia.org/wiki/Marginalia_(search_engine)