Search footprint, decoded

What `(site:pages.dev or site:vercel.app ...) (intitle:before taxonomy)` actually does

Matthew Diakonov, Written with AI

Published June 16, 20266 min read

Direct answer (verified 2026-06-16)

This is a footprint: a query meant to surface indexed pages on five free static-hosting domains pages.dev, vercel.app, netlify.app, github.io, workers.dev whose title or URL contains the words “before taxonomy”. As literally typed it is malformed: the lowercase or is not Google’s boolean operator, and intitle:before taxonomy only scopes the single word before to the title. So it returns a much broader, noisier result set than it appears to ask for.

Operator behavior confirmed against Google’s own search-operator documentation.

Token by token

Here is the whole query broken into the pieces Google parses. Teal tokens are real operators doing their job. Gray struck-through tokens are the ones that do not behave the way they read.

(Opens a grouped clause.
site:pages.devRestrict to Cloudflare Pages deployments.
orLowercase. Google's boolean is uppercase OR. Lowercase 'or' is treated as an ordinary search word.
site:vercel.appRestrict to Vercel preview/production deployments.
orSame lowercase 'or' problem.
site:netlify.appRestrict to Netlify-hosted sites.
orSame lowercase 'or' problem.
site:github.ioRestrict to GitHub Pages.
orSame lowercase 'or' problem.
site:workers.devRestrict to Cloudflare Workers subdomains.
)Closes the first clause.
(Opens the second clause.
intitle:beforeintitle: binds to the very next single token only: the word 'before'.
taxonomyFloats free as a plain full-text term. It is NOT scoped to the title.
orSame lowercase 'or' problem.
inurl:beforeinurl: binds to 'before' only. The URL must contain 'before'.
taxonomyAgain a free term, not scoped to the URL.
)Closes the second clause.

real operatorfree-floating termdoes not parse as intended

Two things this query does not do

1. The lowercase or is not a boolean

Google’s OR has to be uppercase, or written as a pipe (|). A lowercase or is read as a plain word you want on the page, not as a union between the site: clauses. So the query is not really saying “any of these five hosts.” It is mixing five host constraints with a literal word or sprinkled through, which Google resolves loosely and unpredictably.

2. intitle: and inurl: only grab the next word

intitle:before taxonomy scopes only before to the title. taxonomy floats free and can match anywhere on the page. To require the whole phrase in the title you quote it (intitle:"before taxonomy") or start the query with allintitle:. The identical single-token rule applies to inurl:.

What it reads like vs. what Google does with it

Find pages on any of five free hosting domains whose title or URL contains the exact phrase 'before taxonomy'.

Five hosts unioned together
'before taxonomy' required as a phrase in the title
Or the same phrase inside the URL

The corrected query

(site:pages.dev OR site:vercel.app OR site:netlify.app OR site:github.io OR site:workers.dev) (intitle:"before taxonomy" OR inurl:before-taxonomy)

Uppercase every OR, quote the title phrase, and hyphenate the URL term (URLs rarely contain literal spaces). That returns the tight footprint the original was reaching for.

The five domains in the footprint

Each site: clause pins results to one free static-hosting platform. This is why footprints like this skew toward indie projects, docs, and programmatically generated pages: these hosts make low-friction publishing cheap.

Feature	Platform	Domain
site:pages.dev	Cloudflare Pages	Static/JAMstack sites on Cloudflare's free tier.
site:vercel.app	Vercel	Next.js and frontend deploys, incl. preview URLs.
site:netlify.app	Netlify	Static sites and serverless functions.
site:github.io	GitHub Pages	Repo-hosted docs, portfolios, project sites.
site:workers.dev	Cloudflare Workers	Edge functions and Worker-served pages.

Indexing of these domains is uneven. Vercel preview URLs in particular are often deliberately kept out of the index, so the result count is a sample, never a complete enumeration.

Why a distribution tool cares about query precision

