Build a Topic Cluster from Customer Questions and Search Data

A topic cluster is easy to draw and expensive to maintain. An AI assistant can generate fifty related article ideas in seconds, but those ideas may repeat existing pages, target people you do not serve, or require expertise your team cannot provide.

The useful output is smaller: a set of distinct reader tasks, a page responsible for each task, and links that help someone move to their next question. Some tasks will belong in existing pages. Others will justify a new resource. Several should remain outside the plan.

Use Claude or ChatGPT to organize customer evidence and supplied search data, then use RankParse to inspect the pages behind the proposed structure. The objective is a defensible publishing sequence with clear boundaries, not a diagram with the largest number of nodes.

Anchor the cluster in one customer decision

Choose a decision your company understands well enough to help someone make. For a fictional equipment-maintenance platform, that might be “replace a spreadsheet-based maintenance schedule without losing service history.”

The decision naturally contains several tasks: recognizing when the spreadsheet is failing, defining a maintenance schedule, cleaning records, choosing software, and preparing a migration. Those tasks are related, but they do not automatically require five articles.

Write down the audience, trigger, desired outcome, and useful next step with your company. Add scope exclusions. A maintenance platform serving small workshops might exclude complex aviation compliance or enterprise asset-accounting advice because the team cannot responsibly support those needs.

This boundary helps the assistant reject attractive but irrelevant topics. A cluster should reflect a coherent area of usefulness. It does not guarantee rankings or confer a measurable “topical authority” score merely because the pages link to one another.

Build an evidence packet with separate source types

Collect a manageable set of questions before asking the model to group them. Use redacted support tickets, sales notes, onboarding questions, and internal site-search terms where available. Keep source IDs and dates so the team can examine surprising interpretations.

Add your existing page inventory and search evidence:

Do not join a sitewide query export to individual pages simply because their wording resembles a title. Use page-filtered query exports or a dataset containing the dimensions needed for the relationship. Finding content opportunities in Search Console explains how to preserve that scope.

Keep frequency claims tied to their source. Three support tickets demonstrate three recorded questions, not the share of all customers who experience the problem. Search Console impressions measure your site's observed visibility, not the market's total search volume.

For a new site with little search data, customer questions and manual research can still support an editorial plan. Mark the demand hypothesis as unmeasured and choose a small initial publication set. Do not ask the assistant to manufacture monthly search volumes to make the spreadsheet look complete.

Stage 1: group questions by task, not shared nouns

Give the assistant the evidence packet and ask it to preserve ambiguity.

Group these customer questions and supplied query rows by the task the
reader wants to complete. Cite source IDs for every group. Keep business
context, search evidence and inferred intent separate. Do not invent
query-to-page relationships or search volume.

For each group, state the audience, trigger, desired outcome and closest
existing page. Flag questions that could mean different tasks. Suggest
merge, expand existing page, create distinct resource, investigate, or
exclude. Do not produce article titles until these boundaries are reviewed.

Shared language is insufficient evidence of a shared page purpose. “Maintenance schedule template” asks for a usable artifact. “Maintenance scheduling software” may ask for a buying decision. Both concern schedules, but a template download and a software comparison could serve different stages of the journey.

The opposite mistake is splitting synonyms into separate pages. “Preventive maintenance checklist” and “scheduled maintenance checklist” may refer to the same task for your audience. Inspect the source context and manually review relevant search results before deciding.

Use mixed search results as a reason to investigate. If the observed results include templates, videos, and service pages, there may be multiple interpretations. Narrow the intended audience or explain which interpretation the proposed page will serve. Do not force every result type into one oversized guide.

Stage 2: use RankParse to inspect existing coverage

Connect RankParse in Claude or ChatGPT and provide the exact existing and candidate reference URLs. The OAuth web connector supplies read-only public checks. It does not directly retrieve Search Console, enumerate ranking keywords, or return a keyword search-results database. Your uploads and browser notes supply those inputs.

For each existing page that might own a task, use get_page_seo. Keep status_code, final_url, title.text, canonical.url, robots.raw, headings.h1, and headings.h2. These fields help establish whether the proposed owner is the expected public page and how its fetched structure presents the task.

For the existing URLs nominated as task owners, run get_page_seo and
record the requested fields with collection time. Compare their stated
purpose with the uploaded copy and task groups. Flag unexpected final
URLs, response errors and canonical discrepancies for review.

Use the supplied copy or browser reading to judge actual coverage.
The first ten H2s are not the whole page. Do not interpret link counts
as an internal-link map or robots meta as proof of indexing. Return a
coverage matrix with evidence, uncertainty and proposed page ownership.

The page SEO documentation explains that checks parse raw HTML. The assistant cannot infer an absent answer from a missing heading alone, especially on a JavaScript-heavy page. If the check sees an access screen or incomplete content, read the page in a browser or supply a captured excerpt.

Use get_sitemap only as an additional inventory source when useful. It accepts a bare domain and an optional limit; retain truncated and the fetched child-sitemap information. A bounded sitemap result cannot prove that an unlisted page does not exist, and it says nothing about the full internal-link structure.

