Build a Keyword Plan From Product Facts, Not a Tool Export

The short version

• A keyword tool expands outward from a seed term. Whether those terms have anything to do with your product is a question it never asks.
• Derive candidates from product facts instead, and every term comes with a one-line answer to "what gives us the standing to write this?"
• Cover six categories (brand, product, competitor, scenario, question, long tail). Four is the floor.
• Before you sort the list, write down what the number means. Relevance and search volume are different measurements and they don't mix.

Building a keyword plan from product facts means writing down what the product verifiably does, deriving candidate terms from that, and keeping only the terms you can answer one question for: what gives us the standing to write this? Cover at least four of the six categories, then validate every surviving term against live search results.

Most keyword plans start the same way. Open a research tool, type in a seed term, export 800 rows, sort by volume, take the top twenty.

By the time the CSV lands, the plan has already come loose from the product.

An export ranks somebody else's problems

Three things go wrong with that list, and they get more expensive as you go.

The seed term was a guess. Semantic expansion only walks the neighborhood around whatever you typed. Aim the seed slightly off and the whole export is slightly off, with no signal telling you so.

High volume means high competition, usually from bigger sites. Every vendor in your category is chasing the same generic head terms. Winning them takes either budget or a content library you don't have yet.

The export has no idea what your product does. This is the one that actually costs money. You pick a term, write 3,000 words, rank, get traffic, and the visitor lands on a product that doesn't do the thing the article implied. That traffic is worse than no traffic. It burns a first impression you only get once.

Change the starting point and all three go away at the same time.

Start by writing down what's true

A product fact is one checkable statement per line. Take a hypothetical time-tracking tool for design agencies:

• Syncs two-way with Jira and Linear
• Timesheet approval runs weekly, not per entry
• Free tier covers 3 seats
• No native invoicing; exports to QuickBooks instead

Three rules when you write these. One claim per line. Every line traceable to something a stranger could check: a pricing page, a docs page, a screenshot. And write down what the product doesn't do.

That last rule pays for itself. Limits generate search terms. "No native invoicing" produces "does [tool] do invoicing" and "time tracking with invoicing", and an article that answers honestly ("it doesn't, here's the QuickBooks route, here's when that's a dealbreaker") holds a reader better than one that dodges. Someone searching that phrase is eliminating options. They want an answer, not a pitch.

Twenty to forty facts will support a plan of about thirty terms. The exercise overlaps almost exactly with writing a brief, so the creative brief template works here too.

Six categories, six kinds of searcher

Spread your derived terms out and they sort themselves into six groups. Each one catches a different moment in the buying process, and each one wants a different kind of page.

Brand. Terms carrying your product or company name: "[tool] pricing", "how to cancel [tool]". Small volume, shortest distance to a sale. Don't assume these belong to you by default. Competitors bid on brand terms, review aggregators outrank vendors on them constantly, and "[tool] alternatives" written by someone else is often the first result your prospect sees.

Product. The capability itself, named the way a buyer would name it: "two-way Jira time sync", "weekly timesheet approval". The searcher doesn't know you but knows what they want. Easiest category to write well, because you have the feature and can describe how it works and where it breaks.

Competitor. "[Competitor] alternatives", "[A] vs [B]". These people are actively evaluating. The craft here is proportion: say what the other tool genuinely does better, then say which situations point to you. A comparison page that only flatters itself gets closed in three seconds.

Scenario. The job, with no tool name in the query: "agency utilization rate too low", "how to bill retainer overages". Furthest from a sale, widest reach, and the only category that reaches someone before they know software exists for this.

Question. Anything opening with what, how, can, or should: "do freelancers need to track billable hours". These have a structural advantage. The answer is usually definite, so getting it right beats out-writing anyone on length. Getting it right is also the price of admission for AI-generated answers — Google's own guidance is blunt that there's no separate playbook for showing up in AI features, just the same fundamentals.

Long tail. Specific combinations with few searchers and few competitors: "time tracking for 5 person design studio free". One term brings a handful of visits. Thirty of them bring a steady trickle of people who know exactly what they're looking for.

Cover four categories minimum. All long tail gives you scattered traffic far from revenue. All brand and product means you only ever catch people who already found you, and nobody is working the top of the funnel. The coverage check takes a minute: sort your list into six piles and see which pile is empty.

Derivation is a hypothesis. Search results are the test

Terms derived from product facts use your vocabulary. Buyers may use a different one. Internally it's "utilization reporting"; the search box gets "how many hours are my designers actually billing". No amount of thinking at a whiteboard surfaces that gap.

