Topical Map and Site Architecture
Build a topical map that assigns every page one intent, post type, status, priority, and link path before content production creates costly overlap today.
A topical map is the set of pages a site needs to cover its subject area, organized into clusters, with every page assigned a reader intent, post type, location, and role in the internal link graph. It is not a keyword spreadsheet or publication calendar. Keywords describe language; the map decides ownership and connections.
Phase: P8, Topical Map and Information Architecture. Stage: B — Decide. Timebox: 3–5 working days for a focused site or 1–2 weeks for a multi-market site. Owner: SEO strategist or information architect, with content and commercial owners approving their parts.
This is the handoff from research to page design. The process pillar establishes what the site needs; the SEO post types pillar then determines how each approved node should work as a guide, comparison, product page, case study, glossary term, or another defined format.
Why this phase, and why here
P8 consumes the competitor and gap analysis from P7: the themes competitors cover, prompts and queries they answer, pages that earn visibility, and gaps where the site is absent or weak. Gap analysis shows opportunity; it does not decide whether ten query variants need one page, ten pages, or no page. That decision belongs here.
The phase comes before production because overlap is cheap to prevent and expensive to unwind. When two briefs quietly target the same search intent , both pages may split links, drift toward duplicate answers, and alternate in search results. That is content cannibalization : multiple pages compete for the same need instead of reinforcing one clear destination. Fixing it later requires choosing a survivor, merging useful material, redirecting URLs, repairing links, and waiting for systems to process the new structure.
Running P8 too early is also harmful. Without baseline findings, existing-page data, keyword and prompt research, and competitor gaps, the map becomes a wish list shaped by internal vocabulary. Running production alongside an unfinished map freezes accidental decisions into published URLs.
The second output is information architecture : the hierarchy, labels, routes, and relationships that make content findable. The map says what must exist; the architecture says where it belongs and how people and crawlers move between it. Design them together.
Inputs and outputs
The inputs are evidence, not inspiration. The outputs are the contract production uses to create every future issue.
| Direction | Item | Acceptance condition |
|---|---|---|
| Input | Business goals and conversion paths | Names the audiences, offers, markets, and actions the site is expected to support. |
| Input | Existing URL inventory | Includes canonical URL, indexability, template, directory, traffic or visibility, links, and content owner. |
| Input | Keyword and prompt research | Groups query language, prompt themes, modifiers, journey stage, and observable result patterns. |
| Input | Competitor and gap analysis | Identifies missing coverage, weak coverage, cited competitor pages, and opportunities worth evaluating. |
| Input | Technical and AI-accessibility findings | Flags routes, rendering patterns, duplication, and crawl constraints that affect the proposed architecture. |
| Output | Approved node inventory | Every in-scope page has one node ID, one primary intent, one post type, and one proposed or canonical URL. |
| Output | Existing-page disposition | Every node is marked fine, improve, merge, or create, with the destination named for every merge. |
| Output | Cluster and pillar model | Every spoke belongs to a cluster and every cluster has an accountable pillar or an explicit reason not to. |
| Output | Internal link graph | Every priority node has planned inbound and outbound contextual links with source and destination recorded. |
| Output | Sequenced build queue | Priorities have evidence, dependencies, owners, and a release order suited to the business model. |
If an input is incomplete, mark the limitation. Missing analytics should lower confidence in a merge decision, not erase the duplicate-intent problem.
Ready to Monitor Your AI Visibility?
Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.
The checklist
Each check has a done-when condition so another operator can audit the decision without repeating the entire discovery process.
1. Extract entities and topics
What to do: Build a normalized inventory of entities, topics, attributes, problems, use cases, comparisons, and questions from the prior research. An entity is a distinct thing the site discusses, such as a product, method, audience, location, or standard. A topic is the subject relationship around that thing, such as choosing, using, comparing, troubleshooting, or buying it.
Why it matters: Raw language fragments the same idea across synonyms and hides materially different needs behind similar words. Normalization creates stable objects for clustering without treating every phrase as a page.
How to do it: Combine prompt themes, fan-out queries, keyword groups, competitor headings, product taxonomy, and sales questions. Keep source phrases, but add a normalized entity, topic, modifier, likely intent, market, and evidence source.
Tool: Use Semantic Map at app.amicited.com/semantic-map to inspect proximity among tracked prompts, fan-out queries, and cited pages. Proximity is a discovery clue, not proof that points belong on one page.
Done when: Every material research item maps to a normalized entity and topic, duplicates are consolidated, and ambiguous items have an owner for resolution.
2. Form clusters around shared subject and journey
What to do: Group nodes that reinforce one subject area and serve adjacent reader needs. A cluster is a connected set of pages, not merely a shared keyword stem.
Why it matters: Clusters establish boundaries for coverage and linking. Loose grouping produces sprawling pillars; over-tight grouping creates small islands that cannot support one another.
How to do it: Compare semantic proximity, shared entity, audience, journey stage, and likely link behavior. A page may link across clusters, but it should have one primary cluster owner.
Tool: Use the Semantic Map view, competitor coverage, and the research sheet.
Done when: Every planned node has one primary cluster, no cluster is just an unstructured list, and every boundary case has a recorded rationale.
3. Identify the pillar and define its scope
What to do: Choose the page that provides the broad orientation for each cluster. A pillar page explains the subject at the level needed to route readers toward narrower spokes; it is not automatically the longest page or the page with the highest search volume.
Why it matters: Without a pillar, spokes link sideways at random and the cluster has no reliable entry point. A pillar that tries to answer every spoke in full creates overlap instead.
How to do it: Write a one-sentence job for the pillar, list what it answers, and list what it delegates. Select an existing page where it fulfills that role; otherwise create a node. Document any alternative navigation route.
Tool: Existing-page inventory, page report, and directory report.
Done when: Every cluster has one pillar or a documented exception, and the pillar scope does not duplicate the full answer owned by any spoke.
4. Define one intent per spoke
What to do: Give every spoke one primary intent statement in the form: “For [audience] who needs to [task or decision], this page will [useful outcome].”
Why it matters: One-intent ownership is the main prevention mechanism for cannibalization. It makes two superficially different titles comparable before either becomes expensive content.
How to do it: Compare audience, desired outcome, evidence needed, result-page pattern, and appropriate call to action. Apply the merge test: if the same reader would be satisfied by the same answer, evidence, format, and next action, plan one page with sections. Split only when at least one of those dimensions materially changes.
Tool: Unified Keywords at app.amicited.com/reports/keywords , prompt research, and live result inspection.
Done when: No two active nodes share the same primary intent, and every split or merge that was debated has a written reason.
5. Assign a post type by intent
What to do: Assign one post type to every node according to the job the reader needs the page to perform.
Why it matters: Topic does not determine format. “CRM software” could require a definition, a best-options list, a product page, a comparison, or a how-to guide. Choosing by topic alone gives writers the wrong evidence and page structure.
How to do it: Match intent and expected decision to the post-type contract: comparison for a direct choice, how-to guide for a repeatable task, glossary term for a definition, and product or category page for commercial evaluation. Record the choice in the node.
Tool: The SEO post-types hub and the approved result-pattern evidence.
Done when: Every node has exactly one primary post type, and a reviewer can explain the choice from intent without relying on the proposed title.
6. Map every node to the existing site
What to do: Match each node against existing URLs and assign exactly one status: exists and is fine, exists and needs work, exists and should merge, or does not exist.
Why it matters: Treating every opportunity as net-new production wastes authority already earned and makes overlap worse. The status converts research into both a content plan and a pruning plan.
How to do it: Compare intent with page titles, headings, ranking queries, citations, traffic, conversions, and links. For a merge, name the surviving canonical page and material worth retaining. Never use “merge” without a destination.
Tool: Organic vs Paid Pages at app.amicited.com/reports/pages , site crawl data, and the URL inventory.
Done when: Every node has one status, every existing URL is represented or explicitly out of scope, and every merge has a survivor, migration owner, and reason.
7. Design the internal link graph
What to do: Specify the contextual links that connect pillars, spokes, commercial destinations, and useful cross-cluster pages. Internal linking means links between pages on the same domain; here it is designed as a graph with pages as nodes and links as directed edges.
Why it matters: A cluster without planned edges can publish as a set of orphaned pages. Navigation alone rarely expresses which page supplies detail, comparison, proof, or the next decision.
How to do it: Give each spoke a route back to its pillar and a relevant onward route. Record source, destination, reason, likely anchor concept, and whether the link exists. Add cross-cluster links only for a real reader task.
Tool: Directory View at app.amicited.com/reports/directory , crawl link data, and the topical-map graph.
Done when: Every priority node has at least one planned contextual inbound link and one contextual outbound link; every cluster connects to the wider site; and no new node depends only on a sitemap or menu for discovery.
8. Prioritize and sequence connected work
What to do: Order creates, improvements, and merges as connected releases rather than isolated page scores.
Why it matters: The first page changes what later pages can link to. Publishing ten spokes before their pillar leaves weak routes; rebuilding navigation before commercial destinations are ready creates dead ends.
How to do it: Score business value, evidence of demand, current gap, dependency, implementation effort, and risk. Then select the smallest connected release that can serve a reader: often a pillar, a commercial destination, and two or three high-value spokes. Adjust the order by business model rather than enforcing one universal sequence.
Tool: Topical map, page and keyword reports, delivery tracker, and the relevant business-type playbook.
Done when: Every priority has a reason, the first release is internally connected on launch, merges precede content that would link to retired URLs, and owners agree on the next production batch.
Tools in AmICited
The product views support different decisions and should not be collapsed into one generic “research” step.
| Product view | Executable decision | Deep link | Completion evidence |
|---|---|---|---|
| Semantic Map | Discover semantic neighborhoods, competitor-cited pages, and query fan-out to review during extraction and clustering. | Open Semantic Map | Export or capture filtered view and record the clusters reviewed. |
| Unified Keywords | Compare query variants, channel evidence, clicks, position, and commercial signals when testing node boundaries. | Open Keywords | Attach the keyword group used to accept a split or merge. |
| Pages report | Match demand and performance to existing URLs before choosing fine, improve, merge, or create. | Open Pages | Each existing-node decision cites the URL and relevant evidence. |
| Directory View | Inspect section shape and performance while placing clusters and auditing routes into them. | Open Directory View | Directory owner and intended parent route are recorded for each cluster. |
Stay Updated on AI Visibility Trends
Get the latest insights on AI mentions, brand monitoring, and optimization strategies.
Decision rules
Thresholds make the map usable across reviewers. They are operating gates, not claims about what an algorithm rewards.
| Decision | Bad looks like | Required action |
|---|---|---|
| Node ownership | Two active nodes have the same audience, task, answer, evidence, and next action. | Merge the planned nodes; one intent may have many keyword variants. |
| Split test | The only difference is a modifier or wording, while the useful answer remains the same. | Keep one node and cover the variants in sections. |
| Cluster size | A cluster has 2 or more spokes but no pillar or documented alternative route. | Define the pillar before the cluster enters production. |
| Existing-page mapping | Any in-scope URL has no disposition, or a merge has no named survivor. | Block map approval until every URL and destination is explicit. |
| Link coverage | A priority node has 0 planned contextual inbound links or 0 planned contextual outbound links. | Add useful edges or defer the node; menu and sitemap links do not satisfy the gate. |
| Cluster connectivity | A cluster has no contextual edge to the rest of the site. | Add a relevant route through a pillar, commercial page, or adjacent cluster. |
| Post-type clarity | A node has multiple primary post types, or its type was chosen only from the topic name. | Restate the intent and choose the single format that best completes that job. |
| Production readiness | Any node lacks intent, post type, status, priority, owner, or proposed/canonical URL. | Do not create its content issue. |
| First release | A batch contains only unlinked spokes or links to URLs scheduled for merge. | Resequence into a connected batch and complete migrations first. |
Evidence can override a heuristic, but record the exception. A utility page may need no contextual outbound link; its node should state why.
Sequencing the build by business type
Build order follows the site’s economic model and current authority. Money pages are pages closest to a transaction, lead, booking, or subscription; supporting pages answer the questions that help people reach and trust those destinations.
| Business type | Usually establish first | Then connect |
|---|---|---|
| e-commerce playbook | Stable category and priority product destinations | Buying guides, comparisons, use cases, and care or troubleshooting content. |
| SaaS playbook | Product, use-case, and high-intent comparison routes | Alternatives, how-to content, glossary support, integrations, and proof. |
| local service playbook | Core service and valid location routes | Process explanations, cost questions, local proof, and decision guides. |
| marketplace playbook | Taxonomy, category, and indexable supply pages | Buyer guides, seller acquisition, trust, and use-case clusters. |
| media and affiliate playbook | A coherent authority cluster with clear editorial standards | Commercial comparisons and best-of pages once support and maintenance are credible. |
| B2B services playbook | Service, use-case, and proof destinations | Educational pillars, decision support, comparison content, and case studies. |
These are starting patterns. An established publisher may lack commercial routes; a new SaaS company may need foundational explanations first. Record which dependency drives the order.
Deliverable: the topical map
The deliverable is one versioned table or database plus a graph view. The table is authoritative; the graph makes missing links and isolated clusters visible. Use one row per node with at least these fields:
Node ID | Cluster | Entity/topic | Primary intent | Audience | Journey stage
Post type | Existing status | Canonical/proposed URL | Pillar/spoke role
Priority | Priority reason | Owner | Inbound links | Outbound links
Source evidence | Dependencies | Merge destination | Notes
Store link node IDs or canonical URLs, not “related articles.” Store priority reasons and use only the four approved statuses. Log approvals for merges, boundary changes, and architecture decisions.
It is complete when a content lead can generate an issue without deciding the intent, post type, cluster, or link obligations again. Writers decide expression, not ownership.
What goes wrong
- The map is a keyword spreadsheet. It has volume and difficulty but no page nodes, intent ownership, status, post type, or links. Convert keyword groups into explicit page decisions.
- Clusters have no pillar. Spokes share a color in a sheet but have no stable route or broad orientation. Name the pillar or document the alternative navigation model.
- Post types follow topics instead of intent. Every “X software” node becomes a product page even when the reader wants a comparison or definition. Re-run the intent statement before selecting format.
- The map has no link graph. Production creates the pages, but none has accountable inbound links. Define edges as part of the node contract.
- Every gap becomes a new page. Existing authority is ignored and overlap grows. Map the gap to fine, improve, merge, or create first.
- One giant pillar absorbs every spoke. It repeats complete answers and competes with details. Set inclusion and delegation boundaries.
- Clusters mirror the company org chart. Validate labels and routes against reader tasks and language.
- Priorities are independent scores. The top ten nodes cannot link to one another or depend on missing destinations. Sequence connected releases, not isolated totals.
- The map never changes. New products, observed prompts, merges, and performance evidence invalidate old decisions. Version the map and review affected clusters when the site or market changes.
Handoff to production and post types
P8 hands the content lead an approved map, decision log, merge instructions, and first connected production batch. Each issue receives its node ID, intent, audience, post type, URL, evidence, required links, and acceptance criteria.
The post-type owner applies the relevant template without reopening the node boundary. If briefing shows that two nodes are one intent, work returns to the map owner before drafting so later issues inherit the correction.
The handoff is accepted when:
- every issue traces to exactly one approved node;
- the first release has live or scheduled link sources;
- merge and redirect work precedes links to the surviving URL;
- architecture, content, and commercial owners approve their dependencies; and
- one person owns map changes for the remainder of the engagement.
FAQ
Is a topical map the same as a keyword list?
No. A keyword list records phrases. A topical map defines the pages a site needs, the distinct intent each page owns, its post type and status, and the internal links that connect it to the rest of the site.
How many keywords can one topical-map node target?
A node can include many query variants when they share one intent and useful answer. Split only for a materially different decision, task, evidence set, or format.
Should we create pillar pages before cluster pages?
Usually define the pillar first, but build order depends on the business model and existing authority. Publish the smallest connected unit that can satisfy demand, then add spokes with their links already specified.
What should happen when two existing pages target the same intent?
Choose the stronger canonical destination, decide what unique material from the weaker page should be retained, and mark the weaker node for merge. Do not create a third page to resolve an overlap between two pages.
When is the topical map complete enough for production?
It is ready when every in-scope node has one intent, one post type, one current-state classification, a priority, a canonical or proposed URL, and explicit inbound and outbound links, with no unresolved ownership collisions.
More tutorials in this section
Ready to put it into practice?
Free check · 7-day trial · no credit card