Google Dorks / Search Operators

OSINTRECONEXTERNALWEB

NOTES

Google dorking is structured search, not a vulnerability by itself. I use it during authorized reconnaissance to understand what a search engine has indexed for an in-scope organization: public documents, forgotten hostnames, login surfaces, old paths, exposed directory listings, and technology clues.

Every query starts with a domain I own or am explicitly allowed to assess. Search results can be stale, incomplete, or misleading, so I treat them as leads to validate inside scope—not proof of impact.

CORE OPERATORS

Limit the scope

site:example.com

Restricts results to the authorized domain. Use a leading minus to omit a noisy host or term.

site:example.com -www
site:example.com -"privacy policy"

Match a phrase or alternatives

site:example.com "exact phrase"
site:example.com (docs OR support)

Quotes keep a phrase together. Uppercase OR is useful when two terms describe the same lead.

Look at titles, URLs, and document types

site:example.com intitle:portal
site:example.com inurl:docs
site:example.com filetype:pdf

intitle: searches page titles, inurl: searches indexed URLs, and filetype: narrows results to a document format.

Bound results by date

site:example.com after:2025-01-01
site:example.com before:2026-01-01 after:2025-01-01

Date filters can reduce noise when looking for a recent migration, release, or documentation change. Indexed and published dates do not always mean the same thing.

QUERY RECIPES

Public documents

site:example.com (filetype:pdf OR filetype:docx OR filetype:xlsx)
site:example.com (filetype:pptx OR filetype:csv)

Authentication and administration surfaces

site:example.com (inurl:login OR inurl:signin OR inurl:portal)
site:example.com (intitle:admin OR intitle:dashboard)

Subdomains and non-default hosts

site:*.example.com -www
site:example.com -site:www.example.com

Directory listings and indexed configuration formats

site:example.com intitle:"index of"
site:example.com (filetype:xml OR filetype:json OR filetype:yml)

Finding a result does not authorize retrieving sensitive material. Capture the smallest evidence needed, avoid opening exposed secrets, and report the indexing problem through the agreed channel.

WORKFLOW

  1. Write the approved root domain and exclusions at the top of the notes.
  2. Start with a plain site: query and record unusual hosts, paths, titles, and file types.
  3. Add one operator at a time so it is clear which constraint changed the result set.
  4. Use safe placeholders in reusable notes; keep client names and sensitive results in the assessment workspace.
  5. Validate an interesting result against the live, authorized asset before treating it as current.
  6. Record the query, result URL, observation date, and why the result matters.

GOTCHAS

PRIMARY REFERENCES

← Back to Resources