Semantec SEO

52 Topical Mapping and Site Architecture Prompts for MIRENA

52 Topical Mapping and Site Architecture Prompts for MIRENA

Use Topical Mapping and Site Architecture prompts when MIRENA needs to turn source context and discovery evidence into a clean page structure.

This workflow decides which pages should exist, which topics should become sections, which pages should merge, which hubs should lead a cluster, which support pages are needed, which routes should connect pages, and which pages should move into briefs, rewrites, internal links, or publishing.

Start with source context.

Do not build a map from a loose keyword file, sitemap, competitor list, analytics export, behavior report, or discovery package until MIRENA knows the site, offer, audience, allowed topics, blocked topics, internal link rules, and next workflow stage.

Use the source context template before mapping if the project base is not ready. Use Getting Started with MIRENA if you need the full onboarding route first.

Start with Source Context Before Mapping

Source context controls the map.

It tells MIRENA what the site is, who it serves, what it sells, which topics belong, which topics should be blocked, how pages should connect, and which workflow should come next.

A topical map can grow too wide if it starts from keywords alone. A sitemap can also contain legacy pages, weak pages, duplicate pages, old experiments, and off-scope topics.

The Source Context page explains how source context protects the site’s topical focus before new pages enter the map.

Use source context to define:

  • site purpose
  • audience
  • offer
  • region
  • allowed topics
  • blocked topics
  • existing pages
  • protected pages
  • pages to merge
  • pages to refresh
  • internal link targets
  • commercial routes
  • workflow goal
  • output format
  • next workflow stage

When source context is missing, stop and build it first.

What Topical Mapping and Site Architecture Does

Topical Mapping and Site Architecture turns selected evidence into a governed site structure.

It does not collect raw evidence.

It does not write briefs.

It does not draft pages.

It does not finalize schema.

It decides structure first.

The output can feed Content Briefs when approved pages need writer instructions. It can feed Drafting + Rewriting when existing pages need repair. It can feed semantic internal linking when pages need route planning. It can feed information gain work when the map reveals repeated SERP coverage or weak differentiation.

Use MIRENA outputs when you need to define the fields the map should return.

A strong map should tell the team:

  • which pages should exist
  • which topics should stay as sections
  • which pages should merge
  • which pages should be blocked
  • which pages should act as hubs
  • which pages should act as spokes
  • which pages should support conversion
  • which pages should support trust
  • which pages should support documentation
  • which pages should support comparison paths
  • which links should connect each cluster
  • which pages should move into briefs
  • which pages should move into rewrites
  • which pages should wait

What This Page Does Not Repeat

This page does not repeat Raw Semantic Discovery prompts.

Raw Semantic Discovery collects candidates, modifiers, query paths, SERP patterns, competitor signals, and opportunity notes.

This page starts after that evidence exists.

This page also does not repeat Entity SEO and Salience prompts.

Entity SEO handles entity structure, salience, entity placement, entity relationships, support pages, and markup cues. Topical Mapping and Site Architecture uses entity and discovery output as evidence, then decides site structure.

Use this page when the job is structure, hierarchy, page roles, page vs section decisions, overlap control, publishing order, or map handoff.

Use Semantic SEO when the map needs stronger meaning, context, and topic fit before page planning.

When to Use Topical Mapping and Site Architecture Prompts

Use this prompt collection when you need to turn source context and selected evidence into a page plan.

Topical Mapping and Site Architecture is useful for:

  • new site planning
  • cluster expansion
  • content refresh planning
  • sitemap cleanup
  • site restructure
  • page inventory creation
  • page role assignment
  • hub and spoke planning
  • docs architecture
  • use case architecture
  • comparison architecture
  • commercial route planning
  • publishing order
  • duplicate intent repair
  • cannibalization prevention
  • topic governance
  • map approval
  • production handoff

Use MIRENA inputs when you need to decide which files should feed the map. Use the MIRENA workflow when the map needs a clear route into briefing, rewriting, internal linking, information gain, or schema notes.

The Topical Mapping Workflow

Run the Topical Mapping and Site Architecture workflow in this order.

  1. Set the map scope.
  2. Define the map goal.
  3. Build the topic inventory.
  4. Create the processed map.
  5. Build the page inventory.
  6. Assign page roles.
  7. Decide query granularity.
  8. Consolidate similar queries.
  9. Decide page vs section.
  10. Map intent to page types.
  11. Map topics to pages.
  12. Use SERP URL clustering as evidence.
  13. Assign cluster roles.
  14. Build cluster hierarchy.
  15. Define parent and child topics.
  16. Design hub pages.
  17. Design spoke pages.
  18. Design bridge pages.
  19. Design support pages.
  20. Plan proof pages.
  21. Plan conversion pages.
  22. Plan docs clusters.
  23. Plan comparison clusters.
  24. Plan use case architecture.
  25. Plan navigation routes.
  26. Build authority hubs.
  27. Build support clusters.
  28. Create the commercial spine.
  29. Build semantic site architecture.
  30. Control topic scope.
  31. Give every page a clear purpose.
  32. Detect duplicate intent.
  33. Prevent cannibalization.
  34. Split topics when needed.
  35. Consolidate topics when needed.
  36. Review semantic overlap.
  37. Set publishing order.
  38. Map topic dependencies.
  39. Set sitewide topic priorities.
  40. Handle multiple audiences.
  41. Handle multiple products.
  42. Merge sites or sections.
  43. Restructure legacy sites.
  44. Model site growth.
  45. Plan templates and examples.
  46. Score topic coverage.
  47. Check cluster health.
  48. Audit the topical map.
  49. Refresh the map.
  50. Set topic governance.
  51. Approve the map.
  52. Hand off the map.

Do not move into content briefs, drafts, rewrites, internal links, or schema if the map contains unclear roles, duplicate intent, weak source context fit, or unapproved pages.

The Topical Mapping Prompt Pattern

Use short commands when the task is clear.

Use expanded prompts when the map needs fields, decisions, exclusions, approval rules, and workflow routing.

Short command pattern:

text

Run [topical mapping module] on [asset].

Expanded prompt pattern:

text

Run [topical mapping module] on [asset].

Use the source context first.

Use raw discovery output only as evidence.

Do not create pages that drift outside the source context.

Return the output with these fields:
- page or topic
- cluster
- page role
- intent
- page vs section decision
- parent page
- support pages
- internal link direction
- overlap risk
- publishing priority
- next workflow route

Flag anything that should merge, stay as a section, move to another cluster, or be blocked.

Route the final output into Content Briefs, Drafting and Rewriting, Internal Linking, Information Gain, or Map Approval.

A short prompt is enough for a simple map task.

An expanded prompt is better when the input is large, messy, risky, or ready for production handoff.

What to Give MIRENA Before Running Topical Mapping

Start with source context.

Then add the strongest evidence available.

For a new site map, give MIRENA:

  • source context
  • product or service notes
  • audience notes
  • seed topics
  • target region
  • competitor notes if available
  • desired page types
  • commercial goal
  • internal link targets

For a sitemap cleanup, give MIRENA:

  • source context
  • sitemap or URL list
  • page titles
  • meta titles if available
  • page roles if known
  • crawl data if available
  • pages to protect
  • pages to merge
  • pages to refresh
  • search data if available

For a keyword led map, give MIRENA:

  • source context
  • keyword export
  • raw discovery output if available
  • query intent labels if available
  • modifier groups if available
  • target clusters
  • page types to allow
  • page types to block

For a content refresh map, give MIRENA:

  • source context
  • existing page inventory
  • GSC pages export
  • GSC queries export
  • GA4 landing page data
  • content crawl
  • weak pages list
  • pages with traffic
  • pages with poor engagement
  • pages needing internal links

For a product or SaaS map, give MIRENA:

  • source context
  • product notes
  • use cases
  • docs pages
  • comparison pages
  • pricing or conversion pages
  • proof pages
  • support topics
  • onboarding steps
  • internal link targets

For a large site architecture task, give MIRENA:

  • source context
  • full sitemap
  • page inventory
  • raw discovery package
  • internal link data
  • performance data
  • audience segments
  • product segments
  • protected pages
  • known risks
  • desired handoff format

Topical Mapping and Site Architecture Modules

The modules below build the processed map, page inventory, site architecture, publishing order, governance rules, and handoff package.

Choose the smallest module that fits the job.

1. Map Scope

Use this to define the boundary of the map before page decisions begin.

Short command:

text

