Focused entity support assets · Entity SEO

Entity support pages strengthen a hub by owning one focused reader task the hub should not carry in full.

MIRENA starts with the central entity and hub job, maps the reader tasks around it, compares the current page inventory, tests each support candidate for distinct intent, depth, overlap, evidence, and route value, then creates, keeps, merges, refreshes, routes, rejects, or holds the candidate.

Method by Kevin Maguire

Understand the distinction See how MIRENA runs it

8 classifications6 MIRENA stages8 review dimensions8 production actions

CenterOne clear entity or asset jobThe subject and reader task that control the review

SupportOnly relevant meaningAttributes, relationships, examples, evidence, and routes

DecisionA visible ownership boundaryKeep, move, route, split, remove, or hold

OutputA controlled handoffBrief, rewrite, map, link, schema cue, or review state

Definition and evidence boundary

Entity Support Pages is an editorial and structural model with a clear evidence boundary.

A support page should deepen the central entity from one clear angle, remain distinct from the hub and siblings, and connect back into the cluster through a useful internal route.

Hub boundary

The hub should orient and route rather than absorb every task

Support pages carry the depth that would otherwise make the hub crowded or unfocused.

Distinct ownership

A support page needs one query, entity angle, task, and canonical role

The candidate should not duplicate the hub or another sibling.

MIRENA rule

No support page is approved without an internal route

The hub and related siblings should reveal why the support page exists and when the reader needs it.

Evidence boundary: Google Search guidance emphasizes helpful content and crawlable descriptive links, but it does not require a support page for every query variation. MIRENA uses support page planning as an editorial and information architecture method tied to distinct intent, depth, evidence, ownership, and reader value.

Google helpful content guidance Google link best practices Google structured data introduction Google Cloud entity analysis Schema.org data model

MIRENA internal workflow

MIRENA selects and plans entity support pages through six wide workflow stages.

The workflow prevents page count expansion, thin modifier pages, hub duplication, sibling overlap, orphan assets, and support candidates approved before evidence and ownership are ready.

Confirm the central entity and hub job

MIRENA fixes the audience, source context, broad reader journey, protected pages, approved offer routes, and hub ownership.

Map the support task candidates

Definitions, attributes, relationships, comparisons, processes, use cases, questions, audits, evidence, and workflow tasks are collected.

Audit the current page inventory

Existing hubs, siblings, thin pages, overlaps, orphan assets, route gaps, and support depth are recorded.

Validate distinct intent, depth, and evidence

Each candidate is checked for user task, query difference, approved material, overlap, cluster value, business value, and effort.

Choose page role and internal route

MIRENA assigns keep on hub, existing owner, new support page, merge, split, refresh, reject, or hold status.

Create the support page handoff

The approved asset receives page job, entity hierarchy, section roles, sources, links, build priority, owner, and review state.

Eight entity support page types

Focused support can define, qualify, compare, sequence, apply, answer, audit, or prove the central entity.

Definition support page

Owns a focused concept, boundary, terminology, or related entity the hub introduces but cannot explain deeply.

Attribute or relationship page

Develops one property, function, constraint, connection, input, output, or semantic branch.

Comparison page

Owns alternatives, criteria, fit, tradeoffs, limits, and a selection decision.

Process page

Owns an ordered workflow, roles, gates, blockers, outputs, and handoffs.

Use case or audience page

Owns application for one role, situation, workflow, market, or asset type.

Question or objection page

Owns a focused follow up, limitation, risk, poor fit condition, or support need.

Audit or scorecard page

Owns diagnosis, evaluation, repair priorities, or a controlled review method.

Evidence or workflow page

Owns source intake, proof, examples, prompts, templates, records, or the next production stage.

Eight support page approval dimensions

MIRENA checks whether the candidate deserves independent ownership and can strengthen the cluster.

Distinct reader task

Does the asset solve a separate question, comparison, process, use case, objection, or support need?

Query and entity fit

Does the candidate clearly support the central entity and approved cluster purpose?

Depth and source readiness

Is there enough approved material to support a complete and useful asset?

Hub and sibling overlap

Can the asset remain distinct from the hub and current support pages?

Journey value

Does the asset help the reader progress into depth, decision, implementation, proof, or support?

Business and workflow value

