Imagine an operations director asking an AI search tool: “Which knowledge-base system should we use for a 150-person support team with Salesforce, Slack and strict access controls?” A traditional keyword report might surface knowledge base software, best knowledge base tools and knowledge base integrations. The buyer’s question connects all three, then adds security, implementation and team size.
That’s where I would start rethinking keyword research for B2B SaaS. I still want search demand, rankings and commercial intent. I also want to understand the complete decision a buyer is asking an AI assistant to help make, including the follow-up questions that would have appeared as separate searches.
Google explains that AI Mode and AI Overviews can use query fan-out, generating multiple related searches across subtopics and sources. That changes the research exercise. A single buyer question can touch a product category, integrations, pricing, implementation and third-party evidence in one session.
What stays in a useful keyword research process
I would still review relevant keywords, actual search result pages, Google Search Console, competing pages, query intent and conversion paths. Google says its AI search features use the existing Search index, and indexed pages remain the starting point for eligibility to appear as supporting links. Technical accessibility, useful content and internal links still matter. Those requirements are described in Google’s AI features documentation.
Keyword tools can reveal language that buyers use repeatedly. Search Console shows which queries already bring impressions and clicks to a site. Reviewing results helps identify the formats that currently serve the query. The problem comes when the final content plan becomes a list of keyword variations with separate articles for each.
Move from a keyword list to a buyer-task map
Start with a commercial question from a real prospect or a plausible product evaluation. Break it into the questions someone would need answered to make a decision. Then map those questions to the most useful existing page or a genuinely new piece.
| Buyer task | Questions to research | Potential content asset |
|---|---|---|
| Understand the category | What does a knowledge base do? How is it different from a company wiki? | Clear product overview or category guide |
| Establish product fit | Does it support separate teams, restricted pages and agent access? | Use-case explanation with permissions documentation |
| Compare vendors | Which tools provide the required features on the relevant plan? | Product comparison using a common test or evidence framework |
| Plan implementation | How does the Salesforce integration work? What data must migrate? | Implementation and integration guides |
| Get internal approval | What will it cost? What does security need to review? | Pricing explanation, security documentation and customer evidence |
Notice that the same buyer task may require several linked pages. The point of research is to identify which pages already answer the questions and where the real gaps remain.
Research conversational questions without pretending to know prompt volumes
AI tools often accept long, context-rich questions. That doesn’t mean a marketer has access to reliable monthly search volumes for every possible conversation. I would collect question patterns from sources close to the buyer: sales calls, support requests, customer interviews, implementation tickets, website searches and existing Google queries.
For each task, record the exact language, who raised it and where they were in the decision. A question about data residency from an enterprise security reviewer has a different purpose from one about quick setup raised by a startup founder.
Use AI answers to investigate coverage gaps
Once you have the questions, test them in the AI interfaces relevant to your audience. Save the prompt, location, date, cited URLs and the explanation the assistant gave. Review where it found information, which details it omitted and whether a vendor’s documentation actually supports the answer.
You can ask an AI tool for likely follow-up questions, but treat its suggestions as research leads. They become useful after checking them against the product, customers and search results.
How query fan-out changes the way I organize topics
Suppose the initial buyer question concerns a knowledge base with restricted agent access. Related searches could investigate permission models, integrations, retrieval architecture and comparable tools. Google’s documentation confirms that its systems may issue related searches, although the exact queries and supporting links vary by question and search experience.
I would group the questions by the information a buyer needs rather than creating a new page for every suggested phrase. A permissions page might answer access, role and sharing questions together. A separate integration tutorial may deserve its own URL because it walks through a distinct technical process.
Keep one page responsible for each core decision
If the site has five slightly different articles ranking knowledge-base products for remote teams, their intent may overlap. Consolidate the useful evidence where appropriate. If one article answers how a permission setting works, keep that implementation page separate and link to it from the main comparison.
In my refresh-versus-new-content framework, I use intent and existing page equity to make that choice. It is especially important when an AI research journey touches several closely related topics.
Build a keyword brief around evidence, not just headings
Here is an illustrative brief for a page targeting the decision “Which internal knowledge-base product suits a regulated support team?”
| Brief field | What to collect |
|---|---|
| Reader | Support operations leader assessing a knowledge base alongside an IT or security reviewer |
| Decision | Which product supports required access controls, search, integrations and rollout needs? |
| Queries | Category keywords, comparison terms, access-control questions, integration queries and implementation searches |
| Primary evidence | Current vendor documentation, tested permissions where access permits, plan restrictions, actual setup steps |
| Buyer questions | Can contractors access selected articles? How does revocation work? Which integrations preserve access restrictions? |
| Internal links | Product overview, permissions documentation, integration guide, security page and comparison |
| Outcome | Help the evaluation group identify which claims need testing before it selects a vendor |
The brief gives a writer specific questions and a source-gathering plan. It also makes it clear when an expert or product account is needed to finish the research.
What changes when the search results include an AI answer?
Inspect the result for the important queries. Is an AI Overview present? Which third-party pages are cited? Does the answer name particular vendors? Which product claims appear, and which are absent? Compare those observations with the site’s own search performance.
There are at least three outcomes to record separately:
- Organic visibility: search impressions, clicks and the query group reported in Search Console.
- AI visibility: whether the brand was named and whether a specific URL appeared as a cited source in a sampled answer.
- Commercial value: whether the content helps the prospect evaluate a product, sign up, request a demo or make progress in sales.
An assistant may cite a vendor page to explain a general topic without recommending the vendor. It may also recommend a product while citing a different website. I would read the answer before treating either event as a meaningful result.
The AI Search and GEO Statistics resource brings together original 2026 studies of those visibility patterns.
Where the research process becomes more demanding
Broader questions can expose gaps that a keyword-focused article would miss. The page may describe a feature but omit which plan includes it. It may link to an integration without saying whether data is synchronized one way or both ways. A competitor comparison may list five products without testing the same workflow in each.
Before publishing, I would run a product-evidence check:
- Identify the buyer question the section answers.
- Find the relevant feature in current product documentation or a test account.
- Record the plan, permissions, version and limitations affecting the claim.
- Use descriptive links to original documentation and explain the actual workflow.
- Have an appropriate product expert review claims that affect buying or implementation.
Google’s guide to generative AI search optimization emphasizes non-commodity information and existing search fundamentals. It does not require special AI-only markup, unnecessary text files or an entirely separate content system for eligibility.
A lean monthly review
I would maintain a small group of high-intent questions rather than a giant spreadsheet of artificial prompts. Once a month, review new queries in Search Console, relevant questions from prospects, changes to important search results and whether documentation has kept up with the product.
For each question, make one decision: improve an existing page, add a focused new page, connect two existing assets or leave it alone. Track what was changed and why. This keeps keyword research connected to real publishing decisions.
If you need the broader editorial handoff, my B2B SaaS content brief template explains how to record the angle, reader, evidence and verification tasks. And my SEO versus GEO guide covers how the same page can serve search and AI-assisted discovery.
