A client just asked whether they show up in ChatGPT, and you need an answer that works for every account on your roster, not just that one. This guide walks you through eight steps for building topic clusters for clients that AI answers can actually find, quote, and link to. By the end you will have a repeatable delivery loop: buyer prompts in, a connected cluster out, and a report the client can read. The method stays the same across accounts. Only the evidence changes, which is what lets you package agency content clusters as an agency aeo service and sell the same thing twice.
If that feels like a lot, take a breath. You are going to build this once and reuse it forever.
Step 1: Set up an isolated client cluster brief
Your agency seo cluster process starts with a boundary, not a topic.
Create one workspace and one cluster brief for the account. Load only that client's positioning, products, personas, competitors, site inventory, claims to avoid, and business goal. Then write down what this first cluster has to accomplish: lift visibility on a set of buyer questions, support one product, close a competitor coverage gap, or fill a missing funnel stage.
Use the same brief schema for every client. Same field names, different values. Give each cluster a unique ID, and record the client name, core topic, funnel goal, prompt set, page list, publication wave, and reporting date against it.
Here is where the product earns a mention. Keeping accounts separate by hand is where most agencies leak facts from one brand into another's draft. DeepSmith's Multi-Workspace keeps each client's brand, content, and reporting isolated inside one agency account, and Deep IQ holds the product, persona, and voice context that the later steps pull from. That is the isolation layer doing the work, not a folder naming convention.
Done when: a new strategist can open the account and name the client, product, audience, competitors, target outcome, and source rules without asking you which facts belong to which brand.
Common mistake: reusing a master brief with the last client's facts still in it. A reusable template holds empty fields or account-specific values. Never a blended prompt list, a leftover competitor set, or someone else's voice instruction.
Pro tip: make the cluster ID the join key across the brief, the prompt baseline, the page inventory, the link map, the publishing queue, and the report. That one habit is what stops you reporting a page against the wrong client.
Step 2: Map the buyer prompts AI should answer
Now switch from keywords to questions.
Build a prompt matrix across three stages. Awareness covers problem definitions, symptoms, how-to questions, and terminology. Consideration covers alternatives, comparisons, fit, requirements, and evaluation criteria. Decision covers vendor selection, cost questions, proof, migration, and next steps.
For each prompt, record the exact wording, the stage, the topic, the intent, the audience, the product involved, the expected answer type, whether the brand is currently mentioned, whether it is currently cited, which page was cited if any, which competitors were named, and the next content action. Include the uncomfortable ones: prompts where a rival is recommended, prompts where your client is named but never linked, and prompts nobody owns yet.
Then take a baseline before you publish anything. Save the full answer, the engine, and the date. Do not treat one answer as a fixed position. Generative answers move with platform, wording, location, and time.
DeepSmith's AI Visibility area is built for exactly this. You define the buyer questions yourself, or let Discover Prompts generate candidates from the account's product, personas, and buyer stages. It reports mention rate and citation rate separately, keeps the full answer history on a schedule, shows which of the client's pages got cited, and shows the competitor pages winning the same answers.
Done when: every candidate prompt has a stage, a topic, an intent, a baseline answer, and a yes or no on the first cluster. You can say out loud which prompts are unowned, which are mentions without citations, and which a competitor already holds.
Common mistake: calling a mention a citation. A mention names the brand. A citation links to one of its pages as a source. An answer can do one without the other, so report the two rates separately or your client will hear a promise you did not make.
Pro tip: keep the wording close to how a buyer would really ask. Add variants only when the answer intent genuinely changes. A baseline padded with near-duplicate prompts just costs you tracking capacity.
Step 3: Choose the core topic from visibility and coverage gaps
You have evidence now. Let it pick the topic.
Run every candidate through five filters. Business fit: does this support a real product, audience, or commercial goal? Prompt opportunity: is the client absent, mentioned without a citation, or losing prompts that matter? Coverage: is there a gap, thin depth, or a lopsided funnel on the client's own site? Competitive evidence: does a rival own citations here that the client could realistically challenge? Information gain: can this client say something a generic page cannot?
Pick the topic that supports a coherent set of distinct questions, not the one with the biggest volume number. Search volume and difficulty are inputs. They are not the definition of a good cluster. And check the existing site first. A page that already exists may be the right pillar after an update, which beats minting a new URL.
Content Map is where this stops being a hunch. It classifies every page on the client's site onto a granular topic and a funnel stage, maps competitors onto that same taxonomy, and surfaces coverage gaps, untapped topics, and per-topic depth. Sitemaps are rechecked every 24 hours, so new pages fold in without a re-import. Opportunity Agents then turn a gap into ideas that carry the data point that justified them. Use those outputs as prioritization evidence, not as an automatic instruction to publish.
Done when: the decision names one core topic, the buyer and business reason, the weak or missing prompt set, the competitor evidence, the intended funnel coverage, the existing pages you will reuse, and why this cluster goes before the others.
Common mistake: picking the competitor's biggest topic and cloning their page list. A gap is a signal to investigate. It is not proof the topic fits your client's product or buyer.
Pro tip: require a one-sentence information-gain statement before you approve a cluster. "This client can help the buyer decide X because it can provide Y that a generic page cannot." If nobody on the team can finish that sentence, the topic is not ready.
Step 4: Give every cluster page one job
Draw the architecture before you assign a single writer.
You need one pillar and a set of supporting pages. The pillar is the broad, comprehensive overview and the navigation point. Each supporting page answers one narrower, intent-driven question and links back to the pillar. The pillar links out to every relevant supporting page. Supporting pages link sideways only when the reader genuinely needs the adjacent answer.
For every node, write down the page role, its one primary question, its dominant intent, its funnel stage, the entity or problem it covers, what it covers that no other page does, whether an existing URL should be kept, updated, consolidated, or redirected, its parent and child links, and its next-step purpose.
Resist a fixed page count. A cluster is finished when the important distinct intents are covered without redundancy and the relationships are clear. There is no universal pillar word count and no magic number of internal links. Comprehensiveness, intent fit, and navigability matter more than length.
Done when: a reader can move from the broad topic to the specific answer and back, every page has one non-duplicative job, every priority prompt has a destination, and every existing page has an explicit disposition.
Common mistake: creating four pages for four keyword variations that answer the same question. That fragments authority and gives you no defensible reason for the pages to coexist.
Pro tip: ask of every supporting page, "what would a reader still need after finishing the pillar?" The answer defines the page. If the answer is only a synonym, fold it into a page you already have.
Step 5: Turn each page into a citable brief
This is the step that decides whether the cluster reads as expert or interchangeable.
Give each writer a brief that makes the intended answer easy to identify and verify. Require the target prompt and its close relatives, the audience and funnel stage, a one-sentence answer for the top of the page, the page's role and its relationship to the pillar, the required headings and subquestions, the entities and product facts that must be handled accurately, the original detail this client can contribute, any claim needing a source or client confirmation, the internal links in and out with the reason each one helps, the external evidence needed for factual or time-sensitive claims, the metadata, and the acceptance criteria.
A page that is easy to cite answers its main question promptly, uses descriptive headings, defines its terms, separates fact from recommendation, makes claims attributable, and puts the useful detail in text rather than hiding it in an image or an interaction. Lists, tables, and short answer blocks help when they clarify.
One thing to let go of: there is no special markup shortcut. Google says sites do not need new machine-readable files, AI text files, or special schema for AI Overviews and AI Mode. Structured data is a supporting detail, used only when it describes what is visibly on the page.
Done when: a writer can produce the page without guessing its question, audience, role, evidence, links, or success condition, and a reviewer can trace every material claim to an approved fact or a named source.
Common mistake: writing a generic answer and sprinkling the client's name on top at the end. That produces interchangeable pages with no information gain. The client-specific evidence has to shape the answer and the examples from the brief onward.
Pro tip: put the answer, definition, or decision rule at the top of each section, then support it underneath. It helps readers skim and gives an AI system clean text to work with. It does not guarantee a citation, and you should never sell it as one.
Step 6: Produce and publish the cluster in connected waves
Plan production around the architecture, not around whatever is next in the queue.
Prepare the pillar and the first supporting pages as one linked unit. Then release additional pages in waves that close the highest-value prompt or funnel gaps, keeping the link map current as you go. When an existing page already satisfies an intent, update or consolidate it. Do not publish a near-duplicate beside it.
Run every page through the same gate before it goes live. Does it answer its assigned question and differ materially from the other nodes? Are the product facts, comparisons, and dates accurate or clearly qualified? Does it add client-specific information gain? Are the headings, examples, metadata, and links usable by a human? Are the internal and external links there for a reason? Is the live URL crawlable, canonical, indexable, and fine on mobile? Is the client approval or expert fact check done where the claim needs one?
Content Studio carries an approved idea through New Ideas, Planned Content, and Produced Content, with the Writer in between handling research, SEO and AEO structure, internal and external links, a cover image, and publish-ready metadata. Autowrite runs a configured article on its scheduled date with nobody in the app, and Produced Content is where you review, edit, and publish to WordPress, Webflow, Strapi, Sanity, Contentful, or a webhook. That is what lets you scale content for multiple clients without adding a strategist per logo. The judgment gate still belongs to you.
Done when: the wave has a published or scheduled pillar, supporting pages with distinct roles, a complete link plan, a page-level acceptance record, and the list of prompts each page is meant to influence.
Common mistake: treating volume as delivery. Google permits useful applications of generative AI, including research and structure on original content, but warns that generating many pages without added value can cross its scaled-content-abuse line. Every page still needs a purpose, a fact check, and a human gate.
Pro tip: never tell a client a page is "AI optimized" because a tool made it. Promise a documented process, a citable structure, a live technical check, and measured visibility that can improve or fail and then inform the next round. That promise you can keep.
Step 7: Build and validate the internal link network
A planned link is not a live link. This step is where most clusters quietly fall apart.
Implement the architecture on the live site. The minimum is pillar to each relevant supporting page, and each supporting page back to the pillar. Add lateral links only when they move a reader to a genuinely adjacent answer, and place them in sentences that explain what the reader will find next.
Then check the mechanics. Use a normal crawlable anchor element with a working href. Keep anchor text concise and descriptive so it makes sense out of context. Skip "click here" and "read more." Do not stuff every related keyword into one anchor, and do not chain links together until the surrounding context disappears. Make sure every important page has at least one internal link pointing at it. Confirm the pillar links to the pages it promises and that each supporting page points at the right pillar. Then hunt for orphans, broken links, redirect chains, wrong canonicals, and blocked crawling.
The ordinary technical work still matters here. Google's guidance for AI features is that a supporting page has to be indexed and eligible to appear in Search with a snippet, content has to be findable through internal links, important information should be available as text, and structured data has to match what is visible. Meeting those conditions does not guarantee crawling, indexing, or serving. It just makes you eligible.
Done when: a crawl reaches every cluster page, the hub relationships are real on the live site, anchors describe their destinations, nothing is orphaned, and the link map in your brief matches the implementation.
Common mistake: assuming a tool's suggested links were published correctly. Inspect the live HTML. A suggestion is not a link.
Pro tip: keep the link map as a small graph with source URL, target URL, anchor meaning, relationship, and validation status. It becomes a reusable delivery artifact and it makes client reporting concrete instead of abstract.
Step 8: Report what changed and pick the next cluster
Now close the loop, because this is the part clients renew for.
Compare the same tracked prompts before and after publication. Report by client, cluster, prompt, page, engine, and period. Include the baseline and current mention rate, the baseline and current citation rate, which pages earned citations and which prompts drove them, share of voice against the named competitors, the exact competitor pages still showing up for prompts you want, the answer history with collection dates and platforms, whichever organic measures sit in the client's contract, the pages you published or consolidated or left alone, the issues still blocking the outcome, and the next evidence-backed action.
Give it time. Collection and evaluation are different jobs. A platform can pull prompt answers daily, but crawling, indexing, and answer systems need room to process new pages. The content-audit guidance most teams follow suggests waiting at least two months after a change before analyzing it, then rerunning the analysis two or three months later. Use the same sources and comparable periods, and account for seasonality and algorithm updates.
One reporting trap worth naming: Google folds traffic from pages appearing in AI features into the overall Search Console Performance report under the Web search type. Do not present that as a clean, separate AI channel unless your data source actually separates it.
At roster scale, run one client-ready report template per workspace. DeepSmith's AI-visibility reporting is white-labelable, covering prompt-level citations and mentions, page-level attribution, and competitive benchmarking, so the deliverable carries your brand. Show observed movement and the next action. Do not claim the cluster caused every change.
Done when: the client can see what was measured, which pages and prompts moved, how competitors appeared, what you shipped, what is still uncertain, and what the next cluster decision rests on.
Common mistake: reporting article count as the result. A client bought a visibility outcome, not a pile of URLs. Connect every page to a prompt, an intent, a cluster role, and a measured next step.
Pro tip: run a quarterly decay check on your important clusters. A practical trigger is any page down more than 20 percent year over year. Then work out whether it is aging content, a competitor improvement, an intent shift, cannibalization, or a technical fault.
What to do next
Do not try to run this on eight accounts at once. Pick your best-fit client, run the eight steps end to end, and let that first cluster become the template.
Then save it properly. The brief schema, the prompt matrix, the five topic filters, the page-role fields, the brief template, the production gate, the link-map format, and the report layout. That bundle is your agency seo cluster process, and it is the thing you reuse. That bundle is how you scale content for multiple clients without the method resetting each time. The next account gets new evidence, a new topic, and new information gain, but never a blank document.
Then price it. Sell a cluster delivery unit rather than an undefined promise to "do AEO": account setup, prompt baseline, one prioritized topic, the page architecture, the briefs, one production wave, the link implementation and QA, and the report with a recommendation attached. A retainer repeats that unit at an agreed cadence. That is an agency aeo service a client can understand and buy. Scope it by tracked prompts, pages, engines, and reporting depth, and never by a guaranteed citation count.
You are closer to this than you think. You already run briefs, production, and reporting. This just gives them one spine.
Want to see the visibility and production halves in one place before you commit? Start a DeepSmith free trial and run your first client cluster on real data.
