# Test Search Operators Before a Recurring Research Workflow

Check your search queries against a small set of known relevant and irrelevant pages. Change one part of the query at a time. Inspect the returned pages, record what passed or remains unknown, and save the exact query settings. Start with a manual check of public pages. Use a small collection when you need saved result records. A missing known page does not prove that the query is wrong or that Google has not indexed the page.

A public researcher asks whether Google search operators sometimes stop working. That question points to a useful first step: separate a syntax check from a relevance check. Syntax means the required form of a query. Relevance means whether a page answers your research question. One unexpected result does not establish which problem occurred. [Public operator question — observed October 25, 2026; publication date unknown, one post does not establish demand or operator performance](https://www.reddit.com/r/searchengines/comments/1reqs02/google_search_operators_are_sometimes_not_working/)

The method below produces two records. The first is a query test table with reference pages and clear test states. The second is an accepted query panel: the small set of exact queries you choose for repeated research. No Actor collection occurred for this guide. The supplied product checks cover documented fields and input format only.

## 1. Define the decision before you write the query

Write one sentence that states what the search must help you decide. Name the page type you need and the pages you want to exclude.

For example, your decision might require public documentation pages that explain a named feature. A page that only mentions the feature in a sales offer might not meet that need. Decide this before you inspect search results.

Use these steps:

1. State the research question.
2. Name the required page type.
3. State the required topic or phrase.
4. State any required website or document format.
5. Define what makes a returned page useful.
6. Define what makes a returned page unsuitable.
7. State which missing evidence would prevent a decision.

Keep the scope clear. Public search can show candidate public pages. It does not give access to private account records or establish a complete list of a website’s pages. If your question concerns records in an account you own, inspect those records through that account. Do not use public search absence as proof about private records.

This guide checks query behavior and research fit. For the separate question of saving a search sample, use [the guide to bounded Google search exports](/en/articles/google-search-bounded-export/). An export count cannot establish whether your query finds the page types you need.

## 2. Choose positive and negative reference pages

A reference page is a page you inspect before the test. A positive reference is a page that meets your inclusion rule. A negative reference is a page that does not meet it.

These pages act as controls. A control is a known example used to help interpret a test. Choose a small set that you can check by hand.

1. Open each proposed positive page.
2. Confirm that it contains the information you need.
3. Save its exact web address and the reason it qualifies.
4. Open each proposed negative page.
5. Record why it does not qualify.
6. Save the date of your inspection.
7. Declare the reference set before you inspect query results.

A negative page should represent a real risk to your research. It might use the same phrase on an unrelated website. This helps you check whether a website restriction serves your purpose.

Keep page identity separate from page relevance. A title alone may not identify the intended page. Inspect the returned web address and the destination page when needed. If you cannot resolve the identity, record it as unknown.

Do not replace a missing positive reference with a convenient returned page and call the original test a pass. You can add a new reference later. Give the revised set a new version and explain the change.

## 3. Check Google’s documented operator behavior

A search operator is query text that asks a search engine to apply a restriction. Google documents quotation marks, `site:`, minus exclusions, `before:`, `after:`, and `filetype:`. Check the documentation for the engine you intend to use. Do not assume that another engine uses the same syntax or behavior. [Google search guidance — retrieved October 25, 2026; documents intended operator behavior, not results from this guide](https://support.google.com/websearch/answer/2466433)

| Query feature | Intended use | What to check |
| --- | --- | --- |
| Quotation marks | Search for an exact phrase | Whether the phrase matches your research need |
| `site:` | Restrict a search to a stated site | Whether returned addresses fit the requested site scope |
| Minus exclusion | Exclude a stated term | Whether that term also occurs on useful pages |
| `filetype:` | Request a document type | Whether that format serves the decision |
| `before:` and `after:` | Restrict by document update dates | Whether update dates answer your question |

Do not put a space between an operator and its value. For example, keep `site:docs.example.com` together. Google’s guidance states that the symbol or operator word must remain attached to the search term. [Google syntax guidance — retrieved October 25, 2026; syntax rules do not guarantee a particular returned page](https://support.google.com/websearch/answer/2466433)

Use date operators only when document update dates matter. Do not describe their results as a verified set of original publication dates.

The main limit for your positive control is important: Google says `site:` results are not exhaustive. An indexed address is not guaranteed to appear in a `site:` query. Thus, a missing positive page leaves that inclusion check inconclusive. It does not prove that the page is unindexed. [Google Search Central guidance — retrieved October 25, 2026; `site:` results are not exhaustive or a complete index count](https://developers.google.com/search/docs/monitor-debug/search-operators/all-search-site)

## 4. Write query variants with one change each

A query variant is one version of the search text. Change one feature between comparable variants. This makes an unexpected result easier to investigate.

A useful sequence is:

1. Start with a plain phrase.
2. Add a site restriction to that phrase.
3. Add quotation marks around the phrase while keeping the site restriction.
4. Add another operator only if the research decision requires it.

Save the full text of each query. A note such as “site test” is not enough to repeat the search.

Keep the engine, country, language, result limit, and other settings the same during the comparison. Record any setting you cannot confirm. If you change a setting, treat the next collection as a changed test.

A result cap is the maximum number of results requested for each executed query. An executed query is the search text attached to a collected result. A small cap lets you inspect each returned record. It also limits what you can conclude about missing pages.

Exact phrases can help define a narrow need. They can also leave useful wording outside that scope. If you need a second phrase, test it as a separate query. The [Reddit keyword test guide](/en/articles/reddit-noise-query-tests/) explains why a useful wording change can still miss another problem type. Its Reddit results do not verify Google operators.

## 5. Make a small manual check or proposed Actor collection

For a few query variants, first run the searches manually and inspect the returned public pages. Save the query, settings you can identify, inspection time, and page-level notes. This directly answers a small query-design question.

When you need stored result rows, the documented Chronometrica Google Search Scraper provides fields that fit this method. An Actor is a hosted data collection program. It supplies search records; you still judge relevance, inspect reference matches, and choose the accepted queries.

The supplied small input is:

```json
{"country":"US","engines":["google"],"language":"en","maxResultsPerExecutedQuery":3,"queries":["site:developers.google.com \"site:\""]}
```

5. Make a small manual check or proposed Actor collection

JSON is a text format for named values and lists. This input requests Google, United States and English settings, and a cap of three results for the query. The query concerns the phrase `site:` within the stated Google documentation site. It is a starting example, not proof that a particular documentation page will appear.

Replace the sample values in this order:

1. Replace the query in `queries` with your first declared variant.
2. Keep `engines` set to `["google"]` for this Google test.
3. Keep or replace `country` and `language` to match your intended research.
4. Start with `maxResultsPerExecutedQuery` set to 3.
5. Save the full input before collection.
6. Test the other variants with the same settings.

The checked cap range is 1 to 100. The supplied input passed a static schema check. A schema is a set of rules for data fields and values. A static check examines the input without running the collection. It does not prove live results, complete coverage, or successful operation. [Public default build 1.0.15 — checked October 25, 2026; input and output contract inspected, no live collection](https://api.apify.com/v2/acts/mlmVX4amk2biciJaB/builds/default)

A Task is a saved input preset for an Actor. The public Multi-Engine Search Results Scraper Task can serve as a starting point. Its page and exact Task ID were checked. Its current saved settings were not verified. Inspect and replace those settings before use; do not assume they match this example. [Multi-Engine Search Results Scraper Task — checked October 25, 2026; page presence verified, saved input and runtime unverified](https://apify.com/chronometrica/google-search-scraper/examples/multi-engine-search-results-scraper)

## 6. Save source fields and your own test decisions

Keep original result records separate from your review notes. The checked product contract declares these fields for the method:

| Source field | What to retain |
| --- | --- |
| `engine` | Engine attached to the result |
| `executedQuery` | Exact executed query |
| `canonicalUrl` | Returned result address |
| `resultDomain` | Returned result domain |
| `title` | Returned title |
| `snippet` | Returned text, including a supplied null value |
| `rank` | Running position among supported result blocks parsed across fetched pages |
| `isSponsored` | Returned sponsored-result flag |
| `observedAt` | Recorded observation time |

These are documented fields, not observed output from a run for this guide. [Public default build 1.0.15 — checked October 25, 2026; declared result fields only, no runtime output verified](https://api.apify.com/v2/acts/mlmVX4amk2biciJaB/builds/default)

A sponsored result is a paid result. Preserve its flag when you review relevance. Keep the source `rank` as a recorded position. Do not use it as a relevance score. The [Bing rank snapshot guide](/en/articles/web-rank-snapshots/) covers a separate rank-comparison task. This Google control test does not measure rank stability.

Add these review fields in your own sheet:

| Review field | What to record |
| --- | --- |
| Test version and purpose | The declared decision and reference-set version |
| Query variant | Exact query and the one change made |
| Settings and cap | Engine, country, language, limit, and other known settings |
| Reference pages | Positive and negative addresses with reasons |
| Collection evidence | Saved input, actual returned rows, known collection state, and time |
| Reference outcome | Found, not seen in the sample, or identity unresolved |
| Relevance | Relevant, irrelevant, or unknown, with a reason |
| Test state | Pass, fail, or unknown for each declared check |
| Next decision | Accept, revise, investigate, or hold |

If a time is missing, leave it unknown. You may add your inspection time in a separate field. Do not put it into `observedAt` as though the source supplied it.

A null `snippet` is missing text, not proof of an empty destination page. A missing result count is unknown. Record zero only when you have evidence that the defined collection saved zero rows.

## 7. Apply clear pass, fail, and unknown rules

Separate the positive-page check from the restriction check.

| Check | Pass within the sample | Fail within the sample | Unknown or inconclusive |
| --- | --- | --- | --- |
| Positive reference | Declared page is identified | Do not infer failure from absence alone | Page is not seen or its identity is unclear |
| Site restriction | All inspected result addresses fit the declared site scope | A checked destination falls outside that scope | Destination identity cannot be resolved |
| Research relevance | Inspected page meets the inclusion rule | Inspected page does not meet the rule | Required page evidence is unavailable |
| Collection readiness | Available evidence supports review of the saved sample | Collection evidence shows a failure | Collection state or necessary records are unclear |

A site restriction pass means that the inspected sample met the rule. It does not prove that every future result will meet it.

If an unrelated domain appears, inspect the returned address and destination before diagnosing the syntax. If collection fails, keep that failure separate from a zero-result observation. If the known page is missing, retain the original test and its inconclusive state.

Do not calculate a Google false-negative rate from one missing reference. A false negative would mean a relevant item was wrongly excluded under a defined measurement. This small reference check does not establish Google’s full relevant-page population.

## 8. Worked example: an inconclusive variant stays inconclusive

Original fiction. Every page, query result, count, and decision in this example is invented for teaching. This is not an Actor run, customer result, or observed company finding.

A researcher wants public documentation about access setup. They declare two reference pages:

- Positive: `https://docs.example.com/guide`, a checked documentation page about access setup.
- Negative: `https://other.example.com/guide`, an unrelated page that uses the same phrase.

They write three variants. Each step changes one feature:

| Variant | Exact query | Change |
| --- | --- | --- |
| Q1 | `access setup guide` | Plain phrase |
| Q2 | `site:docs.example.com access setup guide` | Add site restriction |
| Q3 | `site:docs.example.com "access setup guide"` | Add phrase quotes |

All three fictional collections use Google, United States and English settings, and a cap of three observations per query. One observation means one saved result record.

| Variant | Saved observations | Reference outcomes | Review decision |
| --- | --- | --- | --- |
| Q1 | 3 | Positive and negative both appear | Broad phrase includes an unsuitable page |
| Q2 | 2 | Neither reference appears; both returned addresses fit the site scope | Site check passes within this sample; positive check is inconclusive |
| Q3 | 1 | Positive appears; negative does not appear | Positive check passes; site check passes within this sample |

The fictional relevance labels are one relevant, one irrelevant, and one unknown observation for Q1. Q2 has one relevant and one unknown observation. Q3 has one relevant observation.

The arithmetic is:

- Requested allowance: 3 queries × 3 observations per query = 9 observations.
- Saved records: 3 + 2 + 1 = 6 observations.
- Relevant records: 1 + 1 + 1 = 3 observations.
- Irrelevant records: 1 + 0 + 0 = 1 observation.
- Unknown records: 1 + 1 + 0 = 2 observations.
- Label check: 3 + 1 + 2 = 6 observations.
- Unused allowance: 9 − 6 = 3 observations.

Those three unused observation slots are not three known missing pages. The six records are result observations, not six people or necessarily six different pages. The same positive page appears under Q1 and Q3.

The researcher accepts Q3 for the narrow exact-phrase task in this fictional sample. They retain Q2 as inconclusive for the positive reference. Q3 does not repair Q2’s missing result. This choice does not establish that Q3 is generally superior or complete.

## Choose the next query panel

Accept a query panel only when each query serves a stated need. Keep its exact text, settings, reference pages, source records, review labels, and unresolved checks together. Hold any query whose missing evidence prevents the research decision.

For your next small saved test, use the [Chronometrica Google Search Scraper — contract checked October 25, 2026; no live collection for this guide](https://apify.com/chronometrica/google-search-scraper). Replace the sample query, retain the small cap, and inspect every returned record. The documented fields support your review; they do not perform or approve that review.

Review the panel when observed behavior changes. Save the new test beside the old one. Keep earlier unknown states visible. Expand repeated collection only after the small test supports your stated research use.

## Sources

- [Google: Refine Google searches — retrieved October 25, 2026; intended syntax and operator behavior, not a live test](https://support.google.com/websearch/answer/2466433)
- [Google Search Central: site: search operator — retrieved October 25, 2026; results are not exhaustive and do not establish complete indexing](https://developers.google.com/search/docs/monitor-debug/search-operators/all-search-site)
- [Chronometrica Google Search Scraper — contract checked October 25, 2026; documented product fit, no live collection or coverage claim](https://apify.com/chronometrica/google-search-scraper)
- [Public default build 1.0.15 — checked October 25, 2026; static input validation and declared output fields, no runtime verification](https://api.apify.com/v2/acts/mlmVX4amk2biciJaB/builds/default)
- [Multi-Engine Search Results Scraper Task — checked October 25, 2026; public page and exact Task ID verified, current saved settings unverified](https://apify.com/chronometrica/google-search-scraper/examples/multi-engine-search-results-scraper)
- [Public Google operator question — observed October 25, 2026; publication date unknown, wording evidence only](https://www.reddit.com/r/searchengines/comments/1reqs02/google_search_operators_are_sometimes_not_working/)