Google Dorking: A Beginner's Guide to Google Dorks (2026)

What Is Google Dorking?

Google dorking is the practice of using advanced search operators to find information a search engine has indexed but that its owner never intended to publish. A dork is one of those queries. Instead of asking Google what a page is about, you ask it for pages with a specific file type, a specific word in the URL, or a specific phrase in the title, and you let the misconfigurations rise to the top.

The name comes from Johnny Long, who began cataloging queries that exposed sensitive systems in 2002 and organized them into the Google Hacking Database (GHDB) in 2004. He presented the research at Black Hat in 2004 and published Google Hacking for Penetration Testers in 2005. Since 2010 the GHDB has been maintained by OffSec as part of the Exploit Database.

Here is the part beginners usually get wrong. Dorking does not exploit anything in Google. Google is doing its job perfectly: it crawled a public URL and indexed what it found. The vulnerability is on the other side, where somebody left directory listing enabled, pushed a .env file into a web root, or put an internal report on a server with no authentication and a link pointing at it. Dorking just gives you a query language for finding that class of mistake at scale.

MITRE tracks this under the Reconnaissance tactic as T1593.002, Search Engines, describing how adversaries use "specialized queries to look for spillages/leaks of sensitive information such as network details or credentials." Real attackers use it, which is exactly why defenders need to know it.

The Google Search Operators That Matter

There are dozens of operators floating around in blog posts. Eight of them do almost all the work. Learn these and you can build any dork you will ever need.

The Ones Google Actually Documents

Worth knowing which of these Google supports on the record. Its official search refinement page documents only exact-phrase quotes, site:, the minus sign for exclusion, filetype:, and the date operators before: and after:. Everything else in the table above is undocumented.

Undocumented does not mean broken. intitle:, inurl:, and intext: have worked for two decades and show no sign of going anywhere. It does mean Google owes you nothing if one of them changes behavior next Tuesday, which is a real thing that happens.

The prefixed variants are worth a line each. allintitle: and allinurl: require every following word to match instead of just one, which is occasionally handy but combines badly with other operators. In practice you will use plain intitle: twice rather than reaching for allintitle: once.

Operators That Are Dead in 2026

This is where most cheat sheets fall apart. If an article still lists these, it was copied rather than tested:

• cache: - gone. Google retired its public page store in February 2024 and removed the operator with it. Search Liaison confirmed the removal publicly. Google added links to the Internet Archive in search results in September 2024 as a partial replacement.
• link: - deprecated in 2017. It still returns something, but the sample is so heavily filtered that the output is not usable for anything.
• info: - retired. Google surfaces the equivalent page details through the "About this result" panel instead.
• + and ~ - both dropped years ago. Use quotes for exact matching instead of +.

When you need a cached copy of a page that has since been cleaned up, go straight to the Wayback Machine. That habit is more reliable than cache: ever was, because the archive keeps history rather than a single snapshot.

Combining Operators: Your First Real Dorks

One operator is a search. Three operators is a dork. The whole craft is stacking constraints until the noise is gone, and the fastest way to understand that is to build one query in stages.

Say you are testing a company and want to know what documents of theirs are sitting in Google's index. Start wide:

site:example.com

That is every indexed page on the domain, which on a real company is thousands of results and useless. Narrow it to documents rather than web pages:

site:example.com filetype:pdf

Better, but a corporate site publishes brochures and datasheets on purpose. You want the ones published by accident, so add a phrase that only appears on documents somebody meant to keep inside:

site:example.com filetype:pdf "internal use only"

Now cut the subdomain that hosts the public marketing library, because you already know what is on it:

site:example.com -site:downloads.example.com filetype:pdf "internal use only"

Four operators, and the result set went from thousands of pages to a list you can read in two minutes. That progression, wide to narrow with a subtraction at the end, is the pattern behind every good dork.

Three Patterns Worth Memorizing

Once the stacking clicks, most useful dorks fall into three shapes.

Directory listing. intitle:"index of" matches the page title Apache and nginx generate when directory browsing is left on and no index file exists. Add a keyword to aim it: intitle:"index of" "backup". This one dork is responsible for a large share of accidental exposures on the internet, and it has been for twenty years.

Login portals. inurl:admin and intitle:"login" find administrative interfaces that were never meant to face the internet. On an authorized engagement this maps your attack surface fast, and it often turns up a forgotten staging panel running two major versions behind production.

Error messages. A stack trace in the index tells you the framework, sometimes the version, and occasionally a file path from the server. Searching an exact error string with site: attached is how you find applications running in debug mode.

In practice, the operator combination matters less than the keyword you feed it. Anyone can run filetype:xlsx. The person who finds something ran filetype:xlsx with a word that only appears in the target's internal templates, and they got that word from an ordinary page on the target's own website.

A Google Dorks Cheat Sheet You Can Trust

Every dork below uses only operators confirmed working in 2026. Read the middle column before you copy the left one, because knowing why a dork works is what lets you write your own.

Two habits will save you time. First, run the same dork on Bing and DuckDuckGo when Google comes back empty, because the three engines index different corners of the web and Bing in particular supports ip: for reverse IP lookups. Second, expect a CAPTCHA if you fire off twenty dorks in a row. That is Google rate limiting you, not blocking you, and slowing down fixes it. Automation tools that spray hundreds of queries per minute get your IP into a much longer timeout.

The Google Hacking Database

