Building a semantic core: from seed phrases to a list ready for clustering

A semantic core is the list of search queries a site intends to earn traffic from, with a search volume, a region and an intent label against every one. Russian SEO uses the term for what English-language teams usually call a keyword map or master keyword list. Building one takes a few days, and its mistakes show up for months: a page written for a query nobody searches, a section with no demand behind it, an article that takes impressions from its own category page. What follows is the order of work from the first seed phrases to a file ready for clustering. What happens to that file next is covered in the article on keyword clustering. This one is about everything before it.

What belongs in the core, and what does not

People often call a tool export a semantic core, but an export is only the raw material. It holds everything the tool found for your words: other companies' brands, queries from cities you do not serve, homonyms, homework essays and torrents. The core is what remains after cleaning, and it keeps only the queries the site can rank for and wants to rank for.

Every row in the core needs five fields:

• the query itself, in the form people actually type it;
• the search volume, and specifically the exact-match figure rather than only the broad one (the reason is explained below);
• the region that volume was measured in;
• the intent: does the person want to learn, compare, buy, or reach a particular site;
• the source: Wordstat, a tool's database, Search Console, search suggestions.

Without a source column the core is hard to audit. Three months on, nobody will remember where a query with a volume of 900 came from, or whether to trust that number.

Agree on the boundaries up front as well. The core describes demand the site can actually serve. If a shop only delivers within Moscow, queries naming other cities are no use to it however good their volumes look. If a repair shop does not fix Apple laptops, that brand goes on the exclusion list straight away. The size of the core follows from the range of products and the geography: a service business in one city may need a few hundred queries, while an online shop with thousands of products can need tens of thousands.

Seed phrases: where the first queries come from

Collection starts with seeds. A seed is a short phrase of one to three words that names a product, a service or a topic: "plastic windows", "laptop repair", "semantic core". The rest of the core grows out of them, so a missing seed means a missing section of the site.

Places to find them:

• your own catalogue and site structure, including sections that are only planned;
• the price list, which usually has more items than the menu;
• customer questions in support, in chats and in the sales team's inbox;
• the menus and sections of competitors that appear in search results;
• Yandex and Google search suggestions for the seeds you already have.

Write each seed the way customers search for it. The company's internal name for a product does not work here. A manufacturer writes "double-chamber glazing unit" while a buyer searches for "triple glazed windows". An agency talks about a "usability audit" while the client searches for "why nobody buys from my site". Wordstat settles this quickly: the phrasing people use shows real volume, and the in-house term shows zero.

It helps to file seeds under future site sections from the start. That saves time during cleaning, because a query that came from the seed "windows for a house" already tells you which section it belongs to.

The common mistake at this stage is to take a single broad seed such as "windows" and expect expansion to find everything. A broad seed drags in unrelated topics, from Microsoft Windows to windows for a sauna, and cleaning that export takes longer than collecting ten narrow seeds by hand.

Expanding with Wordstat

For projects that target Yandex, Wordstat is the primary source of demand data. It is Yandex's own service and shows statistics for queries made to its search engine. You need to be signed in to a Yandex account to use it.

For each seed Wordstat returns two lists. The first holds every query containing the seed's words. The second holds similar queries: neighbouring phrasings people typed around the same search. The first list deepens the core, and the second points to seeds you missed.

Most of the useful work in Wordstat is done with operators. The service's help pages (checked 14 October 2026) describe them as follows; the examples are Yandex's own, in Russian:

Russian is heavily inflected, which is why the ! operator matters so much. For a semantic core the key combination is quotes plus exclamation marks: "!пластиковые !окна" shows how often people searched for exactly that phrase in exactly that form. The number without operators includes every query containing those words, long tails and all. The gap between the two figures tells you more than either one. If a query shows thousands without operators and a few dozen in quotes with exclamation marks, hardly anyone searches for it on its own; it lives only inside longer queries.

Two more Wordstat tabs matter before any number goes into the spreadsheet. "Regions" shows where people search, and for a regional project the volume has to be taken in that region rather than for all of Russia. "Dynamics" shows seasonality: air conditioners have very different numbers in July and in January, and a core collected in summer will overstate demand for the next six months.

Manual collection has a ceiling. Wordstat's help warns that a captcha appears if you query the service too often, and a core of several thousand queries needs hundreds of lookups. Large cores are therefore collected with desktop parsers or through tools that already hold the data. The logic stays the same: the same seeds and the same operators, just faster.

Competitors and tool databases: Keys.so and Semrush

Wordstat tells you what people search for. It cannot tell you which queries already bring traffic to sites in your niche. That comes from tool databases, which regularly collect results for a huge list of queries and record which site ranks where.

For the Russian-language web the usual choice is Keys.so, which has databases for both Yandex and Google. Semrush is stronger on Google and earns its place when a project targets both engines or works beyond Russia. The workflow is the same in either:

1. Pick five to ten competitors from the results for your main seeds. These are your competitors in search, which is often a different list from your competitors in the market. How to choose them is covered in the article on competitor analysis in search.
2. Export each competitor's queries and keep the ones where it ranks in the top twenty or thirty. A query at position eighty says little about what the site actually does.
3. Merge the exports and count how many competitors each query appears for.

That last count is a good filter. A query that three or more competitors rank for is almost certainly part of your topic. A query that only one competitor ranks for needs a manual check: it may reflect something specific to that business, such as a service you do not offer.

In Semrush the tool for expanding a seed is Keyword Magic Tool, which groups the queries it finds and can filter them by intent. In Keys.so a keyword selection by seed does similar work. If neither is in your stack yet, the calculator on the homepage shows what access would cost.

