Google Dorks Cheat Sheet: Advanced Search Operators for OSINT

What dorking actually is

A search engine crawls and indexes an enormous amount of the public web, including plenty of pages that were never meant to be found by a normal search — a misconfigured directory listing, an internal document uploaded without access controls, or a test page that was supposed to be temporary. A "dork" is simply a search query built with operators precise enough to surface that kind of content on purpose, instead of stumbling across it by accident.

The operators themselves are ordinary, documented search syntax — the same features a search engine offers anyone to narrow down results. What makes a query a "dork" is how deliberately it's aimed, not any special access or exploit.

The core operators

site: restricts results to a single domain or subdomain, so `site:example.com` shows only pages the search engine has indexed on that domain — useful for mapping what a specific organization or person has published.

filetype: restricts results to a specific file extension, so `site:example.com filetype:pdf` finds only PDF documents on that domain, which is one of the most common ways to turn up reports, resumes, or spreadsheets that were uploaded but never linked from a normal page.

intitle: restricts results to pages whose <title> tag contains the given word, so `intitle:"index of"` is a classic pattern for finding open, unlisted directory listings that a web server is exposing by default.

inurl: restricts results to pages whose URL contains a given string, so `inurl:admin site:example.com` looks for administrative or login pages on a domain rather than its regular content pages.

Quotation marks force an exact-phrase match, so `"jane smith" "acme corp"` only returns pages containing that exact combination of words rather than pages that merely mention both separately anywhere on the page.

A minus sign excludes a term, so `"jane smith" -linkedin` returns mentions of that exact name while filtering out a source you already know about and don't need to see again.

before: and after: restrict results to a date range around when a page was indexed, so `site:example.com after:2024-01-01` helps focus on more recent content when a domain has years of accumulated pages.

The wildcard operator (usually written as an asterisk) acts as a placeholder for an unknown word, so `"jane * smith"` matches an exact phrase with one unknown word in the middle — useful when you know the surrounding wording of a phrase but not every word in it. An OR search lets you check several alternatives in one query, so `intitle:resume OR intitle:cv "jane smith"` looks for either title wording rather than requiring a separate search for each.

Combining operators

Operators are additive, and most real queries stack several of them together. `site:example.com filetype:xlsx intitle:budget` narrows a search to spreadsheet files on one domain whose title mentions "budget" — three separate filters working together to cut an enormous index down to a handful of candidates.

Building queries like this is mostly a matter of thinking about what an accidentally exposed file tends to look like — its likely extension, a word likely to appear in its title or URL — rather than memorizing operator syntax from scratch. A dedicated dork-builder tool can help assemble these combinations without needing to recall the exact syntax for each operator every time.

Order and spacing matter less than people expect — most operators can be placed anywhere in the query and combined freely — but each operator narrows the result set further, so stacking too many at once can return nothing even when a looser version of the same query would have worked. If a heavily combined query comes back empty, it's usually worth dropping one operator at a time rather than assuming the target simply isn't indexed.

Using dorks defensively

The same operators that find someone else's exposed files also work on your own name, your own domain, or your own organization, which makes dorking a genuinely useful self-check rather than only an offensive technique. Running `site:yourdomain.com filetype:pdf` or `"your full name"` against your own footprint can surface a document, an old profile, or a mention you had forgotten was public.

Because a search engine's index is a snapshot that changes over time, a page that turns up in a dork today may already be gone by the time you look, and a page that was removed can still sometimes be checked in the Internet Archive's Wayback Machine, which keeps historical snapshots of pages independent of whether the live page still exists. Broader OSINT directories like the OSINT Framework are also useful alongside dorking, since they categorize other tools and data sources that complement a plain search-engine query.

If a self-check does turn up something exposed that shouldn't be — an old resume with your address on it, an internal document, a spreadsheet with contact details — the practical next step is usually a takedown or removal request to whoever hosts the file, plus a request to the search engine to remove the cached copy once the source is gone, since a de-indexed page can otherwise keep surfacing in searches for a while after it's actually been deleted.

Where the ethical line sits

Dorking only touches what a search engine has already indexed from public pages — it does not bypass a login, break an access control, or exploit a system. That said, finding a file someone clearly did not intend to expose still raises a judgment call about what to do next: downloading, publishing, or acting on sensitive information you find this way is a separate decision from simply locating it, and laws and norms vary by jurisdiction and by what the data actually is. See our guide to ethics and the law before using dorking on a target other than yourself.

Tools for this

Browse the full tools directory →

Related on this site

• Frameworks & aggregators
• Build a dork with our free tool
• What is OSINT?