Run Map Scope on this project.

Expanded prompt:

text

Run Map Scope on this project.

Use the source context first.

Define the scope of the topical map before any page inventory is created.

Return the output with these fields:
- site or section being mapped
- allowed topic lanes
- blocked topic lanes
- target audience
- product or service connection
- commercial route
- existing pages to include
- pages to protect
- topics to ignore
- output format
- next workflow route

Reject topics that do not support the source context.

Flag topics that need review before mapping begins.

Route the output into Map Goal or Topic Inventory.

Best for:

  • new site planning
  • broad content programs
  • sitemap reviews
  • cluster planning
  • client projects

Output should include:

  • map boundary
  • allowed topics
  • blocked topics
  • pages to include
  • pages to protect
  • next route

Use this to:

Keep the map focused before it expands.

Map Scope stops the workflow from turning a broad idea into an unfocused site structure.

2. Map Goal

Use this to define the job of the map.

Short command:

text

Run Map Goal for this project.

Expanded prompt:

text

Run Map Goal for this project.

Use the source context first.

Define the goal of the topical map.

Choose one primary goal:
- new site structure
- cluster expansion
- site restructure
- content refresh
- page consolidation
- internal link planning
- publishing order
- docs architecture
- comparison architecture
- use case architecture
- commercial route support

Return the output with these fields:
- primary map goal
- secondary goals
- source context fit
- input needed
- output fields
- success criteria
- review risks
- next workflow route

Do not combine too many map goals in one output.

Route the output into Topic Inventory or Processed Map Build.

Best for:

  • unclear mapping tasks
  • agency projects
  • large site audits
  • refresh planning
  • product site planning

Output should include:

  • primary map goal
  • secondary goals
  • success criteria
  • input needs
  • next route

Use this to:

Stop the map from becoming too broad or unclear.

A map for publishing order needs a different output than a map for site restructure.

3. Topic Inventory

Use this to list the topics that may enter the map.

Short command:

text

Run Topic Inventory on this discovery package.

Expanded prompt:

text

Run Topic Inventory on this discovery package.

Use the source context first.

Turn accepted discovery findings into a topic inventory.

Return the output with these fields:
- topic
- source evidence
- source context fit
- likely cluster
- likely page role
- intent signal
- support needed
- keep, merge, section, or block
- reason
- review risk
- next workflow route

Do not build the final map yet.

Do not create pages from every topic.

Route the output into Processed Map Build, Page vs Section Decisions, or Topic Scope Control.

Best for:

  • raw discovery handoff
  • keyword exports
  • SERP evidence
  • sitemap reviews
  • topic list cleanup

Output should include:

  • topic
  • evidence
  • likely cluster
  • keep or block note
  • next route

Use this to:

Create the working list before page structure begins.

Topic Inventory helps MIRENA separate possible map entries from off-scope ideas.

4. Processed Map Build

Use this to turn selected topics into a governed map.

Short command:

text

Build a Processed Topical Map from this topic inventory.

Expanded prompt:

text

Build a Processed Topical Map from this topic inventory.

Use the source context first.

Use raw discovery output only as evidence.

Return the output with these fields:
- cluster name
- hub page
- support pages
- bridge pages
- comparison pages
- docs pages
- conversion pages
- page role for each URL
- page vs section decision
- overlap warning
- consolidation note
- internal link direction
- publishing priority
- next workflow route

Do not include topics that fail source context fit.

Flag pages that should merge, split, or become sections.

Route the output into Map Approval, Content Briefs, or Internal Linking.

Best for:

  • new maps
  • processed maps
  • site architecture planning
  • content programs
  • cluster builds

Output should include:

  • clusters
  • hubs
  • support pages
  • page roles
  • page vs section decisions
  • publishing priority

Use this to:

Move from topic evidence into page architecture.

A processed map should be a governed structure, not a topic dump.

5. Page Inventory

Use this when the map needs a clean list of pages.

Short command:

text

Run Page Inventory for this map.

Expanded prompt:

text

Run Page Inventory for this map.

Use the source context first.

Create a clean inventory of pages that should exist.

Return the output with these fields:
- proposed page title
- proposed URL slug
- cluster
- parent page
- page role
- primary intent
- secondary intent
- source evidence
- page status
- merge or split notes
- internal link direction
- next workflow route

Separate approved pages from review needed pages.

Flag pages with weak source context fit.

Route the output into Page Role Assignment or Publishing Order.

Best for:

  • production planning
  • page queues
  • editorial calendars
  • sitemap cleanup
  • content refresh

Output should include:

  • page title
  • URL slug
  • cluster
  • role
  • status
  • next route

Use this to:

Turn a map into a production ready page list.

The page inventory becomes the bridge between strategy and execution.

6. Page Role Assignment

Use this to give every page a job.

Short command:

text

Run Page Role Assignment on this page inventory.

Expanded prompt:

text

Run Page Role Assignment on this page inventory.

Use the source context first.

Assign one primary role to every page.

Use roles such as:
- hub
- spoke
- bridge
- support
- proof
- docs
- comparison
- use case
- template
- example
- conversion
- pricing support
- trust support

Return the output with these fields:
- page
- page role
- role reason
- parent cluster
- user job
- intent
- internal link direction
- CTA route
- review risk
- next workflow route

Flag pages with unclear roles.

Route the output into Cluster Roles, Page Purpose Framework, or Content Briefs.

Best for:

  • page inventories
  • old sites
  • content refresh
  • map approval
  • editorial handoff

Output should include:

  • page
  • role
  • role reason
  • intent
  • internal link direction
  • next route

Use this to:

Make every page useful before briefs or drafts start.

A page without a clear role is not ready for production.

7. Query Granularity

Use this when a topic may need its own page.

Short command:

text

Run Query Granularity on this topic set.

Expanded prompt:

text

Run Query Granularity on this topic set.

Use the source context first.

Decide which topics need standalone URLs.

Return the output with these fields:
- topic
- query or evidence
- distinct intent
- user job
- page need
- section fit
- overlap risk
- recommended decision
- reason
- next workflow route

Choose one:
- standalone page
- section inside existing page
- FAQ
- comparison block
- template
- example
- merge into canonical page
- block

Do not create pages for minor wording differences.

Route the output into Page vs Section Decisions or Processed Map Build.

Best for:

  • keyword based maps
  • query groups
  • FAQ planning
  • page vs section decisions
  • map cleanup

Output should include:

  • topic
  • distinct intent
  • recommended decision
  • overlap risk
  • next route

Use this to:

Prevent one page from carrying too many different jobs.

Granularity helps MIRENA decide when a topic deserves its own URL.

8. Query Consolidation

Use this when similar queries may belong on one page.

Short command:

text

Run Query Consolidation on this query group.

Expanded prompt:

text

Run Query Consolidation on this query group.

Use the source context first.

Decide which similar queries should be consolidated into one canonical page.

Return the output with these fields:
- query group
- shared intent
- different wording
- canonical page target
- section targets
- FAQ targets
- anchor targets
- queries to merge
- queries to block
- reason
- next workflow route

Do not create separate pages for minor wording differences.

Flag query groups that need page vs section review.

Route the output into Page vs Section Decisions, Topic Consolidation, or Processed Map Build.

Best for:

  • keyword exports
  • GSC query sets
  • long tail groups
  • FAQ decisions
  • duplicate intent cleanup

Output should include:

  • query group
  • shared intent
  • canonical page
  • section or FAQ targets
  • next route

Use this to:

Reduce overlap before the map creates extra pages.

Query Consolidation protects the site from thin or duplicate pages.

9. Page vs Section Decisions

Use this when a topic could be a page or a section.

Short command:

text

Run Page vs Section on this cluster.

Expanded prompt:

text

Run Page vs Section on this cluster.

Use the source context first.

Decide if each topic needs its own page or should live inside another page.

Return the output with these fields:
- topic
- candidate page
- parent page
- query intent
- depth needed
- SERP format signal
- internal link need
- page decision
- section decision
- reason
- next workflow route

Use standalone pages only when the topic has enough intent, depth, and source context fit.

Flag weak standalone page ideas.

Route the output into Processed Map Build or Content Briefs.

Best for:

  • topic inventories
  • query clusters
  • old blog cleanup
  • content refresh
  • sitemap expansion

Output should include:

  • topic
  • page or section decision
  • parent page
  • reason
  • next route

Use this to:

Keep the site from creating weak URLs.

This module helps MIRENA place smaller ideas inside stronger pages.

