Ecommerce Keyword Research - How to Map Queries to Categories, Filters and Products

You do ecommerce keyword research so that every group of queries has one landing page. The mapping rule: a broad query goes to a category, a specific model to a product page, a question to a guide, and a category with a brand or attribute gets its own indexable filter page only when it has demand (it appears in Google's autocomplete or has at least about 50 searches a month) and at least about 10 products. Size, price and sorting stay as filters without indexing. For a store with a few hundred products, free tools are enough: Search Console, Keyword Planner and Google autocomplete. Senuto, Ahrefs or Semrush pay off only with hundreds of categories or for competitor analysis.

How to do ecommerce keyword research and map queries to categories, filters, product pages and guides: a mapping rule with thresholds, a keyword map from 1,109 Google suggestions and real store product counts, Search Console, Keyword Planner, Senuto and Ahrefs with prices, a sheet template and a cannibalisation script.

This post covers the query types in a store and where to send them, when a filter deserves its own page, a keyword map for the "hiking boots" category built from 1,109 Google suggestions and product counts in a real store, a comparison with a second category (coffee machines), a tool comparison with prices, cost at two scales, a mapping sheet template and a script that detects cannibalisation in Search Console data. The data comes from the Polish market (queries in Polish, translated here), but the method works the same in any language.

Do you need a paid tool - the first decision

The most common question before research is: Senuto, Ahrefs or Semrush? Often none of them. If the store is already live, your most valuable queries are in Search Console (queries Google already shows you for) and in the store's internal search (what people ready to buy are looking for). A paid tool adds demand estimates for queries you do not appear for yet, plus competitor data.

I checked the prices on the vendors' sites on 12 October 2026. Search numbers from every tool are estimates, and tools can differ several times over for the same query, so I use them to set the order of work, not as a traffic forecast. I cover research for AI search and the queries no tool will show in the post on keyword research for AI.

Query types in a store and their landing page

Each query type has its place in the store structure. The share in the third column comes from my set of Google suggestions for the Polish query "buty trekkingowe" (hiking boots): 333 suggestions from queries without extra modifiers, method below. One suggestion can have several types, e.g. "women's Salomon hiking boots".

The takeaway: in this category 59% of suggestions (197 of 333) contain a brand or a gender. A "category → gender → type" structure plus indexable brand filters covers most of the demand before you write any text.

When a filter deserves its own page

A filter gets its own indexable URL with a unique title and H1 when it meets three conditions at once. This is my rule from store audits:

1. 1.Demand: the query appears in Google's autocomplete or has at least about 50 searches a month in Keyword Planner or another tool.
2. 2.Range: the page has at least about 10 products. With fewer, the listing looks thin, and after a few models sell out the page becomes empty.
3. 3.Uniqueness: the filter answers a different intent than the parent category and can have its own title and H1 (e.g. "Women's Salomon hiking boots"), not just a "- filter" suffix.

If any condition is not met, the filter works for the shopper but is not indexed and has no links in the HTML. I cover the technical side (noindex, canonical, robots.txt, filter URLs) in the post on ecommerce faceted navigation and SEO, and the order of all the work in the ecommerce SEO strategy.

A keyword map for the "hiking boots" category

How I collected the data: on 12 October 2026 a script pulled Google suggestions (Polish language, Poland) for 158 queries: the query itself, the query + every letter and digit, the query + "women's", "men's", "children's" with letters, and with questions ("which", "how", "should", "best"). That gave 1,109 unique suggestions. I calculated the shares of query types only on the 333 suggestions from "query + letter" requests, because requests with "women's" or "men's" would artificially inflate the gender share. I checked product counts the same day in the women's hiking boots category of eobuwie.pl, a large Polish footwear store (the "Produkty" counter on the page).

What the store itself shows: eobuwie.pl indexes brand and colour filter pages with their own heading (e.g. "Women's Salomon hiking and trekking boots"), the canonical points to the filter itself, and an empty filter for a brand the category does not carry returns a 404 status in the raw HTML instead of an empty page. In the rendered category HTML, links pointed only to a few selected filter combinations, e.g. "Black women's hiking boots". That is a good model: selected filters are indexed, not every combination.

A second category for comparison: coffee machines

The same script for the Polish query "ekspres do kawy" (coffee machine) returned 581 unique suggestions (360 in the set without modifiers). The demand structure is completely different:

The takeaway: do not copy the filter structure between categories. In boots the subcategories are gender and height, in coffee machines the machine type, and queries like "coffee machine ranking" or "which one to choose" need a comparison guide, because a category listing does not answer them.

The cost of research at two scales

Estimates from my quotes (October 2026), excluding the cost of building new categories in the store:

The takeaway: in a small store a paid tool rarely pays back, because you will make most decisions from free data. In a large store the tool costs a fraction of the work it saves and spares dozens of hours of grouping queries.

A mapping sheet template

The sheet is one table in which every query has exactly one landing page. The columns I use, with example rows from the map above (the URLs are illustrative):

query;type;demand_source;demand;products;landing_page;page_type;index;noteshiking boots;category;autocomplete;seed query;1284;/hiking-boots;category;yes;womens hiking boots;gender;autocomplete;top 1;480;/hiking-boots/women;subcategory;yes;womens salomon hiking boots;brand;autocomplete;top 3;57;/hiking-boots/women/brand:salomon;filter;yes;H1 with brandlow salewa hiking boots;brand+attribute;autocomplete;-;7;/hiking-boots/low;filter;no;under 10 productswomens hiking boots size 38;size;autocomplete;-;changing;/hiking-boots/women;filter;no;size not indexedhow to choose hiking boot size;question;autocomplete;-;-;/guide/hiking-boot-size;guide;yes;link to subcategories

The rules: one query has one landing page, one page has one main query and a few secondary ones, and the "index" column follows the three-condition rule. The sheet is also a task list for the developer: every "yes" next to a filter means its own title, H1, an HTML link and a place in the sitemap.

Cannibalisation: how to detect it in Search Console data

Cannibalisation in a store is when Google alternates between the category, a filter and a product page for the same query, and none of them ranks high. The script below pulls query-page pairs for 90 days from the Search Console API, normalises URLs and lists queries where at least two pages get a significant share of impressions.

# pip install google-api-python-client google-auth pandasimport re, datetime as dtfrom urllib.parse import urlsplitimport pandas as pdfrom google.oauth2 import service_accountfrom googleapiclient.discovery import buildSITE = "sc-domain:yourstore.com"creds = service_account.Credentials.from_service_account_file(    "sa.json", scopes=["https://www.googleapis.com/auth/webmasters.readonly"])gsc = build("searchconsole", "v1", credentials=creds)end = dt.date.today() - dt.timedelta(days=3)rows, start = [], 0while True:    body = {"startDate": str(end - dt.timedelta(days=90)), "endDate": str(end),            "dimensions": ["query", "page"], "rowLimit": 25000, "startRow": start}    batch = gsc.searchanalytics().query(siteUrl=SITE, body=body).execute().get("rows", [])    rows += batch    if len(batch) < 25000:        break    start += 25000def norm(url):    # drop sorting, tracking and pagination parameters and the trailing slash    p = urlsplit(url)    return (p.netloc + p.path).rstrip("/").lower()df = pd.DataFrame([{"query": r["keys"][0], "page": norm(r["keys"][1]),                    "impressions": r["impressions"], "clicks": r["clicks"],                    "position": r["position"]} for r in rows])df = df.groupby(["query", "page"], as_index=False).agg(    impressions=("impressions", "sum"), clicks=("clicks", "sum"), position=("position", "mean"))df["share"] = df["impressions"] / df.groupby("query")["impressions"].transform("sum")total = df.groupby("query")["impressions"].transform("sum")cand = df[(total >= 200) & (df["share"] >= 0.2)]multi = cand.groupby("query").filter(lambda g: len(g) >= 2)print(multi.sort_values(["query", "share"], ascending=[True, False]).round(2).to_string())

How to read the output: if for "women's salomon hiking boots" the brand filter has 55% of impressions and a single Salomon product page has 40%, the filter is too weak (few products, a generic title) or the product page has the broad query in its title. The fix follows from the map: strengthen the landing page (title, H1, internal links) and remove the query from the other page's title and heading.

Production pitfall: false cannibalisation from parameter URLs

The most common mistake in this analysis is Search Console data without URL normalisation. The same category appears as /hiking-boots, /hiking-boots/, /hiking-boots?sort=price and /hiking-boots?page=2, so the report looks as if four pages are fighting over one query. Someone "fixes" it with redirects or rewritten content, while the problem exists only in the spreadsheet. That is why the norm() function in the script removes parameters and the trailing slash before calculating anything.

The opposite also happens: if after normalisation you still see parameter URLs with many impressions, that is not an analysis error but a sign that Google is indexing sorting or filters it should not. Then the problem is technical, not keyword selection.

What not to do

• Do not choose queries by search volume alone. A high-demand query with no products in your store brings traffic that will not buy.
• Do not create a page for every brand and every colour. Without demand and without 10 products, that means thousands of thin pages.
• Do not target queries with another store's name ("decathlon hiking boots"). They are navigational - the searcher wants a specific store.
• Do not point one query at both the category and a product page. The product page should rank for the model, the category for the broad query.
• Do not copy the filter structure from one category to another - as the boots vs coffee machines comparison shows, demand looks different in every category.
• Do not treat tool numbers as a traffic forecast. They are estimates for setting priorities.

FAQ

If you want me to prepare a keyword map and filter decisions for your store, see ecommerce SEO.