Splitting B2B export keyword research by part number, application and industry

The output of this process is a spreadsheet: one row per query, one column for the vocabulary the query belongs to, one for where you found it, one for the page it maps to, one for what to do with it. Everything below is about filling those columns honestly. The research part is mostly deciding which rows deserve a page of their own.

The vocabulary column decides everything else

B2B buyers search in one of three vocabularies, and which one they use tells you where they are in the buying process and what kind of page can answer them.

Vocabulary	What the buyer already knows	Query shape	Page that answers it
Part number	the exact part	ABC-1234, ABC1234 datasheet, replacement for XYZ-45	family page with parameters, variants, documents
Application	the job the part has to do	600V mosfet for LED driver, valve for 180C steam line	application page with an app note or a test
Industry	the regulated world they sell into	automotive grade ..., medical device ...	segment page with certifications and references

Sort every row before you do anything else. A list that mixes the three gets prioritised by whatever has the biggest volume number, which is usually the vaguest query and the hardest page to write.

Part numbers: the shortest path from search to enquiry

Start by collecting the strings. They're already written down somewhere:

• your catalogue and order history
• customer emails and RFQs — the exact string is in there, punctuation included
• distributor spreadsheets and price lists
• the cross-reference tables printed in datasheets, both yours and the ones for parts you replace
• drawings, packaging, spare-part lists

Judging demand works differently here. Volume tools return zero or a dash for most of these strings, and that means "not enough data", not "nobody searches". Better evidence, in rough order of strength: the string appears in an actual enquiry; the string shows impressions in your search console query report; a distributor asked for it by name.

Normalise before you count. The same part arrives as ABC 1234, ABC-1234, abc1234, ABC/1234. Counted raw, that's four queries where there is one.

With a CSV that has a query column, this groups strings into families and shows you where the spellings cluster:

import csv
import re
import sys
from collections import defaultdict

FAMILY = re.compile(r"([A-Za-z]{1,5})[\s\-_/]?(\d{2,6})")


def family(query):
    match = FAMILY.search(query)
    if not match:
        return None
    prefix, digits = match.group(1).upper(), match.group(2)
    return f"{prefix}{digits[:3]}"


rows = list(csv.DictReader(open(sys.argv[1], encoding="utf-8")))
by_family = defaultdict(set)
for row in rows:
    key = family(row["query"])
    if key:
        by_family[key].add(row["query"].strip().lower())

for key, queries in sorted(by_family.items(), key=lambda item: -len(item[1])):
    sample = "; ".join(sorted(queries)[:5])
    print(f"{key}\t{len(queries)}\t{sample}")

The heuristic is deliberately crude — prefixes like LED or AC will pull unrelated strings together, so read the output before you build anything from it. What you're looking for is families with several distinct spellings. Those are the ones where buyers are already searching by part number. A family with exactly one spelling, and that spelling matches your internal code, is usually a string you invented.

A family earns its own page when you sell it, you can fill the page with parameters, variants and documents, and more than one spelling shows up. A single SKU with no documents belongs in a row of the family table, not on its own URL. Hundreds of near-identical pages end up competing with each other for the same query, which is worse than one complete page.

Applications: queries from buyers who don't know your part numbers

These buyers describe the job. The query pattern is a part type plus "for" or "used in" plus a condition: temperature, voltage, IP rating, package, certification.

Where they show up: support tickets, notes from sales calls, trade-show conversations, distributor application pages, industry forums, and the applications section of your own datasheets. That last one is underrated — it was written by engineers in the buyer's language rather than in your category tree.

Build a grid rather than a list. Applications down one side, constraints across the other.

Application	Constraint	Query example	Evidence you can show
LED driver	600 V, high switching frequency	600v mosfet for led driver	app note, efficiency curve
Steam line	180 °C continuous	valve for 180c steam line	test report
Battery charger	reverse polarity protection	—	nothing yet

Fill a cell only when there's a document, a test result, or a reference customer behind it. Empty cells are information: they tell you what to ask engineering for before you write anything.

An application phrase without proof belongs in a short FAQ block on the family page. Giving it its own URL produces a page that says the same thing as the family page in slightly different words, which helps nobody.

Industry: the vocabulary the buyer's regulator uses

Automotive, medical, lighting, appliance, industrial automation each have their own words for the same component, and those words come from standards and procurement departments, not from your product taxonomy. That's why industry rows often look unfamiliar when you first see them in a query report.

Industry queries are the vaguest and the most contested. One product page won't hold them. What holds them is a segment page — the parts you ship into that segment, the certifications, the documents, one or two references — with the family and application pages underneath it linking up. If you have no references in a segment, don't build the segment page yet; the page will be a paragraph of adjectives.

Before a term goes into the sheet, test it out loud: would a buyer say this on a phone call, or is it a literal translation of your internal category name? Translated category names are the most common source of rows that sit for a year with no impressions.

Ordering the work

Score each row on two things only: how specific the query is, and how much evidence you can put on the page. A row with zero evidence is a dead row regardless of how attractive the keyword looks.

• Part-number families first if you sell by part number. The queries are narrow enough that one complete page can answer them, and the person searching already knows what they want.
• Applications second. More reach, more work, and it needs documents you may not have yet.
• Industry last, unless you already have references in that segment.

Monday: the first twenty rows

Take the top twenty rows by that score. For each one, write the single sentence that answers the query, exactly as it would appear on the page. If you can't write the sentence from material you already have, the row isn't a page — it's a request to engineering for a datasheet, a test, or a photo.

Two checks before anyone opens an editor:

• Every row maps to a page, and every page has at least one row whose query a real buyer typed.
• No two rows with the same intent map to different URLs. That's how a site ends up with three pages quietly competing for one search, and it's much cheaper to catch in the sheet than after publishing.