10. Intent to Page Mapping

Use this when intent labels need page types.

Short command:

text

Run Intent to Page Mapping on this query set.

Expanded prompt:

text

Run Intent to Page Mapping on this query set.

Use the source context first.

Map each intent group to the right page type.

Return the output with these fields:
- intent group
- query examples
- user job
- page type
- page role
- cluster
- page vs section decision
- SERP format signal
- internal link direction
- next workflow route

Flag mixed intent groups.

Do not force one page to satisfy conflicting intent.

Route the output into Page Inventory or Content Briefs.

Best for:

  • keyword exports
  • raw discovery outputs
  • query intent outputs
  • map planning
  • content brief prep

Output should include:

  • intent group
  • page type
  • page role
  • cluster
  • next route

Use this to:

Make page type follow user intent.

This keeps informational, comparison, docs, support, and conversion pages from blending together.

11. Topic to Page Mapping

Use this when topics need URLs or sections.

Short command:

text

Run Topic to Page Mapping on this topic list.

Expanded prompt:

text

Run Topic to Page Mapping on this topic list.

Use the source context first.

Map each topic to a page, section, FAQ, table, comparison block, template, example, or reject decision.

Return the output with these fields:
- topic
- mapped destination
- destination type
- parent page
- cluster
- page role
- reason
- overlap risk
- internal link direction
- next workflow route

Flag topics that need review before entry into the map.

Block topics that fail source context fit.

Route the output into Processed Map Build or Map Approval.

Best for:

  • topic inventories
  • content audits
  • sitemap planning
  • page queue creation
  • page vs section cleanup

Output should include:

  • topic
  • destination
  • destination type
  • parent page
  • next route

Use this to:

Turn topics into production destinations.

This module helps MIRENA place every topic in the right structure.

12. SERP URL Clustering

Use this to convert ranking patterns into page planning evidence.

Short command:

text

Run SERP URL Clustering on this SERP set.

Expanded prompt:

text

Run SERP URL Clustering on this SERP set.

Use the source context first.

Group ranking URLs by page type, intent, content format, topic depth, and query coverage.

Return the output with these fields:
- SERP cluster
- query group
- dominant page type
- shared URL pattern
- competing page types
- page plan signal
- source context fit
- risk note
- next workflow route

Do not copy competitor structure.

Use SERP URL patterns only as evidence.

Route the output into Page vs Section Decisions, Intent to Page Mapping, or Processed Map Build.

Best for:

  • SERP driven planning
  • mixed intent queries
  • competitor research
  • page type decisions
  • content briefs

Output should include:

  • SERP cluster
  • dominant page type
  • URL pattern
  • page plan signal
  • next route

Use this to:

Use ranking patterns as evidence without copying competitors.

SERP URL Clustering helps MIRENA detect if a query is served by guides, category pages, tools, comparisons, docs, or product pages.

13. Cluster Roles

Use this to assign function across the cluster.

Short command:

text

Run Cluster Roles on this map.

Expanded prompt:

text

Run Cluster Roles on this map.

Use the source context first.

Assign roles across the cluster.

Return the output with these fields:
- page
- cluster
- role
- parent page
- support relationship
- bridge relationship
- conversion relationship
- proof relationship
- internal link direction
- next workflow route

Use roles such as hub, spoke, support, bridge, proof, comparison, docs, use case, template, example, and conversion.

Flag pages with unclear role fit.

Route the output into Hub Page Design, Spoke Page Design, Support Cluster Design, or Internal Linking.

Best for:

  • processed maps
  • cluster planning
  • internal link planning
  • page inventories
  • map approval

Output should include:

  • page
  • cluster
  • role
  • relationships
  • next route

Use this to:

Make the cluster work as a system, not a list.

Cluster roles help every page support the wider architecture.

14. Cluster Hierarchy

Use this to define the hierarchy of a cluster.

Short command:

text

Run Cluster Hierarchy on this map.

Expanded prompt:

text

Run Cluster Hierarchy on this map.

Use the source context first.

Build the hierarchy for the cluster.

Return the output with these fields:
- cluster
- parent node
- child nodes
- sibling pages
- bridge pages
- support pages
- proof pages
- conversion pages
- depth level
- link direction
- next workflow route

Flag hierarchy conflicts and pages with no parent.

Flag pages that sit too deep or too far from the hub.

Route the output into Parent Child Topics, Internal Linking, or Map Approval.

Best for:

  • large clusters
  • site sections
  • hub planning
  • sitemap repair
  • internal link planning

Output should include:

  • parent node
  • child nodes
  • sibling pages
  • depth level
  • next route

Use this to:

Build a clear map before page briefs start.

Cluster hierarchy prevents pages from floating without a parent.

15. Parent Child Topics

Use this when the map needs a clean hierarchy.

Short command:

text

Run Parent Child Topics on this map.

Expanded prompt:

text

Run Parent Child Topics on this map.

Use the source context first.

Define parent topics, child topics, sibling topics, and bridge topics.

Return the output with these fields:
- parent topic
- child topic
- sibling relation
- bridge relation
- page or section decision
- hierarchy reason
- overlap risk
- internal link direction
- next workflow route

Flag topics with more than one possible parent.

Flag topics that should move to another cluster.

Route the output into Cluster Hierarchy, Page Inventory, or Map Approval.

Best for:

  • hierarchy repair
  • cluster planning
  • page inventory creation
  • topic cleanup
  • site restructure

Output should include:

  • parent topic
  • child topic
  • sibling relation
  • bridge relation
  • next route

Use this to:

Prevent topic hierarchy from becoming unclear.

A clean parent child structure makes briefs and links easier to plan.

16. Hub Page Design

Use this to plan the hub page in a cluster.

Short command:

text

Run Hub Page Design for this cluster.

Expanded prompt:

text

Run Hub Page Design for this cluster.

Use the source context first.

Design the hub page role and support structure.

Return the output with these fields:
- hub page title
- hub purpose
- target audience
- primary intent
- support spokes
- bridge pages
- comparison pages
- conversion route
- internal link direction
- brief route
- next workflow route

Do not draft the hub.

Flag hubs that are too broad or too thin.

Route the output into Content Briefs, Spoke Page Design, or Internal Linking.

Best for:

  • authority hubs
  • new clusters
  • site restructure
  • topic expansion
  • content brief planning

Output should include:

  • hub title
  • hub purpose
  • support spokes
  • bridge pages
  • next route

Use this to:

Define the page that holds the cluster together.

A hub should support navigation, meaning, authority, and next steps.

17. Spoke Page Design

Use this to plan child pages.

Short command:

text

Run Spoke Page Design for this cluster.

Expanded prompt:

text

Run Spoke Page Design for this cluster.

Use the source context first.

Plan each spoke page that supports the hub.

Return the output with these fields:
- spoke page
- parent hub
- page role
- target intent
- support topic
- depth needed
- internal link back to hub
- sibling link direction
- CTA route
- next workflow route

Flag spokes that should merge into the hub.

Flag spokes that need more evidence before approval.

Route the output into Content Briefs or Internal Linking.

Best for:

  • hub and spoke planning
  • support content
  • cluster expansion
  • page inventory creation
  • publishing order

Output should include:

  • spoke page
  • parent hub
  • target intent
  • depth needed
  • next route

Use this to:

Create useful child pages without creating overlap.

Spoke pages should support the hub and solve a distinct user job.

18. Bridge Page Design

Use this to connect clusters.

Short command:

text

Run Bridge Page Design for this map.

Expanded prompt:

text

Run Bridge Page Design for this map.

Use the source context first.

Identify pages that should connect two clusters.

Return the output with these fields:
- bridge page
- source cluster
- target cluster
- bridge purpose
- user job
- internal link direction
- anchor intent
- risk note
- next workflow route

Do not create bridge pages unless they support user movement and site structure.

Flag bridge pages that dilute topical focus.

Route the output into Internal Linking, Content Briefs, or Map Approval.

Best for:

  • multi cluster sites
  • use case architecture
  • comparison routes
  • docs to product routes
  • internal link planning

Output should include:

  • bridge page
  • source cluster
  • target cluster
  • bridge purpose
  • next route

Use this to:

Build routes between clusters without diluting focus.

Bridge pages should help users move between related parts of the site.

19. Support Page Design

Use this to plan pages that strengthen hubs.

Short command:

text

Run Support Page Design for this hub.

Expanded prompt:

text

Run Support Page Design for this hub.

