We turned on a Google autocomplete topic source for our content pipeline back in June. Config seeded, feature flag on, plugin enabled for the niche. By every dashboard we had, it looked live.
It produced zero topics. For six weeks.
Nobody noticed, because nothing was throwing an error. The source existed. It just never ran. Turns out a plugin row only grants a niche permission to use a source -- it doesn't schedule anything. Ingestion is driven by a separate per-niche tap row, and that row didn't exist. We'd built the engine and forgotten to bolt it to the car.
The mental model we'd been carrying around was wrong in a specific way: we treated "plugin enabled" as a verb, when it's actually a noun. Enabling a plugin for a niche just inserts a row that says this niche may draw from this source if something asks it to. It's a capability grant, not a subscription. The thing that actually asks -- the tap -- is a completely separate table, keyed by niche and source, carrying its own schedule, its own cursor, its own last-run timestamp. Nothing in the plugin table points at it, and nothing in the plugin dashboard reads from it either. So the UI we were checking every few days showed a green checkmark next to search_autocomplete for the entire six weeks, and the green checkmark was telling the truth about the wrong question. It was answering "is this niche allowed to use this source," which was yes, instead of "is anything actually calling this source on a schedule," which was no.
This is the quiet failure mode that eats automated pipelines: a thing that is "on" in every config you'd think to check, and "off" in the one place that actually fires the cron job. We've hit this shape of bug before, in the queueing layer that runs our background jobs -- see The Solo Developer's Background Job Dilemma for the Postgres LISTEN/NOTIFY version of the same lesson. A subscriber that never subscribes looks identical to a subscriber that has nothing to say.
We fixed it with a migration: added search_autocomplete and gsc_query_gap tap rows for the Glad Labs niche, and gave both a 1.5x boost in the batch pre-rank, which up to that point only scored candidates on fit-to-goals and had no concept of actual search demand behind them. The boost wasn't arbitrary -- before the fix, a topic's score was a function of how well it matched our stated content goals, with no term in the equation for whether anyone was actually searching for it. That meant a beautifully on-strategy topic with zero search volume behind it would outrank a slightly-off-strategy topic that fifty people typed into Google that week. The 1.5x multiplier on tap-sourced candidates was our way of putting a thumb on the scale for "real demand exists," without letting it completely override fit -- a topic still has to clear a minimum fit bar before the demand boost even applies. Within minutes of deploy, the tap fired and the pool filled with real completions: "run llm locally on mac," "gguf quantization types," "llama.cpp vs ollama." Not personas. Not guesses. What people actually type.
Why we picked autocomplete over the alternatives
We didn't default to autocomplete because it was easy. We had three real candidates for a search-demand source and had to pick one to build first: Google autocomplete, Reddit question mining, and Google Trends via pytrends.
Trends gives you relative volume for a term you already have -- a validator, not a discovery tool. It can tell you if "gguf quantization" is trending up, but it can't hand you the term in the first place. You feed pytrends a keyword, and it hands back a normalized interest-over-time series for that exact keyword -- useful for deciding which of two topics you already know about is worth writing first, completely useless for finding a third topic you hadn't thought of. Reddit mining gets you real human questions, which is a different content shape entirely: you're answering a question someone posted, not ranking for a phrase someone typed into a box. A Reddit thread titled "why does my 7B model output garbage after quantizing" is a fully formed problem with context, frustration, and specifics baked in -- great source material for a troubleshooting post, but it's not a search query, and optimizing a title around it doesn't help you rank for the shorter, blunter phrase someone actually types when they hit the same wall. Useful, but not a substitute.
Autocomplete does something neither of those does: it surfaces the literal query shape, generated from actual search behavior, for free, no API key. Type "run llm" into a search box and the completions you get back are exactly what other people finished typing before you. According to Neil Patel, Google built the feature to save typing time -- by their own numbers, autocomplete cuts typing time by 25%. That's the pitch for users. For us, the side effect is the interesting part: it's a live, continuously-updated map of demand, expressed in the exact words people use.
That's why we picked it first. It's the most direct substitute for traditional keyword research that doesn't cost anything to query. There's no volume number attached to any given completion, no way to know if "gguf quantization types" gets ten searches a month or ten thousand -- but the ranking of the suggestions themselves is a rough proxy, and for a solo pipeline with no keyword-tool budget, a rough proxy that costs nothing beats a precise number that costs a subscription. We can always layer Trends on top later to rank the completions we've already mined; we can't use Trends to generate the completions in the first place. That ordering -- discovery first, validation second -- is the whole reason autocomplete went in before either of the other two.
The failure mode that makes this dangerous
Here's the part that should worry anyone plugging a search box into an automated content pipeline: the words matter, and getting them wrong doesn't fail loudly.
We'd already hit this once, with a different topic source. Our web_search source had a tap configured with no seed queries and no categories, so it fell through to its last resort: build a query out of the niche name plus its target-audience tags. Those tags were things like indie-devs, ai-curious, future-matt -- personas we use internally to describe who reads the blog, not phrases anyone would ever type into a search engine. The system dutifully searched "Glad Labs indie-devs," got nothing useful back, and searched "Glad Labs" on its own -- which returned our own homepage, plus a couple of unrelated acronym collisions from unrelated labs and LinkedIn profiles that happen to share the initials. Three of five candidates in that batch were essentially the pipeline Googling itself.
Walk through what that actually looked like downstream, because the batch didn't come back labeled "garbage" -- it came back looking like ordinary output. One candidate topic amounted to an explanation of what Glad Labs is, built from our own homepage title tag. It scored fine against our fit-to-goals rubric, because explaining what your own company does is a perfectly reasonable thing to write about in the abstract. Another candidate was built from a LinkedIn profile snippet belonging to someone at an unrelated company with the same initials, and it scored low but not zero, because the rubric had no term for "this entity is not us." Nothing in the scoring path asks "does this topic's source material actually describe the thing we think it describes." It just asks "does this material fit our stated goals," and self-referential noise fits almost anything, because it's vague enough to fit almost anything.
Nothing downstream caught it. There was no check anywhere in the topic-source path that says "hey, don't recommend a blog post about our own homepage." That's the same failure category as the missing tap row -- silent, structurally invisible, and only obvious in hindsight once you trace the actual query string back to its source. In both cases the fix wasn't a smarter algorithm, it was a dumber, more literal check: does this tap row exist, does this query string contain the niche's own name paired with nothing else meaningful. Neither check requires any judgment. They just require someone to have thought to ask the question before the batch shipped, instead of after.
If you're building anything that turns a search box into a content decision, that's the lesson: audit the literal string that gets sent to the query, not just the config that produced it. It's tempting to review the seed queries, the categories, the tags -- the inputs you deliberately wrote -- and assume that if those look reasonable, whatever the system builds from them will be reasonable too. That assumption is exactly where this bug lived. The seed config was empty, which looked like an oversight but not a dangerous one, right up until you traced what the fallback path actually did with an empty config. We wrote about the moment this clicked for us in The Poindexter Philosophy -- typing a half-formed phrase into a search bar and discovering what actually comes back is a different exercise than assuming you know.
Autocomplete isn't just a discovery tool -- it's also a liability
There's a second dimension to this that doesn't show up in a topic-source config at all: what autocomplete does to your reputation once it's attached your name to something you didn't say.
Autocomplete surfaces what other people searched, not what's true about you. If enough people search "Glad Labs scam" or "Glad Labs lawsuit," Google will happily suggest it to the next person before they finish typing, regardless of whether it's accurate. Search Engine Land calls this exactly what it is: a silent threat to online reputation, because negative autocomplete suggestions shape a searcher's first impression before they've clicked anything. The mechanism is the same one we're exploiting for content ideas -- frequency of prior queries -- which means the exact feature we're using to find "run llm locally on mac" is, for someone else, surfacing "LM Studio refund complaints" to a prospective customer who hadn't even typed the word "refund" yet.
And you can't fix it by yelling at the platform. Mike Masnick at Techdirt has covered this pattern repeatedly -- targeting a search engine directly over an unflattering autocomplete suggestion tends to make the problem worse, not better, because the complaint itself becomes a new signal, a new story, a new thing people search for. A takedown request, a public callout of Google, a lawsuit threat -- all of it generates coverage, and coverage generates searches, and searches are the raw material autocomplete is built from. The fix is never "make them take it down." It's changing the underlying search behavior that produced the suggestion in the first place, which is slow and mostly out of your hands.
That's worth sitting with if you're treating autocomplete purely as a content-mining opportunity, the way we do. The same signal that tells you what people want to read about you is also, on the flip side, telling everyone else what people are already saying about you. It's a two-way mirror. You can point it outward to find demand. You can't stop other people from pointing it at you.
Worth noting: this is a different "autocomplete" than the one an ecommerce site builds into its own search box -- the kind Doofinder writes best practices for, where the goal is conversions on your own site. On your own site's search box, you control the index, you control the ranking logic, and you can hand-tune a suggestion the moment it looks wrong -- it's your product surface end to end. Google's public autocomplete is a signal you can only read, never author. Don't confuse the two -- we've also written about a completely different sense of the word, code-editor autocomplete, in Beyond Autocomplete: Navigating the Landscape of AI Coding Assistants in 2026. Three products, one overloaded term. There's even a whole party game built around guessing Google's completions -- Google Feud -- which tells you something about how deeply this feature has embedded itself in how people think about search.
Mining demand is only half the job
Getting real demand into the topic pool doesn't automatically mean you write something worth ranking. We learned that the hard way while fixing the tap-row bug, because the same pull request that added the autocomplete taps also shipped a completely separate fix: a gate on the titles those topics turn into.
The problem: a topic can be exactly what people are searching for and still get written up under a title with no searchable entity in it -- nothing a person would actually type, no digit, no proper noun, no term pulled from the article's own keywords. A topic sourced straight from the phrase "gguf quantization types" could still ship under a title like "Understanding the Nuances of Modern Model Compression" -- accurate, on-brand, completely disconnected from the query that justified writing it in the first place. The demand signal did its job; the title-generation step just didn't preserve it. We went back through our own published titles and found the pattern held cleanly: every page that had ever earned a click passed a rule requiring a digit, a proper noun, or a term lifted from the article's own tags. Titles like "GGUF Quantization Types Explained" or "Llama.cpp vs Ollama: Which One Should You Run" cleared the bar on a proper noun alone. Titles like "4 Ways to Speed Up Local Inference" cleared it on the digit. Every title from a stretch of zero-click pages in our history failed that same rule -- the vague, adjective-heavy, entity-free kind, the sort of headline that reads fine to a human skimming a list but matches nothing anyone typed into a search box. That's not a coincidence you can argue with -- it's the data telling you what a searchable title actually looks like.
So we added a gate. A canonical title has to clear that bar now. If it doesn't, the system gets one corrective regeneration, prompted with the article's own concrete terms pulled straight from its headings -- not a generic "make this more clickable" instruction, but the actual nouns and numbers already sitting in the body of the piece, fed back in as the raw material the rewrite has to work with. If the rewrite clears the bar, it ships. If it still doesn't, the original title ships anyway, but it lands on our findings board tagged title_no_searchable_entity -- visible, not silently swallowed.
That last part matters more than it sounds. We've had the opposite failure before too -- a ranking system quietly falling back to a weaker method a large share of the time, with that fallback rate treated as a rotated-out warning instead of a standing finding on the board. That's the failure mode we wrote about in The Trap Nobody Notices Until Output Breaks: output that looks finished, ships clean, and only reveals the gap once someone goes looking for why nothing is landing. A title that fails the searchability gate and gets buried in a log is exactly that trap -- one bad title is a rounding error, nobody checks, and a month later a quarter of your published titles are running on autopilot with nothing a search engine can latch onto, and the only way to find that out is to go digging through logs nobody had a reason to open. A title that fails the gate and shows up as a finding is a system you can actually act on: it accumulates on a board you already check, it's countable, and a spike in that count is itself a signal that something upstream -- a prompt, a model, a source -- degraded before it costs you a month of traffic.
Put those two fixes side by side and you get the real shape of the autocomplete dilemma for anyone building an automated content pipeline. It's not enough to mine the right demand signal. You also have to make sure what you produce from that signal is shaped the way the signal itself is shaped -- as a phrase a real person would type, recognize, and click.
What this actually means if you're building your own
If you're a solo dev wiring a search-demand source into anything -- a content pipeline, a product-discovery tool, an internal search box -- take three things from this:
First, "enabled" and "running" are not the same state, and your dashboards will lie to you about the difference unless you specifically check for it. A feature flag on, a config seeded, a plugin permission granted -- none of that guarantees a scheduler actually picked the job up. Verify the thing fired, not that it was allowed to. Concretely: don't trust a green checkmark next to a source's name unless you know exactly which table it's reading from, and whether that table records permission or execution. If you can't answer that question in ten seconds, go check the actual last-run timestamp on the thing you think is running, not the toggle that says it's supposed to be.
Second, audit the literal string your system sends to a search box, not the config that generated it. Persona tags, category labels, internal shorthand -- none of that behaves like a search query, and nothing downstream will stop it from being treated like one unless you build that check yourself. We didn't have one, and it cost us a batch of candidates that were essentially the pipeline Googling its own homepage. The check itself is cheap once you know to write it: does the outbound query contain the niche or brand name with nothing else substantive attached, and if so, throw it out before it ever reaches the search API, rather than trusting the results that come back to look obviously wrong.
Third, remember that a public autocomplete feed cuts both ways. You can read it to find demand. You cannot control what it says about you, and trying to strong-arm the platform into removing an unflattering suggestion tends to backfire rather than fix anything. Treat it as a one-way instrument for discovery, and treat your own reputation on it as something you influence slowly, by changing what people actually search, not by complaining about what the box shows.
We're running with all of this now -- two demand taps live, a rank weight that actually values them, and a title gate that won't let a topic slip through with nothing searchable in its headline. It took a silent six-week gap and a self-search bug to get there. If you're building the same kind of pipeline, you can skip both of those and go straight to the version that works.
Sources
- https://neilpatel.com/blog/google-autocomplete/
- https://searchengineland.com/google-autocomplete-online-reputation-432106
- https://www.doofinder.com/en/blog/autocomplete-in-search-engine
Originally published at www.gladlabs.io.
Top comments (0)