Does the asset support an approved offer, support path, or production stage without creating an intent mismatch?

Internal route value

Can the hub and siblings link to the asset at a natural moment with a clear relationship?

Production effort and dependency

Are sources, owners, technical needs, prerequisites, and build priority clear?

Eight support page decisions

Each candidate receives a hub, existing owner, new page, merge, split, refresh, reject, or hold decision.

Keep the task on the hub

Use when the support is necessary but too small or too close to the broad journey for a separate asset.

Route to an existing support page

Use when an approved sibling already owns the task or entity branch.

Create a new support page

Use when the candidate has distinct intent, enough depth, low overlap, and strong route value.

Merge duplicate support pages

Combine assets that serve the same entity, intent, and reader task.

Split a mixed support page

Separate distinct primary entities, intents, audiences, or workflows.

Refresh and reposition an existing asset

Clarify the page job, title, hierarchy, support depth, routes, and structured identity.

Reject the candidate

Do not build thin, repetitive, off topic, unsupported, or low value assets.

Hold for evidence, ownership, or dependency review

Pause when source material, canonical owner, technical work, or business priority remains unresolved.

Examples

The stronger support page owns one focused job, adds real depth, and connects naturally to the hub.

Review targetEntity SEO hub

Weak support idea

Create a separate asset for every entity modifier and closely related phrase.

MIRENA page

Create support assets only for distinct roles such as salience, hierarchy, placement, audit, or conflict resolution.

Review targetProduct hub

Weak support idea

Create feature pages that repeat the product description with one phrase change.

MIRENA page

Create focused comparison, use case, pricing, evidence, integration, or support pages with clear ownership.

Review targetProcess hub

Weak support idea

Place the full workflow, checklist, audit, prompts, and template on one oversized guide.

MIRENA page

Keep the broad sequence on the hub and give focused execution tasks to owned support pages.

Review targetExisting cluster

Weak support idea

Add a new URL because the topic is missing from one asset.

Main job

Connects the hub, support pages, proof, workflows, and next tasks.

Relationship

Makes the support relationship visible to readers and the site architecture.

Ownership and production decisions

MIRENA decides whether the task belongs on the hub, an existing support page, a new asset, or no page.

Keep on the hub

The task is foundational, navigational, or too small for independent ownership.

Assign to an existing support page

An approved sibling already owns the entity angle or reader task.

Create a new support asset

The task has distinct intent, enough depth, low overlap, and a strong internal route.

Merge, reject, or hold

The candidate is duplicated, thin, unsupported, private, off topic, or not ready.

Common mistakes

Weak support page planning creates pages from modifiers, duplicates the hub, ignores routes, or approves assets without enough evidence.

Creating a page for every keyword

Language variation does not automatically create a new user task or entity owner.

Repeating the hub

A support page should deepen one angle rather than reproduce the broad orientation.

Building without enough depth

A short section, question, comparison row, or contextual link may be the better treatment.

Ignoring existing ownership

A current sibling may already own the topic and need a refresh or stronger route.

Ignoring internal links

An orphan support page does not strengthen the cluster or reader journey.

Building before evidence is ready

Identity, claims, examples, data, screenshots, and relationships should be approved first.

Accepted, held, rejected, blocked, and review needed assets with owners and next workflows.

Review the route

Entity SEO routes

Move from support page selection into cluster architecture, gap review, briefing, and internal links.

Can an existing asset become a support page?

Yes. MIRENA can refresh and reposition an asset when its role, scope, hierarchy, and routes need clarification.

How should support pages link to the hub?

The route should explain the relationship and appear where the reader needs the broader entity context or next task.

What does MIRENA return?

MIRENA can return the candidate register, approval matrix, ownership record, Entity Led Brief, build and link plan, and final handoff.

Next route

Give MIRENA the central entity, hub, page inventory, query evidence, source context, internal links, and support candidates. It returns the approved page roles, briefs, build order, consolidation, routes, and handoff.

Use topical maps to implement the support architecture, then use Entity Led Briefs before each approved asset enters drafting.

Founder access is €20 per 30 days excluding VAT for one seat and one active MIRENA instance. OpenAI account rules, plan charges, model access, and usage limits remain separate.

Open MIRENA Review the Entity Led Brief