Use the source context first.

Plan support pages that strengthen the hub.

Return the output with these fields:
- support page
- supported hub
- support role
- user job
- depth needed
- evidence source
- internal link direction
- priority
- next workflow route

Flag support pages that should become sections.

Flag support pages with weak topic fit.

Route the output into Content Briefs or Publishing Order.

Best for:

  • authority hubs
  • support clusters
  • content gaps
  • new site structures
  • refresh planning

Output should include:

  • support page
  • supported hub
  • support role
  • priority
  • next route

Use this to:

Add depth where the hub needs support.

Support pages should strengthen the parent topic without creating duplicate intent.

20. Proof Page Planning

Use this when trust content is needed.

Short command:

text

Run Proof Page Planning for this cluster.

Expanded prompt:

text

Run Proof Page Planning for this cluster.

Use the source context first.

Identify proof pages or proof sections needed to support claims, comparisons, pricing, use cases, and conversion routes.

Return the output with these fields:
- proof asset
- proof page or section
- supported page
- trust need
- evidence source
- internal link direction
- page role
- priority
- next workflow route

Do not create proof pages without a clear support path.

Flag proof needs that belong inside an existing page.

Route the output into Content Briefs, Drafting and Rewriting, or Internal Linking.

Best for:

  • SaaS pages
  • comparison pages
  • service pages
  • use case pages
  • conversion paths

Output should include:

  • proof asset
  • supported page
  • trust need
  • evidence source
  • next route

Use this to:

Add trust paths without turning the cluster into generic proof content.

Proof pages should support buyer confidence and internal routing.

21. Conversion Page Planning

Use this when the map needs stronger commercial routing.

Short command:

text

Run Conversion Page Planning for this map.

Expanded prompt:

text

Run Conversion Page Planning for this map.

Use the source context first.

Identify pages that should support conversion.

Return the output with these fields:
- conversion page
- supported offer
- target audience
- buyer stage
- supporting pages
- comparison paths
- proof paths
- CTA route
- internal link direction
- next workflow route

Flag pages that should educate before they convert.

Do not force conversion into every informational page.

Route the output into Commercial Spine, Content Briefs, or Internal Linking.

Best for:

  • product sites
  • service sites
  • SaaS sites
  • agency sites
  • commercial content plans

Output should include:

  • conversion page
  • supported offer
  • buyer stage
  • support pages
  • next route

Use this to:

Connect topical authority to the product or service path.

Conversion planning keeps the map tied to business goals.

22. Docs Cluster Planning

Use this when product or support docs need structure.

Short command:

text

Run Docs Cluster Planning for this product.

Expanded prompt:

text

Run Docs Cluster Planning for this product.

Use the source context first.

Build a documentation cluster around user onboarding, product actions, inputs, outputs, workflows, troubleshooting, and handoffs.

Return the output with these fields:
- docs hub
- docs page
- user task
- page role
- sequence
- support path
- internal link direction
- next workflow route

Flag docs pages that belong in support, templates, or examples.

Flag docs pages that need a clearer sequence.

Route the output into Content Briefs or Drafting and Rewriting.

Best for:

  • product docs
  • onboarding docs
  • support centers
  • SaaS workflow pages
  • help content

Output should include:

  • docs hub
  • docs page
  • user task
  • sequence
  • next route

Use this to:

Build documentation that supports the product workflow.

Docs clusters should help users move from setup to action to output.

23. Compare Cluster Planning

Use this when comparison pages need structure.

Short command:

text

Run Compare Cluster Planning for this product.

Expanded prompt:

text

Run Compare Cluster Planning for this product.

Use the source context first.

Plan comparison pages and their relationship to product, pricing, use cases, proof, and alternatives.

Return the output with these fields:
- comparison hub
- comparison page
- competitor or alternative
- buyer question
- proof need
- table need
- conversion route
- internal link direction
- next workflow route

Do not create comparison pages without a product route.

Flag comparisons that need information gain review.

Route the output into Content Briefs, Information Gain, or Drafting and Rewriting.

Best for:

  • software comparisons
  • alternative pages
  • buyer guides
  • product comparison clusters
  • commercial investigation queries

Output should include:

  • comparison page
  • buyer question
  • proof need
  • conversion route
  • next route

Use this to:

Make comparison pages support buyer decisions and site structure.

A comparison cluster should connect to product, proof, and conversion pages.

24. Use Case Architecture

Use this when pages should follow user jobs.

Short command:

text

Run Use Case Architecture on this site.

Expanded prompt:

text

Run Use Case Architecture on this site.

Use the source context first.

Build page structure around user jobs, workflows, pains, and outcomes.

Return the output with these fields:
- use case
- user job
- page role
- product fit
- support pages
- comparison path
- proof path
- conversion route
- internal link direction
- next workflow route

Flag use cases that overlap.

Flag use cases that do not support the product or service.

Route the output into Content Briefs or Commercial Spine.

Best for:

  • SaaS sites
  • service sites
  • product led sites
  • workflow pages
  • buyer journey mapping

Output should include:

  • use case
  • user job
  • product fit
  • support pages
  • next route

Use this to:

Build pages around jobs people need done.

Use case architecture connects audience needs to product value.

25. Navigation Cluster Plan

Use this when users need clearer site paths.

Short command:

text

Run Navigation Cluster Plan on this site.

Expanded prompt:

text

Run Navigation Cluster Plan on this site.

Use the source context first.

Plan how users should move through hubs, spokes, docs, examples, comparisons, proof pages, pricing pages, and use cases.

Return the output with these fields:
- source page
- next step page
- route reason
- journey stage
- internal link direction
- navigation note
- CTA note
- risk note
- next workflow route

Flag dead ends.

Flag routes that push users too early.

Route the output into Internal Linking or Map Approval.

Best for:

  • large sites
  • product docs
  • conversion paths
  • internal link planning
  • navigation cleanup

Output should include:

  • source page
  • next step page
  • route reason
  • journey stage
  • next route

Use this to:

Design clearer paths through the site.

Navigation planning helps users move from learning to action.

26. Authority Hub Planning

Use this to plan hub pages.

Short command:

text

Run Authority Hub Planning on this topic.

Expanded prompt:

text

Run Authority Hub Planning on this topic.

Use the source context first.

Define the hub page and the supporting pages needed to strengthen it.

Return the output with these fields:
- authority hub
- hub purpose
- supporting pages
- bridge pages
- proof pages
- internal link direction
- publishing priority
- gap note
- next workflow route

Do not create a hub if the topic is outside source context.

Flag hubs that need stronger support before publishing.

Route the output into Support Cluster Design or Content Briefs.

Best for:

  • authority building
  • hub planning
  • content programs
  • new clusters
  • topical coverage repair

Output should include:

  • authority hub
  • hub purpose
  • support pages
  • gap note
  • next route

Use this to:

Create a hub that can hold a topic cluster.

An authority hub needs support pages, links, and a clear role.

27. Support Cluster Design

Use this to plan supporting pages.

Short command:

text

Run Support Cluster Design on this hub.

Expanded prompt:

text

Run Support Cluster Design on this hub.

Use the source context first.

Design supporting pages that strengthen the hub.

Return the output with these fields:
- support page
- support function
- parent hub
- related sibling pages
- page role
- internal link direction
- priority
- brief route
- next workflow route

Flag support pages that add noise or overlap.

Flag support pages that should become sections.

Route the output into Publishing Order or Content Briefs.

Best for:

  • hub support
  • content gap repair
  • cluster planning
  • authority growth
  • editorial planning

Output should include:

  • support page
  • support function
  • parent hub
  • priority
  • next route

Use this to:

Build cluster support without expanding too far.

Support Cluster Design keeps depth focused around the hub.

28. Commercial Spine

Use this to connect structure to conversion.

Short command:

text

Run Commercial Spine on this map.

Expanded prompt:

text

Run Commercial Spine on this map.

Use the source context first.

Build the route from informational pages to use cases, product pages, pricing, proof, and contact pages.

Return the output with these fields:
- informational page
- bridge page
- use case page
- product page
- pricing or conversion page
- proof path
- internal link direction
- CTA route
- risk note
- next workflow route

Do not force conversion too early in educational pages.

Flag commercial gaps in the map.

Route the output into Internal Linking, Content Briefs, or Drafting and Rewriting.

Best for:

  • product led SEO
  • SaaS sites
  • service sites
  • comparison clusters
  • conversion path planning

