Systematic Literature Search Strategy: Build Search Strings, Database Queries, and a Search Log

Overview

A systematic literature search strategy is a documented method for finding relevant research articles as consistently and comprehensively as possible. It is more than entering a few terms into an academic database. You need to decide what the question contains, how each concept may be described by different authors, which databases are appropriate, and how to record every meaningful search decision.

The goal is not always to retrieve the largest possible result set. A useful strategy balances recall, finding potentially relevant records, with precision, reducing records that are clearly unrelated. Early searches usually favor recall: it is easier to remove irrelevant results during screening than to recover an important article that your search never found.

Before building a search string, define the type of review or project you are conducting. A formal systematic review may require a highly comprehensive and reproducible search across several databases. A student literature review may need a focused, transparent search that can be completed within realistic time limits. In either case, write down your decisions rather than relying on memory.

For background on locating peer-reviewed material, see this repeatable workflow for finding peer-reviewed journal articles. Once you have identified useful studies, a literature review matrix can help you organize and compare them.

What to track

1. Break the question into concepts

Start by identifying the main ideas in the research question. Many questions can be organized with a framework such as population, intervention or exposure, comparison, and outcome. Other projects may need concepts for a setting, phenomenon, experience, or study design. Do not force every question into the same framework; use only the elements that genuinely affect retrieval.

For example, a question about whether remote learning affects undergraduate engagement might contain these concepts:

• Population: undergraduate students, university students, college students
• Exposure or intervention: remote learning, online learning, distance education, virtual instruction
• Outcome: student engagement, academic engagement, participation, involvement

These concepts become the main blocks of the search. You will usually combine synonyms within a block with OR, then combine different blocks with AND.

2. Build a synonym table

Researchers may describe the same idea using different spelling, terminology, abbreviations, or disciplinary language. Create a table before writing the final query:

Use truncation carefully. In many interfaces, an asterisk retrieves multiple word endings, so student* might find student and students. Syntax varies, however. A symbol that works in one database may behave differently or be unsupported in another. Treat each database query as a version that must be tested and recorded.

3. Add subject headings where available

Some databases assign controlled vocabulary, subject headings, or indexed terms to records. These terms can improve retrieval when authors use different wording. A strong database search often combines controlled vocabulary with free-text keywords:

• Use the subject heading when the database has a relevant, specific term.
• Search title, abstract, and keyword fields for natural-language variations.
• Check whether a subject heading includes narrower terms automatically or requires an expansion option.
• Record the exact heading label and database feature used.

Subject headings are not interchangeable across databases. Do not copy one database's controlled vocabulary into another without checking its own thesaurus or indexing guidance.

4. Assemble the Boolean search

A basic literature search string follows this structure:

(synonym OR synonym OR synonym) AND (synonym OR synonym) AND (synonym OR synonym)

For the example above, a starting search might be:

(undergraduate* OR "college student*" OR "university student*") AND ("online learning" OR "remote learning" OR "distance education" OR "virtual instruction") AND ("student engagement" OR "academic engagement" OR participation)

Use quotation marks for exact phrases only when the database supports phrase searching as expected. Parentheses matter: without them, the database may interpret AND and OR in an unintended order. Test each concept block separately before combining the blocks. This makes it easier to identify which term is causing an unexpectedly large or small result set.

5. Separate the strategy from the filters

Filters can be useful, but they should not hide weaknesses in the search string. First develop the conceptual search. Then consider limits such as publication date, language, document type, age group, or subject area. Record the reason for each limit. A date range may be appropriate when the research concerns a recent technology, while an unexplained language restriction can exclude relevant evidence.

Be particularly cautious with database filters for peer review. Indexing systems and interfaces do not always describe publication types in the same way. Inspect the database's available fields, and verify important records rather than assuming that a filter has classified every result correctly.

6. Maintain a search log

A search log makes the process auditable and easier to update. At minimum, record:

• Database or platform name and the date searched
• Exact search string, including field codes and subject headings
• Filters, limits, and sorting choices
• Number of results returned
• Number of records exported and the file format used
• Changes made after testing, with a short reason
• Notes about duplicates, access problems, or unusual results

