How to Separate Product Keywords From Category and Advice Queries

When you sort ecommerce search queries, decide whether each searcher wants one item, a group of products, or help understanding or choosing. A product query points to a particular item or variant, a category query suggests browsing a group of products, and an advice query asks for help understanding or choosing. These are working labels for the searcher’s likely task, not official Google query types.

Start with the words people search, then check the organic results and the pages they lead to. That check matters because wording alone can mislead: “best running shoes” suggests evaluation, for example, but the results might include buying guides, product listings, or both. For the candidate phrase keyword research ecommerce, the wording suggests an advice query. That is a starting hypothesis, not a verified reading of results in a particular market.

Match the query to the task

Use the page type that lets a searcher complete the likely task. A product page gives details about one item, such as its specifications, variants, price, and availability. A category page helps people browse a range of related products. An advice page explains a topic, compares options, or helps someone decide what to choose.

Treat these examples as starting points. “Best running shoes for flat feet” could call for advice, product listings, or a mix. Google’s Search Quality Rater Guidelines describe how a query can have more than one meaning and how context, including location, can matter. The guidelines explain how human raters assess results; they do not provide an SEO formula that assigns every query to one page type.

Check the results before assigning a page

For important queries, inspect the organic results in the market you want to reach. Organic results are the regular search listings, separate from ads. Look at the pages they lead to and record whether the results mainly show individual product pages, category pages, editorial advice, or a mixture.

Compare the page types in the results with your first guess about the query. If a broad product noun leads mostly to category pages, the searcher likely wants a range to browse. If a specific model name leads mostly to product pages, a page about that item is a closer fit. If guides and comparisons dominate, an advice page is a stronger candidate. A mixed result page is evidence that more than one task may fit the query.

Record the query and date. Note the target country or market and language, then record the device and page types you observed. Google says search results can vary by time and place. Device and recent search history also affect them, so one inspection describes a snapshot rather than a permanent classification. Recheck important or ambiguous queries before making a page decision.

Search-result data needs the same care. In a US English Google organic-results snapshot checked on November 11, 2026, eight queries returned 65 organic rows. The exported URL fields for 63 rows were opaque google.com/goto wrappers, which did not reveal the destination pages. A string comparison returned no overlap for the query pairs, but the opaque fields could not establish whether the destinations actually overlapped. This was one snapshot of eight queries, not evidence about all Google results or about keyword research ecommerce.

When an analysis depends on destination URLs, confirm that the data actually contains resolved destinations before comparing pages or calculating overlap. A result’s displayed domain or breadcrumb can help you spot a mismatch, but it does not by itself verify the full destination URL.

Assign queries to pages that satisfy the task

Once you have an initial guess about which page type fits the query, check it against your site: people looking for one item’s size, compatibility, or availability need a different landing page from people browsing a category or learning how to choose. Google’s guidance on ecommerce site structure describes how category pages, subcategories, and product pages can connect through site navigation. That structure helps search engines and shoppers find the pages; it does not decide which query belongs to each URL.

For pages already appearing in Google Search, use Search Console’s Performance report to compare search queries with the pages people reach from those searches. Check whether a product query leads to a relevant product page, whether a broad category query leads to a useful range, and whether advice queries lead to content that answers the question. Search Console reports clicks, impressions, click-through rate, and average position, but it does not show every query: Google omits some anonymized searches and limits the rows shown. Missing queries do not prove that no one searches for them. The report’s query and page dimensions explain how the data is grouped.

Keep related wording on one page when the queries point to the same task and the results favor a similar page type. Investigate separately when the task changes. Do not create a separate URL for every wording variation, and do not force product, category, and advice needs onto one page simply because they share a product term.

Structured data is code that describes a page to search engines, and it offers a limited check on page type. Google’s product snippet guidance explains when pages focused on one product or its variants qualify for product rich results, enhanced listings in search, rather than general category listings. This helps you check whether product markup fits the page. It does not classify query intent or prove that a page will rank or receive a rich result.

Use search volume to prioritize, not classify

Search volume can help you decide which queries deserve attention first, but it cannot tell you whether to create a product page, category page, or guide. Google Keyword Planner’s average monthly searches depend on settings such as location, date range, and Search Network. The figure includes close variants, and the competition metric refers to advertisers, not organic SEO competition. Google explains these conditions in its guidance on Keyword Planner metrics.

For keyword research ecommerce, the phrase names a research task and an ecommerce subject, so an advice page is a reasonable first hypothesis. No market-specific result check or site data is established here. Check the current organic results for your target market before assigning the phrase to a page, and do not infer its search volume or ranking difficulty from the wording.

Avoid shortcuts that confuse the decision

Modifiers such as “buy,” “best,” “review,” and “cheap” can suggest intent without determining it. “Buy” may point toward a product, while “best” may signal comparison, but the result pages and the task they support provide better evidence than a single word.

Do not treat advertising data as an organic intent classifier. Google Ads explains keyword matching in the context of ads and search terms; it describes which searches may trigger an ad, not which organic page type should target a query.

Google’s AI search guidance says foundational SEO practices also apply to its generative Search features. A page that fits the searcher’s task and states product facts clearly gives search systems useful information to interpret. That does not guarantee an AI answer will cite, mention, or send traffic to the page.

Key Takeaways

• Classify the task: Decide whether the searcher wants one item, a range of products, or help making a choice.
• Verify with organic results: Record the market and date, then inspect the destination page types instead of relying on modifiers alone.
• Match the page to the task: Use a product page when the searcher wants an individual item, a category page when they want to browse, and advice content when they want explanation or evaluation.
• Check the data before comparing URLs: Unresolved search-result wrappers cannot establish destination overlap.
• Use volume for prioritization: Keyword Planner estimates demand under selected settings; it does not identify intent or measure organic difficulty.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com