Google Dorking for OSINT: The Practical Investigator's Guide

This is the reference I keep open in a tab during OSINT work, particularly Trace Labs investigations. It isn't a list of a thousand pre-built dorks to copy and paste. Those lists go stale, and worse, they teach you to look for a magic string instead of understanding what's actually happening when you search.

The operators themselves are a small, stable set. What changes investigation to investigation is how you combine them and what you do with what comes back. So that's what this guide is built around: the operators that currently work, the ones that don't (despite what a lot of older cheat sheets still claim), and the thinking that turns a Google search into an investigative pivot.

Last verified against Google's current documentation and observed behaviour: September 2026. Search behaviour changes over time. If you spot something here that's stopped working the way it's described, let me know.

Don't memorise dorks: learn the pattern

The framing I use for every query is the same five components:

TARGET + IDENTIFIER + CONTEXT + SOURCE + FILTER

• Target: the person, username, organisation or thing you're investigating.
• Identifier: a name, alias, email, phone number, handle.
• Context: something that narrows it, such as a city, employer, year or relationship.
• Source: a specific platform or domain, via site:.
• Filter: a format or exclusion, via filetype: or -.

You don't need all five in every query, and you build them up one at a time rather than trying to write the perfect query on the first attempt. A realistic sequence for a Trace Labs-style person search looks like this:

"John Smith" "Auckland" site:linkedin.com/in

Nothing back? Drop the source, try a document filter instead:

"John Smith" "Auckland" filetype:pdf

Found a PDF with an email address in it. That email is now its own target:

"john.smith@example.com"

Getting swamped by the domain the email lives on:

"john.smith@example.com" -site:example.com

Every result is a potential new identifier, and every new identifier is a new query. That's the whole method. Formally:

Search broad
↓
Find a distinctive clue
↓
Search that clue exactly
↓
Add context
↓
Remove false positives
↓
Search specific sources
↓
Search documents
↓
Search historically
↓
Search associations
↓
Try another search engine
↓
Record evidence
↓
Repeat

Core operators you actually need

These are the operators I'd actually put money on working reliably today. I've checked each of these against Google's own search operator documentation rather than assuming an old blog post is still accurate.

Exact phrase: "…"

Wrapping text in quotes tells Google to match that exact sequence of words, rather than treating it as a bag of keywords it can rearrange, drop, or "helpfully" swap for synonyms. This is the single operator I use most often, and it's the foundation almost everything else builds on.

"Jane Doe" "Wellington"

site:

Restricts results to a domain, or a specific path on that domain. This is the operator that turns "search the entire internet" into "search this one place."

site:linkedin.com/in "Jane Doe"

site:facebook.com "Jane Doe" Wellington

You can go as specific as a subdomain, or as broad as a TLD:

"Jane Doe" site:.gov.nz

Exclusions: -

A minus sign directly before a word or operator (no space) excludes it. This is how you cut the noise out of a search rather than just adding more terms to try to drown it out.

"Jane Doe" -actress -musician

Excluding a whole site: -site:

Combine the exclusion with site: to remove an entire domain from the results, most commonly the domain a piece of identifying information came from, so you can see where else it turns up.

"jane.doe@example.com" -site:example.com

filetype:

Restricts results to a specific document format. This is one of the highest-value operators for OSINT because organisations leak an enormous amount of identifying detail through documents nobody thought to scrub: author metadata, internal names, phone extensions, org charts.

"Jane Doe" filetype:pdf

site:example.com filetype:xlsx

Combining terms: OR and parentheses

OR

OR (capitalised: lowercase "or" is treated as a normal word) matches any of the terms rather than requiring all of them. Useful for name variants, nicknames, or spelling differences.

"Jon Smith" OR "John Smith" OR "Jonathan Smith"

Parentheses

Group OR terms so they don't leak into the rest of the query. Without grouping, Google's operator precedence can produce a much broader search than you intended.

site:linkedin.com/in "Auckland" ("John Smith" OR "Jon Smith" OR "Jonny Smith")

Wildcard: *

Inside a quoted phrase, * acts as a placeholder for one or more unknown words. It's genuinely useful for filling in a gap in a phrase you only partially know, such as a half-remembered quote, a bio fragment or a document title.

"employee of the * at" "Ministry of"

intitle:, inurl:, intext:

These three restrict where your term has to appear, rather than just anywhere on the page.

intitle:

Matches pages where the term appears in the page's <title>. Good for finding a page that's specifically about something, not one that just mentions it in passing.

intitle:"resume" "Jane Doe"

inurl:

Matches the term appearing in the URL itself. Handy for finding profile pages, ID-based paths, or specific URL patterns a platform uses.

inurl:profile "janedoe"

intext:

Forces the term to appear in the visible body text of the page, as opposed to a title, URL, or alt text. In practice this overlaps heavily with just typing the word normally, since Google already searches body text by default. It's useful when you're stacking it with intitle: or inurl: restrictions on other terms in the same query, to be explicit about where each term must land.

intitle:"staff directory" intext:"Jane Doe"

before: and after:

Restrict results to Google's indexed date for a page, rather than a full text match. Written as before:YYYY-MM-DD and after:YYYY-MM-DD.

"John Smith" before:2018-01-01

"John Smith" after:2018-01-01

Combine both to bracket a window:

"John Smith" after:2018-01-01 before:2020-01-01

Operators that need caution

These still function in some form, but each has a real limitation that's easy to get burned by if you treat it like a core operator.

allintitle:, allinurl:, allintext: apply "all following words must match" to every term after them, for the rest of the query. That means they don't combine cleanly with other operators the way intitle:/inurl:/intext: do. Put anything else in the same query and behaviour gets unpredictable. Google's own guidance is to use these alone, not stacked with other operators. I mostly skip them in favour of repeating intitle: per term, which is clearer and behaves more predictably.

AROUND(X) is an undocumented proximity operator (term1 AROUND(3) term2) that's meant to match terms within a set number of words of each other. It's not in Google's official operator list, its behaviour is inconsistent, and it can silently fail to apply without warning. If you use it, verify every result manually rather than trusting the proximity constraint held.

Deprecated and unreliable operators

If you've found an older Google dorking cheat sheet, and most of what's floating around the internet is from 2015 to 2020, it almost certainly includes some of the following. None of these should be relied on today.

• cache:: Google officially discontinued the cached-page feature in 2024. The operator no longer returns a cached snapshot.
• related:: the "similar sites" operator was deprecated years ago and no longer returns meaningful results.
• link:: never fully reliable for general use, and today it doesn't provide the kind of backlink discovery people used to reach for it. Use a proper backlink tool if you need that.
• info: and id: are legacy operators for a one-page summary of a URL. Both are discontinued.
• phonebook:: Google's old phone/address lookup operator, retired a long time ago.
• ~ (synonym search): deprecated around 2013. Google's core algorithm handles synonym matching automatically now, without the operator.
• + (force exact match on a word): superseded by quoting. Use "word" instead.

Investigation playbooks

These are the patterns I actually reach for, organised by what you're starting with. None of these assume the platform is fully indexed by Google. It isn't, for any of them, so treat every result as a lead, and go to the platform directly when a Google search comes up empty.

Person

Start broad, then layer on context one piece at a time until the noise drops out.

"John Smith" Auckland

"John Smith" "Auckland" "Acme Corp"

"John Smith" "nickname" OR "Johnny"

"John Smith" "born" OR "graduated"

Useful context layers to add, one at a time: full name variants, middle name, nickname, suburb or city, employer, occupation, and known associates (see association searching below).

Username

Usernames are frequently reused across platforms, which makes them one of the strongest pivots available.

"johndoe1987"

"johndoe1987" -site:instagram.com

"johndoe1987" OR "johndoe_1987" OR "john.doe.1987"

"johndoe1987" "John" OR "email"

Email

"john.smith@example.com"

"john.smith@example.com" -site:example.com

"john.smith" "example.com"

"john.smith@example.com" "John Smith"

Searching the local part (john.smith) alone, without the domain, can surface the same handle reused on a different email provider or as a username elsewhere, which is worth trying once the full address dries up.

Phone

Search every formatting variant. Sites, forms and people all write numbers differently, and Google's phrase match is exact, so a single missing space is enough to miss a result.

"021 123 4567"

"0211234567"

"+64 21 123 4567"

"+64211234567"

"021-123-4567"

Address

"12 Queen Street, Auckland"

"12 Queen St" Auckland

"John Smith" "12 Queen Street"

"Acme Corp" "12 Queen Street"

Try both the full and abbreviated forms (Street/St, Road/Rd, Avenue/Ave) as separate exact-phrase searches. Google won't normalise Street/St for you.

Organisation

site:example.com

"Acme Corp" filetype:pdf

"Acme Corp" "annual report" OR "directors"

"Acme Corp" "contact" "phone" OR "email"

"Acme Corp" before:2015

The last one, an old date bracket against a company name, is useful for finding a company's earlier web presence: previous names, previous addresses, staff who've since moved on, or a version of the site from before a rebrand.

Documents

Every common office and data format is worth checking individually. Don't assume filetype:pdf alone covers it, since different organisations default to different formats.

"Jane Doe" filetype:pdf

"Jane Doe" filetype:doc OR filetype:docx

"Jane Doe" filetype:xls OR filetype:xlsx

"Jane Doe" filetype:ppt OR filetype:pptx

"Jane Doe" filetype:csv

"Jane Doe" filetype:txt

Social platforms

Google indexes a genuinely small and inconsistent slice of most social platforms. Some content is public but blocked from crawling by the platform's own robots.txt, some is public but simply hasn't been crawled, and plenty is only visible once you're logged in and searching the platform directly. Treat every query below as "does Google happen to have this," not "does this exist."

site:linkedin.com/in "Jane Doe"

site:facebook.com "Jane Doe" Auckland

site:instagram.com "Jane Doe"

site:reddit.com "johndoe1987"

site:github.com "John Smith"

site:youtube.com "John Smith"

site:tiktok.com "@johndoe1987"

site:pinterest.com "Jane Doe"

