Ecommerce SEO
Keyword research for catalogs: demand to taxonomy
A catalog-first method: gather demand you already own, build the modifier grid, map each cluster to a page type and decide what to publish.
By CartKernel · Published
Keyword research for a store is not a list of phrases. It is a decision about which pages exist, what each one is called, how they link to each other and which ones you refuse to build. The output is a taxonomy the whole catalog runs on, and the input is mostly data the store already owns.
Working the other way around, starting with a keyword tool and looking for phrases with volume, produces pages that duplicate each other, collections with four products in them and a navigation nobody can hold in their head. Start with the catalog.
Begin with what you sell and how it varies
Write down every product type you stock, in the words a shopper would use rather than the words on your purchase orders. Then, for each type, list the attributes that change the buying decision: size, material, capacity, fit, compatibility, use case, price band, certification, season. These attributes are the raw material for everything that follows, because shopper queries are almost always a product type plus one or two attributes.
This step also surfaces the gaps. A product type with only two options behind it cannot support a page per option. A type with sixty options and eight meaningful attributes can support a great deal, which is where programmatic collection pages become a sensible build rather than a shortcut.
Gather demand from four sources you already own
External volume estimates are useful for scale, and unreliable for intent. Three of the four best sources cost nothing and describe your actual buyers.
- Internal site search. The purest statement of intent on the site. Every query typed into your own search box is a shopper telling you what they expected to find, in their own vocabulary. Pay attention to searches that return nothing, and to searches that return results but no clicks.
- Search Console. Filter to queries where the store already receives impressions but few clicks, and to queries where a product page ranks but a collection would answer better. This is the fastest source of pages that already have demand and the wrong destination.
- Paid search terms. If the store runs search campaigns, the search terms report shows real queries with commercial intent already priced by the market. Queries that convert in paid are candidates for a page in organic.
- Support and sales conversations. Email tickets, chat transcripts and reviews carry the questions that come before a purchase, including the ones the category page never answers.
Add an external keyword tool last, for volume order of magnitude and for discovering vocabulary you do not use internally. Treat its numbers as relative rather than absolute.
Build the modifier grid
Put product types down one axis and attributes across the other. In each cell, note whether real demand exists for that combination and how many products you stock that satisfy it. The grid does three things at once: it shows where demand exceeds inventory, where inventory exceeds demand, and where two different words describe the same thing.
An illustrative row for a store selling office chairs might carry the type “ergonomic office chair” against attributes for back height, adjustment features, material, weight capacity and price band. The cell for one attribute might hold twenty products and clear demand, another might hold three products and demand that is genuinely about something else.
The grid is also where synonyms get resolved. If shoppers search for two words that mean the same thing, one becomes the page and the other becomes a phrase inside it, never a second page.
Match each cluster to the page type that answers it
Demand does not map to one kind of page. Assign each cluster deliberately:
| What the query wants | Page that should answer it |
|---|---|
| A product type, broad | Top-level collection |
| A type plus one durable attribute with real inventory | Subcollection with its own URL, copy and internal links |
| A type plus a transient attribute such as color or size | Filter state, not an indexable page |
| A specific product, model or SKU | Product page |
| Compatibility with something the shopper owns | Fitment page |
| Help choosing between options | Buying guide |
| A single factual question | Answer page, linked from the guides and collections it serves |
The line between the second and third rows is the one that decides whether a site stays healthy. Durable, high-demand attributes earn a real page. Every other combination stays behind a filter that does not generate a crawlable URL, which is the whole subject of faceted navigation and the rules in faceted navigation rules.
Apply a publish rule, and hold to it
Before a page goes on the build list it should pass all four tests:
- Inventory. Enough products to make the page useful once a shopper lands, with enough remaining after filters and stockouts. How many products per collection page covers the floor.
- Distinctness. The page can carry a description, a set of criteria and a product set that no neighboring page could truthfully carry. If it cannot, it is a filter.
- Demand. Somebody outside the company searches for this, in these words.
- Maintenance. Somebody will keep it accurate when the catalog changes.
Pages that fail the second test are the main cause of index bloat, where a store accumulates thousands of near-identical URLs competing with each other. It is much cheaper to not create them than to consolidate them later.
Merge before you publish
Run the candidate list through a deduplication pass. Two candidates belong together when they would be satisfied by the same product set and the same page content. Pick the phrasing shoppers use most, make that the page, and keep the other phrasing as an internal search synonym and a sentence within the page.
This is also the moment to decide the URL. Short, lowercase, readable, one pattern for the whole site, and stable once published. Changing a URL later costs redirects, lost links and a period of instability that nobody plans for.
Write the taxonomy down
The deliverable is a document, not a spreadsheet of phrases. For each page it records the URL, the page type, the primary phrase, the product rule that fills it, the parent, the children, the guides and answers it links to, and the person responsible. That document then drives the collection build, the internal linking plan in internal linking for ecommerce, and the copy brief for each page described in the collection page anatomy.
Sequence the build by revenue at stake rather than by search volume. A page serving a product line with healthy margin and stock is worth more than a page serving a larger query you cannot fulfill.
Refresh on a schedule, not on a whim
Catalogs move. Set a quarterly review that does four things: pull new site search terms and Search Console queries, check which published pages have too few products left, retire or merge pages that failed to earn traffic in two quarters, and add the new product types the merchandising team introduced since the last pass.
The specifics of which phrase belongs on a product page rather than a collection are in which keywords should product pages target, and the way subcategories earn their place is in do subcategory pages help SEO. The full build sits inside ecommerce SEO.