Scopus Advanced Search Syntax: Field Codes, Proximity Operators, and Precedence Rules

Scopus’s advanced search field runs on its own query language, and most searchers use almost none of it. A default Scopus search box query matches across a broad default field set, which is fine for a quick look-up and a poor foundation for a search you need to report, defend, or rerun months later with the same results. The field codes, proximity operators, and boolean precedence rules below let you build a query string that says exactly what you mean — and that you can paste into a methods section or an appendix as a reproducible artefact, the same way PubMed’s Advanced Search Builder lets you record a search history number.

Field codes: searching a specific part of the record

Scopus field codes restrict a search term to one part of the indexed record instead of the whole thing. The syntax is always FIELD(search terms), and field codes can be combined with boolean operators in the same query string.

• TITLE-ABS-KEY(term) — the default, combined field for most topic searches: matches the article title, abstract, and both author keywords and Scopus’s own indexed keywords in one pass. This is the closest Scopus equivalent to PubMed’s [tiab], but broader, because it also pulls in the controlled-vocabulary keyword field.
• TITLE(term) — title field only. Tighter and higher-precision than TITLE-ABS-KEY; use it when a term is central enough to a paper that you’d expect it in the title, not just discussed somewhere in the abstract.
• AUTH(lastname, initial) — author search, by last name and first initial (for example AUTH(smith, j)). Because Scopus author-name matching is algorithmic and imperfect (the same ambiguity problem covered on this site’s Scopus Author ID page), a name-only AUTH() search on a common surname will pull in unrelated authors — pair it with AFFIL() or a subject filter to narrow it, or search by Scopus Author ID directly when you have one.
• AFFIL(term) — searches the author affiliation string: institution name, city, and country as recorded at time of publication. Useful for institutional bibliometrics and for disambiguating a common author name by home institution.
• SRCTITLE(term) — restricts to the source title: the journal, book series, or conference proceedings name, not the article itself.
• DOCTYPE(code) — restricts by document type. Common codes: ar (article), re (review), cp (conference paper), ch (book chapter), bk (book), ed (editorial), le (letter), no (note), er (erratum). Example: DOCTYPE(ar OR re) restricts a search to primary research articles and review articles only, a common systematic-review-adjacent filter.
• PUBYEAR — numeric year filtering using comparison operators rather than a field-code parenthesis: PUBYEAR > 2020, PUBYEAR < 2020, or PUBYEAR = 2023 for an exact year. Combine two comparisons with AND to build a range: PUBYEAR > 2019 AND PUBYEAR < 2025 captures 2020 through 2024 inclusive.

Field codes combine directly with boolean operators: TITLE-ABS-KEY(research OR data) AND AFFIL(canada) is a single valid query.

Proximity operators: W/n and PRE/n

Scopus supports two proximity operators, and the difference between them is the single most common source of a wrong search string copied off a library guide without checking which one it actually needs.

• W/n (within) — order-independent. The two terms must fall within n words of each other, in either order. "research" W/3 "data" matches both “research on open data” and “data-driven research practice.”
• PRE/n (precedes) — order-dependent. The first term must appear before the second, within n words. "open" PRE/2 "access" matches “open access” and “open, unrestricted access” but not “access to openly available” data, because the word order is reversed.

Set n to 0 for adjacency without a gap: PRE/0 requires the second term to directly follow the first, which is the closest Scopus gets to an exact-phrase match while still being a proximity operator rather than a literal quoted string. Both operators apply within a single field — you cannot proximity-search across, say, a title term and an abstract term, only within one field code’s scope (typically TITLE-ABS-KEY). Scopus does not allow AND or AND NOT as an argument inside a proximity expression; only terms and OR can sit on either side of W/n/PRE/n.

Boolean precedence: why AND NOT can silently drop records you wanted

Scopus evaluates a query in a fixed precedence order — OR first, then AND, then AND NOT — and, once that precedence is applied, reads left to right. That ordering is not always what a query written the way you’d say it out loud actually means, and the failure mode is quiet: the query returns a result set, just a smaller and wrong one, with nothing flagging that a clause got excluded.