The Google Hacking Database is a categorized public index of search queries that expose sensitive information or vulnerable systems. It has been running since 2004 and lives on Exploit-DB, where every entry is tagged, dated, and credited to whoever submitted it.

Entries are grouped by what they find, and the category names tell you a lot about how systems fail:

• Files Containing Passwords, Files Containing Usernames, Files Containing Juicy Info
• Sensitive Directories, Vulnerable Files, Vulnerable Servers
• Pages Containing Login Portals, Various Online Devices
• Error Messages, Web Server Detection, Footholds
• Advisories and Vulnerabilities, Network or Vulnerability Data, Sensitive Online Shopping Info

Use the GHDB as a source of ideas rather than a list to run. Many older entries target software that no longer exists, and Google has quietly stopped matching some of the syntax. The value is in the pattern: read ten entries under "Vulnerable Servers" and you will start noticing which strings a given product always puts in its titles, which is knowledge you can point at whatever you are actually testing.

A strong opinion, since somebody should say it: ignore the "1000 best Google dorks" listicles. They are copies of copies of the GHDB with the dead operators left in, and working through one teaches you nothing except how to paste. Eight operators and the reasoning behind them will take you further than a thousand queries you did not write.

Google Dorking in CTFs and Bug Bounty Recon

For a CTF player, dorking shows up in two places. OSINT challenges hand you a name, a handle, or a photo and expect you to find the rest, and a well-aimed site: query on the platforms where people leak things about themselves will beat any tool. Web challenges sometimes hide a hint or an old version of a page outside the challenge box entirely, and the Wayback Machine plus a site: dork gets you there.

Bug bounty recon is where dorking earns real money. The workflow that works looks like this:

1. Read the program scope and write down every domain and wildcard you are allowed to touch.
2. Run site:*.target.com -www to enumerate subdomains Google already knows about, for free, before you resolve a single DNS record.
3. Hunt for file types nobody publishes on purpose: filetype:env, filetype:sql, filetype:log, filetype:bak.
4. Search the code hosts: site:github.com "target.com" paired with words like api_key, token, or the company's internal project names.
5. Check what an old version of the site exposed, then verify whether the path is still live.

Notice what that list does not include: touching the target. Everything above queries a third party, which is why dorking is classified as passive reconnaissance and why it is safe to run before an engagement window opens. The moment you fetch one of those URLs directly, or start brute-forcing paths with a tool like Gobuster, you have crossed into active testing and the rules change completely.

Dorking pairs naturally with the rest of a recon toolkit rather than replacing it. Our roundup of free OSINT tools covers where subdomain enumeration, breach lookups, and metadata extraction take over once Google has given you everything it has.

How to Check What Google Knows About Your Site

The defensive half of this skill takes ten minutes and is the single highest-value thing in this article for anyone who runs a website. Run these against your own domain right now:

site:yourdomain.com intitle:"index of"
site:yourdomain.com filetype:env
site:yourdomain.com filetype:sql OR filetype:bak OR filetype:log
site:yourdomain.com inurl:admin OR inurl:login
site:yourdomain.com "confidential" OR "internal use only"

Anything that comes back is already public. It has been crawled, indexed, and served to anybody who asked, and no amount of deleting it today changes who read it yesterday.

The DHS, FBI, and NCTC issued a joint bulletin on this in July 2014, titled "Malicious Cyber Actors Use Advanced Search Techniques". It documents an October 2013 case where attackers dorked for sites running a vulnerable message board product, then compromised 35,000 websites and created administrator accounts on them. The bulletin's own advice was to minimize what goes online, self-audit using the GHDB, and remove indexed content through Search Console.

The robots.txt Trap

The instinct is to add the sensitive path to robots.txt. Do not. Two problems, and both are worse than the thing you were fixing.

First, robots.txt controls crawling, not indexing. A URL that is disallowed can still appear in Google's results if anything anywhere links to it, because Google never had to crawl the page to know it exists. Google's own documentation says plainly that robots.txt is not a mechanism for keeping a page out of search results.

Second, robots.txt is a public file. Every hacker's first request on a new target is /robots.txt, precisely because administrators helpfully list their most sensitive directories in it. You have written a map to the treasure and left it at the front door.

What to do instead: put a noindex meta tag or an X-Robots-Tag header on pages that must stay out of the index, use Search Console's removal tool for anything already indexed, and put actual authentication in front of anything genuinely sensitive. Directory listing should be off on every production web server, and a .env file should never be reachable from a web root in the first place.

Legal and Ethical Considerations

Google dorking sits in genuinely gray territory, and the honest answer is that the query is fine and what you do next might not be. The dork itself queries Google. Acting on the result touches somebody else's system.

Where You Are Clearly Fine

• Auditing domains you own or administer
• Engagements covered by a signed authorization that names the domain in scope
• Bug bounty programs, within the scope and the rules the program publishes
• CTF competitions and training labs built for practice
• Security research where you report findings and do not download or redistribute the data

Where People Get Themselves in Trouble

• Downloading exposed personal data "to check if it is real"
• Logging into a portal with credentials found in an indexed file, even once, even to confirm they work
• Publishing a dork that points at a specific unpatched organization before they have fixed it
• Automating hundreds of queries against a domain outside any authorization

If you find something exposed and it is not yours, the right move is responsible disclosure: contact the organization, describe what is public and how you found it, do not touch the data, and give them time to fix it. For where reconnaissance sits inside a structured methodology, OWASP's Web Security Testing Guide documents the information gathering phase in detail.

Frequently Asked Questions