Output should include:

  • informational page
  • bridge page
  • use case page
  • product page
  • proof path

Use this to:

Make topical authority support revenue paths.

The commercial spine shows how users move from education to product fit.

29. Semantic Site Architecture

Use this when the map needs meaning based structure.

Short command:

text

Run Semantic Site Architecture on this sitemap.

Expanded prompt:

text

Run Semantic Site Architecture on this sitemap.

Use the source context first.

Structure the site around topical relationships, user jobs, page roles, parent child topics, and internal link paths.

Return the output with these fields:
- site section
- hub
- spoke
- bridge
- support page
- conversion page
- relationship type
- internal link direction
- architecture risk
- next workflow route

Flag sections that lack a clear relationship.

Route the output into Processed Map Build or Map Approval.

Best for:

  • sitemap restructure
  • semantic SEO planning
  • topic clusters
  • navigation cleanup
  • internal link planning

Output should include:

  • site section
  • hub
  • spoke
  • relationship type
  • next route

Use this to:

Build clusters that hold their shape.

Semantic architecture supports meaning, hierarchy, and user movement.

30. Topic Scope Control

Use this when clusters are getting too broad.

Short command:

text

Run Topic Scope Control on this map.

Expanded prompt:

text

Run Topic Scope Control on this map.

Use the source context first.

Review every topic for scope fit.

Return the output with these fields:
- topic
- cluster
- source context fit
- boundary issue
- keep, narrow, merge, move, or block
- reason
- affected page
- next workflow route

Flag topics that weaken the cluster.

Flag topics that belong in a different map.

Route the output into Topic Governance, Topic Consolidation, or Map Approval.

Best for:

  • broad maps
  • large topic lists
  • site expansion
  • client sites
  • topic cleanup

Output should include:

  • topic
  • boundary issue
  • keep or block decision
  • affected page
  • next route

Use this to:

Keep pages focused and clusters clean.

Scope control prevents a map from expanding into unrelated areas.

31. Page Purpose Framework

Use this when pages need one clear job.

Short command:

text

Run Page Purpose Framework on this inventory.

Expanded prompt:

text

Run Page Purpose Framework on this inventory.

Use the source context first.

Give every page one clear purpose.

Return the output with these fields:
- page
- primary job
- secondary support job
- user need
- intent
- page role
- CTA route
- internal link direction
- next workflow route

Flag pages with too many jobs.

Flag pages with unclear user need.

Route the output into Content Briefs, Drafting and Rewriting, or Map Approval.

Best for:

  • page inventories
  • weak sites
  • map approval
  • rewrite planning
  • content brief prep

Output should include:

  • page
  • primary job
  • user need
  • CTA route
  • next route

Use this to:

Prevent pages from becoming mixed and unclear.

A page with one clear job is easier to brief, write, link, and review.

32. Duplicate Intent Detection

Use this when pages may compete.

Short command:

text

Run Duplicate Intent Detection on this page set.

Expanded prompt:

text

Run Duplicate Intent Detection on this page set.

Use the source context first.

Find pages or proposed pages with duplicate or near duplicate intent.

Return the output with these fields:
- page A
- page B
- shared intent
- difference if any
- overlap risk
- recommended action
- merge, split, keep, redirect, or block
- reason
- next workflow route

Flag pages that compete for the same query path.

Route the output into Cannibalization Prevention or Topic Consolidation.

Best for:

  • old blogs
  • large maps
  • site restructures
  • content refresh
  • proposed page queues

Output should include:

  • page pair
  • shared intent
  • overlap risk
  • action
  • next route

Use this to:

Stop overlapping pages before they compete.

Duplicate intent should be fixed before briefs begin.

33. Cannibalization Prevention

Use this before approving the map.

Short command:

text

Run Cannibalization Prevention on this map.

Expanded prompt:

text

Run Cannibalization Prevention on this map.

Use the source context first.

Review proposed pages for cannibalization risk.

Return the output with these fields:
- competing pages
- shared query or intent
- overlap type
- parent page
- canonical page
- merge note
- split note
- internal link fix
- next workflow route

Do not approve the map until competing page roles are clear.

Flag pages that need consolidation.

Route the output into Topic Consolidation, Page Purpose Framework, or Map Approval.

Best for:

  • map approval
  • content refresh
  • site restructure
  • keyword led planning
  • old content cleanup

Output should include:

  • competing pages
  • shared intent
  • canonical page
  • merge or split note
  • next route

Use this to:

Protect the map before production starts.

Cannibalization prevention gives every competing page a clear decision.

34. Topic Splitting

Use this when one topic needs more than one page.

Short command:

text

Run Topic Splitting on this topic.

Expanded prompt:

text

Run Topic Splitting on this topic.

Use the source context first.

Decide if one topic should split into multiple pages.

Return the output with these fields:
- original topic
- split pages
- distinct intent for each page
- user job for each page
- parent child relation
- internal link direction
- overlap risk
- next workflow route

Do not split a topic for minor wording differences.

Flag split pages that need separate briefs.

Route the output into Page Inventory or Content Briefs.

Best for:

  • broad topics
  • mixed intent pages
  • overloaded hubs
  • content refresh
  • page planning

Output should include:

  • original topic
  • split pages
  • distinct intent
  • parent child relation
  • next route

Use this to:

Give separate intents their own clear pages.

Topic splitting should create clarity, not extra pages for weak variants.

35. Topic Consolidation

Use this when pages should merge.

Short command:

text

Run Topic Consolidation on this page set.

Expanded prompt:

text

Run Topic Consolidation on this page set.

Use the source context first.

Identify pages, topics, or sections that should merge into one canonical page.

Return the output with these fields:
- source page
- target canonical page
- merge reason
- content to keep
- content to cut
- redirect note
- internal link update
- next workflow route

Flag consolidation risks.

Flag pages that need rewrite notes after merging.

Route the output into Drafting and Rewriting, Internal Linking, or Map Approval.

Best for:

  • old blogs
  • duplicate topics
  • content refresh
  • site restructure
  • cannibalization cleanup

Output should include:

  • source page
  • target page
  • merge reason
  • content to keep
  • next route

Use this to:

Merge overlap without losing useful intent.

Consolidation should preserve value while removing competition.

36. Semantic Overlap Review

Use this when related pages may blur together.

Short command:

text

Run Semantic Overlap Review on this cluster.

Expanded prompt:

text

Run Semantic Overlap Review on this cluster.

Use the source context first.

Review pages for semantic overlap, shared concepts, shared intent, and unclear boundaries.

Return the output with these fields:
- page pair
- shared concept
- distinct role if any
- overlap risk
- boundary fix
- internal link note
- next workflow route

Flag pages that need clearer purpose.

Route the output into Page Purpose Framework, Topic Consolidation, or Map Approval.

Best for:

  • semantic SEO clusters
  • large sites
  • product content
  • docs pages
  • comparison clusters

Output should include:

  • page pair
  • shared concept
  • overlap risk
  • boundary fix
  • next route

Use this to:

Keep related pages distinct.

Semantic overlap review helps MIRENA preserve topical depth without page conflict.

37. Publishing Order

Use this to prioritize production.

Short command:

text

Run Publishing Order on this map.

Expanded prompt:

text

Run Publishing Order on this map.

Use the source context first.

Set the publishing sequence for the map.

Return the output with these fields:
- priority
- page
- cluster
- page role
- dependency
- business value
- authority value
- link value
- effort
- next workflow route

Prioritize hubs, commercial routes, and pages needed before dependent pages.

Flag pages that should wait.

Route the output into Content Briefs or Map Approval.

Best for:

  • editorial planning
  • new site builds
  • cluster rollouts
  • content refresh
  • team handoff

Output should include:

  • priority
  • page
  • dependency
  • business value
  • next route

Use this to:

Roll out pages in the right sequence.

Publishing Order helps teams avoid producing pages before their support structure exists.

38. Topic Dependency Mapping

Use this to identify which pages must come first.

Short command:

text

Run Topic Dependencies on this map.

Expanded prompt:

text

Run Topic Dependencies on this map.

Use the source context first.

Map dependencies between topics, pages, hubs, spokes, docs, comparisons, and proof pages.

Return the output with these fields:
- dependent page
- required page
- dependency type
- reason
- publishing note
- internal link note
- next workflow route

Flag pages that should not be briefed yet.

Route the output into Publishing Order or Map Approval.

Best for:

  • page queues
  • docs clusters
  • complex maps
  • site restructure
  • publishing order

