How it works
Google dorks are advanced search queries built from operators that narrow results to very specific pages: site: limits to a domain, filetype: to a format, inurl: and intitle: to URL and title text, intext: to body content, quotes for exact phrases and - to exclude terms. Combined, they surface things site owners forgot were public — exposed configuration files, directory listings, backup archives, error pages leaking stack traces.
The builder assembles those operators for you: fill the fields, watch the query render, copy it, or open it directly in Google. No syntax to memorize, and no risk of an operator silently invalidating the whole query because of a stray space.
The preset library covers the classic exposure patterns: .env files, exposed .git directories, SQL dumps, log and config files, phpinfo pages, directory indexes and admin panels. One click loads the dork into the output and copies it — the fast path when you are auditing several of your own domains in a row.
Authorized use. Dorking is just search — the legitimate, high-value use is auditing your own attack surface: finding what Google indexed on your domains before someone else does. The defense section below explains how to fix and prevent each exposure pattern.
Worked example
Audit your own domain for exposed environment files: set site to yourdomain.com, phrase to DB_PASSWORD, inurl to .env.
| Field | Value | Query fragment |
|---|---|---|
| site | yourdomain.com | site:yourdomain.com |
| inurl | .env | inurl:.env |
| Exact phrase | DB_PASSWORD | "DB_PASSWORD" |
- Set the scope: Put your own domain in site: and any file type or path hint.
- Add evidence terms: Phrases like DB_PASSWORD or "index of" target real exposures.
- Copy or open: Copy the dork or launch it in Google directly from the tool.
- Fix what you find: Rotate secrets, remove files, verify with curl, request removal.
Result: site:yourdomain.com inurl:.env "DB_PASSWORD". Any hit means a real secret is publicly indexed — rotate the credential immediately, remove the file, then request removal in Search Console. The same pattern works for AWS_SECRET, API_KEY and PRIVATE KEY.
Common errors and edge cases
- Operators take no space after the colon.
site: example.comsilently breaks the operator —site:example.comis required. The builder handles this for you. - Dorks find indexed pages only. A clean result does not prove a file is safe — it may be unlinked or freshly exposed. Pair dorks with your own directory scans and log reviews.
- OR needs parentheses.
filetype:sql OR filetype:bak backupscopes the last term oddly; group alternatives explicitly. - Indexed ≠ still live. Cached results linger after removal. Verify with a direct request, then use Google's removal tools for urgent takedowns.
- Defense: robots.txt is not enough. Disallow prevents crawling but not indexing of linked URLs, and it advertises your sensitive paths. Use noindex plus real access control for anything secret.
Code equivalents
The same operators work programmatically through official APIs, which is how you monitor exposure continuously instead of by hand.
| Tool | Usage |
|---|---|
| Google Programmable Search | GET https://www.googleapis.com/customsearch/v1?q=site:yourdomain.com+filetype:env&key=...&cx=... — automate weekly self-audits. |
| Search Console | Coverage and Removals reports: what is indexed, plus urgent takedown requests for exposed URLs. |
| curl (verify) | curl -sI https://yourdomain.com/.env — a 200 here is an incident, regardless of search results. |
Related tools
Frequently asked questions
Are Google dorks legal to use?
Searching a public engine is legal in most jurisdictions; accessing systems you find may not be. The intended use here is auditing your own domains and assets you have written permission to test.
What are the most useful operators to learn first?
site:, filetype:, inurl:, intitle:, exact-phrase quotes and the minus exclusion. Those six cover the vast majority of exposure-hunting queries.
My site appears in an exposure dork — what do I do first?
Rotate any leaked credential immediately, remove or protect the file, verify the fix with a direct request, then request removal in Search Console. Investigate how it was indexed — usually a deploy mistake or a missing access rule.
Why does robots.txt not protect my .env file?
robots.txt is a crawl hint, not access control: it stops well-behaved bots from fetching but does not prevent indexing of linked URLs, and it lists your sensitive paths publicly. Use server-side denial plus noindex.
How do I monitor new exposures over time?
Schedule weekly self-audit queries through the Programmable Search API for your domains, alert on any hit for .env, .git, filetype:sql and backup patterns, and keep Search Console coverage under review.
Privacy note
All processing happens in your browser. The values you enter never leave your device and are never transmitted to ToolPlex.