← Back to blog

Search Operators for Research: A Working Guide

October 21, 2026
Search Operators for Research: A Working Guide

Search operators are short commands that tell a search engine how to combine, limit or exclude terms. For research, the core set is Boolean logic (AND, OR, NOT), parentheses, phrase quotes and truncation, plus a few web-specific operators such as site: and filetype:. The catch: syntax is not universal. A string that works in one database can silently return something different in another.

Gyrence
Turn Web Research Into Structured Data
Gyrence gives developers API tools to search the web, fetch pages, and extract structured data for research workflows.
Explore Gyrence

TL;DR

  • Learn three Boolean operators first: AND narrows, OR broadens (synonyms), NOT excludes. Write them in capitals.
  • Use parentheses every time you mix AND with OR. Without them, the engine decides the order for you.
  • Phrase quotes, truncation (*) and proximity operators behave differently in PubMed, Scopus, EBSCOhost and Google. Check each platform's help page.
  • Avoid NOT in high-recall work. It removes whole records on a technicality.
  • Save every search string with its platform and date. If you can't rerun it, you can't defend it.

Table of Contents

The three Boolean operators

Boolean operators work on sets. Per University of Illinois Chicago's research guide, AND narrows, OR broadens by capturing synonyms, and NOT excludes. The same guide recommends typing them in ALL CAPS so the engine doesn't read them as ordinary keywords.

OperatorEffectExample
ANDBoth concepts must appearinflation AND wages
OREither term may appearinflation OR "price increases"
NOTExcludes a terminflation NOT cryptocurrency

Use OR inside a concept (synonyms) and AND between concepts. That one habit covers most of what a literature or market search needs.

Parentheses decide what your query means

The most common error in complex searches is skipping parentheses. USC's Boolean guide explains that databases process operators in a default order, and natural-language phrasing can quietly exclude relevant results without any warning.

Compare:

  • wages AND inflation OR deflation is ambiguous. The engine may read it as "(wages AND inflation) OR deflation", which pulls in every deflation record regardless of wages.
  • wages AND (inflation OR deflation) says exactly what you mean.

Build searches concept by concept: one parenthesized OR group per concept, then join the groups with AND.

Phrases, truncation and why your results look odd

Quotation marks force an exact phrase. Truncation, usually *, finds word endings: econom* catches economy, economics and economist. Ohio State's PubMed guide covers truncation in detail.

There is a side effect. PubMed's help page describes Automatic Term Mapping (ATM), which maps your keywords to controlled vocabulary (MeSH) behind the scenes. Per the University of Dayton's PubMed guide, ATM applies when you search with plain keywords. Use a quoted phrase or truncation and you take over the precision yourself. Mysterious results usually trace back to this switch, in either direction.

So use phrases sparingly. They are right for multi-word proper nouns and fixed technical terms. Overused, they cut recall hard.

Phrases, truncation and why your results look odd — overview diagram

Syntax changes by platform

Don't paste one string everywhere. The University of Minnesota's systematic review guide notes that Scopus uses curly brackets for exact phrases, while PubMed, Web of Science and EBSCOhost use double quotes. Proximity operators (NEAR/x, ADJn) also vary by platform and are often missing from consumer search tools.

Proximity is the biggest gap between research databases and the open web. Google leans on relevance ranking rather than strict word distance, whereas EBSCO, Ovid and Web of Science let you require two terms within a set number of words. When you need fewer false positives, that control matters.

Google Scholar is a middle case. According to the University of Washington's Scholar guide, a space acts as AND, the pipe | as OR, and the dash - as NOT. It has a character limit on the query, and it lacks PubMed-style synonym expansion.

Search syntax differences across research platforms

Google's advanced operators for research

Open-web research adds operators that library databases don't have. Ahrefs maintains a long list of Google operators; some are retired, so test before relying on one. The ones that earn their place:

  • site: limits results to a domain. site:.gov or site:sec.gov narrows to official sources.
  • filetype: (or ext:) finds PDFs, spreadsheets and slide decks, where reports and filings often sit.
  • "exact phrase" and -term work as described above.
  • * is a wildcard for a missing word.
  • ( ) groups terms, as in (ipad OR iphone) apple.

A practical example: "annual report" (sustainability OR ESG) filetype:pdf site:.com -template. Four operators, one clear intent.

Why NOT is risky

Librarians at the University of Dayton and Ohio State advise against NOT in systematic or high-recall searches. It deletes whole records, so a slight difference in how a document is indexed can remove exactly the evidence you needed. Prefer more specific AND terms, or exclude by reviewing results. If you must use NOT, log it and check what it removed.

Log every string you run

Professional searchers keep an audit trail of strings and the exact syntax used, because platforms change how they interpret operators. The Minnesota guide stresses this for systematic reviews, and the NYU Health Sciences Library covers translating a search across databases. A log should hold:

  1. Platform and interface (for example, PubMed web vs. an API).
  2. The full string, copied verbatim.
  3. Date run and result count.
  4. Filters applied (date, language, document type).
  5. Notes on what you changed when translating to another platform.

If you want tools that support reproducible workflows, this roundup of AI research tools is a useful reference for finding, verifying and analyzing sources.

Our view: operators are a spec, not a trick

We build web data tooling, and the same lesson shows up in code. A query that returns something is not a query that returns the right thing. Operators are a specification of intent, and a specification you can't replay is a rumor.

Three points from how we think about it:

  • Silent rewriting is the enemy. Synonym expansion, term mapping and relevance reordering all change results without telling you. We would rather a system report what it did.
  • Failure should be explicit. An empty result, a blocked page and a malformed query are three different outcomes. Treat them that way, in a database or in an API.
  • Log the query with the result. If a finding feeds a compliance or financial decision, you need to trace it back to the string, the source and the time.

For programmatic work, see our guides on search APIs for research and what structured SERP data looks like.

— Glen

When manual operators stop scaling

Operators are enough for a few dozen searches. Past that, teams script them: run the string, fetch the pages, extract fields, keep the trail. Gyrence exposes Search, Fetch, Extract and Map as separate calls, and every response, including failures, comes back typed so a pipeline can handle it. Spending caps keep the bill predictable. You can start from the pricing page, where the Standard plan is listed at $75 per month.

FAQ

What is the difference between AND and OR in research searches?

AND requires every term to appear, so it narrows results. OR accepts any of the terms, so it broadens them. Use OR for synonyms within one concept and AND to join different concepts.

Do search operators work the same in Google and academic databases?

No. Google and Google Scholar accept shorthand such as a space for AND, | for OR and - for NOT. Databases like Scopus, PubMed and EBSCOhost have their own phrase, truncation and proximity syntax. Check each platform's help page before reusing a string.

Should I use quotation marks around every phrase?

No. Quotes switch off features such as PubMed's term mapping and can sharply cut recall. Reserve them for proper nouns and fixed technical phrases where variation would add noise.

Why do my results change when I add parentheses?

Because engines apply a default order of operations. Parentheses make the grouping explicit, so the engine evaluates your logic rather than its own guess.

Sources