A practical search log row can use these columns:

Date | Database | Search ID | Exact query | Limits | Results | Exported | Revision notes

Keep the original query when you revise it. A sequence of dated versions shows how the strategy developed and prevents useful tests from being lost.

Cadence and checkpoints

Build the search in checkpoints rather than trying to perfect it in one session.

1. Question checkpoint: Confirm the population, topic, intervention or exposure, outcome, setting, and date boundaries that actually matter.
2. Concept checkpoint: Ask whether each block represents one idea. Split a block if it combines unrelated concepts; remove a block if it makes the search unnecessarily narrow.
3. Term checkpoint: Review titles and abstracts from known relevant papers. Add terminology that appears repeatedly, and investigate unfamiliar abbreviations.
4. Database checkpoint: Translate the strategy into each database's field labels, operators, truncation rules, phrase syntax, and subject headings.
5. Retrieval checkpoint: Inspect an initial sample of results. Are they on topic? Are known relevant studies appearing? Are entire disciplines or populations missing?
6. Documentation checkpoint: Save the final query, result count, export details, and date for every database.

For an ongoing project, schedule a monthly or quarterly review of the search log when the subject changes quickly or the review will remain active for a long period. A one-time class assignment may need only a final verification before submission. A living or regularly updated review needs a defined update interval and a consistent method for comparing new results with earlier searches.

Use citation chasing as a complementary checkpoint. Examine references in key articles for earlier work and use cited-by tools to locate later work. Record this activity separately from the database search, including the article or seed study used, date checked, and screening decision. Citation chasing can identify useful records, but it does not replace a documented database strategy.

How to interpret changes

Changes in result counts do not automatically mean that a search has improved or deteriorated. A larger set may reflect a newly added synonym, broader indexing, a changed default field, or a less restrictive filter. A smaller set may result from a new phrase interpretation, a removed term, a narrower subject heading, or an interface change.

When the result count changes, compare the exact query versions first. Then inspect a sample of new and missing records. Ask:

• Did the revision retrieve relevant studies that were previously absent?
• Did it introduce a large, identifiable group of irrelevant results?
• Are important concepts represented in titles, abstracts, or subject headings?
• Did a filter remove records that should be screened?
• Is the database using a different indexing or phrase-search rule than expected?

Do not judge a search only by the number of results. A smaller, well-targeted set can be more useful than thousands of poorly related records, while an apparently precise query may miss terminology used by a particular discipline. Keep a short rationale for every material change so that another researcher can understand the trade-off.

When databases disagree, do not assume one is wrong. Coverage, indexing depth, update timing, and subject emphasis can differ. Compare records across databases, deduplicate them, and report the databases separately in your methods. If your project depends on indexed journal coverage, verify the database's current source information rather than relying on an old list or an unverified claim.

When to revisit

Revisit a systematic literature search strategy at four practical moments: when the research question changes, when initial results reveal a terminology gap, before the search is finalized, and when the review is updated. Also revisit it if a database changes its interface, field codes, subject headings, truncation rules, or export process.

For a monthly or quarterly monitoring routine, begin with the saved query rather than rebuilding it from memory. Run the same version, record the date and result count, and screen newly retrieved records using the same eligibility rules where possible. If you change the query, run the previous and revised versions during the transition and note what the change added or removed.

Before closing the project, complete this short action list:

1. Save the final search strings in a plain-text file and in the project record.
2. Record the database name, platform, search date, limits, and result count.
3. Export results with stable identifiers when available.
4. Document deduplication and citation-chasing steps separately.
5. Check whether known relevant articles were retrieved, and investigate any that were not.
6. Set a review date if the project will be updated.

A clear search log turns a one-time search into a reusable research tool. It helps you explain how the evidence was located, repeat the work after a break, adapt the strategy to another database, and identify exactly what changed when new scholarly articles appear.

If the search leads to publication, connect the documented strategy to your manuscript preparation process with this manuscript submission checklist. For journal selection after the review is complete, use a structured journal finder workflow rather than choosing solely by title or ranking.