Build a topic cluster when it helps readers move from a broad question to distinct, useful answers. Give the overview page links to focused supporting pages, make those links crawlable, and measure the pages as a portfolio. For example, an email deliverability overview might link to separate guides on diagnosing bounces and cleaning an email list when each guide serves a different reader task.
A topic cluster is an editorial and navigation model, not a special page type or ranking formula. Google documents crawlable internal links and eligibility requirements for its AI features, but it does not identify topic clusters as a preferred ranking system or promise better rankings or citations. Outcomes depend on content usefulness, intent fit, technical access, competition, and implementation. See Google’s guidance on AI features and its guidance on crawlable links.
This guide focuses on the operating system behind a cluster: deciding whether a new URL is justified, recording page ownership and relationships, validating links before publication, and separating page metrics from sampled AI-answer observations.
What a topic cluster is, and what it does not guarantee
A topic cluster connects a broad overview page, often called a pillar, with focused pages that answer related but distinct needs. The pillar introduces the subject and its main subtopics. Supporting pages provide the depth, evidence, instructions, or decisions that would make the overview unwieldy. Supporting pages usually link back to the pillar, and relevant pages may link to one another.
The distinction from a flat blog archive is the deliberate relationship among pages, not a required page count. A cluster should help a reader understand where to start and where to go next. HubSpot’s pillar-page explanation describes this broad-to-specific structure as vendor guidance, not a search-engine standard.
Create a separate page to serve a distinct reader task, not merely to target another keyword variation.
Use this opening decision before planning a URL: if the broad page can answer a proposed subtopic adequately without burying the answer, keep the explanation on the pillar. If the subtopic has a distinct user problem, search intent, evidence requirement, or next action, assess it as a supporting page.
Decide which topics deserve separate pages
Start with audience problems and the expertise your organization can credibly contribute. Use query research and search-result review to understand demand and intent, but do not let keyword variations dictate the page plan. A different phrase does not necessarily mean a different page.
Inventory existing URLs before commissioning content. For each candidate, record the problem it will solve, the result type a searcher appears to need, the evidence or expertise required, the intended next action, and the existing URL that already serves substantially the same intent, if one exists.
Approve a new URL only when it has a distinct job and a defensible gap in current coverage. Keep a short definition or close variant on the pillar when it can answer the need clearly there. If two existing pages serve substantially the same intent, improve or merge them rather than adding another competitor. A different conversion role can matter, but it should not be used to disguise duplicate informational intent.
A small content inventory can serve as the system of record. These are proposed editorial fields, not a Google or HubSpot schema:
cluster_id: email-deliverability
pillar_url: https://example.com/email-deliverability/
page_url: https://example.com/fix-email-bounces/
page_role: supporting
primary_intent: troubleshoot email bounces
target_query_group: bounce rate troubleshooting
distinct_user_problem: diagnose and reduce delivery failures
supporting_evidence_required: bounce causes and remediation steps
canonical_url: https://example.com/fix-email-bounces/
content_owner: deliverability editor
conversion_role: product evaluation
last_reviewed_at: 2026-10-14Add fields for inbound and outbound cluster links, search-intent status, provenance notes, and an existing URL that already serves the intent. Suggested sizes, including HubSpot’s 20 to 30 post planning heuristic, are not universal standards. Let distinct reader needs determine the scope.
Map the pillar, supporting pages, and internal links
Write the pillar to stand on its own as an overview. Define the topic early, explain the major subtopics at overview depth, and link to a detailed page where a reader would naturally want more. A supporting page should link back to the canonical pillar URL with clear, contextual anchor text. Link supporting pages to one another only when the next page genuinely helps the reader.
For a crawlable internal link, use a standard HTML anchor with an href attribute. Check the rendered page, not only the editor’s link list. The destination should be live and canonical, and important pages should have at least one internal link pointing to them. Google recommends descriptive anchor text and internal links for discovery. It does not prescribe a fixed link count or promise an authority-transfer result.
- The pillar links to the supporting page where its subtopic is introduced.
- The supporting page links to the expected canonical pillar URL.
- Rendered HTML contains an anchor with an
href, and the destination returns the expected status and content. - Anchor wording explains the destination in context rather than repeating an exact-match phrase mechanically.
- Any cross-link helps with a related reader task; omit irrelevant or forced reciprocal links.
Do not treat a redirect, blocked destination, or noncanonical URL as a successful relationship without a deliberate technical reason. If the intended relationship cannot be confirmed in rendered mobile HTML, send it back to content operations or the site owner before publication.
Publish with a repeatable editorial workflow
Use the inventory to connect planning, publishing, technical checks, and reporting. A strategist owns the topic decision, an editor approves intent and evidence, a named content owner maintains each page, and a content-operations or site owner resolves crawlability and canonical issues.
Three practical implementation patterns
The following patterns are proposed operating designs. They are not documented Google, HubSpot, or ConsultEvo modules, and they should be implemented only with the systems your team has actually approved.
1. Intent-map assistant with editorial approval
- Trigger: A strategist starts a cluster or audits a supplied set of URLs.
- AI job: Group candidate URLs by likely user problem, suggest possible overlap, and list missing evidence questions.
- Validation: The editor compares the suggestions with the actual pages, search results, business expertise, and the supplied inventory. Every returned URL must exist in that inventory.
- Action: Write the approved cluster ID, page role, owner, decision, and review date to the content inventory.
- Fallback: Reject malformed output, unsupported claims, uncertain intent, or an unlisted URL. The managing editor or content strategist decides whether to keep the content on the pillar, create a page candidate, or review a merge.
2. Deterministic internal-link launch gate
- Trigger: A pillar or supporting page enters pre-publication review.
- AI job: None is required for URL, status, canonical, or markup checks. A human may assess whether a link is contextually useful.
- Validation: Inspect rendered HTML for an anchor with an
href; verify destination status and canonical URL; check the pillar-to-page and page-to-pillar paths; confirm an inbound internal link exists. - Action: Return a pass or fail result to the editorial checklist or content-operations queue.
- Fallback: Block publication for a deprecated, blocked, redirected, noncanonical, or missing destination until the named owner resolves it. The editor decides whether a questionable cross-link belongs in the copy.
3. Sampled AI-answer citation observation
- Trigger: A team reviews a documented prompt set in an AI-answer product using a currently permitted observation method.
- AI job: The answer-generating product returns its response and displayed source links. If another AI tool is used after capture, it may suggest citation-context labels for human review only.
- Validation: Preserve the response capture, prompt reference, engine and product context, timestamp, locale, and collection method. Verify that a linked citation is not merely an unlinked brand mention.
- Action: Store one PromptRun record and separate CitationObservation records for each cited URL occurrence. Create a VisibilitySummary only as an explicit aggregation.
- Fallback: Mark ambiguous citations for measurement-owner review. Do not automate collection until the relevant product terms, access method, permissions, and rate limits have been checked.
Keep deterministic checks out of an AI model’s decision-making. Code or a content-operations rule should test URL status, required fields, canonical mismatch, inbound links, duplicate records, and permission rules. An AI suggestion should not publish links, change a canonical URL, or overwrite measurement data.
Teams considering bounded AI classification can review ConsultEvo’s AI agents service. This is a general AI-systems service, not a documented topic-cluster tool.
Measure the cluster as a portfolio, not a causal experiment
Group URLs by a stable cluster_id, and report the pillar separately from supporting pages. In Search Console, review page-level clicks, impressions, CTR, and position for a defined query set and period. In analytics, review URL-level sessions, engagement, and conversions using the organization’s attribution rules. These measures describe different things, so do not combine them into a single unexplained visibility score.
Record the query-set version and observation dates before comparisons. Log publication, rewrites, internal-link changes, redirects, canonical changes, seasonality, and relevant site-wide releases. A before-and-after chart alone cannot prove that a link change caused a performance change.
Google says AI-feature traffic is included in Search Console’s overall Performance report under the Web search type. Its public documentation does not describe a separate report of individual AI citations. If you monitor AI answers, treat the method as a sample whose prompt set, product context, locale, timestamp, and collection method are documented. A citation in one answer is one observation, not a stable measure of overall visibility.
One PromptRun is one execution of one prompt in one recorded engine and product context. One CitationObservation is one cited URL occurrence in that run. A citation rate is a summary across defined runs, prompts, context, locale, and period. For example, three runs with a citation in two runs produce an illustrative rate of two out of three for that sample, not a universal visibility score.
Use separate records for raw observations and summaries
Give each prompt execution a generated run_id. Identify each citation by the run and its citation occurrence, so repeated URLs or multiple citations in one answer do not collapse into one record. A useful proposed model is:
- PromptRun: run ID, engine, product variant, model variant when exposed, prompt hash, prompt reference, locale, device where relevant, timestamp, and collector version.
- CitationObservation: citation ID, run ID, cited URL, citation order, captured context, whether the target entity was mentioned, and a source-capture reference.
- VisibilitySummary: aggregation period, engine context, locale, prompt-set version, target URL or entity, runs observed, runs with a citation, and the resulting scoped rate.
The row grain determines the key. A CitationObservation must permit multiple citations in one run and repeated runs on the same day. Use a database-enforced unique constraint on the run ID plus citation occurrence identifier, and use a transactional upsert or insert-on-conflict operation when collectors may write concurrently. A read-then-insert check alone can race.
Keep a response capture or source reference so a reviewer can distinguish a linked citation from an unlinked brand mention and resolve ambiguous URLs. Search Console metrics remain page and query observations; they are not citation-level data. Do not attribute aggregate AI citation rates to individual analytics users or conversions.
Audit, update, merge, or retire pages
Set review timing according to topic risk and how often the underlying product, policy, or search intent changes. An evergreen cluster may need a different cadence from a product-led or fast-moving cluster. At review, check outdated claims, changed reader needs, deprecated or redirected destinations, pages without useful inbound links, overlapping URLs, and outdated conversion paths. Google’s crawling troubleshooting guidance can help investigate technical discovery issues.
Record each change with its URL, change type, date, owner, and query-set version. Refresh a page when its task remains useful but its coverage is stale. Merge or redirect when another page now better serves the same need, with the site owner reviewing URL and canonical consequences. Retain a page when it still serves a distinct reader task, even if one reporting period is weak.
Assign every finding to an owner. An AI-generated audit suggestion may identify a possible issue, but it should not change URLs, publish links, or alter canonical signals by itself. Technical changes belong with the site owner, while intent and evidence decisions belong with the editor.
A well-run topic cluster is an editorial system with clear page jobs, discoverable links, accountable owners, and interpretable measurement. The right next step may be a new page, a better overview, a merge, or no change at all. If your team is formalizing recurring content and operations workflows, explore ConsultEvo’s services overview for broader process support.