Doing it by hand: run each candidate through a search engine, read the first eight to ten results, and record three numbers.

• Result count. Zero results, or results that are all about something else, means nobody phrases it that way. Cut the term.
• Title hits. How many results put the term in the title. A high count means people already write for this term on purpose. It's a real term, and you'll have to earn your way in.
• Body hits. How many results mention it only in the snippet or body. Terms that show up in bodies but never in titles are the openings: real searches with no page built for them.

That third pattern is where I'd start writing.

While you're there, look at what kind of pages came back. Ten ecommerce category pages means a tutorial won't rank. Ten forum threads means the pain is real and a clear explainer has room. The result page tells you what format the term wants.

This step takes the longest and it's the one you can't skip.

Decide what your number measures before you sort

You need one number to sort by, so you know which three articles to write first. Write down what that number is.

If you have real volume data (a tool subscription, Search Console history), use it. If you don't, resist the urge to invent an estimate and call it volume. A made-up number quietly steers every decision downstream of it.

Without volume, sort on a relevance score you can take apart:

Record the four separately, then weight them into a total. The payoff comes later: three months on, you can explain why a term scored 82, and if the weighting turns out wrong you re-sort by changing one number instead of redoing the research.

One rule to hold: terms whose search check failed get labeled unvalidated and stay out of the ranked pool. Sorting two measurement standards in one list makes the cutoff arbitrary.

Doing it by hand, step by step

1. Write 20 to 40 product facts, each traceable, limits included.
2. Derive 5 to 8 candidates per category. Ignore overlap for now.
3. Deduplicate and normalize: case, plurals, and synonymous phrasings collapse into one entry.
4. Search each term. Record result count, title hits, body hits, and one line on what the result page looked like.
5. Drop the zero-result and off-topic terms.
6. Sort the survivors by whatever scoring rule you wrote down, cut at roughly thirty.
7. Tag every surviving term with the product fact that justifies it. Anything you can't tag comes off the list.
8. Write the top three to five, publish, look at the data, then revise the plan.

Step 7 is the gate the whole method hangs on. A term with no supporting fact produces an article you have to invent, and invented claims come back as support tickets.

Step 8 matters just as much. A plan isn't an artifact you finish once. It should get edited after the first few pieces ship and you see which categories actually pull.

What automating this looks like

LinkBloom's content engine runs that checklist in two stages: produce the keyword plan, then draft against it. Stage one maps onto the manual version line for line:

• Candidates derive from product facts you confirmed in the workspace, not from a seed term.
• The target is 30 terms across the six categories, with at least four categories covered in any plan.
• Candidates are oversampled first, then each term goes through live search results for calibration.
• The score reported is relevance, and it breaks into evidence, result coverage, title match, and body match.
• Terms whose search check fails are labeled unvalidated, and a plan flags itself as degraded if every check fails.

One thing it won't give you: search volume. There's no live volume data source behind it, so the score answers how well a term connects to your product and whether anyone outside phrases things that way. Judging commercial value stays with you, or with a volume dataset you read alongside the plan.

What automation removes is steps 2 through 6. Steps 1 and 7 stay yours, because the facts are yours and so is the call on which articles get written.

FAQ

So keyword tools are useless?

No. They're good at two jobs: estimating how many people search a term, and surfacing phrasings you'd never have guessed. Run them after derivation as a cross-check instead of before it as a starting point. Same tools, different position in the sequence, very different plan.

Why thirty terms?

Practical limits on both ends. Under twenty and six categories won't fill out, so one or two stay empty. Over fifty and you'll never write them, which turns the plan into decoration. What sets the real number is how many pieces you finish per week, so use yours rather than copying someone else's.

We haven't launched. There are no product facts yet.

There are. What the product solves, who it's for, how it differs from the current workaround, what it deliberately leaves out. A pre-launch plan leans on scenario and question terms; brand terms come later, once people have a name to type.

Can we translate the plan for a second language?

Not the term list. Translation gives you your phrasing in another language, not what people in that market type into a search box, so the validation step has to run again per language. The product facts carry over; the category mix usually doesn't, since brand terms have almost no volume in a market that hasn't heard of you and the weight shifts to scenario and question terms. If both language versions go live, declare them as localized versions of each other with hreflang, or search engines may surface only one of them.

Do we have to build all six categories at once?

No. Start with four, and go deepest in the categories where your fact list is richest. Category coverage exists to stop you from chasing one kind of traffic, and filling a quota isn't the point.