What Is a Google Dork?
A Google Dork (or “dork query”) is a search string built from Google’s advanced search operators, like site:, filetype:, intitle:, and inurl:, used to find specific, often unintentionally exposed, content that Google has already crawled and indexed.
Google dorking does not hack anything. It doesn’t bypass a login, exploit a vulnerability, or inject code. It queries data that a search engine already collected from publicly accessible pages. The skill lies in knowing which operator combinations surface high-value results, exposed configuration files, open directories, login portals, or leaked credentials that a site owner never meant to be searchable.
Security researchers, penetration testers, bug bounty hunters, journalists, and OSINT (open-source intelligence) analysts all use the same core operators for reconnaissance, attack-surface mapping, and investigative research. The technique is documented in the Google Hacking Database (GHDB), originally compiled by Johnny Long in the early 2000s and maintained under Exploit-DB since 2010.
Why it still matters in 2026
dorking remains the fastest, zero-cost way to map an organization’s public attack surface before any active scanning begins. It’s also a foundational OSINT skill taught in nearly every cybersecurity certification track. This guide gives you the full, current operator list, real examples, the legal boundaries you need to respect, and a printable reference you can keep at your desk.
The technique is documented in the Google Hacking Database (GHDB), originally compiled by Johnny Long in the early 2000s, handed to Offensive Security in 2010, and maintained under Exploit-DB ever since. Security researchers, penetration testers, journalists, and OSINT analysts use the same operators for reconnaissance, attack-surface discovery, and open-source intelligence gathering.
How Google Dorking Works
Google indexes publicly accessible pages, files, and metadata across the web. Dork operators combine keywords with filters (site:, filetype:, intitle:, inurl:, intext:) to narrow that massive index down to a precise, targeted result set.
For example, a dork looking for PDF files on a specific domain containing the word “confidential” combines a domain filter, a file-type filter, and a keyword search into one query. The operator does the filtering; Google’s existing crawl does the work. Nothing is bypassed or exploited; the query only surfaces what a site owner already allowed search engines to crawl and cache.
Does Google Dorking Still Work in 2026?
Yes, with caveats. The core operators (site:, filetype:, intitle:, inurl:, intext:) function exactly as before. What’s changed is the tooling and reliability around a few edge features.
| Change | Impact on Dorking in 2026 |
| Deprecation of the public cache: operator (2024) | Cached-page retrieval must go through the Wayback Machine or third-party cache tools |
| Stricter rate-limiting on automated queries | Bulk/automated dorking triggers CAPTCHAs faster than in 2022–2023 |
| AI Overviews reordering result snippets | Raw dork results still return, but snippet display can bury exact-match text, click through to organic results |
| Improved server-side hardening (robots.txt, auth walls) | Fewer raw open directories and unprotected admin panels than in the 2010s |
| Continued GHDB curation | New categories added regularly for exposed APIs, cloud storage buckets, and IoT panels |
Bottom line: core operator syntax hasn’t changed. Automation- and cache-dependent dorking now requires more workaround tooling than in prior years; see the Tools section below.
What Is the GHDB (Google Hacking Database)?
The Google Hacking Database (GHDB) is the authoritative, public, categorized archive of Google Dorks, maintained under Exploit-DB (Offensive Security) and hosted at exploit-db.com/google-hacking-database.
- Origin: Compiled and popularized by Johnny Long (author of Google Hacking for Penetration Testers), who built and maintained the original public list from the early 2000s.
- Handover: In 2010, Long transferred maintenance to Offensive Security, the team behind Kali Linux and the OSCP certification, and it has been hosted on Exploit-DB ever since.
- Scale: Thousands of cataloged dorks, with new entries submitted continuously and curated by Exploit-DB before going live.
- Tool integration: The Metasploit Framework includes a search module that pulls GHDB queries directly; Recon-ng can fetch entries through its module system; Kali Linux and BlackArch ship with GHDB-aware tooling preinstalled.
Key distinction: Google Dorks are the queries themselves, the GHDB is a specific, curated collection of those queries.
GHDB’s 14 Official Categories (with Example Dorks)
| #Sr | Category | What It Exposes | Example Dork |
|---|---|---|---|
| 1 | Footholds | Entry points for establishing initial access | intitle:”index of” “shell.php” |
| 2 | Files Containing Usernames | Exposed username lists | filetype:txt “usernames.txt” |
| 3 | Sensitive Directories | Unprotected folders leaking internal data | intitle:”index of” “backup” |
| 4 | Web Server Detection | Server software/version fingerprinting | intitle:”Apache Status” inurl:”server-status” |
| 5 | Vulnerable Files | Known-vulnerable scripts/files still live | inurl:”install.php” intitle:”install” |
| 6 | Vulnerable Servers | Servers matching known CVE-exposed configs | intitle:”phpMyAdmin” “Welcome to phpMyAdmin” |
| 7 | Error Messages | Debug/error output revealing stack details | intext:”Warning: mysql_connect()” |
| 8 | Files Containing Juicy Info | Config/env files with secrets | filetype:env “DB_PASSWORD” |
| 9 | Files Containing Passwords | Direct credential leaks | filetype:sql intext:”password” |
| 10 | Sensitive Online Shopping Info | Exposed payment/order data | filetype:xls intext:”credit card” |
| 11 | Network or Vulnerability Data | Scan logs, firewall/network reports | filetype:log intext:”Nmap scan report” |
| 12 | Pages Containing Login Portals | Discoverable admin/login entry points | intitle:”login” inurl:admin |
| 13 | Various Online Devices | Exposed cameras, routers, IoT panels | intitle:”Live View” intext:”Network Camera” |
| 14 | Advisories and Vulnerabilities | Published security advisories referencing a target | intext:”security advisory” site:example.com |
Cross-check any dork here against the live GHDB before use, Google’s indexing behavior shifts over time, and entries are periodically retired or updated by Exploit-DB’s moderators.
Is Google Dorking Legal? Ethics & Rules
Is Google Dorking Legal?
Using Google’s public search operators is not illegal; you are using a search engine as intended. Legality depends entirely on what you do with the information you find and how you access it.
| Activity | Legal Status |
|---|---|
| Running a dork query on Google | Legal, standard search usage |
| Viewing a publicly indexed, unauthenticated file | Generally legal |
| Downloading/using exposed credentials, API keys, or PII | Illegal in most jurisdictions (unauthorized access, CFAA in the US, Computer Misuse Act in the UK, similar statutes elsewhere) |
| Using found credentials to log into a system | Illegal, unauthorized computer access |
| Dorking as part of an authorized penetration test | Legal, provided a signed scope/rules-of-engagement exists |
| Dorking someone’s personal data for harassment or stalking | Illegal in nearly all jurisdictions, regardless of “public” data status |
Key principle: the operator is legal; the action taken with results determines legality. Finding an exposed database is not a crime. Extracting, distributing, or exploiting its contents almost always is.
Ethical Standards & Responsible Disclosure
- Authorization first. Only dork against systems you own or have written permission to test.
- No exploitation. If you find exposed credentials, secrets, or PII, do not log in, download, or redistribute them.
- Report, don’t publish. Use responsible disclosure: contact the site owner, their security team, or a CERT (e.g., US-CERT, national CERTs) before any public write-up.
- Follow a disclosure timeline. Standard practice is 30–90 days notice before public disclosure, per common vulnerability disclosure norms (ISO/IEC 29147 guidance).
- Document, don’t hoard. Keep evidence limited to what’s needed to prove the issue exists (a screenshot, a URL), not full data dumps.
- Respect robots.txt and ToS when running any automated dork tooling.
Core Google Dorks Cheat Sheet
Basic Search Operators
| Operator | Function | Example |
|---|---|---|
| “…” | Exact phrase match | “employee handbook 2026” |
| – | Exclude a term | budget -template |
| OR / | | Match either term | login OR signin |
| * | Wildcard placeholder | “* is the CEO of Tesla” |
| .. | Number range | camera $100..$300 |
| AROUND(n) | Terms within n words of each other | security AROUND(3) breach |
Top 20 Most Useful Google Dorking Commands
This is the fastest way to get productive with a Google dorking commands cheat sheet: the 20 queries that cover the vast majority of real-world recon and OSINT work.
| # | Dork | Purpose |
|---|---|---|
| 1 | site:example.com | Restrict results to one domain |
| 2 | intitle:”index of” | Find open directory listings |
| 3 | filetype:pdf site:example.com | Find PDFs on a domain |
| 4 | inurl:admin | Find admin login pages |
| 5 | intext:”password” | Find pages containing the word “password” |
| 6 | site:pastebin.com “example.com” | Find leaked data referencing a domain |
| 7 | filetype:env “DB_PASSWORD” | Find exposed environment files |
| 8 | inurl:wp-content filetype:log | Find exposed WordPress logs |
| 9 | intitle:”login” inurl:admin | Find restricted admin portals |
| 10 | site:s3.amazonaws.com “example” | Find exposed AWS S3 buckets |
| 11 | filetype:sql “INSERT INTO” | Find exposed SQL dump files |
| 12 | inurl:”/phpinfo.php” | Find exposed server configuration pages |
| 13 | intitle:”index of” “backup” | Find exposed backup directories |
| 14 | filetype:xls intext:”@gmail.com” | Find spreadsheets with exposed email lists |
| 15 | site:linkedin.com “name” “job title” | Professional/OSINT profile search |
| 16 | inurl:config filetype:json | Find exposed JSON configuration files |
| 17 | intext:”api_key” filetype:env | Find exposed API keys |
| 18 | site:github.com “password” filename:.env | Find leaked secrets in public repos |
| 19 | inurl:”.git” -github.com | Find exposed .git repository folders |
| 20 | filetype:log inurl:”error_log” | Find exposed error logs |
Full Operator Reference Table
| Operator | Description | Example | Notes |
|---|---|---|---|
| site: | Limit search to one domain/subdomain | site:blog.example.com | Most-used operator |
| inurl: | Term must appear in the URL | inurl:login | Great for finding panels |
| intitle: | Term must appear in page <title> | intitle:”index of” | Core for directory listing dorks |
| intext: | Term must appear in body text | intext:”confidential” | Broad but effective |
| filetype: | Restrict to a file extension | filetype:pdf | Works with doc, xls, sql, env, log, json, config |
| ext: | Alias of filetype: | ext:php | Interchangeable |
| link: | Pages linking to a URL | link:example.com | Largely deprecated/unreliable since 2017 |
| cache: | View Google’s cached version | cache:example.com | Deprecated for public use as of 2024; use Wayback Machine instead |
| related: | Find sites similar to a domain | related:example.com | Limited accuracy post-2020 |
| info: | Summary info Google has on a URL | info:example.com | Rarely used now |
| define: | Dictionary definition | define:phishing | Non-security use |
| numrange: | Numeric range search | numrange:100-200 | Rare, mostly superseded by .. |
| allintitle: | All terms must be in the title | allintitle:admin login panel | Stricter than intitle: |
| allinurl: | All terms must be in the URL | allinurl:admin config | Stricter than inurl: |
| allintext: | All terms must be in body text | allintext:username password | Stricter than intext: |
| before: / after: | Restrict by date | after:2025-01-01 | Effective for custom date ranges |
Site Search (Google Dork Search in Site)
site: is the anchor operator for scoped reconnaissance. Combine it with other operators to narrow further:
site:example.com filetype:pdf
site:example.com inurl:admin
site:*.example.com -www
The third example expands to all subdomains while excluding the main www host, useful for subdomain enumeration during OSINT recon.
Intitle and Inurl
intitle:”index of” “parent directory”
inurl:login inurl:admin
intitle:”phpMyAdmin” inurl:”main.php”
intitle: filters by page title; inurl: filters by URL path. Stacking both narrows results to pages that are both named and routed the way you expect (e.g., real admin panels vs. blog posts mentioning “admin”).
Filetype Search
filetype:pdf “confidential”
filetype:xlsx intext:”password”
filetype:docx “internal use only”
filetype:env “SECRET_KEY”
Common high-value extensions for security recon: pdf, doc/docx, xls/xlsx, sql, log, env, json, config, bak, ini.
Link and Cache
link:example.com
cache:example.com
Both are unreliable in 2026. link: was deprecated for general use years ago and now returns partial or no data. cache: was removed from public Google Search in 2024, use the Wayback Machine (web.archive.org) or third-party cache viewers instead for historical snapshots.
Operator Stacking
Combine multiple operators for precision. Order does not matter, but fewer, more specific terms produce cleaner results:
site:example.com filetype:sql intext:”INSERT INTO” -github.com
inurl:wp-admin intitle:”login” site:*.example.com
filetype:log inurl:”debug” intext:”Traceback”
Custom Date Ranges
site:example.com after:2025-01-01 before:2026-01-01
“data breach” after:2025-06-01
after and before: accept YYYY-MM-DD format and are the most reliable way to scope dorks to recent disclosures, recent leaks, or a specific incident window.
Tools for Google Dorking
Manual browser queries work for one-off checks. For recurring recon or bug bounty work, dedicated tooling scales better and avoids CAPTCHA lockouts:
| Tool | Type | Purpose |
|---|---|---|
| Google Hacking Database (GHDB) | Reference archive | Curated, categorized master list of dork queries, 14 categories, hosted on exploit-db.com |
| Metasploit Framework | Pentest framework | Built-in search module pulls GHDB queries directly into recon workflows |
| Recon-ng | CLI (Python) | Fetches GHDB entries via its module system for automated OSINT recon |
| Pagodo | CLI (Python) | Automates GHDB-based dork queries against a target domain |
| DorkSearch.com | Web tool | Browser-based dork builder with saved query templates |
| dork-cli | CLI (Python) | Lightweight scripted dork runner with rate-limit handling |
| Google Custom Search JSON API | API | Official, rate-limited way to run dork queries programmatically without CAPTCHA issues |
| Shodan / Censys | Search engine | Complements dorking with device/service-level scanning outside Google’s index |
| theHarvester | CLI (Python) | Automates email/subdomain harvesting, often paired with dork output |
| BinGoo | CLI (Bash) | Cross-engine (Google + Bing) dork automation script |
Note: Any tool that automates queries against Google directly (not via the official API) risks violating Google’s Terms of Service and triggering IP-level CAPTCHA blocks. Use the Custom Search JSON API for sustained/automated work.
Common Mistakes to Avoid
- Over-stacking operators. Five or more combined operators often return zero results, narrow gradually instead.
- Forgetting exact-phrase quotes. intext:confidential report searches two separate terms; intext:”confidential report” searches the phrase.
- Confusing filetype: with file content. filetype:pdf matches the file extension, not necessarily the true file format, a mislabeled file can still slip through.
- Ignoring CAPTCHA signals. Repeated rapid queries from a single IP trigger CAPTCHA walls quickly in 2026, space out manual queries or use the official API.
- Trusting cache: results. The operator is deprecated for public use; results are unreliable or blank. Use the Wayback Machine instead.
- Skipping manual verification. Automated dork scanners can return false positives (decoy pages, honeypots, expired content), always confirm manually before reporting.
- Downloading exposed data “just to check.” Even opening and saving a leaked file can constitute unauthorized access in some jurisdictions, view, document, report; don’t collect.
How to Google Dork Properly
Step-by-step methodology for clean, low-noise results:
- Define scope. Decide the target domain, file type, or data category before writing any query. Vague dorks return noise.
- Start broad, then narrow. Begin with site:target.com, review results, then add filetype:, inurl:, or intext: incrementally.
- Use exact phrases. Wrap multi-word terms in quotes (“confidential report”) to avoid partial matches.
- Exclude noise. Use – to remove irrelevant subdomains, file hosts, or common false positives (e.g., -github.com, -w3schools.com).
- Stack operators sparingly. Two to four operators per query is usually optimal, more than that often returns zero results.
- Verify manually. Never trust a dork result blindly, open the page (safely) to confirm it’s a genuine exposure, not a decoy or honeypot.
- Log your queries. For authorized engagements, keep a query log for the final report and for reproducibility.
- Respect scope boundaries. Stop at discovery. Do not download, log in, or interact beyond confirming the exposure exists.
Google Dorking Cheat Sheet by Use Case
Restricted Login Portals
inurl:admin intitle:”login”
inurl:”/wp-login.php”
inurl:”cpanel” intitle:”login”
Used to identify exposed administrative entry points during authorized attack-surface mapping.
Open Directories
intitle:”index of /” “parent directory”
intitle:”index of” “backup.zip”
Open directories occur when a web server lists folder contents instead of serving an index page, a common misconfiguration.
Exposed SQL Databases
filetype:sql “INSERT INTO” “password”
filetype:sql intext:”CREATE TABLE” site:example.com
Flags accidentally published database dumps, often from unsecured backup scripts.
Full Tech Stack Discovery
intitle:”phpinfo()” inurl:”phpinfo.php”
intext:”Powered by” filetype:txt
inurl:”/server-status” intitle:”Apache Status”
Reveals server software, PHP configuration, and version banners, standard passive reconnaissance for pentest scoping.
Leaked Credentials and Tokens
filetype:env “DB_PASSWORD”
intext:”api_key” filetype:json
site:pastebin.com “password” “example.com”
Used almost exclusively in authorized security assessments or breach-monitoring workflows, never to log in with discovered credentials.
Published Sensitive Files
filetype:xlsx intext:”salary”
filetype:pdf “internal use only” site:example.com
filetype:doc “confidential” site:example.com
Common in compliance audits checking for accidental publication of HR, financial, or legal documents.
Exposed API Keys
filetype:json “aws_secret_access_key”
intext:”Authorization: Bearer” filetype:log
site:github.com filename:.env “API_KEY”
GHDB tracks entire categories dedicated to leaked cloud credentials, one of the fastest-growing dork categories since 2022.
Google Dork Email Search
site:example.com intext:”@example.com”
filetype:xls intext:”@gmail.com”
“contact us” intext:”@example.com” site:example.com
Useful for legitimate contact-discovery during authorized OSINT or B2B outreach research. Scraping emails for spam or unsolicited contact violates most anti-spam laws (CAN-SPAM, GDPR, CASL).
Google Dorking Name Search
“John Smith” site:linkedin.com
“John Smith” filetype:pdf resume
intext:”John Smith” site:example.com
Common in due-diligence research, recruitment screening, and journalism. When applied to private individuals without a legitimate purpose, this crosses into privacy-invasive territory, treat name-based dorking with the same consent standards as any background check.
Google Dork Phone Number Free
intext:”phone” filetype:xls site:example.com
“+1″ intext:”contact” site:example.com
filetype:vcf intext:”TEL”
These patterns surface accidentally published contact lists (e.g., exported spreadsheets, vCard files). They are not a tool for locating a private individual’s personal number, using them that way risks violating harassment and stalking statutes, regardless of whether they are framed as “free” or “public”.
Google Dorking Cheat Sheet Android (Mobile Usage Notes)
Dorking works identically on Android via the Chrome or Google app, with practical adjustments:
| Consideration | Mobile Note |
|---|---|
| Operator syntax | Identical to desktop, no mobile-specific operators |
| Long dork strings | Use a dedicated notes app to store reusable dorks, then paste into the search bar |
| CAPTCHA frequency | Higher on mobile carrier IPs due to shared NAT addresses triggering abuse detection |
| Result rendering | AI Overviews take up more screen space on mobile, scroll to raw organic results for accurate dork matches |
| Automation | Mobile browsers cannot run dork automation scripts (e.g., Python/Bash tooling), use Termux on Android for a full CLI environment if scripting is needed |
| Voice search | Does not support operator syntax, always type dorks manually |
Real Google Dork Results – Visual Examples (2026)
Below are real-world examples of the dorks in action. All sensitive data has been anonymized or blurred for demonstration purposes.
How to Chain Google Dorks Like a Pro
Individual operators are useful, but their real power is unlocked when you chain them together. Google’s search engine processes Boolean operators (AND, OR, |, ()), allowing you to build highly granular queries.
- Narrowing the Scope (The Implicit AND): By default, Google adds an “AND” between your operators. To find PDF reports specifically on a target domain, simply put them next to each other.
- Example: site:example.com filetype:pdf
- Expanding the Search (The OR Operator): Use OR (or the pipe symbol |) to search for multiple variations at once. This is perfect for catching multiple file types.
- Example: site:example.com (filetype:env OR filetype:sql OR filetype:bak)
- Excluding Noise (The Minus Sign): The minus sign (-) is your best tool for filtering out false positives. If a target site has a massive public blog clouding your results, exclude it.
- Example: site:example.com -inurl:blog -inurl:news
Google Dorks for OSINT, Pentesting & Bug Bounty
How Attackers Use Google Dorks to Find Vulnerabilities
Threat actors use dorking as a zero-interaction reconnaissance phase, no packets touch the target server directly, only Google’s index is queried. Typical attacker workflow:
- Dork for exposed admin panels or login pages on a target’s domain.
- Dork for technology fingerprints (phpinfo, version strings, error banners).
- Cross-reference exposed files (.env, .git, .sql) for hardcoded credentials.
- Use found credentials or misconfigurations as an initial-access vector.
Because this phase generates no logs on the target’s infrastructure, it’s a favored technique in the reconnaissance stage of frameworks like MITRE ATT&CK (Technique T1593, Search Open Websites/Domains).
How Security Teams Integrate Google Dorks Into Recon Workflow
| Stage | Dorking Role |
|---|---|
| Attack surface mapping | Enumerate subdomains, exposed files, and tech stack via site: and filetype: |
| Vulnerability triage | Cross-check GHDB categories against the organization’s own domains |
| Continuous monitoring | Automated dork scanning tools (e.g., custom scripts querying Google Custom Search API) alert on new exposures |
| Red team reporting | Dork results feed into recon sections of pentest reports as evidence of passive exposure |
| Bug bounty recon | Dorking is a standard first step before active scanning in most bug bounty methodologies |
How Can You Use Google Dorking in Person of Interest Investigations?
Legitimate use cases include journalism, due diligence, recruitment verification, and law-enforcement investigations conducted with proper legal authority. Typical query categories:
- Email discovery: “[email protected]” site:linkedin.com OR site:twitter.com
- Document footprint: “[full name]” filetype:pdf
- Social media cross-referencing: “[full name]” site:facebook.com OR site:instagram.com
Any investigation involving a private individual should have a documented legitimate purpose and comply with local privacy law (GDPR in the EU/UK, similar statutes elsewhere). Using these techniques to stalk, harass, or dox someone is both unethical and, in most jurisdictions, criminal.
What Types of Sensitive Information Are Commonly Exposed?
| Category | Examples |
|---|---|
| Credentials | Passwords, API keys, database connection strings |
| Configuration files | .env, .yml, .json, .ini with secrets |
| Source code | Exposed .git repos, private code pushed to public paths |
| PII | Names, emails, phone numbers in unsecured spreadsheets |
| Financial data | Invoices, payroll files, banking details in leaked docs |
| Internal communications | Meeting notes, internal memos accidentally indexed |
| Infrastructure details | Server banners, stack traces, debug logs |
| Backup files | .bak, .zip, .sql dumps left in public directories |
2026 Updates
How Has Google Dorking Changed in 2026?
- Automation growth: More security teams run scheduled dork queries via the Google Custom Search JSON API rather than manual browser searches, since bulk manual queries now trigger CAPTCHAs faster.
- Community-driven categorization: GHDB continues to expand its dedicated categories for cloud storage exposures (S3, Azure Blob Storage, GCP buckets), IoT device panels, and CI/CD secret leaks.
- OSINT education expansion: University and bootcamp cybersecurity curricula increasingly include dorking as a standard reconnaissance module, alongside tools like Shodan and Censys.
- Cache operator retirement: With cache: removed from public search, analysts now rely on the Wayback Machine, Google’s “cached” link in older indexed snapshots, or third-party archival tools.
- AI Overview interference: Google’s AI-generated summaries occasionally paraphrase or omit exact-match snippets, always click through to the raw result rather than trusting the summary box.
- Rise of dork-aware defenses: More organizations now actively scan their own exposure using GHDB-style queries as part of routine security hygiene (see Defense section below).
Defense & Prevention
How to Prevent Google Dorks From Exposing Your Site
| Action | Why It Matters |
|---|---|
| Add a robots.txt disallow rule for sensitive paths | Prevents crawler indexing of admin/config directories |
| Use noindex meta tags on internal pages | Stops individual pages from appearing in search results |
| Disable directory listing on the web server | Prevents intitle:”index of” exposure |
| Never store credentials in publicly-served files | Removes the root cause of .env/.config leaks |
| Restrict .git, .svn folders from being web-served | Blocks source code and history leaks |
| Require authentication on all admin/config endpoints | Removes inurl:admin login exposure risk |
| Regularly self-audit with GHDB-style queries | Confirms nothing new has leaked since the last check |
| Set up Google Search Console alerts | Flags newly indexed pages under your domain |
| Use a Web Application Firewall (WAF) | Adds a layer of protection even if pages are briefly exposed |
| Rotate any credential immediately if found exposed | Assume compromise the moment a secret is indexed |
Defensive OSINT: How to Protect Your Site from Google Dorks
Google Dorks aren’t just for offensive reconnaissance; they are a critical tool for defensive security. Threat actors are actively scraping Google for exposed credentials. Here is how to ensure your domain doesn’t become a target:
1. Audit Your Own Footprint: Regularly run a dork audit on your own domain. At a minimum, query site:yourdomain.com intitle:”index of /” and site:yourdomain.com filetype:env to ensure no sensitive directories or configuration files are currently indexed.
2. Master the robots.txt File: Prevent Google’s crawlers from accessing sensitive directories in the first place. Add specific Disallow rules for directories containing admin panels, backups, or internal documents.
Plaintext
User-agent: *
Disallow: /admin/
Disallow: /backups/
Disallow: /private/
3. Implement noindex Tags For pages that must remain accessible online but should never appear in search results, add the noindex meta tag to the page’s HTML <head>.
HTML
<meta name=”robots” content=”noindex, nofollow”>
4. Use Google Search Console for Emergency Removals If a sensitive file (like a database dump or a document containing PII) is already indexed, deleting the file from your server is not enough, Google will still show the cached version. You must use the Removals tool in Google Search Console to forcefully purge the URL from the search index.
Quick Tips and Best Practices
- Always test dorks on a scoped, authorized target first.
- Use quotation marks for exact phrases to cut noise significantly.
- Combine site: + filetype: for the highest-precision recon queries.
- Treat every exposure you find as sensitive, do not screenshot, download, or share beyond what’s needed for reporting.
- Bookmark GHDB and check it monthly, new dork categories are added continuously.
- Use after:/before: to focus on recent leaks tied to a specific incident window.
One-Pager Cheat Sheet (Printable Summary)
GOOGLE DORKS CHEAT SHEET 2026 , QUICK REFERENCE
CORE OPERATORS
site:domain.com restrict to a domain
filetype:pdf restrict to file type (ext: also works)
intitle:”text” term in page title
inurl:text term in URL
intext:”text” term in page body
allintitle: / allinurl: / allintext: all terms required
“exact phrase” exact match
-term exclude term
OR / | either term
after:YYYY-MM-DD / before:YYYY-MM-DD date range
HIGH-VALUE STACKS
site:target.com filetype:pdf “confidential”
inurl:admin intitle:”login”
filetype:env “DB_PASSWORD”
intitle:”index of” “backup”
filetype:sql “INSERT INTO”
site:github.com filename:.env “API_KEY”
inurl:”.git” -github.com
GHDB — 14 CATEGORIES (exploit-db.com/google-hacking-database)
1. Footholds 8. Files Containing Juicy Info
2. Files w/ Usernames 9. Files Containing Passwords
3. Sensitive Directories 10. Sensitive Shopping Info
4. Web Server Detection 11. Network/Vulnerability Data
5. Vulnerable Files 12. Login Portals
6. Vulnerable Servers 13. Various Online Devices
7. Error Messages 14. Advisories & Vulnerabilities
RULES
- Only dork targets you own or are authorized to test.
- Never use found credentials.
- Report exposures responsibly; do not publish first.
- link: and cache: are deprecated/unreliable in 2026, use Wayback Machine instead.
- Cross-check queries against the live GHDB, entries get retired/updated regularly.
Knowledge Test / Intuition Builder
- Which operator restricts results to a single domain? (Answer: site:)
- What replaced the deprecated cache: operator for viewing historical page snapshots? (Answer: Wayback Machine / archival tools)
- True or False: Finding an exposed database via a dork is illegal. (Answer: False, viewing is generally legal; extracting/using the data is not)
- Which operator finds pages with a term appearing specifically in the title? (Answer: intitle:)
- What MITRE ATT&CK technique classifies dork-based recon? (Answer: T1593, Search Open Websites/Domains)
Complementary OSINT Techniques
- Shodan / Censys, internet-wide device and service scanning beyond what Google indexes.
- Wayback Machine, historical snapshots of pages, replacing the deprecated cache: operator.
- theHarvester, automated email/subdomain harvesting that complements manual dorking.
- Maltego, link-analysis visualization for person-of-interest and organizational investigations.
- GitHub/GitLab code search, finds leaked secrets in public repositories, a common Google Dork target category.
Frequently Asked Questions FAQ’s
What is a Google Dork in simple terms?
A search query built with Google’s advanced operators to find specific, often unintentionally exposed, content that Google has already indexed.
Does Google Dorking still work in 2026?
Yes. Core operators (site:, filetype:, intitle:, inurl:, intext:) still function normally. Cache-dependent and heavily automated dorking face more restrictions than in past years, mainly due to CAPTCHA rate-limiting and the retirement of the public cache: operator.
Is Google Dorking illegal?
No, running the search itself is legal, since it’s standard use of a public search engine. What you do with the results (accessing, downloading, or using exposed data without authorization) determines legality.
What is the best Google Dork for finding exposed files?
filetype:pdf site:target.com (swap pdf for xls, sql, env, or log) is the most broadly useful starting query for finding exposed files on a specific domain.
Can Google Dorks find phone numbers or emails for free?
They can surface accidentally published contact lists within indexed documents, such as spreadsheets or vCard files. They are not a legitimate tool for locating a private individual’s personal contact details without consent, and using them that way can violate privacy and anti-harassment laws.
Where can I find a full, updated Google Dork list?
The Google Hacking Database (GHDB), maintained under Exploit-DB, is the authoritative, continuously updated source, organized into 14 categories.
What replaced the deprecated cache: operator?
The Wayback Machine (web.archive.org) and third-party archival/cache-viewing tools now serve the purpose the cache: operator used to fill for viewing historical page snapshots.
Which operator restricts results to a single domain?
site: , for example, site:example.com limits all results to that domain and its subdomains.
Are Google Dorks used in real cyberattacks?
Yes. Threat actors use dorking as a zero-interaction reconnaissance phase, classified under MITRE ATT&CK Technique T1593 (Search Open Websites/Domains), because it generates no logs on the target’s own infrastructure.
How many operators should I stack in one dork?
Two to four is usually optimal. Stacking five or more operators frequently returns no results because the query becomes overly restrictive.
Can I automate Google Dorking?
Yes, but direct automation against Google’s search page risks CAPTCHA blocks and Terms of Service violations. For sustained or scheduled dorking, use the official Google Custom Search JSON API instead.
Is Google Dorking the same as hacking?
No. Dorking only surfaces content that Google has already indexed from publicly accessible sources; it doesn’t bypass authentication, exploit software, or access anything not already exposed by a misconfiguration.
Conclusion & Next Steps
Google Dorking in 2026 is still one of the highest-leverage, zero-cost reconnaissance techniques available to security professionals, OSINT analysts, and researchers, provided it’s used within clear legal and ethical boundaries. The operators haven’t changed much; what has changed is the tooling for automation, caching, and rate limits.
Bookmark this page, save the one-pager cheat sheet above, and cross-check the live GHDB monthly, since new dork categories are added continuously. If you run a website, don’t just read this as an offensive playbook; run the defensive audit against your own domain this week.
Next steps:
- Download the printable PDF version of this cheat sheet.
- Run a self-audit dork sweep on your own domain.
- Bookmark the GHDB for ongoing reference.
- Explore our related guides linked below to go deeper on specific tools and techniques.