LinkedIn

LinkedIn is worth its own note because it's usually the highest-value source for professional context: employer, role, location, colleagues. It's also one of the more consistently (if partially) indexed platforms.

site:linkedin.com/in "Jane Doe" Auckland

site:linkedin.com/in "Jane Doe" "Acme Corp"

site:linkedin.com/in "Jane Doe" -"student"

Association searching: nodes and edges

A lot of OSINT progress doesn't come from searching for your target directly. It comes from searching for the things and people connected to them. Think of it less as "search for a person" and more as mapping a small network:

People
↔
Usernames
↔
Emails
↔
Phones
↔
Addresses
↔
Organisations
↔
Documents
↔
Other people

Every one of those is a jumping-off point to the next. In practice, the queries are simple, usually just two identifiers in the same exact-phrase search:

"John Smith" "Jane Doe"

"John Smith" "Acme Corp"

"John Smith" "12 Queen Street"

"johndoe1987" "john.smith@example.com"

Two names appearing together repeatedly across otherwise unrelated pages is a real signal: a family relationship, a workplace, a shared event, a sports team. It's rarely proof on its own, but it's exactly the kind of lead that turns into a confirmed connection once you check it against a second, independent source.

Distinctive-text searching

People and organisations reuse text constantly: a bio paragraph copied from an old CV into a new one, a conference speaker blurb pasted into three different event pages, a phrase from a personal "about me" that's been sitting untouched on a site for a decade. Search for that exact wording, not just the name.

"passionate about building products that make a difference"

"has over 10 years of experience in" "Acme Corp"

A distinctive sentence like that can surface:

• previous employers or organisations, where the same bio was reused
• old conference or speaker-listing pages
• abandoned personal websites or blogs
• accounts the person has since stopped using
• archived or cached copies referenced elsewhere
• a fuller employment history than any single profile shows

Timeline and historical searching

before: and after: (covered above) are the main tools for reconstructing someone's earlier footprint: old employer, old username, old writing style, before a rebrand or a name change.

"John Smith" before:2015

"johndoe1987" before:2018

"Acme Corp" after:2010 before:2015

Remember: as noted under before:/after: above, the date Google shows you is when it believes the page was indexed or last changed, not a verified publication date. Cross-check anything time-sensitive against the page itself, the Wayback Machine, or another independent source before treating it as fact.

Search-engine hopping

Google is one index of the web, not the web itself. Different engines crawl different things, weight results differently, and in a few cases are noticeably less aggressive about filtering or de-ranking certain kinds of content. When a Google search dries up, the same query on a different engine is often worth thirty seconds:

• Bing: a genuinely different index, with its own site:/filetype:/intitle: style operators. Worth trying anything that came up empty on Google.
• Brave Search: runs its own independent index rather than relying on another engine's results.
• DuckDuckGo: blends multiple sources, useful as a quick second opinion.
• Yandex: indexes Russian-language and Eastern European content far more thoroughly than Google does, and is worth trying specifically for content in that region.

I'm not going to turn this into a full guide to each engine's operators here. That's a big enough topic for its own post, but the habit of trying a second engine before giving up on a lead is worth building regardless.

The Google Hacking Database

If you've spent any time around Google dorking, you'll have come across the Google Hacking Database (GHDB), maintained on Exploit-DB. It traces back to Johnny Long, who popularised the term "Google dork" in the mid-2000s by cataloguing search queries that exposed login pages, misconfigured devices, and files that were never meant to be public.

The GHDB is a genuinely useful reference for understanding what a search footprint looks like: the kind of file names, error strings, or URL patterns that show up when something's been misconfigured or overshared. That mindset carries over well to OSINT: knowing what a leaked spreadsheet's filename convention looks like, or what a misconfigured directory listing looks like in a URL, helps you recognise it when you stumble across it.

Ethics and scope

A few things worth keeping in view while you're doing this work, whether it's a Trace Labs CTF, a real missing-persons case, or professional research:

• Google dorking searches what's already indexed. That it's indexed doesn't mean it's appropriate to collect, store, or redistribute. Apply the same judgement you'd apply to any other OSINT source.
• Finding exposed credentials in a search result does not authorise you to use them.
• Finding an exposed system, panel, or file share does not authorise you to access it.
• Stay inside the rules and scope of whatever you're working on, whether that's a CTF's rules of engagement, a client's investigation scope, or your own organisation's policy.
• Don't attempt authentication, exploitation, or "just checking" access to a system simply because a search engine revealed it exists. That's a different activity requiring separate, explicit authorisation.

None of that is meant to be alarmist. Most OSINT work never comes close to any of these lines. It's just worth being deliberate about where the line actually is, especially in a fast-moving CTF environment where the instinct is to chase every lead as far as it goes.

Cheat sheet

The condensed version. Everything below is covered in more depth earlier in the guide. This is here for when you already know what you're doing and just need the syntax.

Further reading

• Google Search operators (official documentation)
• ShadowDragon: Google Dorks for OSINT
• Google Hacking Database (Exploit-DB)
• Ahrefs: Google Advanced Search Operators