Treat database volumes with care. They are the tool's estimates, not figures from the search engine. For Yandex, check them against Wordstat; for Google, against Keyword Planner or the impressions in your own Search Console. Never mix volumes from different sources in one column without labelling them, or you end up with queries whose volume appears in no source at all.

If the site is already live, Search Console and Yandex Webmaster show the queries it already appears for. Teams often forget this source, although it is free and describes your own site. Queries with impressions at positions below twenty are usually the quickest wins.

Cleaning: what to remove before clustering

Cleaning takes longer than collection. Remove:

• queries with zero exact-match volume;
• other brands and competitors' navigational queries, unless you sell their products;
• cities and regions you do not serve;
• homonyms: in a car parts shop, "jaguar" may turn out to be the animal;
• formats you do not offer, such as "download", "free", "DIY" or "essay", unless that is what the site is about;
• obvious duplicates with reordered words: "pvc windows buy" and "buy pvc windows" stay as one row, and their volumes are not added together.

Keep a negative-word list as you go. Each junk word is written down once and applied to the whole core, instead of being struck out row by row. On a core of five thousand queries that is the difference between an hour and a day.

Word-based cleaning is fine here, even though it is the wrong method for clustering. At this stage the job is modest: remove obvious junk. Clustering by search results will draw the boundaries between topics later.

Queries you are unsure about should go to a separate tab rather than the bin. A month later, when a new service or section appears, half of them will be useful and you will not have to collect them again.

Search volume: which figures to use and how to read them

A single query in Wordstat can have three numbers: without operators, in quotes, and in quotes with exclamation marks. Decisions are made on the last one. The first two show how many long tails hang off a query, but they are no basis for planning pages.

For seasonal demand, use a twelve-month average instead of last month's figure. Otherwise a core collected at the peak of the season will promise traffic that does not arrive for nine months of the year.

Yandex and Google have different audiences, and their volumes cannot be added into one number. If a project targets both, the core carries two volume columns, and each engine ends up with its own priorities. Other differences between the two engines are collected in the article on Yandex and Google.

Do not drop low-volume queries automatically. A long query with ten searches a month is often commercial, faces less competition, and the person typing it is closer to buying. It rarely deserves a page of its own, but it belongs in the core: during clustering it will join its group and strengthen it.

People often read the total volume of a core as a traffic forecast, and they are wrong to. Even at position one not everyone clicks, and at position five noticeably fewer people do. The core shows the size of demand; a traffic forecast is built separately and adjusted for positions.

Intent: label it before clustering

Every query should get an intent label while the core is still being built. Four types are standard: informational ("how to choose", "what is"), navigational (looking for a specific site), commercial (comparing options before buying) and transactional (ready to buy or order). According to Semrush's own blog (checked 14 October 2026), Semrush marks queries with the letters I, N, C and T, and a single query can carry more than one.

The words in a query give a first pass: "buy", "price", "order" point one way, "how", "why", "what is" another. Words can mislead, though. The results page has the final say: if the top ten for "stretch ceiling price" is full of calculators and articles rather than service pages, the engine treats the query as informational, and fighting that is expensive.

Labelling before clustering matters because queries with different intents almost never share a page well. With labels in place, doubtful clusters stand out at once: if "buy" and "how to do it yourself" ended up in one group, either the threshold is too loose or the engine has not settled on what the topic is.

Do not force mixed-intent queries into a single type. Mark them separately and decide during clustering, when the results show which group they lean towards.

What to hand over to clustering

Collection should end in a single table in which every query appears once:

Junk and doubtful queries stay out of this table, on their own tabs. The cleaner the input, the less manual work after clustering, because every stray query in the core becomes either a pointless cluster or an odd neighbour inside a good one.

From here the table goes to SERP collection and clustering: the match threshold, hard and soft grouping, single-query clusters. All of that is covered in detail in "Keyword clustering: turning a raw export into site structure". The clusters then feed a quarterly content plan, prioritised by volume and current positions.

In terms of time, a core of two to five thousand queries takes two to four working days, more than half of it spent on cleaning. Rebuild it roughly every six months and after any significant change to the product range. By then Search Console will usually have suggested new seeds of its own.

Common mistakes

The first is relying on one source for everything: a core built only from Wordstat for a project that also targets Google, or only from Semrush for a Yandex project. Each engine sees demand its own way, and one half of the core comes out empty.

Collecting from a single broad seed produces a forty-thousand-row export for "windows" of which a tenth is useful. Ten narrow seeds give a cleaner result in less time.

Deleting everything with low volume also deletes the long commercial queries that convert best.

Volume without operators misleads too: the figure for "repair" without quotes says nothing about how many people search for "laptop repair in Kazan".

The last mistake is about the order of work: building a core for a site that is poorly indexed. New sections built around the demand you found will not help if half the existing pages are missing from search. Before planning structure, check how the site is indexed in Yandex and Google.

FAQ

How many queries should a semantic core contain?

As many as the site can actually serve. A service business in one city may need a few hundred, a large shop tens of thousands. A row count borrowed from someone else's project says nothing about yours.

Can you build a semantic core for free?

A small one, yes: Wordstat, search suggestions, Search Console and Yandex Webmaster cost nothing. Paid tools earn their keep when you need to see competitors' queries or collect thousands of rows without manual lookups.

Do Yandex and Google need separate cores?

One core can serve both, but keep the volumes and priorities separate. The queries mostly overlap, while their weight in the two engines can differ several times over.

How is building a core different from clustering?

Building the core decides which queries the site needs. Clustering decides how to spread them across pages. The first works from volume and meaning, the second from search results.

Can a language model do the collection?

A language model is good at suggesting seeds and at labelling intent across a long list. It does not know search volumes and can invent a plausible-looking number, so figures come only from Wordstat, tool databases and the webmaster consoles.