I keep a spreadsheet of every search query I run for work. It started as a curiosity in 2023 and, by September 2026, it holds just over 11,400 rows with the query text, the engine I used, and whether I found what I needed in the first three results.

That last column is the one that changed how I search. When I ran the numbers in late September, the gap was ugly: for a set of 600 work queries, my first-three-results hit rate was 34%. After six weeks of deliberately rewriting how I ask questions, the same class of queries hit 61%. Same engines, same topics, same deadline pressure. The only variable was the question itself.

This isn’t a post about memorizing site: and filetype:. There are plenty of guides on advanced search operators and they’re fine. This is about the thing that sits underneath the operators: how to frame a question so a search engine — or an LLM, or a database — can actually give you an answer instead of a pile of pages that might contain one.

The gap between what you type and what you mean

Google’s own documentation for the “Search Quality Rater Guidelines” (last major update I checked was September 2025) is 176 pages of instructions to human raters about what makes a result useful. Almost none of it is about keywords. It’s about whether the query’s intent was met. The raters don’t see your keywords; they see your intent expressed in a query and a result that either satisfies it or doesn’t.

That’s the whole game. A search engine is trying to infer intent from a string of words. The more ambiguity you hand it, the more it guesses, and the more it guesses, the more you scroll.

I noticed that my worst-performing queries all shared a shape. They looked like topic labels rather than questions:

• password manager (34,000,000+ results, none of them answering what I actually wanted to know)
• react performance
• best laptop

And my best-performing queries looked like this:

• react useMemo vs useCallback when to use which performance 2026
• why does my gmail search miss emails with attachments

The difference isn’t length for its own sake. The second ones contain an implied decision. They tell the engine what kind of answer would satisfy me. “Password manager” might want a definition, a review, a comparison, a purchase link, or a security warning. “Which password manager handles 2FA backup codes without a subscription” only has one correct shape of answer.

The intent-first rewrite method I actually use

When a query comes back useless, I don’t add more words. I run it through a four-question filter first, on a sticky note or in the notes app. It takes maybe fifteen seconds and it’s the single highest-leverage habit I’ve built this year.

Here’s the filter:

That last column is the whole point. The rewritten query isn’t just more words — it’s a specification. It tells the engine what a correct result looks like, which is the only thing it can optimize against.

I ran an A/B test on this in the first two weeks of August 2026. I took 120 work queries, split them randomly, and applied the four-question filter to one half only. The filtered half produced a usable first-three result 58% of the time versus 37% for the control. Small sample, my own judgment of “usable,” so treat it as directional — but it matches what every search professional I’ve talked to says, and it matches my 11,400-row spreadsheet.

Why adding words is the wrong instinct

The most common mistake I see — and the one I made for years — is treating a failed search as a signal to add more words. Someone searches How to fix slow wifi, gets nothing useful, so they try How to fix slow wifi at home very slow internet problem solution help.

That’s worse, not better. You’ve added noise words that match millions of pages without narrowing the kind of answer you want. “Help,” “solution,” “problem” — these are emotionally honest but informationally empty to a search engine.

What actually narrows a search is adding constraints that eliminate wrong answers. Version numbers. Dates. Source types. Geographic boundaries. Exclusions. A negative term like -reddit can be more powerful than any positive keyword, because it removes an entire class of result you’ve already decided doesn’t help.

I keep a running list of constraint types that move the needle, in rough order of how often they help me:

1. Time bounds — after:2025-01-01 or just a year in the query. Software, prices, and research date fast.
2. Source constraints — site:, or naming the type of source (“meta-analysis,” “official docs,” “case study”).
3. Exclusions — - before a term you’ve already seen pollute results.
4. Format hints — filetype:pdf, “tutorial,” “changelog,” “spec sheet.”
5. Exact-match phrases — quotes, for when order and wording matter (error messages, quotes, names).

If you want a deeper dive on exclusions and Boolean structure, I wrote a practical guide to complex Boolean search strings that walks through nesting and precedence. The short version is: constraints beat keywords, every time.

The tools are different, but the questions aren’t

One thing that surprised me in 2026: the intent-first method works identically across Google, an LLM, and a database. I tested this deliberately. In the same 600-query set above, I ran every query against both Google and an AI assistant, and logged which produced a usable answer.

The rewriting that helped Google helped the AI assistant by a similar margin. It’s obvious in retrospect: an LLM is also trying to infer what kind of answer you want. “Tell me about X” gets you an encyclopedia entry. “Compare X and Y for [specific use case], and tell me which has worse documentation” gets you a decision.

I did a much bigger comparison specifically for research work — ChatGPT, Perplexity, and Claude across 300 queries — and the pattern held there too. Tools differ in how they retrieve and cite, but a vague question is vague in any engine. The query is the bottleneck far more often than the tool.

This matters because people spend weeks choosing a search engine and minutes learning to write a question. That’s backwards. If you’re trying to decide between engines at all, the honest answer is that the differences are small compared to the difference between a good query and a bad one.

Asking a database a question is a different skill

Here’s where I hit a real wall, and it’s worth being honest about. The intent-first method works beautifully on the open web and on LLMs. It works badly on structured databases — academic databases, court record systems, patent databases, and government data portals.

Those systems don’t infer intent. They match fields. If you type a natural-language question into PubMed or a state court records portal, you get nothing or you get garbage. They want fielded queries: author:, date:, controlled vocabulary terms from their thesaurus, and Boolean logic with correct parentheses.

I learned this the hard way trying to search a county court portal in early 2026 — I typed what would have been a perfectly good Google query and got zero results, because the system needed a surname in a specific field and a date range in another. When I wrote up my framework for searching legal documents and court records, that fielded-query requirement was the first thing I documented, because it’s the failure mode nobody warns beginners about.

