You copy a dork from a list, run it, and get a page of ordinary results. Nothing errored, so you assume the target is clean. It probably is not — the operator you used was retired years ago and Google quietly ignored it. That silent failure is why most cheat sheets do more harm than good.
How to Use This Google Dorks Cheat Sheet
Organised by what you are looking for, not alphabetically by operator. That ordering matters, because nobody starts with "which operator" — they start with "how do I find X".
Two rules before anything else. Quote any value that must match literally, or Google will substitute related terms. And capitalise OR, because lowercase "or" becomes an ordinary search word and changes your query's meaning without warning.
Everything below assumes you are searching a domain you own or are authorised to assess. If you want them pre-filled and one click from running, the generator builds these dorks automatically.
Finding Documents and File Types
Format filters are the highest-yield category, because documents rank poorly and rarely surface otherwise.
| Query | What it surfaces |
|---|---|
site:example.com filetype:pdf | Every indexed PDF on the domain |
site:example.com filetype:xlsx | filetype:csv | Spreadsheets and data exports |
site:example.com ext:sql | ext:bak | Database dumps and backup copies |
site:example.com ext:env | ext:conf | Configuration files served as text |
site:example.com ext:log | Log files reachable over HTTP |
The filetype: and ext: pair deserves a note. Google documents the first and never documented the second, and in our experience ext: occasionally returns a slightly wider set. Try both before concluding nothing exists.
Expect false positives throughout this category. Published reports, price lists and sample configuration templates all match. Check whether values in a config file are real before treating a hit as an incident.
Google Dork Examples for Directory and Path Discovery
Path-based dorks find structure rather than content. They tell you what exists, which is often more useful than what it says.
site:example.com intitle:"index of"— folders rendering as browsable file listssite:example.com inurl:admin | inurl:login— authentication pages Google indexedsite:example.com inurl:.git— repository directories deployed alongside the sitesite:example.com -inurl:www— indexed content on other hosts, which surfaces staging
The directory listing query is the one we would run first on any unfamiliar domain. A single listing makes everything in that folder crawlable, so one hit frequently drags a whole backup directory into the index behind it.
One caution on inurl:. It matches anywhere in the URL including the domain itself, so on a short domain name the noise is considerable. Quote the value to tighten it.
OSINT Google Dorks for People and Organisations
Here the operators matter less than knowing where information collects. The query is easy; picking the right target is the skill.
Useful patterns include searching document metadata for author names, restricting to a company domain while excluding the marketing site, and bracketing a date range around a known event with before: and after:.
Be careful with those date filters. Google infers publication dates when a page does not declare one, and gets it wrong regularly on older content. They are fine for narrowing. They are not evidence of when anything was published.
The broader point: search is one OSINT source among many, and often not the best. Certificate transparency logs, code repositories and public filings each answer questions no query will.
Which Operators Are Dead and Still Get Published
Five appear in lists constantly and none of them work.
| Operator | Status |
|---|---|
cache: | Removed by Google. No direct replacement. |
link: | Dead for years, but still returns results — which is worse. |
related: | No longer supported. |
info: | Retired with the other diagnostic operators. |
~ and + | Both retired. Quotation marks replaced the plus sign. |
link: is the dangerous one. It returns output, people count it, and report a backlink figure that has meant nothing for a long time.
Our full operator reference tags every command with its current status, which is faster than testing each one yourself.
Turning This Into a Defensive Checklist
Every query above works better pointed at your own domain, because you know what should be there.
Findings on someone else's site need interpretation and raise questions about what to do next. Findings on your own site are unambiguous, and you can fix them the same afternoon.
We would run the file-type and directory-listing categories quarterly and after every migration. Migrations are where exposure appears — a backup gets copied into the web root, a config file rides along in a release. The audit set for a domain you own pairs each query with its specific fix.
If reconnaissance rather than defence is the goal, recon workflows that start with these queries covers sequencing on an authorised target.
Keeping a Dork List That Stays Useful
Five proven queries beat a thousand copied ones. Long lists feel like coverage and mostly are not — entries duplicate each other or died years ago.
Keep what has returned something real for you. Note what each one is for. Retest occasionally, because Google changes behaviour without announcing it and a query that worked last year may be quietly doing nothing.
New to the technique? A plain-English explanation of dorking covers what these queries can and cannot reach, which is worth understanding before you rely on a clean result.