Deduplicating Joins Across Citation, Referral, and CRM Data
Website owners comparing citation reports with referrals and customer relationship management (CRM) outcomes need to keep the three record types separate. A…
In search engine optimization (SEO), a keyword is a word or search query entered into Google or another search engine. It may be a single word, such as “insurance,” or a longer query, such as “how much renters insurance do I need.” Keyword research examines the language people use and the need behind it.
It helps decide whether to create a page, improve an existing page, combine overlapping pages, or leave a topic alone. The goal is to find page opportunities that serve a real search need.
Do not create a separate URL for every wording variation. Several queries may describe the same need and belong on one page. Similar-looking queries may signal different needs and require different answers. Create a separate page when searchers need a distinct answer and the site can provide it well.
Keyword research moves from audience language and search data to search intent - the goal behind a search - then to opportunity evaluation, query grouping, and URL planning. Those decisions determine what the site should answer, where each answer belongs, and which topics do not merit a page.
Google’s people-first content guidance asks whether content serves an intended audience and adds value. It gives no keyword formula and makes no promise that a page will rank.
Start with the people the site serves, the problem they need to solve, what the site offers, and the next step that would help them. That focus keeps research tied to people the site can actually help.
Collect the exact words people use in customer questions, sales and support conversations, interviews, reviews, internal site searches, and relevant community discussions. Keep the original wording. Record the source, context, and task the person was trying to complete.
In interviews and conversations, ask:
A small or self-selected group supplies candidate phrases; it does not show how common a need is. Keep observed phrases separate from autocomplete and keyword-tool suggestions, and keep both separate from your own hypotheses.
Record questions submitted to AI tools as qualitative evidence of topics and wording, along with their source and context. Keyword-volume estimates measure search activity according to a tool’s source and settings. They do not measure prompts sent to AI products.
For an established site, review Google Search Console queries, clicks, impressions, and landing pages. These metrics describe reported performance in Google Search, not every search or every visitor.
Look for queries already generating impressions or clicks. Check which landing pages receive those visits, then review queries whose landing page appears not to meet the searcher’s need. Google omits some queries for privacy and applies reporting limits, so an absent query does not prove that nobody searched for it. The Search Console Performance report documentation defines the metrics and reporting limits.
Internal site-search logs show the terms visitors use after reaching the site. They can reveal missing content and weak navigation, but they represent current visitors rather than people who never found the site.
Autocomplete, related searches, and keyword tools add candidate wording. Keep a suggestion only when it fits the audience, problem, and offer. Review competitor pages to see what appears in search and how those pages address the topic. Their wording does not show why they rank and does not provide a template to copy.
Use one research sheet for every phrase. Record the phrase, source, date, relevant context or tool settings, and whether it fits the audience and offer. Label each entry as an observed phrase, a tool-generated suggestion, or an editor’s hypothesis.
Those labels preserve the evidence behind each candidate phrase and make later decisions about intent and page content easier to review.
A useful keyword fits the audience the site serves and the page it can deliver. Before comparing search volume or competition, state what the searcher likely needs and decide whether the proposed page meets that need.
Four labels describe common search goals:
These are working labels, not fixed categories. One query can suggest more than one need.
Write the likely need in plain language: “Canonical tag definition” calls for an explanation, while “SEO agency comparison” calls for evidence that helps someone compare providers. Query wording offers clues, and the live results page tests them.
Separate audience relevance from business relevance. A high-volume query is a poor target if the site cannot give visitors a useful, credible answer.
Inspect Google’s live results for the target country, language, device, and date. Record those details with the query because results vary by context and over time. Compare several results. Note whether Google shows guides, product or category pages, local listings, videos, forums, or other formats.
Record ads and search features above or within the organic listings. Ranking position alone does not show how much organic content is visible or how far down the page a result appears. Google’s Search Console Performance report reports impressions and clicks separately because an appearance in search results does not ensure a visit.
Treat the results page as dated evidence of what Google serves for that query in that context. It does not establish what every searcher wants. When results support competing interpretations, record each one. Leave the query unassigned if one page cannot answer them well.
Assess the pages competing for visible organic positions: their relevance, coverage, format, apparent authority, and usefulness to the searcher. The number of indexed results does not measure the strength or relevance of competing pages.
Keep paid-ad data separate from organic competition. Google Ads’ competition metric describes advertiser bidding activity for a keyword; it does not establish organic ranking difficulty. Third-party keyword-difficulty scores also reflect a provider’s database, method, location settings, and scale. Use them to prompt a closer review of live results, not as an automatic publishing or link-building decision.
Group queries only when they express the same need and the results favor a similar page. Map each group to one existing or proposed URL. Keep queries separate when they require different answers or formats.
Treat search-volume figures as tool-based estimates tied to location and date. Check demand across periods with Google Trends, and record the settings used. Preserve each query’s likely need, audience and business fit, result-page notes, volume estimate, and proposed URL.
Questions from sales conversations, customer support, and AI tools reveal language keyword tools miss. Label them as qualitative evidence. Google search-volume estimates do not measure how often people ask AI systems those questions.
Search volume estimates how frequently people searched a query in a provider’s selected market, period, and settings. It does not count guaranteed visitors or predict traffic to a specific page. Keyword providers use different databases and methods. They may group close variants, round figures, or report ranges instead of exact counts.
Record the tool, collection date, country, language, search network, and time period with each estimate. Without that context, the number has limited meaning.
Treat small differences as weak evidence. An estimate of 1,000 monthly searches does not establish more demand than an estimate of 900 when the provider does not support that level of precision.
When one page will answer several closely related phrasings, assess demand for the query group. Do not add every estimate as though each one represents separate people or searches. Provider data for close variants can overlap and inflate a simple total.
Google Trends shows relative interest over time and across places. It normalizes values for the selected region and date range: 100 marks the query’s peak popularity in that comparison, while lower values show proportionally lower interest. They are not absolute search counts.
When comparing charts, record the geography, date range, category, and search type. Google’s explanation of Trends data describes how it scales results.
Use several years of data when the topic has a long enough history and the tool provides it. Choose a region that matches the intended audience. A rise that returns at roughly the same time each year supports seasonal planning. A short spike may reflect a news event, product launch, or change in terminology.
Compare trend charts with the site’s Google Search Console history. Search Console reports impressions and clicks for the site in Google Search, while Trends reports relative interest across Google searches. Similar patterns support a timing decision; they do not guarantee future traffic.
A fixed volume cutoff misses narrow queries with clear relevance. A low-volume query may reach a valuable audience, answer a specific need, or strengthen a useful page that serves several related searches.
The decision depends on audience fit, the value of the need, available evidence, and the work required to create and maintain the page.
Group queries when they express the same reader need and call for a compatible answer. Similar wording alone is weak evidence. Two searches can share a topic term yet reflect different decisions, audiences, or preferred page formats.
Treat a cluster as an editorial judgment. Test it against the search results and the proposed page’s purpose; do not assume it mirrors Google’s internal query categories.
Someone seeking a definition needs a different answer from someone comparing options or preparing to buy. Keep those searches separate when one page would serve neither need well. Several phrasings that seek the same answer belong on one useful page.
Check existing pages before proposing a new URL. Improve a relevant page when it already serves the need, and combine overlapping pages with the same purpose. Create a separate page when the group needs a distinct answer and the site can provide one. Do not create near-duplicate pages for minor wording changes.
For a related approach to mapping customer questions without creating a page for every variation, see How to Map Customer Questions Without Creating a Page for Every Query Variation.
For each group, record the reader need and supporting queries. Include the evidence for the grouping and the proposed primary URL. Then decide what to do with the group: keep or improve the current page, combine it with another page, create a distinct page, or leave it unassigned.
Before splitting a group, confirm that the searches need different answers, produce meaningfully different result patterns, and justify pages with distinct value. For a new page, define the main answer, needed evidence, the reader’s next useful step, and relevant internal links before drafting.
A single page can answer many query variations, but broad groups have limits. A comparison query and a step-by-step query may need separate pages. When evidence remains incomplete, leave the group unassigned and gather better data rather than treating missing URL matches as proof of different intent.
Keep the original export beside the analysis. The sheet should let another researcher see what the data recorded, what you estimated, and why you assigned a query to a page.
On a raw-data tab, record the exact query, source type, and tool. Add the collection date, country, and language, then include the device, time range, and request settings. Preserve the original wording and exported values. For search results, retain the raw URL and domain. Also record the title, breadcrumb, rank, and result type.
Use a separate analysis tab for the normalized query, customer wording, likely need, intent hypothesis, relevance, result-page formats, estimated volume or range, seasonality, and difficulty score with its provider. Record the proposed cluster, assigned URL, current page status, evidence notes, confidence, next action, and reason for keeping or rejecting the candidate.
Mark claims as observed, estimated, inferred, or unknown. Do not overwrite raw data, silently merge query variants, remove outliers without a record, or convert missing values to zero. Save a dated result-page snapshot or enough query details to repeat the search. A result page records one search context at one point in time.
A URL field must identify the destination page before it supports a comparison of ranking pages.
On November 11, 2026, eight US English Google organic queries were collected through DataForSEO Live Advanced at a request depth of 10. The API returned 65 organic items at a cost of $0.016.
| Query | Organic rows | Google redirect wrappers |
|---|---|---|
| keyword research | 10 | 10 |
| how to find keywords for seo | 7 | 7 |
| canonical tag | 8 | 7 |
| canonical url seo | 8 | 8 |
| local seo | 8 | 8 |
| ecommerce seo | 9 | 9 |
| title tags | 7 | 7 |
| meta descriptions | 8 | 7 |
Of the 65 result URLs, 63 were opaque google.com/goto wrappers, and two were direct destination URLs. A planned comparison covered four query pairs. Comparing the exported URL strings produced zero overlap for every pair, but the unresolved redirects did not identify destination pages.
Destination overlap was unavailable. Those zero-overlap results provide no evidence about search intent or query clustering.
One canonical tag row listed google.com as its raw domain, while its title named Moz and its breadcrumb began with moz.com. This raised an attribution concern but did not establish the full destination URL. No destination was guessed, decoded, or followed.
The sample contains one snapshot per query. It does not show how common wrapper URLs are across Google or DataForSEO, whether a provider-wide outage occurred, whether rankings changed, or any SEO or AI-search outcome. Retain the raw rows and request resolved destination URLs, or use the provider’s documented matching method, before making destination-dependent comparisons.
Keep one row per query and retain cleaned values beside the raw export. Keep missing values blank or mark them unknown. Treat volume and difficulty scores as estimates from named providers, not precise measures of opportunity.
When a key input is missing, record the uncertainty and the next check rather than forcing a cluster or URL decision.
Should a low-volume query be rejected?
No. Keep it when it closely matches the audience’s need and one useful page can address it. Low or missing volume estimates indicate uncertainty; they do not prove that nobody searches for the query.
When should you check the results again?
Record the date and search settings each time. Recheck before making a page decision based on result-page formats or competing URLs, because each snapshot reflects a specific search context and date.
Prioritize a query group only after confirming that it reflects a real audience need and that the site can answer that need well. Set aside candidates that do not fit the audience or offer, make a misleading promise, or lack a useful page to create or improve. A high-volume estimate does not overcome those limits.
For the remaining groups, weigh customer language, Search Console data, likely intent, the current results page, and fit with the site’s offer. Then compare the available actions.
Improve an existing page when it already addresses the need but leaves a clear gap. Create a new page for a distinct need when it has enough substance to answer that need well. Leave the group unassigned while you investigate when the evidence does not support a choice.
Use volume estimates, seasonal trends, and third-party difficulty scores as context. Small differences in estimated volume do not support exact rankings. A vendor’s difficulty score is not a Google metric and does not predict the effort required to rank. Review the search results themselves. Check whether leading pages address the same need and whether a proposed page would give searchers a useful alternative.
Record a plain-language decision and its reason for each group:
Revisit decisions when the audience, offer, search results, or available evidence changes. A priority records a judgment made from dated evidence and needs review when that evidence no longer reflects current conditions.
Keyword research helps choose and shape content, but it cannot reveal every search need, predict exact traffic, or determine whether a page will rank.
Google Search Console reports how a specific site appeared and performed in Google Search. Keyword tools estimate demand from their own data sources, selected markets, and settings. Treat each number as evidence with stated limits, not as a complete count of interest in a topic.
Search results do not prove why a page ranks. A competitor’s position does not reveal which signals Google used to rank it. An indexed-result count does not measure the quality or competitive strength of pages targeting a query. A vendor’s difficulty score reflects that vendor’s method; it is not a Google metric and does not guarantee ranking difficulty. A single search results page shows what appeared for one query, location, device, and date.
URL comparisons have the same limits. Unresolved Google redirect URLs do not identify final destinations. Zero literal matches between raw URL strings establish only that the strings differ; they do not establish different search intent.
Keyword research remains useful within those limits. Customer language points to questions people use to describe their needs. Search Console shows which queries already generate impressions or clicks for a site. Current results help test whether a proposed page addresses the need suggested by the query.
Keep direct observations, tool estimates, and inferences separate. When evidence remains incomplete, investigate further or leave the decision open.
Google’s people-first content guidance asks creators to assess whether content serves its intended audience and provides useful, trustworthy information. These are qualitative criteria for evaluating a page. They do not provide a numerical test of keyword quality or explain how keyword tools calculate search volume and difficulty.
Use keyword data to assess demand and competition signals. Use people-first guidance to assess whether planned content deserves to meet the reader’s need. Neither proves that a page will rank.
How many keywords should one page target?
There is no fixed number. One page can serve a coherent group of related queries when searchers share the same need, expect the same type of answer, and see similar results in search.
Create separate pages when the queries need distinct answers and each page would give readers different useful information. Pages that repeat the same answer with only minor wording changes rarely add value.
How often should keyword research be updated?
Review keyword research when the offer, audience, search results, or page performance changes. For seasonal or time-sensitive topics, schedule the review before the relevant period.
Update content when its facts, examples, or the intent it serves have changed. Do not change a publication or update date just to make unchanged content look current. Google advises against that practice in its people-first content guidance.
Should a page target a low-volume query?
Yes, when the query reflects a real audience need and the page can answer it well. A low search-volume estimate does not prove that demand is absent, especially for specific queries with limited data.
Check whether an existing page already answers the need. Create a separate page only when it gives readers a clearer or more complete answer and the expected value justifies the work to create and maintain it.
Can Google search volume show how often people ask AI tools the same question?
No. Google keyword-volume estimates describe search activity within selected settings, such as location, language, and date range. They do not count prompts submitted to AI tools.
Google’s Keyword Planner metrics reflect Google Search and search-partner data rather than activity across AI services. Questions observed in AI interactions still offer useful qualitative evidence. They reveal wording, confusion, and needs worth investigating.
Group several queries on one page when they share the same need and call for a similar answer. Use separate pages when readers need distinct answers or result pages favor different formats.
Check audience fit and the quality of the answer you can provide before comparing volume estimates. A relevant, specific query can justify work even when its estimated volume is low.
It gives one provider’s estimate of competition, based on that provider’s data and method. Check the provider’s methodology, location settings, and collection date, then inspect the actual search results.
No. Search-volume estimates describe search activity as defined by the data source and its settings. They do not count prompts sent to AI tools.
Review it when your audience, offer, page performance, or search results change. For seasonal topics, plan reviews around patterns seen across multiple years where available.
Confirm that exported URLs identify actual destination pages before treating overlap as evidence about intent. Opaque redirect wrappers prevent destination-level comparison.
Record the competing interpretations and assess whether one page can answer them well. If the results suggest different needs or page types, leave the query unassigned until you have stronger evidence.
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