How search demand should influence site navigation — without dictating it

Search demand reveals how customers describe products and services, but it should not dictate your categories or navigation. Use Create, Combine or Support to turn evidence into better architecture.

Customers rarely organise a website in the same way as the organisation behind it. They may use a different name for a product, expect several services to sit together or search for a problem rather than the category used in the catalogue. The result can be confusing navigation, weak category discovery and important offers that are difficult to find.

Search-demand data can expose those gaps. It can show how people describe a product or service, which alternatives they consider and which language is associated with existing pages. But search demand is evidence about customer vocabulary and behaviour. It is not, by itself, a specification for a new category, URL or menu item.

The practical question is not “Which keywords should become categories?” It is “What should this evidence change about the way customers find and understand the business?”

This article introduces a practical Create / Combine / Support decision model. It helps marketing and ecommerce teams decide whether a demand pattern should lead to a distinct navigational grouping, sit alongside related terms under one destination or remain supporting language in copy, filters, internal search and contextual links.

Search demand is customer-language evidence, not business architecture

Search data describes how people search for, name or seek products, services and problems. It can reveal recurring vocabulary, alternative names, emerging terminology and demand associated with existing pages.

It does not tell you, on its own:

• which products belong in the same commercial range;
• which services share an owner or delivery process;
• whether a phrase describes a distinct customer task;
• whether users expect a category, a guide, a filter or a single product page;
• whether the business can maintain and fulfil the destination; or
• whether a new page would improve the customer experience.

An organisation usually has several overlapping structures:

• Customer-facing information architecture: how people browse, compare and understand the offer.
• Business architecture: how products, services, teams, suppliers, markets and commercial responsibilities are organised.
• Catalogue or service structure: how the CMS, product-information system or operational tools represent relationships.
• Crawl architecture: how search engines discover and interpret URLs and links.

These structures need to work together, but they do not need to be identical. A customer-facing label may use familiar language while the underlying catalogue retains a more precise internal classification. A filter may expose an attribute without becoming a top-level navigation item. A curated collection may help users reach a group of products without becoming a permanent branch of the main taxonomy.

Search volume cannot resolve those choices. It can show where a decision deserves investigation.

The Demand-to-Architecture Translation Model

Liquid Silver’s proposed decision aid considers four layers before changing navigation or page groupings:

1. Demand evidence: what people search for, how consistently they use the language and which query patterns appear around it.
2. Customer task: what someone is trying to find, compare, buy, book, understand or solve.
3. Business architecture: whether there is a distinct offer, product set, service relationship, commercial priority and accountable owner.
4. Implementation reality: whether the CMS, catalogue, inventory, translation process, merchandising model and operational teams can support the change.

The output is one of three actions:

• Create: establish a distinct navigational grouping when the evidence supports a coherent, supportable destination.
• Combine: use several related terms under one destination when they represent the same underlying task, offer or product set.
• Support: retain the language in page copy, filters, internal search, FAQs or contextual links when it does not justify a separate structural destination.

This is not a search-engine rule or an industry-standard taxonomy model. It is a way to make the reasoning visible and prevent keyword volume from becoming an unexamined architecture decision.

When should a demand pattern create a new navigational grouping?

A new grouping deserves serious consideration when several forms of evidence point in the same direction. Search demand is one part of that evidence, not the threshold that decides the outcome.

Look for the following combination:

• Consistent demand: the language appears across a meaningful range of related queries rather than in one ambiguous phrase.
• A distinct customer task: users are trying to browse, compare or select a recognisable set of products or services.
• A distinct offer or inventory set: the business can describe what belongs in the grouping and what does not.
• Commercial importance: the grouping supports a meaningful strategic, revenue, customer or market priority.
• Clear expectations: a customer can predict what they will find after selecting the label.
• Operational ownership: someone can maintain the products, content, availability, merchandising and terminology.

Search-result pages can provide a useful page-type signal. If results for a query consistently present category or collection pages, that may suggest that users are looking for a browseable set rather than one answer. It does not prove that your business should create a new navigation branch or indexable URL. Search results reflect the current market, competitors, ranking systems and existing page formats.

Google’s ecommerce guidance recommends crawlable links between important pages and explains how navigation and cross-page links can help Google understand page relationships and relative importance. That makes crawlable linking a useful implementation check. It does not mean every visible navigation item should become an indexable page, or that crawl architecture must mirror the customer-facing menu.

Worked example: creating a distinct grouping

Imagine a retailer selling equipment for home coffee preparation. Search data shows sustained demand around “manual espresso machines”, “lever espresso machines” and related product names. The product catalogue contains several models that share a buying task, comparison criteria and merchandising owner. Existing category pages group them only under a broad “coffee machines” branch, where they are difficult to distinguish.

This may support a distinct grouping such as Manual espresso machines if:

• the products form a coherent range;
• customers understand the category label;
• the business can maintain stock, content and filters for it;
• the grouping has commercial importance; and
• testing shows that users can find and use it successfully.

The decision is not based on the largest keyword volume. It is based on the fact that the demand pattern aligns with a distinct customer task, a recognisable product set and a supportable business responsibility.

This article keeps the question of whether a new grouping should receive a specific indexable URL at a high level. For that narrower ecommerce decision, see When Does a New Ecommerce Category Deserve an Indexable URL?

When should related terms be combined under one destination?

Different search terms do not necessarily represent different destinations. Customers may use several names for the same offer or describe the same task from different angles.

Combine terms when the destination, selection process and underlying offer are substantially the same. Useful evidence includes:

• similar search-result intent across the terms;
• the same products or services satisfying the searches;
• the same comparison criteria and buying questions;
• one clear page purpose and one accountable owner;
• no meaningful difference in what the customer expects to find; and
• evidence that separate destinations would duplicate content or force users to choose between near-identical labels.

Worked example: combining related terms

Consider a software company offering a platform for managing employee expenses. Searchers may use phrases such as “expense management software”, “business expense software” and “corporate expense tracking”. The wording differs, but the underlying task may be the same: evaluate software that helps a business record, control and report employee spending.

If the search results, sales conversations, product capabilities and existing page behaviour point to one buying journey, these terms are better treated as supporting language for a single destination. The page can use the clearest customer-facing label in its navigation while incorporating alternative language in the title, introduction, headings, product explanation and internal-search vocabulary.

Creating three top-level destinations merely because three phrases have measurable demand could split the proposition, duplicate the offer and make users decide which version of the same service they need. Clustering or semantic similarity might help identify the relationship, but similarity alone does not prove that the terms describe one task or one commercial destination.

The useful test is destination equivalence: would a customer expect materially different content, products, proof or next steps after selecting each term? If not, combining them may be clearer.

When should a term remain supporting language?

Some phrases are useful and commercially relevant without deserving a category, menu item or standalone destination.

Use a term as supporting language when it describes:

• an attribute that helps customers narrow a broader range;
• a feature shared by products in several categories;
• a problem that the existing offer already solves;
• an informal or emerging customer expression;
• a regional or audience-specific variation of an established destination; or
• a concept that the business cannot consistently fulfil as a separate range.

Worked example: supporting a term without creating a top-level page

Suppose a travel company sees demand for “city-break hotels with late checkout”. “Late checkout” may be important to some customers, but it may not represent a distinct inventory set or a separate buying journey. Hotels with that facility could sit across destinations, price bands and accommodation types.

In that case, the term might be better supported through:

• a filter where the availability data is reliable;
• internal-search synonyms;
• clear amenity information on hotel pages;
• copy on relevant destination or accommodation pages; and
• contextual links from guidance about planning short city breaks.

A top-level category could create an expectation that every result meets the requirement, even when availability is variable. Rejecting the category is not ignoring demand. It is recognising that the demand does not map cleanly to a stable navigational destination.

The same principle applies to a high-volume term. A phrase may be broad, ambiguous or associated with several incompatible intents. If the business cannot provide a coherent offer behind the label, volume is not a sufficient reason to promote it in the main navigation.

How to evaluate the four decision layers

Demand evidence

Start with more than one volume figure. Examine query variations, recurring modifiers, seasonality, regional differences and the pages that currently receive impressions or clicks. Search Console can be used to examine observed queries alongside impressions, clicks, click-through rate, average position and landing pages. This helps explain how existing destinations relate to observed search behaviour, rather than estimate the full market.

Interpret the data carefully. Search Console query data is incomplete, and keyword volumes or forecasts are estimates rather than direct predictions of organic traffic, revenue or category value. A large number can reflect ambiguity or several unrelated intents. A small number can reflect fragmented, emerging, specialist or regional demand.

Internal search can add customer language that external tools miss, particularly for specialist products or services. But internal search is not neutral evidence: poor navigation can increase search use, while weak onsite search can distort or suppress recorded vocabulary. Review zero-result searches, refinements, exits and successful downstream actions rather than counting queries alone.

Customer task and expectations

Ask what the person is trying to do. Are they browsing a range, looking for one product, comparing solutions, checking an attribute, solving a problem or learning terminology?

For this decision, treat information scent as the cues surrounding a label that help a person judge whether a path is likely to lead towards their goal. A phrase can have substantial demand and still be a poor navigation label if it is ambiguous, internally defined or unable to tell users what they will find next.

Card sorting can help explore possible groupings and labels. Tree testing can help test whether people can find items in a proposed structure. Treat both as evidence about a particular research design, not as proof that a taxonomy is optimal in a live interface. Results can vary with the wording, test design, sample and level of context provided. Use research to test a hypothesis, then combine it with behavioural and commercial evidence.

Business architecture

Test whether the proposed grouping represents a real difference in the offer. Relevant questions include:

