Keyword research for your site

We do not simply export keys from one service; we gather demand from several sources and bring it into a single structure. Below is the scope of work and what each block gives.

The size of the core depends on the niche: for a service site it is hundreds of queries, for a large store tens of thousands. In any case you get not a raw export but a document ready for work.

How we collect the core

The process is built in steps, and the result of each step can be checked. This removes the "magic" and makes the core transparent.

1. We parse queries from Serpstat, Google suggestions by the A-to-Z principle, competitor keys and question phrases;
2. We clean the list of duplicate word forms, noise and negative words;
3. We cluster queries by search intent;
4. We distribute clusters across the site structure — which pages to create and for which queries;
5. We arrange the core into a table with frequency, groups and target pages.

We speed up collection and clustering with our own tools — a desktop pipeline and the seo-text AI agent. So the core comes out full, free of duplicate forms, and a large niche takes days rather than weeks.

Sources of queries

The completeness of the core is defined by its sources. We use not one service but a bundle, so as not to miss demand.

• Serpstat — frequency, related queries and the keys competitors rank for;
• Google suggestions — live user phrasings that are absent from databases;
• Competitor sites from the top — queries they have created pages for;
• Question queries (People Also Ask) — a basis for FAQ and informational pages.

Combining sources closes blind spots: what is missing in Serpstat often surfaces in suggestions or among competitors. So the core reflects real demand, not only what made it into one database.

Clustering and site structure

Raw keys are useless without grouping. We cluster queries by meaning and search intent: which of them a user expects to see on one page, and which require separate ones. This protects against cannibalization, when several pages compete for one query.

On the basis of clusters the structure is designed: categories, subcategories, filters, landing and informational pages. You get not just keys but a clear plan — what to create and in what order. After it comes SEO promotion and the writing of texts.

One service shows only its part of demand. Serpstat databases are strong on frequency but do not know fresh phrasings; Google suggestions are live but without numbers; competitors reveal commercial queries absent from databases. Collection from one source gives an incomplete core, and that means missed traffic.

So we run keyword selection from several sources at once and bring them into one list. The overlap of data removes random gaps: a query missing in one database is almost always found in another. This way the grouping of queries rests on a full picture, not a fragment.

Negative words and core cleaning

A raw export always contains junk: other brands, irrelevant regions, informational queries where commercial ones are needed. Without cleaning, such a core inflates the structure and pulls non-target traffic to the site. We remove duplicate word forms and irrelevant phrases and build a list of negative words.

Negative words are useful not only for SEO but for future paid ads — they cut off impressions on unsuitable queries. A clean core saves budget both on organic and on paid traffic, so we give this stage as much attention as the collection itself.

Semantics for an online store

Stores have the largest semantics: queries split into categories, subcategories, brands, filters and individual products. Query clustering here defines the catalog tree and faceted navigation — which filters to turn into separate landing pages for demand of the "buy a product with a feature" kind.

A correctly built store core covers the long tail: color, size, material, price, compatibility. These queries are low-frequency one by one, but together they give a significant share of traffic and sales. So for a catalog we work the semantics deeper than for a service site.

The core and a content plan

Building a core does not end with a table — it turns into a work plan. Each cluster becomes a page with a goal and a priority, and question queries become article topics and FAQ blocks. So the core sets both the structure and a content plan for months ahead.

On the basis of clusters we prepare briefs: which subtopics to cover, which keys to use, what length is needed. This transition from core to brief is sped up by our tools, so content comes out systematically rather than as one-off texts.

Common mistakes when collecting a core

Knowing typical missteps helps you assess the quality of someone else's core and avoid repeating them on your own.

• Collecting from one service — half the demand stays unnoticed;
• No cleaning and negative words — junk in the structure and non-target traffic;
• Clustering by words rather than intent — page cannibalization;
• Ignoring question queries — missed informational pages;
• A core with no tie to pages — a list of keys you do not know what to do with.

We build the process so as to rule out each of these mistakes at the collection stage.