Output should include:

  • dependent page
  • required page
  • dependency type
  • publishing note
  • next route

Use this to:

Avoid publishing support pages before their parent pages exist.

Dependencies make the production plan more stable.

39. Sitewide Topic Priorities

Use this when the whole site needs order.

Short command:

text

Run Sitewide Topic Priorities on this site.

Expanded prompt:

text

Run Sitewide Topic Priorities on this site.

Use the source context first.

Prioritize sitewide topic areas by business value, authority need, link value, production effort, and workflow fit.

Return the output with these fields:
- topic area
- priority
- reason
- hub needed
- support pages needed
- commercial route
- risk note
- next workflow route

Flag topic areas that should wait.

Route the output into Publishing Order or Site Growth Model.

Best for:

  • full site planning
  • agency roadmaps
  • product sites
  • content programs
  • site expansion

Output should include:

  • topic area
  • priority
  • hub needed
  • commercial route
  • next route

Use this to:

Decide which clusters should come first.

Sitewide priorities help teams focus on the highest value areas.

40. Multi Audience Map

Use this when the site serves more than one audience.

Short command:

text

Run Multi Audience Map on this site.

Expanded prompt:

text

Run Multi Audience Map on this site.

Use the source context first.

Structure the site across audience groups without creating drift or duplicate pages.

Return the output with these fields:
- audience
- shared pages
- audience specific pages
- page role
- overlap risk
- internal link direction
- commercial route
- next workflow route

Flag pages that should serve multiple audiences through sections instead of separate URLs.

Flag audience pages that create duplicate intent.

Route the output into Page vs Section Decisions or Topic Governance.

Best for:

  • B2B sites
  • SaaS sites
  • agencies
  • publishers
  • multi segment products

Output should include:

  • audience
  • shared pages
  • audience pages
  • overlap risk
  • next route

Use this to:

Serve more than one audience without breaking structure.

Multi audience mapping prevents the site from creating duplicate pages for every segment.

41. Multi Product Map

Use this when the site has more than one product.

Short command:

text

Run Multi Product Map on this site.

Expanded prompt:

text

Run Multi Product Map on this site.

Use the source context first.

Structure pages across several products without overlap.

Return the output with these fields:
- product
- product hub
- shared support pages
- product specific pages
- comparison pages
- docs pages
- internal link direction
- risk note
- next workflow route

Flag topics that need one shared page instead of many product pages.

Flag product pages that compete for the same intent.

Route the output into Commercial Spine or Topic Governance.

Best for:

  • SaaS platforms
  • product suites
  • ecommerce categories
  • service lines
  • software comparison sites

Output should include:

  • product
  • product hub
  • shared support pages
  • risk note
  • next route

Use this to:

Keep multi product structure clean.

This module helps MIRENA separate shared support topics from product specific pages.

42. Site Merger Map

Use this when two sites or sections need to combine.

Short command:

text

Run Site Merger Map on these inventories.

Expanded prompt:

text

Run Site Merger Map on these inventories.

Use the source context first.

Combine page inventories without topic collisions.

Return the output with these fields:
- source page
- target page
- keep, merge, redirect, rewrite, or block
- reason
- cluster destination
- internal link update
- risk note
- next workflow route

Flag duplicate intent.

Flag pages that should be protected.

Route the output into Topic Consolidation, Publishing Order, or Drafting and Rewriting.

Best for:

  • site migrations
  • brand mergers
  • content consolidation
  • multiple blogs
  • taxonomy cleanup

Output should include:

  • source page
  • target page
  • action
  • cluster destination
  • next route

Use this to:

Combine structures without creating duplicate intent.

A merger map should protect valuable pages while removing overlap.

43. Legacy Site Map

Use this when an older site needs a clean structure.

Short command:

text

Run Legacy Site Map on this sitemap.

Expanded prompt:

text

Run Legacy Site Map on this sitemap.

Use the source context first.

Rebuild the old site structure into a cleaner topical map.

Return the output with these fields:
- existing page
- new role
- keep, merge, rewrite, redirect, or block
- new cluster
- parent page
- internal link update
- priority
- next workflow route

Flag pages with outdated roles.

Flag pages that no longer fit source context.

Route the output into Content Refresh, Drafting and Rewriting, or Map Approval.

Best for:

  • older sites
  • blog cleanup
  • site restructure
  • SEO recovery
  • content refresh programs

Output should include:

  • existing page
  • new role
  • action
  • new cluster
  • next route

Use this to:

Restructure a site without starting over.

Legacy Site Map helps turn old content into a cleaner architecture.

44. Site Growth Model

Use this to plan future expansion.

Short command:

text

Run Site Growth Model on this cluster.

Expanded prompt:

text

Run Site Growth Model on this cluster.

Use the source context first.

Plan how the cluster should expand over time.

Return the output with these fields:
- current hub
- current support pages
- next pages
- later pages
- blocked pages
- dependency notes
- publishing order
- internal link direction
- next workflow route

Do not expand into topics that weaken source context.

Flag pages that need more evidence before entry.

Route the output into Publishing Order or Topic Governance.

Best for:

  • long term SEO plans
  • cluster expansion
  • product roadmaps
  • editorial roadmaps
  • site growth planning

Output should include:

  • current hub
  • next pages
  • later pages
  • blocked pages
  • next route

Use this to:

Scale clusters without losing structure.

Site Growth Model keeps expansion tied to source context.

45. Templates and Examples Plan

Use this when reusable assets should support the map.

Short command:

text

Run Templates and Examples Plan on this cluster.

Expanded prompt:

text

Run Templates and Examples Plan on this cluster.

Use the source context first.

Identify templates, examples, checklists, calculators, prompt packs, and copyable assets that should support the cluster.

Return the output with these fields:
- asset type
- target page
- supported cluster
- user job
- internal link direction
- lead value
- production priority
- next workflow route

Flag assets that are not tied to a clear page or user job.

Route the output into Content Briefs or Publishing Order.

Best for:

  • template hubs
  • examples pages
  • lead magnets
  • documentation
  • content support assets

Output should include:

  • asset type
  • target page
  • user job
  • production priority
  • next route

Use this to:

Add reusable assets that strengthen the cluster.

Templates and examples should support user action, not sit apart from the map.

46. Topic Coverage Score

Use this to grade cluster strength.

Short command:

text

Run Topic Coverage Score on this cluster.

Expanded prompt:

text

Run Topic Coverage Score on this cluster.

Use the source context first.

Score cluster strength.

Return the output with these fields:
- cluster
- hub strength
- support depth
- role clarity
- overlap risk
- missing pages
- link coverage
- commercial route
- score
- priority fixes
- next workflow route

Flag weak hubs.

Flag missing support pages.

Route the output into Cluster Health Check, Topical Map Audit, or Map Refresh.

Best for:

  • cluster QA
  • map approval
  • content audits
  • site refresh
  • editorial planning

Output should include:

  • score
  • hub strength
  • support depth
  • overlap risk
  • priority fixes

Use this to:

Measure cluster strength before production or refresh.

Topic Coverage Score helps teams see if a cluster is ready, thin, crowded, or missing support.

47. Cluster Health Check

Use this before the cluster breaks.

Short command:

text

Run Cluster Health Check on this page set.

Expanded prompt:

text

Run Cluster Health Check on this page set.

Use the source context first.

Review the cluster for weak hubs, unsupported spokes, overlap, missing bridge pages, weak conversion routes, poor link direction, and unclear page roles.

Return the output with these fields:
- cluster issue
- affected page
- severity
- fix
- owner workflow
- priority
- next workflow route

Flag urgent fixes.

Flag pages that should not move into briefs yet.

Route the output into Topical Map Audit, Map Refresh, or Internal Linking.

Best for:

  • live clusters
  • content refresh
  • site audits
  • internal link repair
  • map approval

Output should include:

  • issue
  • affected page
  • severity
  • fix
  • next route

Use this to:

Find weak points before production scales.

Cluster Health Check keeps the map from hiding structural problems.

48. Topical Map Audit

Use this to review the map before action.

Short command:

text

Run Topical Map Audit on this sitemap.

Expanded prompt:

text

Run Topical Map Audit on this sitemap.

Use the source context first.

Audit the topical map for gaps, overlap, drift, weak hubs, missing support, unclear page roles, poor publishing order, and weak internal routes.

Return the output with these fields:
- issue
- affected page
- affected cluster
- severity
- recommended fix
- merge, split, rewrite, brief, link, block, or publish
- next workflow route