Concretely: TITLE-ABS-KEY(diabetes) AND TITLE-ABS-KEY(diet OR exercise) AND NOT TITLE-ABS-KEY(review) behaves as intended, because parentheses around diet OR exercise force that OR to resolve before the surrounding ANDs apply. Drop the parentheses — TITLE-ABS-KEY(diabetes) AND TITLE-ABS-KEY(diet) OR TITLE-ABS-KEY(exercise) AND NOT TITLE-ABS-KEY(review) — and the query no longer means “diabetes and (diet or exercise), excluding reviews.” OR resolves first across the whole string, so the query effectively splits into two separate searches joined by OR: everything about diabetes and diet (minus reviews), plus every exercise paper site-wide regardless of whether diabetes appears at all — a much larger, mostly irrelevant set, with no error or warning that the query didn’t do what it looked like it should.

Practical rule: always parenthesize an OR group that sits next to an AND or AND NOT in the same query, and never assume precedence “reads naturally.” When a search returns a record count that looks too high, or contains obviously off-topic results, an unparenthesized OR next to an AND NOT is the first thing worth checking before assuming the topic itself has more literature than expected.

A worked, reproducible query string

Combining field codes, a proximity operator, document-type filtering, and a date range into one query, for a hypothetical search on funder open-data mandates in engineering research, 2021 through the present, excluding editorials and letters:

TITLE-ABS-KEY("open data" PRE/2 mandate) AND TITLE-ABS-KEY(engineering) AND DOCTYPE(ar OR re) AND PUBYEAR > 2020 AND NOT TITLE-ABS-KEY(editorial OR letter)

Read left to right against the precedence rule above: the PRE/2 proximity expression and the DOCTYPE(ar OR re) group are each self-contained in their own parentheses, so nothing from the boolean-precedence pitfall applies here — every OR is safely contained inside a field-code group rather than sitting bare between two ANDs. Save the exact string alongside the search date and result count; Scopus itself does not version or timestamp a saved search the way some database interfaces do, so the query string is the reproducible record.

Document type and date range, beyond the query string

Everything above works as raw query syntax typed into the search box. The Scopus web interface also exposes document type and publication-year filters as post-search facets in the left-hand refine panel — functionally equivalent to adding DOCTYPE() and PUBYEAR clauses, but applied by clicking rather than typing. The two approaches produce the same result set; the query-string version is worth learning anyway because it is what you can paste into a methods appendix, share with a co-author, or rerun identically later — a facet click in the interface leaves no reusable record on its own.

Frequently asked questions

What is the default field if I don’t use a field code at all?

A plain, code-free search in the Scopus search box runs against the same combined title/abstract/keyword scope as TITLE-ABS-KEY. Typing the field code explicitly does not change what is matched in that case — it matters once you start combining it with other field codes in one query string, where an un-coded term can default to a different, broader scope depending on which search bar you’re in (basic vs. advanced search).

Can I combine TITLE-ABS-KEY with AUTH and AFFIL in one query?

Yes — field codes combine freely with AND/OR/AND NOT across different fields. TITLE-ABS-KEY(machine learning) AND AUTH(lecun) AND AFFIL(new york) is a valid, well-formed query restricting a topic search to a specific author at a specific institution.

Does Scopus support exact-phrase searching with quotation marks?

Quoted phrases are supported for loose phrase matching within Scopus’s default search behaviour, but for a precise, reproducible phrase match inside a field code, PRE/0 is the more exact and explicit tool, since it makes the adjacency requirement part of the visible query syntax rather than relying on how quotation marks are silently interpreted.

How is this different from searching Scopus through Scholarly Search or SciVal instead of scopus.com directly?

The field-code and proximity-operator syntax on this page is specific to the Scopus search interface and its underlying query language. SciVal is built on the same underlying Scopus data but is an analytics/benchmarking layer, not a search interface, and does not expose this query syntax the same way.

Related CASRAI pages

• Scopus — what the database is, coverage, and how it differs from Web of Science.
• Scopus vs. Web of Science vs. OpenAlex — coverage and access-model comparison.
• The PubMed Advanced Search Builder — the equivalent reproducible-syntax guide for PubMed.
• Google Scholar Advanced Search — which operators actually work there, for contrast with Scopus’s documented syntax.
• Getting a Journal Indexed in Scopus — the CSAB review process that determines what a Scopus search can find in the first place.
• Journal Indexing: DOAJ, Scopus, Web of Science — what being indexed actually means.