• Is there a distinct product or service set?
• Does the grouping have different buying criteria?
• Is there a clear boundary between what belongs and what does not?
• Does it have commercial or strategic importance?
• Is there a team responsible for its accuracy and performance?
• Can stock, fulfilment, pricing, availability or service delivery support the promise?

Business architecture can legitimately override search volume. A high-volume term may attract unsuitable users or create expectations the organisation cannot fulfil. Conversely, a lower-volume specialist grouping may deserve prominence if it is strategically important, difficult to find and commercially supportable. Neither decision is proven by volume alone.

Implementation reality

Taxonomy changes cross organisational boundaries. Ecommerce, merchandising, SEO, UX, analytics, engineering, customer service, regional teams and commercial owners may each hold part of the decision.

The CMS and catalogue may impose further constraints. A new grouping might require product attributes to be populated consistently, a new merchandising owner, translated labels, revised templates or a new feed relationship. A customer-friendly label may not map neatly to the catalogue’s internal hierarchy.

Before approval, document the decision rather than relying on a meeting outcome. A useful decision record should capture:

• the demand pattern and its limitations;
• the customer task and expected terminology;
• the proposed scope and what is excluded;
• the existing destination, if one exists;
• commercial value and accountable ownership;
• catalogue, CMS and translation constraints;
• the chosen Create, Combine or Support outcome;
• the validation method and success measures; and
• the conditions that would trigger a future review.

Navigation architecture is not crawl architecture

A navigation change may affect search-engine discovery, but the two problems should not be conflated. The main navigation should help customers understand and move through the offer. Crawl architecture should help search engines discover and interpret important pages efficiently.

Sometimes the same structure serves both purposes. Sometimes it should not. A filter may be useful for customers but create many low-value URL combinations. A curated collection may deserve a visible link without becoming a permanent top-level category. A specialist destination may need strong contextual links even if it does not belong in the main menu.

After implementation, check that important destinations remain discoverable through appropriate crawlable links, that redirects and canonicals behave as intended and that the change has not created unnecessary URL combinations. Crawl depth and click depth are useful validation considerations, not substitutes for deciding what the customer-facing taxonomy should be. For a separate discussion of navigation scale and link relationships, see Mega-menu inflation: the sitewide navigation graph problem and Crawl depth vs click depth.

Stage the change and measure what happened

Taxonomy changes should be staged where possible. Start with a clearly defined grouping or a limited navigation area, record the baseline and avoid changing unrelated templates, merchandising rules and content at the same time if the effect needs to be understood.

Measurement should cover four areas:

• Findability: navigation selection, successful task completion, exits, refinements and use of internal search.
• Search performance: impressions, clicks, landing-page distribution, rankings and query coverage for relevant destinations.
• Commercial behaviour: product views, enquiries, conversion, assisted conversion and progression through the relevant journey.
• Operational quality: catalogue accuracy, missing products, ownership issues, maintenance effort and support requests.

Do not treat a visibility increase as proof that navigation caused organic growth. Seasonality, availability, competitors, algorithm changes and other releases can affect the result. Likewise, a clearer navigation path may improve findability without producing an immediate ranking change.

A practical decision: Create, Combine or Support?

When a new search pattern appears, ask these questions in order:

1. What is the customer trying to do? Identify the task before choosing the label.
2. Is the demand pattern coherent? Separate consistent language from ambiguous or unrelated volume.
3. Does the business have a distinct offer or set? Define the boundary of the proposed grouping.
4. Would customers expect a separate destination? Test the wording and the proposed contents.
5. Can the organisation support it? Confirm ownership, data quality, catalogue relationships and maintenance capacity.
6. What is the least complex structure that solves the problem? Choose Create, Combine or Support.
7. How will the decision be validated? Define behavioural, search, commercial and operational measures before release.

If the evidence shows a coherent task, distinct offer and supportable destination, Create may be appropriate. If several terms lead to the same task and offer, Combine them under one destination. If the term is useful but does not represent a stable grouping, Support it through content, filters, internal search or contextual links.

Conclusion

Search demand is most valuable when it challenges assumptions about how customers describe and find an offer. It should prompt better questions about labels, groupings and discoverability, rather than dictate the shape of the website.

The important distinction is between customer-language evidence and business architecture. A search term may justify a new navigational grouping, several terms may belong under one destination and a commercially useful phrase may be better handled as a filter or supporting language. The right answer depends on demand, customer task, offer structure, commercial importance and implementation reality together.

For a large or complex site, the difficult part is usually not finding more keywords. It is reaching a defensible decision across teams and implementing it without weakening the catalogue, navigation or measurement. The Create / Combine / Support model provides a practical record of that reasoning, while validation determines whether the chosen structure works in context.

Liquid Silver can help diagnose these decisions across a site, prioritise their commercial importance and work with the teams responsible for implementation and measurement.