Online Tool Store
· 5 min read
How to Use Advanced Google Search Operators
Manesh Jayawardhana
CIO & Co-founder
You need every PDF on your own domain, or every page on your site with “staging” in the title, or the one document a colleague swears they published somewhere on the company site three years ago. Typing keywords and scrolling isn’t going to find it.
Search operators solve this, and most people know two of them. There are a dozen or so worth knowing, and combining them turns a search engine from a keyword box into something closer to a query interface.
What search operators actually do
Operators are constraints appended to a query that restrict where and how the engine matches. The common ones fall into a few groups.
Scope: site: limits results to one domain or subdomain. This is the single most useful operator and the one most worth learning first.
Content location: intitle: and inurl: require a term to appear in the page title or URL rather than anywhere on the page. intext: requires it in the body.
File type: filetype: restricts to a specific extension — PDF, DOCX, XLSX, CSV.
Exclusion and exactness: a leading minus excludes a term; quotation marks require an exact phrase.
Combining them is where the power is. site:example.com filetype:pdf intitle:report finds PDFs on one domain whose titles mention reports — a query that would be hopeless as plain keywords.
Where responsibility comes in
The same techniques that audit your own site can be used to find things on other people’s sites that were never meant to be public — misconfigured directories, backup files, documents published without anyone realising they’d be indexed.
The line is straightforward. Auditing your own domain, or one you’re authorised to test, is legitimate and useful. Systematically hunting for exposed data on domains you have no relationship with is not, regardless of whether the search itself is technically just a search.
If you do stumble across exposed data belonging to someone else — which happens accidentally often enough — the constructive response is to report it through whatever security contact the organisation publishes, and not to explore further.
| Use | Legitimate? | Notes |
|---|---|---|
| Auditing your own domain | Yes | The primary intended use |
| Authorised penetration test | Yes | Within the agreed scope |
| Research on public documents | Generally | Respect terms and copyright |
| Hunting exposed data elsewhere | No | Report accidental finds, don’t dig |
Common mistakes to avoid
- Putting a space after the colon.
site: example.comdoesn’t work;site:example.comdoes. - Assuming
site:shows everything. It shows what’s indexed, which is not the same as what exists. - Over-constraining. Four operators at once frequently returns nothing. Add them one at a time.
- Forgetting subdomains.
site:example.combehaviour with subdomains varies; test explicitly if it matters. - Treating operator results as a complete audit. For finding what’s exposed on your own site, a proper crawl beats a search query — the index is always behind.
What a good query builder does
Shows you the query it’s building
The output should be a query string you can read, edit, and understand — so you learn the operators rather than depending on the interface.
Suggests combinations that work
Some operators combine badly or are mutually exclusive. Knowing which pairs are productive saves a lot of empty result pages.
Keeps the focus on your own domain
A builder oriented around auditing a site you control is a tool. One oriented around finding other people’s exposed files is something else.
How to do it with Google Dorking Assistant
Online Tool Store’s Google Dorking Assistant builds advanced search operator queries in your browser, with nothing sent anywhere.
- Start with
site:set to a domain you own or are authorised to audit. - Add one more operator — usually
filetype:orintitle:— and run it before adding anything else. - Narrow further only if the results are too broad; over-constrained queries return nothing and teach you nothing.
- Note what turns up that you didn’t expect to be indexed, particularly documents and staging pages.
- Fix what shouldn’t be public at the source — access controls, then robots directives, then removal requests.
- Re-run the same queries periodically, since indexes change as your site does.
The Sitemap URL Extractor and the Visual Site Crawler give you a more complete picture of your own site than a search index can.
Frequently asked questions
Is using search operators legal?
Constructing a search query is just searching, and searching public indexes is not itself unlawful. What you do with what you find is where legal lines exist — accessing systems or data you’re not authorised to access remains unauthorised regardless of how you found the link.
Why doesn’t site: show all my pages?
Because it shows indexed pages, and indexing is selective and lagging. Pages blocked by robots directives, marked noindex, or simply not yet crawled won’t appear. For a complete inventory, crawl your own site rather than querying an index.
What should I do if I find someone else’s exposed data?
Stop looking, don’t download anything, and report it to the organisation through a published security contact or their security.txt file if they have one. Continuing to explore turns an accidental discovery into something much harder to defend.
Final thought
Learn site: and filetype: first and audit your own domain with them — you’ll almost certainly find something indexed that you didn’t intend. That’s the version of this skill worth having.