If the CMS inventory is already reliable, skip the extra discovery step. The purpose of the tool call is to resolve an uncertainty, not to decorate every proposed article with more data.

Add selective link evidence when the format is uncertain

Sometimes the unresolved question is what kind of resource would make a useful contribution. A checklist, annotated example, or calculator may help the reader more than another explanation.

For one or two relevant reference domains, RankParse's get_top_pages can identify pages with inbound links. Use a small explicit limit, and retain url, inbound_links, referring_domains, and any partial status. Open promising resources manually before describing why people might use them.

The top-pages response reflects a periodic link-graph snapshot. It is not a traffic ranking, a complete content inventory, or a report of current search positions. total counts returned rows. A resource appearing in the sample is a reason to inspect its usefulness, not evidence that copying its format will attract links.

If no relevant resource appears, keep the customer-led proposal. Missing link evidence does not erase an observed customer need. Record the snapshot limitations and move on rather than expanding competitor research indefinitely.

For a deeper competitive investigation, follow the competitor analysis workflow. Cluster planning needs only enough external evidence to challenge the proposed format and boundaries.

Decide whether a task deserves its own page

Use a page only when it can make and fulfill a distinct promise. A separate URL needs more justification than a related phrase in a query list.

A standalone resource is plausible when the reader needs a different artifact, prerequisite, or decision. A record-cleanup worksheet may deserve its own page because the user can complete and reuse it independently. A short definition needed to understand that worksheet may belong inside the resource.

For an existing page, ask whether the missing answer fits its current promise. Adding a duplicate-record example to a data-cleanup guide can improve the same task. Adding a long vendor comparison may disrupt it and create a second purpose.

Give each proposed page explicit exclusions. “Explains how to prepare import data; does not compare vendors or prescribe accounting policy” tells a writer what to leave out. This is more useful than a list of twenty keywords the page must mention.

Also require an owner and evidence contribution. If nobody can review the method or maintain the downloadable file, defer the resource. Publishing capacity is a real constraint, not a detail to address after the cluster has been approved.

Worked example: turn six questions into three actions

This is an illustrative example for a fictional maintenance software company. The source rows, observations, and decisions are invented to show the method, not measured RankParse results.

The company has a general maintenance-planning guide and a software product page. Its packet contains six questions across customer notes and a supplied Search Console export: choosing service intervals, assigning owners, finding a schedule template, cleaning duplicate asset IDs, preserving service history, and evaluating replacement software.

The result is not six new articles. It is one existing-page improvement, one distinct new resource, and one existing commercial destination that needs a clearer connection from the learning material.

Here is the actual planning artifact for the illustrative cluster:

The deferred landing page can be reconsidered later. The team has not declared that templates never deserve separate URLs; it has chosen the smallest useful structure supported by its current evidence and capacity.

Stage 3: produce briefs and a publishing sequence

Once a human has reviewed the ownership matrix, ask the assistant to write the execution plan.

Turn the approved page ownership matrix into briefs. Each brief must
state audience, reader outcome, existing or proposed URL, source IDs,
original contribution, included questions, explicit exclusions, owner
and acceptance check. Do not add unsupported topics to fill a calendar.

Order the work by reader dependencies and available evidence. Propose
contextual links with a source paragraph or planned section, destination,
anchor and reader reason. Label proposed links separately from links
observed in the supplied crawl. Include deferred decisions and the
specific evidence that would reopen them.

Publish in the order that creates usable journeys. An existing guide improvement may be ready before a new worksheet because the source material is already available. A promised destination should exist and fulfill its promise before an editor adds a prominent link to it.

Do not make every page link to every other page. A reader choosing service intervals may need the schedule template immediately; a migration worksheet becomes relevant when they are preparing existing records. Use that transition to explain the link.

For verified existing connections, supply a crawl export or inspect the source pages manually. RankParse's page checks return internal and external counts, not destination lists. The internal-linking workflow turns approved relationships into precise edits and verification steps.

Keep the cluster useful after publication

Maintain a simple register with page purpose, owner, dependencies, last substantive review, and unresolved questions. This prevents future writers from creating another article that quietly claims the same task.

After publication, use RankParse to check the final public URLs and their intended title and canonical declarations. Open the resources and follow the planned links in a browser. Confirm that a download works and that an example still matches the explanation; metadata alone cannot verify either.

Review new Search Console and analytics exports after an appropriate observation period for your site. Ask whether the pages attract relevant questions, whether readers use the resources where measurement exists, and whether customer-facing teams find the material useful. Do not assume that a cluster caused every traffic change after publication.

When several pages appear for similar queries, inspect their reader tasks before treating that as a defect. Multiple appearances do not automatically prove harmful overlap. Consolidation should follow evidence about redundant purpose, poor routing, or competing ownership, with technical consequences reviewed separately.

Start with one decision, a small evidence packet, and a page ownership matrix. Approve only the work your team can substantiate and maintain. That gives the next writer a clear assignment and gives the reader a clear route through the questions that matter.