A footprint that over-matches is a quiet tax. Every false positive it returns is a page you open, read, and discard. The difference between intitle:before taxonomy and intitle:"before taxonomy" is the difference between an afternoon of triage and a list you can actually act on.

That is the same muscle distribution work runs on. S4L spends its day turning a fuzzy intent (“founders frustrated with their current scheduling tool”) into precise queries that surface the exact Reddit and X conversations where a product belongs, then engaging in those threads in a human voice rather than spraying the same comment everywhere. A loose query lands you in the wrong communities; a tight one puts you in front of the right readers. Operator precision and distribution precision are the same discipline pointed at different surfaces.

If you would rather not hand-build those queries and babysit the results, that is the part we run for you: finding the right threads, and showing up in them well.

Want the right threads found for you?

Book a call and we will show you how S4L turns intent into precise queries, then engages in the conversations that matter.

Frequently asked questions

What does this search query actually find?

Its intent is to find indexed pages living on one of five free static-hosting domains (pages.dev for Cloudflare Pages, vercel.app for Vercel, netlify.app for Netlify, github.io for GitHub Pages, workers.dev for Cloudflare Workers) where the words 'before taxonomy' appear in the page title or the URL. That is a 'footprint': a query designed to surface every page that shares one structural fingerprint rather than to answer a question. As literally typed, though, it does not do that cleanly, because two of the operators are written in a form Google does not parse the way it looks.

Why is the lowercase 'or' a problem?

Google's boolean OR has to be written in uppercase (OR) or as a pipe (|). A lowercase 'or' is not an operator at all; Google treats it as an ordinary word you want on the page. So in this query the lowercase 'or' tokens between the site: clauses do not union the five domains. The reliable way to express 'any of these five hosts' is to uppercase every OR, or drop the words entirely and let Google's implicit behavior handle the grouped site: terms inconsistently. Uppercasing is the only dependable fix.

Does intitle:before taxonomy require both words in the title?

No. intitle: scopes only the single token immediately after the colon, so intitle:before requires 'before' in the title and leaves 'taxonomy' as a free full-text term that can match anywhere on the page. To require the whole phrase in the title you need a quoted argument, intitle:"before taxonomy", or you start the query with allintitle: so every following word must appear in the title. The same single-token rule applies to inurl:.

What is the corrected version of this query?

(site:pages.dev OR site:vercel.app OR site:netlify.app OR site:github.io OR site:workers.dev) (intitle:"before taxonomy" OR inurl:before-taxonomy). Uppercase every OR so the unions hold, quote the title phrase so both words are scoped to the title, and use the hyphenated slug form for inurl: because URLs rarely contain literal spaces. That returns the tight footprint the original was reaching for.

Why would anyone run a footprint like this?

Footprints are how people enumerate every page that shares one fingerprint: a CMS, a template, a hosting platform, a recurring URL pattern. Restricting to free static-hosting domains is a common way to surface side-projects, indie docs, and programmatically generated pages, because those platforms host a lot of low-friction publishing. People use footprints for competitive research, link prospecting, finding communities to engage, and platform-security triage. The technique is neutral; the value is in knowing exactly what each operator scopes.

Why is S4L writing about a Google search operator?

Because the same skill (turning an intent into a precise query that surfaces exactly the pages or threads you want, and nothing else) is the core of distribution work. S4L spends its day building queries to find the specific Reddit and X conversations where a product belongs, then engaging there in a human voice. A footprint that over-matches wastes hours on noise; one that is scoped tightly puts you in front of the right readers. Operator precision and distribution precision are the same discipline.

Will this footprint reliably return the same results over time?

No footprint does. Google does not index every free-host page, indexing of preview URLs (especially vercel.app preview deploys) is intentionally inconsistent, and operators like site: are approximate at scale. Treat the result count as a sample, not a census. If you need a complete enumeration of a platform's pages you reach for the platform's own APIs or sitemaps, not a search footprint.