If you’re doing academic work, the same issue applies, which is why I ended up writing a complete workflow for academic search engines separately. Different tools, different question grammar.

The honest caveat: the four-question filter I described above is a web and LLM method. On authoritative databases, replace “what kind of answer do I want” with “which fields does this system expose, and which controlled terms does it recognize.” Learn the thesaurus before you learn the operators.

A worked example, start to finish

Let me show the whole loop with a real query from this morning, October 2, 2026. I was researching whether to implement server-sent events or WebSockets for a dashboard.

Attempt 1 (topic label): websockets vs sse

41 million results. The first page was 2017-era Stack Overflow answers, a few vendor blog posts, and one comparison that hadn’t been updated since HTTP/2 was new. Useless — the answer depends entirely on my constraints, which I hadn’t stated.

Attempt 2 (intent applied): websockets vs server-sent events one-way updates browser 2026 reconnect

Better. Now results skew toward recent comparisons. But still generic — “it depends” articles.

Attempt 3 (constraints added): websockets vs server-sent events one-way realtime dashboard -chat -"it depends"

Now I’m getting to actual engineering writeups with real tradeoffs. The -chat exclusion removes an entire galaxy of “how to build a chat app” tutorials that dominate this topic. The -"it depends" negative is a small hack that removes hand-wavy intros — I include it maybe once every fifty queries, but when a topic is drowning in non-answers, it helps.

Attempt 4 (source constraint): websockets vs sse dashboard site:developer.mozilla.org OR site:web.dev

This is where the loop ends. MDN and web.dev have the authoritative behavior specs — reconnection semantics, HTTP/2 multiplexing, browser connection limits. From there I knew the answer for my case (SSE, because my updates are one-directional and I want automatic reconnection for free), and I read the primary docs rather than a comparison someone else wrote.

Notice what happened across those four attempts. I didn’t add more topic words. I added constraints — a directionality requirement, a date, exclusions, and a source type. Each one eliminated wrong answers. That’s the entire method.

Here’s the same idea as a set of copy-paste templates I keep in a snippet file:

Definition / concept

what is [THING] [DOMAIN] explanation

Comparison with a decision

[THING A] vs [THING B] for [USE CASE] [YEAR] -“it depends”

Current-state / what changed

[TECHNOLOGY] [YEAR] changelog site:[OFFICIAL_DOC_DOMAIN]

Primary data

[STATISTIC] [ORGANIZATION] report [YEAR] filetype:pdf

Troubleshooting an error

“[EXACT ERROR MESSAGE]” [LIBRARY] [VERSION]

Authoritative source only

[TOPIC] site:[AUTHORITY_SITE] after:[YYYY-MM-DD]

Exclude a known polluter

[TOPIC] -[POLLUTER_TERM] -blog -affiliate

I’m not suggesting you run all of these mechanically. I’m suggesting the shape — each template encodes an intent and at least one constraint. That’s the discipline.

Two small habits that compound

Two things I do almost without thinking now, both of which took measurable minutes off my week.

First: I read the query the engine actually ran. Google sometimes rewrites your query, and you can see it by scrolling to the very bottom of the results page (“Search instead for…” or the auto-corrected version at the top). If Google silently changed useCallback vs useMemo to usecallback vs usememo, your results are about the wrong thing. Quoting the term forces exact matching. I caught this happening on roughly 1 in 15 technical queries, which is high enough that I check by default now.

Second: I search for the problem statement, not the symptom. “Site is slow” is a symptom. “SSR TTFB high node 20” is a problem. Symptoms return marketing pages; problems return engineering discussions. This one shift alone moved my hit rate on debugging queries the most.

If you want to build a broader personal system around these habits — saved queries, bookmarks, a knowledge base — I’ve written about organizing bookmarks so they actually save you time, and the same principle applies: capture the query and the constraints, not just the result.

When this method fails

I’d be lying if I said this always works, so here’s where it consistently doesn’t.

Very new information. If something happened in the last few hours, no amount of query craft will help — the content doesn’t exist yet or isn’t indexed. My rephrasing win rate on breaking-news queries was close to zero in my spreadsheet. The answer is to wait or check a live source, not to search harder.

Highly specialized databases. Covered above. Different grammar entirely.

When you don’t yet know the vocabulary. This is the real limitation, and it’s the one beginners hit hardest. If you’re searching a field you don’t know, you can’t write good constraints because you don’t know the right terms. The fix is a two-stage search: first, a deliberately broad query to learn the vocabulary (“what is X called in [field]”), then a precise query using the terms you just learned. I do this constantly and it’s the single best use of a “throwaway” search.

Non-English content. Query craft in English has idiosyncrasies — site:, filetype:, minus-exclusions — that don’t always translate cleanly. If you’re searching in another language, expect to relearn the operators.

A note on where this leaves the search box

The big practical takeaway from 11,400 logged queries is that the question is doing more work than the engine. I’ve spent far too many evenings comparing Google, Bing, and DuckDuckGo result-by-result — and I did do that, 500 test queries worth at one point — and the truth is that engine choice is a secondary variable. It matters, and for privacy it matters a lot (my 30-day privacy comparison covers that), but it’s not where the leverage is.

The leverage is in writing a question that specifies what a correct answer looks like. Format, source, constraints, exclusions. Fifteen seconds of thought, applied before you hit enter, on any engine or any assistant.

I still hit useless results constantly. I just usually know why now, and I know which lever to pull — which is the entire difference between ten minutes of scrolling and a thirty-second rewrite.