Flag high risk map issues.

Flag issues that block production.

Route the output into Map Refresh, Content Briefs, Drafting and Rewriting, or Internal Linking.

Best for:

  • site audits
  • sitemap reviews
  • content refresh
  • SEO roadmaps
  • map approval

Output should include:

  • issue
  • affected page
  • severity
  • recommended fix
  • next route

Use this to:

Find structural problems before downstream work begins.

A map audit should come before large scale briefing or rewriting.

49. Map Refresh

Use this when a topical map needs updating.

Short command:

text

Run Map Refresh on this topical map.

Expanded prompt:

text

Run Map Refresh on this topical map.

Use the source context first.

Update the map using new pages, search data, performance signals, content changes, competitor changes, and business priorities.

Return the output with these fields:
- page or topic
- current role
- new role
- keep, refresh, merge, split, block, or publish
- reason
- link update
- brief route
- next workflow route

Flag pages that have drifted.

Flag pages that need a rewrite before link updates.

Route the output into Content Briefs, Drafting and Rewriting, Internal Linking, or Map Approval.

Best for:

  • older maps
  • content refresh
  • site growth
  • performance review
  • page queue cleanup

Output should include:

  • page or topic
  • current role
  • new role
  • action
  • next route

Use this to:

Update the map without breaking structure.

Map Refresh helps new data enter the architecture safely.

50. Topic Governance

Use this to define long term rules.

Short command:

text

Run Topic Governance on this page queue.

Expanded prompt:

text

Run Topic Governance on this page queue.

Use the source context first.

Create rules for adding, blocking, merging, refreshing, linking, and retiring pages.

Return the output with these fields:
- governance rule
- applies to
- decision threshold
- review trigger
- blocked topic rule
- merge rule
- refresh rule
- link rule
- approval owner
- next workflow route

Flag rules that need human approval.

Route the output into Map Approval or Master Context Update.

Best for:

  • growing sites
  • editorial teams
  • agency delivery
  • enterprise content programs
  • recurring refresh cycles

Output should include:

  • governance rule
  • decision threshold
  • review trigger
  • approval owner
  • next route

Use this to:

Keep the site structure clear as it grows.

Topic Governance gives the team rules for adding, blocking, merging, refreshing, and retiring pages.

51. Map Approval

Use this when the map is ready for review.

Short command:

text

Run Map Approval on this topical map.

Expanded prompt:

text

Run Map Approval on this topical map.

Use the source context first.

Review the map before production starts.

Return the output with these fields:
- approved pages
- review needed pages
- blocked pages
- pages to merge
- pages to split
- pages to brief
- pages to rewrite
- internal link notes
- publishing order
- approval notes
- next workflow route

Do not approve pages with unclear roles, duplicate intent, or weak source context fit.

Route approved pages into Content Briefs, Drafting and Rewriting, or Internal Linking.

Best for:

  • final map review
  • editorial handoff
  • agency delivery
  • production planning
  • client approval

Output should include:

  • approved pages
  • review needed pages
  • blocked pages
  • publishing order
  • next route

Use this to:

Create the final check before briefs and production.

Map Approval keeps unready pages from moving downstream.

52. Map Handoff

Use this to route the approved map downstream.

Short command:

text

Run Map Handoff for this approved topical map.

Expanded prompt:

text

Run Map Handoff for this approved topical map.

Use the source context first.

Route each approved item into the right next workflow.

Return the output with these fields:
- page
- cluster
- page role
- next workflow route
- content brief route
- rewrite route
- internal link route
- information gain route
- schema cue route after approval
- owner note
- handoff note

Do not leave approved pages without a next workflow route.

Return a clean production handoff package.

Best for:

  • approved maps
  • team handoff
  • production planning
  • content brief queues
  • refresh queues

Output should include:

  • page
  • cluster
  • page role
  • next workflow route
  • handoff note

Use this to:

Move the approved map into briefs, rewrites, links, information gain, and publishing.

A map is not complete until every approved page has a next route.

Which Topical Mapping Module Should You Run First?

Start with Map Scope if the boundary is unclear.

Start with Map Goal if the site needs a clear reason for the map.

Start with Topic Inventory if raw discovery output already exists.

Start with Processed Map Build if topics are approved and ready for structure.

Start with Page Inventory if you need a production page queue.

Start with Page Role Assignment if the page list exists but page jobs are unclear.

Start with Page vs Section Decisions if the map is creating too many URLs.

Start with Duplicate Intent Detection if the site already has overlap.

Start with Topical Map Audit if the sitemap exists and needs review.

Start with Map Handoff if the map is approved and ready for production.

Common Topical Mapping Starting Points

I Have Raw Discovery Output

Start with Topic Inventory.

Prompt:

text

Run Topic Inventory on this discovery package.

Use the source context first.

Turn accepted discovery findings into a topic inventory.

Return the output with these fields:
- topic
- source evidence
- source context fit
- likely cluster
- likely page role
- intent signal
- support needed
- keep, merge, section, or block
- reason
- next workflow route

Do not build the final map yet.

Then run:

text

Build a Processed Topical Map from this topic inventory.

Use the source context first.

Use raw discovery output only as evidence.

Return clusters, hub pages, support pages, bridge pages, comparison pages, docs pages, conversion pages, page roles, page vs section decisions, overlap warnings, consolidation notes, internal link direction, publishing priority, and next workflow routes.

Do not include topics that fail source context fit.

Then run:

text

Run Map Approval on this topical map.

Use the source context first.

Return approved pages, review needed pages, blocked pages, pages to merge, pages to split, pages to brief, pages to rewrite, internal link notes, publishing order, approval notes, and next workflow routes.

Do not approve pages with unclear roles, duplicate intent, or weak source context fit.

Route approved pages into Content Briefs, Drafting + Rewriting, or semantic internal linking.

I Have a Sitemap

Start with Topical Map Audit.

Prompt:

text

Run Topical Map Audit on this sitemap.

Use the source context first.

Audit the topical map for gaps, overlap, drift, weak hubs, missing support, unclear page roles, poor publishing order, and weak internal routes.

Return issues, affected pages, affected clusters, severity, recommended fixes, action type, and next workflow routes.

Then run:

text

Run Page Role Assignment on this page inventory.

Use the source context first.

Assign one primary role to every page.

Return page role, role reason, parent cluster, user job, intent, internal link direction, CTA route, review risk, and next workflow route.

Flag pages with unclear roles.

Then run:

text

Run Topic Consolidation on this page set.

Use the source context first.

Identify pages, topics, or sections that should merge into one canonical page.

Return source page, target canonical page, merge reason, content to keep, content to cut, redirect note, internal link update, and next workflow route.

Route the output into map refresh, content refresh, or rewrites.

I Have a Keyword Export

Start with Page vs Section Decisions after discovery and query intent classification.

Prompt:

text

Run Page vs Section on this cluster.

Use the source context first.

Decide if each topic needs its own page or should live inside another page.

Return topic, candidate page, parent page, query intent, depth needed, SERP format signal, internal link need, page decision, section decision, reason, and next workflow route.

Use standalone pages only when the topic has enough intent, depth, and source context fit.

Then run:

text

Run Query Consolidation on this query group.

Use the source context first.

Decide which similar queries should be consolidated into one canonical page.

Return query group, shared intent, canonical page target, section targets, FAQ targets, anchor targets, queries to merge, queries to block, reason, and next workflow route.

Then run:

text

Build a Processed Topical Map from this topic inventory.

Use the source context first.

Return clusters, hubs, support pages, bridge pages, comparison pages, docs pages, conversion pages, page roles, page vs section decisions, overlap warnings, internal link direction, publishing priority, and next workflow route.

Route the output into Topical Maps + Planning and then Content Briefs.

I Need a Hub and Spoke Plan

Start with Authority Hub Planning.

Prompt:

text

Run Authority Hub Planning on this topic.

Use the source context first.

Define the hub page and the supporting pages needed to strengthen it.

Return authority hub, hub purpose, supporting pages, bridge pages, proof pages, internal link direction, publishing priority, gap notes, and next workflow route.

Do not create a hub if the topic is outside source context.

Then run:

text

Run Spoke Page Design for this cluster.

Use the source context first.

Plan each spoke page that supports the hub.

Return spoke page, parent hub, page role, target intent, support topic, depth needed, internal link back to hub, sibling link direction, CTA route, and next workflow route.

