Content-Location Operators

Search Techniques

Chapter 4 · Content-Location Operators

site: narrowed where on the web a query looks. This chapter narrows something different: where within a page — and what kind of file — a term has to appear. Four operators, each targeting one specific location: the file type itself, the page title, the URL, and the visible body text.

filetype: — Restricting by File Type

filetype: restricts results to one specific file format. react hooks cheatsheet filetype:pdf searches for PDF documents specifically, filtering out the ordinary HTML pages that would otherwise dominate the results.

QueryWhat it restricts to
filetype:pdfPDF documents — common for whitepapers, cheat sheets, official specs
filetype:xlsxExcel spreadsheets — useful for finding structured data someone has already published
filetype:pptxPowerPoint slide decks — often conference talks or training material
Why this matters for technical searches specifically
Official specifications, RFCs, and academic papers are very often published as PDFs rather than ordinary web pages. A plain keyword query buries them under blog posts and tutorials that merely reference the same standard — filetype:pdf goes straight to the primary source.

intitle: — Requiring a Term in the Page Title

intitle: requires a term to appear specifically in the page's own title, not just anywhere on the page. This is a genuinely different, stronger signal than the term merely being present somewhere in the body — a page whose title contains a term is very likely actually about that term, rather than mentioning it in passing.

A concrete before/after
python decorators can surface pages that mention decorators briefly inside a much broader Python tutorial. intitle:decorators python favors pages whose title is specifically about decorators — a real signal of topical focus, not just keyword presence.

inurl: — Requiring a Term in the URL

inurl: requires a term to appear in the page's URL. Because URL paths often reflect a site's own content categories — /docs/, /api/, /blog/ — this operator can effectively filter by content type on sites that follow a predictable URL structure, the same structural pattern seo1-7 covered from the site-building side.

QueryEffect
stripe payments inurl:docsFavors pages whose URL contains "docs" — likely official documentation rather than blog commentary
rate limiting inurl:apiFavors API-reference-style pages over general articles

intext: — Requiring a Term in the Visible Body Text

intext: requires a term to appear in the page's visible body content specifically. This is the subtlest of the four, because it overlaps heavily with a search engine's own default behavior — most plain keywords are already expected to appear in the body somewhere.

Where intext: actually earns its keep
intext: matters most in combination with the other three operators in this chapter. intitle:tutorial intext:async ensures "async" specifically appears in the body — not only satisfied by, say, an unrelated page whose title happens to contain both words through some other coincidence. Used alone on a simple query, intext: is often the operator least likely to visibly change the results, precisely because it's closest to default behavior already.

The "all-" Variants, Briefly

allintitle:, allinurl:, and allintext: apply the same restriction to every term that follows, rather than just the one term immediately after the operator. allintitle: python async decorators requires all three words in the title, not just "python." These are blunter tools — they apply to the rest of the query wholesale, and can't be mixed with other unrelated keywords the way the single-term versions can.

Combining Content-Location Operators With Earlier Chapters

One realistic compound example
"rate limiting" intitle:guide inurl:docs site:stripe.com filetype:html -inurl:changelog — an exact phrase, required in the title, favoring documentation-style URLs, scoped to one domain, restricted to ordinary web pages, and explicitly excluding changelog pages. Every operator from Chapters 2 through 4 appears in that single line.

Hands-On Exercises

Exercise 1

Write a query to find official-looking PDF cheat sheets specifically about Git rebasing, and explain why each operator you chose is necessary.

📄 View solution
Exercise 2

Explain why intitle: is described as a "genuinely different, stronger signal" than a plain keyword, using this chapter's own decorators example.

📄 View solution
Exercise 3

Explain why this chapter says intext: is "often the operator least likely to visibly change the results" when used alone, and describe a situation where it does actually matter.

📄 View solution

Chapter 4 Quick Reference

  • filetype:pdf — restricts to one specific file format
  • intitle:term — requires the term in the page title, a stronger topical signal than plain keywords
  • inurl:term — requires the term in the URL, often reflecting a site's own content categories
  • intext:term — requires the term in the visible body text; most useful combined with other operators, not alone
  • allintitle:/allinurl:/allintext: — apply the restriction to every remaining term, not just one
  • Next chapter: Date & Time-Range Filtering