Build a processed topical map through 15 gated stages.
The full MIRENA topical map process routes the task, checks source context and evidence, assigns page ownership and routes, adds user movement, runs Map QA, records approval, and creates a controlled handoff.
The eight-stage model on the definition page is the summary. This page expands it into the production gates a team needs before briefs, drafts, redirects, schema cues, or publication begin.
- Source context before discovery
- One canonical owner per need
- Map QA before approval
- Approval before handoff
Map Build Route Planner
Check the intake before opening the full build.
- No blocking readiness item was found in this intake.
Run Topical Mapping Route for Semantec SEO topical mapping.
Five phases keep the map from turning into an unchecked page list.
Each phase closes a different risk before the next one begins.
Route and qualify the work
Choose the route, confirm source context, and check whether the evidence is ready.
Open this phase →Model the topic territory
Collect raw evidence, then group candidate needs without creating pages too early.
Open this phase →Make architecture decisions
Assign ownership, page homes, roles, decision states, and dependency rules.
Open this phase →Plan routes and behavior
Add internal routes, user movement, trust, effort, ownership, and publishing waves.
Open this phase →Review, approve, and learn
Run Map QA, record approval, build the handoff, and revise the map from live signals.
Open this phase →The eight-stage summary maps to the 15-stage production process.
The definition page stays easy to scan. The full process adds routing, evidence, ownership, QA, approval, and handoff controls.
| Eight-stage summary | Full build stages |
|---|---|
| Eight-stage summary | Full build stages |
| Set source context | 01 Route, 02 Context, 03 Evidence |
| Find topic territory | 04 Raw discovery |
| Group related needs | 05 Candidate groups |
| Decide page homes | 06 Ownership, 07 Roles, 08 Overlap |
| Plan internal routes | 09 Semantic routes |
| Add the user path | 10 Behavioral layer |
| Review and approve | 11 Waves, 12 QA, 13 Approval, 14 Handoff |
| Read live signals | 15 Refresh |
Open each stage to see its inputs, return fields, and stop condition.
A stage does not pass merely because work was produced. It passes when its required decision is clear enough for the next stage.
Route and qualify the work
Choose the route, confirm source context, and check whether the evidence is ready.
01 Route the task Choose the correct MIRENA workflow before topical mapping begins. Gate
Inputs
- current request
- project state
- available files
- requested output
Return
- selected route
- route confidence
- readiness state
- blockers
- stop conditions
- next safe action
02 Confirm source context Lock the site purpose, audience, offer, allowed territory, blocked territory, and existing structure. Gate
Inputs
- site or project identity
- audience
- offer
- topic boundaries
- commercial and support paths
Return
- approved source context
- scope boundary
- blocked topics
- existing-page context
03 Review evidence readiness Check source quality, dates, privacy state, relevance, and field completeness. Gate
Inputs
- sitemap or URL list
- keyword export
- SERP notes
- analytics
- page inventory
- research files
Return
- evidence state
- usable inputs
- held inputs
- missing fields
- risk note
Model the topic territory
Collect raw evidence, then group candidate needs without creating pages too early.
04 Build the raw discovery set Collect topic, query, entity, attribute, page, and result-pattern evidence. Gate
Inputs
- approved source context
- ready evidence
- seed topic or site inventory
Return
- raw topic set
- query candidates
- entity-attribute set
- current URL set
- gap notes
05 Group candidate needs Group evidence by user need, intent, entity relationship, and likely answer form. Gate
Inputs
- raw discovery set
- query patterns
- SERP and page evidence
Return
- candidate groups
- dominant intent
- supporting intent
- answer-form cues
- uncertain groups
Make architecture decisions
Assign ownership, page homes, roles, decision states, and dependency rules.
06 Decide page ownership Choose one canonical owner for each distinct need. Gate
Inputs
- candidate groups
- current URLs
- topic boundaries
- granularity evidence
Return
- page or content-block decision
- canonical owner
- keep, merge, split, hold, or block state
07 Assign roles and homes Give each approved page a role, URL, parent, content type, and cluster position. Gate
Inputs
- approved page candidates
- site architecture
- conversion and support paths
Return
- page role
- cluster role
- target URL
- parent page
- template or page type
08 Resolve overlap and dependencies Find duplicate intent, mixed ownership, missing prerequisites, and pages that need a merge or split. Gate
Inputs
- page inventory
- page roles
- candidate groups
- current and proposed URLs
Return
- overlap log
- merge and split actions
- dependency map
- blocked ideas
- redirect holds
Plan routes and behavior
Add internal routes, user movement, trust, effort, ownership, and publishing waves.
09 Plan semantic routes Assign parent, child, sibling, proof, support, recovery, and action paths. Gate
Inputs
- approved pages
- roles
- dependencies
- site navigation
Return
- route map
- internal-link role
- anchor direction
- next page
- fallback path
10 Add the behavioral layer Attach user state, journey stage, friction, trust, effort, CTA timing, and a satisfaction signal. Gate
Inputs
- page role
- entry context
- route map
- proof and support assets
Return
- user state
- journey stage
- friction
- trust need
- effort score
- CTA direction
- refresh trigger
11 Set waves and ownership Put the map into a build sequence with owners, dependencies, review states, and release waves. Gate
Inputs
- approved architecture
- route dependencies
- team capacity
- business priority
Return
- publishing wave
- priority
- owner
- status
- required predecessor
- held action
Review, approve, and learn
Run Map QA, record approval, build the handoff, and revise the map from live signals.
12 Run Map QA Check context, evidence, ownership, overlap, roles, routes, behavior, and output completeness. Gate
Inputs
- processed map
- source context
- evidence log
- route map
- behavioral fields
Return
- passed checks
- review items
- blocked items
- required repairs
- QA decision
13 Record Map Approval Record the human decision, approver, date, held items, and changes required before downstream work. Gate
Inputs
- QA result
- processed map
- risk log
- stakeholder review
Return
- approval state
- approved rows
- held rows
- blocked rows
- approval note
- approval date
14 Build the downstream handoff Send approved page targets into briefing, rewriting, internal linking, or another named route. Gate
Inputs
- approved page row
- route and behavior fields
- proof needs
- content support needs
Return
- selected downstream workflow
- required handoff inputs
- held schema cues
- next task
- owner
15 Read live signals and refresh Use route use, proof use, task completion, return to search, and support demand to test the map. Gate
Inputs
- published routes
- analytics and support signals
- search and conversion observations
Return
- signal result
- challenged assumption
- refresh action
- priority
- new review state
Every proposed page receives a clear state.
These states stop raw ideas from entering production as if they were approved pages.
Keep
The page owns a distinct need, role, and route.
Merge
Two ideas serve the same job and need one canonical owner.
Split
One proposed page contains distinct needs that need separate homes.
Hold
The idea may fit, but evidence, route, proof, or timing is not ready.
Block
The idea conflicts with source context, duplicates another owner, or has no useful route.
Track the build without skipping the gates.
The checklist is a working aid. A checked box does not replace the stage output, QA record, or human approval.
0 of 15 stages marked complete
A processed map row must carry enough data for the next workflow.
The map is not finished when it has topic names. It is finished when ownership, routes, behavior, operations, and approval are recorded.
Identity and evidence
Project, topic, query group, entity set, current URL, evidence source, evidence date, and source-context state.
Architecture
Page or content block, canonical owner, decision state, role, cluster role, target URL, parent, and dependency.
Routes and behavior
Parent, child, sibling, proof, support, recovery, action, user state, journey, friction, trust, effort, and CTA direction.
Control and handoff
Wave, priority, owner, QA state, approval state, approval date, handoff route, schema state, status, and refresh trigger.
| Field group | Required decision | Example |
|---|---|---|
| Page ownership | One canonical owner and one decision state | Keep · `/coffee-brewing/` |
| Page role | One primary page job | Hub |
| Route set | Useful next, proof, support, recovery, and action paths | Beginner setup → method page → support route |
| Behavior | User state, journey stage, friction, trust, and effort | Beginner · Orientation · Choice overload |
| Release control | Wave, owner, QA, approval, and handoff | Wave 1 · Approved · Content Brief Route |
| Live review | Satisfaction signal and refresh trigger | Useful child-page continuation · repeated site search |
The input changes the first pass, not the need for context.
| Starting point | Best use | Add before approval |
|---|---|---|
| Topic or niche | New site or new subject area | Offer, audience, allowed territory, blocked territory, and expected routes |
| Sitemap or URL list | Existing architecture | Page titles, known priorities, conversion pages, support pages, and problem notes |
| Live site | Full architecture review | Source context, page inventory, crawl date, proof routes, and business priorities |
| Keyword or SERP export | Discovery and query evidence | Evidence date, current URL ownership, source quality, and overlap review |
| Page inventory | Repair, migration, or consolidation | Traffic role, conversion role, redirect holds, and current page quality notes |
The map controls the next task. It does not start it silently.
Map QA
Checks the architecture before a stakeholder decision.
- Context and evidence
- Ownership and overlap
- Roles, routes, and behavior
- Output completeness
Map Approval
Records approved, held, blocked, and returned rows.
- Approver and date
- Remaining risk
- Required repair
- Allowed next route
Named handoff
Sends one approved target into the correct workflow.
- Content Brief Route
- Rewrite Route
- Internal Link Route
- Schema cues held until copy approval
Human review stays in control of scope, evidence, approval, and publication.
Input responsibility
Do not submit personal, confidential, regulated, or sensitive material without permission. Review the privacy policy and acceptable use policy.
Output responsibility
MIRENA output is working material. Review page ownership, links, claims, redirects, content support, and release effects before acting.
Schema boundary
The map may record schema cues. Final markup follows approved visible copy. Review the output documentation and legal disclaimer.
MIRENA topical map process FAQ
What is the full MIRENA topical map process?
It is a gated planning sequence that routes the task, confirms source context, checks evidence, builds discovery groups, assigns page ownership and roles, plans routes and behavior, runs Map QA, records approval, creates a handoff, and reads live signals after publication.
What must be ready before topical mapping starts?
The project needs an approved source context, a clear site purpose and audience, a known subject boundary, and evidence whose source, date, privacy state, and relevance have been checked.
Can MIRENA start from one topic or niche?
Yes. A seed topic can begin discovery for a new site or subject area. Add the offer, audience, allowed territory, blocked territory, and expected commercial or support path before the map is approved.
How does MIRENA decide between a page and a content block?
A topic gets its own page when it serves a distinct need, has enough useful depth, owns a clear role, has a clean route, and differs from nearby pages. Close variants with the same job belong under one owner.
Where do behavioral fields enter the process?
They enter after page roles and semantic routes are stable. Each important page then receives a user state, journey stage, friction point, trust need, effort score, next path, fallback path, CTA direction, satisfaction signal, and refresh trigger.
What does Map QA check?
Map QA checks source-context fit, evidence readiness, page ownership, overlap, role clarity, route completeness, behavioral fields, publishing dependencies, output completeness, and unresolved risk.
What is Map Approval?
Map Approval is the recorded human decision that marks rows approved, held, blocked, or returned for repair. It also records the approver, date, remaining risk, and downstream route.
When can content briefing start?
Briefing starts only after the target page row passes Map QA and receives approval. The handoff should include page purpose, role, intent, entities, routes, proof needs, user state, CTA timing, and required content components.
Can MIRENA build a processed map from a sitemap?
Yes, but a sitemap alone does not explain the offer, audience, topic boundaries, proof routes, page quality, or user path. Add source context and any useful inventory, research, analytics, or problem notes before approval.
What happens after the map is published?
The map enters a review loop. Route use, proof use, task completion, return to search, support demand, and conversion behavior can confirm or challenge the planned structure and create a refresh task.
Start with the route and finish with an approved handoff.
Supply the current task, source context, site state, and ready evidence. MIRENA can then build page ownership, roles, routes, waves, QA, approval, and the next named task.