Flag spokes that should merge into the hub.

Then run:

text

Run Cluster Hierarchy on this map.

Use the source context first.

Return cluster, parent node, child nodes, sibling pages, bridge pages, support pages, proof pages, conversion pages, depth level, link direction, and next workflow route.

Route the output into briefs and internal links.

I Need a Site Restructure

Start with Legacy Site Map or Site Merger Map.

Prompt:

text

Run Legacy Site Map on this sitemap.

Use the source context first.

Rebuild the old site structure into a cleaner topical map.

Return existing page, new role, keep, merge, rewrite, redirect, or block decision, new cluster, parent page, internal link update, priority, and next workflow route.

Flag pages that no longer fit source context.

Then run:

text

Run Semantic Site Architecture on this sitemap.

Use the source context first.

Structure the site around topical relationships, user jobs, page roles, parent child topics, and internal link paths.

Return site section, hub, spoke, bridge, support page, conversion page, relationship type, internal link direction, architecture risk, and next workflow route.

Then run:

text

Run Map Approval on this topical map.

Use the source context first.

Review the map before production starts.

Return approved pages, review needed pages, blocked pages, pages to merge, pages to split, pages to brief, pages to rewrite, internal link notes, publishing order, approval notes, and next workflow routes.

Route the output into content refresh, rewrites, and internal linking.

I Need a Docs Architecture

Start with Docs Cluster Planning.

Prompt:

text

Run Docs Cluster Planning for this product.

Use the source context first.

Build a documentation cluster around user onboarding, product actions, inputs, outputs, workflows, troubleshooting, and handoffs.

Return docs hub, docs pages, user tasks, page roles, sequence, support paths, internal link direction, and next workflow route.

Flag docs pages that belong in support, templates, or examples.

Then run:

text

Run Topic Dependency Mapping on this map.

Use the source context first.

Map dependencies between topics, pages, hubs, spokes, docs, comparisons, and proof pages.

Return dependent page, required page, dependency type, reason, publishing note, internal link note, and next workflow route.

Then run:

text

Run Publishing Order on this map.

Use the source context first.

Set the publishing sequence for the map.

Return priority, page, cluster, page role, dependency, business value, authority value, link value, effort, and next workflow route.

Route the output into docs briefs and drafting.

I Need a Comparison Cluster

Start with Compare Cluster Planning.

Prompt:

text

Run Compare Cluster Planning for this product.

Use the source context first.

Plan comparison pages and their relationship to product, pricing, use cases, proof, and alternatives.

Return comparison hub, comparison page, competitor or alternative, buyer question, proof need, table need, conversion route, internal link direction, and next workflow route.

Do not create comparison pages without a product route.

Then run:

text

Run Commercial Spine on this map.

Use the source context first.

Build the route from informational pages to use cases, product pages, pricing, proof, and contact pages.

Return informational page, bridge page, use case page, product page, pricing or conversion page, proof path, internal link direction, CTA route, risk note, and next workflow route.

Then run:

text

Run Map Handoff for this approved topical map.

Use the source context first.

Route each approved item into the right next workflow.

Return page, cluster, page role, next workflow route, content brief route, rewrite route, internal link route, information gain route, schema cue route after approval, owner note, and handoff note.

Route the output into information gain work and Content Briefs.

Output Review Checklist for Topical Mapping

Before moving downstream, check the topical map for:

  • source context fit
  • clear map scope
  • clear map goal
  • approved topic inventory
  • clean page inventory
  • page role for every page
  • hub pages
  • spoke pages
  • support pages
  • bridge pages
  • proof pages
  • conversion pages
  • docs pages
  • comparison pages
  • page vs section decisions
  • duplicate intent warnings
  • cannibalization warnings
  • topic split decisions
  • topic consolidation decisions
  • publishing order
  • internal link direction
  • cluster health notes
  • topic governance rules
  • map approval status
  • downstream workflow routes

Do not move into content briefs, drafting, rewriting, internal links, or schema if the map still contains unclear roles, duplicate intent, weak source context fit, or unapproved pages.

How Topical Mapping Connects to Other MIRENA Workflows

Topical Mapping and Site Architecture is the structure layer.

It feeds other workflows but does not replace them.

An approved page inventory can feed Content Briefs when the next job is writer instruction.

A map with existing weak URLs can feed Drafting + Rewriting when the next job is page repair.

A cluster hierarchy can feed semantic internal linking when the next job is route building.

A comparison or SERP heavy cluster can feed information gain work when the next job is useful differentiation.

A map can feed Semantic SEO when the next job is meaning, topic fit, and coverage.

A map can feed Entity SEO when the next job is entity structure for a page or cluster.

Use MIRENA workflow when you need to decide the next route. Use MIRENA outputs when the map needs to follow a set handoff format.

Topical Mapping Mistakes to Avoid

Mistake 1: Mapping Without Source Context

Do not create a map from keywords alone.

Source context tells MIRENA which topics belong, which topics should be blocked, and which pages support the site’s offer.

Mistake 2: Turning Every Topic Into a Page

Not every topic needs a URL.

Use Page vs Section Decisions, Query Granularity, and Query Consolidation before creating new pages.

Mistake 3: Ignoring Page Roles

A map without page roles is not ready for production.

Every page should have a job: hub, spoke, support, bridge, proof, docs, comparison, use case, template, example, or conversion.

Mistake 4: Skipping Overlap Review

Duplicate intent creates weak architecture.

Run Duplicate Intent Detection, Cannibalization Prevention, Topic Consolidation, and Semantic Overlap Review before map approval.

Mistake 5: Publishing in the Wrong Order

Some pages need parent pages, hubs, proof pages, or support pages first.

Use Topic Dependency Mapping and Publishing Order before moving into briefs.

Mistake 6: Treating a Map as a Static File

A topical map should change when source context, search data, site content, product priorities, or performance signals change.

Use Map Refresh and Topic Governance to keep the structure clean over time.

Mistake 7: Leaving the Map Without a Handoff

A map is not complete until each approved page has a next route.

Use Map Handoff to move pages into briefs, rewrites, internal links, information gain, or schema cues after approval.

FAQs About Topical Mapping and Site Architecture Prompts in MIRENA

What is Topical Mapping and Site Architecture in MIRENA?

Topical Mapping and Site Architecture is the workflow that turns source context and selected evidence into a governed site structure.

It decides pages, sections, roles, hierarchy, internal link direction, publishing order, overlap controls, and handoff routes.

What should I run first?

Start with Map Scope if the project boundary is unclear.

Start with Map Goal if the reason for the map is unclear.

Start with Topic Inventory if raw discovery output already exists.

Start with Topical Map Audit if you have a live sitemap that needs review.

Is Topical Mapping the same as Raw Semantic Discovery?

No.

Raw Semantic Discovery collects evidence.

Topical Mapping and Site Architecture turns selected evidence into structure.

Is Topical Mapping the same as Entity SEO?

No.

Topical Mapping decides page architecture.

Entity SEO structures entity meaning, salience, relationships, and support signals inside or across pages.

Can I build a topical map from a keyword export?

Yes, but do not turn every keyword into a page.

Use source context, query intent labels, Query Granularity, Query Consolidation, and Page vs Section Decisions before building the processed map.

Can I use a sitemap with this workflow?

Yes.

Use Topical Map Audit, Page Role Assignment, Duplicate Intent Detection, Topic Consolidation, and Map Refresh when working from a sitemap.

Can this workflow help with internal links?

Yes.

Cluster hierarchy, page roles, bridge pages, support pages, and commercial routes can all feed semantic internal linking.

Can this workflow help with content briefs?

Yes.

Approved pages from the map should move into Content Briefs with page role, intent, parent page, support pages, internal link direction, and publishing priority.

Can this workflow help with rewrites?

Yes.

A map audit can identify pages to rewrite, merge, split, block, or refresh. Those pages can then move into Drafting + Rewriting.

What does Map Approval do?

Map Approval checks the topical map before production starts.

It separates approved pages from review needed pages, blocked pages, pages to merge, pages to split, pages to brief, pages to rewrite, and pages needing internal link review.

What should I do after Topical Mapping?

Move the output into the correct next workflow.

Use Content Briefs when approved pages need writer instructions.

Use Drafting + Rewriting when existing pages need repair.

Use semantic internal linking when the next job is route building.

Use information gain work when repeated SERP coverage or weak differentiation appears.

Use schema cues only after a page draft is approved.

Written by

Kevin Maguire

in