Entity based site architecture · Entity SEO

Entity cluster design turns related concepts into a governed set of pages with clear ownership and internal routes.

MIRENA selects the central entity, maps the reader journeys around it, classifies the required support roles, compares the current inventory, decides which tasks stay on the hub or move to support assets, and creates the build, consolidation, and internal link plan.

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 Cluster Design is an editorial and structural model with a clear evidence boundary.

A strong cluster has one central entity, a clear hub, focused support assets, bounded overlap, and internal routes that help the reader move between explanation, comparison, application, evidence, and action.

Central entity

The cluster needs one stable semantic center

The hub and support pages should reinforce the same core entity while serving different reader tasks.

Page ownership

Every distinct job needs one approved owner

Definitions, attributes, comparisons, processes, use cases, evidence, audits, and support questions receive bounded roles.

MIRENA rule

The route system is part of the design

A cluster is incomplete until the hub, siblings, bridges, support assets, and next workflows are connected contextually.

Evidence boundary: Google Search guidance emphasizes helpful content and crawlable, descriptive links, but it does not publish one required entity cluster architecture. MIRENA uses cluster design as an editorial, semantic, and information architecture model tied to user journeys, source context, page ownership, and internal routes.

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

MIRENA internal workflow

MIRENA designs entity clusters through six wide workflow stages.

The workflow prevents loose keyword groups, duplicate support pages, hub overload, orphan assets, unplanned cannibalization, and internal links that do not reflect page ownership.

Confirm the central entity and cluster purpose

MIRENA fixes the audience, offer, source context, primary journeys, protected pages, and the entity the cluster must own.

Map reader tasks and support roles

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

Audit the current page inventory

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

Assign page ownership and hierarchy

MIRENA chooses the hub, core support, attribute, comparison, process, use case, audit, evidence, and bridge roles.

Design internal routes and build order

The hub, siblings, proof sources, support steps, conversion paths, consolidation actions, and publication sequence are planned.

Create the cluster handoff

The approved architecture becomes a topical map, page brief queue, internal link plan, consolidation list, owners, and review states.

Eight entity cluster roles

A complete cluster separates broad ownership from focused support, comparison, application, evidence, and workflow jobs.

Hub page

Owns the central entity, broad definition, main routes, and cluster orientation.

Core support page

Explains one foundational concept or reader task the hub cannot cover deeply.

Attribute or relationship page

Develops a defining property, function, constraint, connection, or semantic branch.

Comparison page

Owns criteria, alternatives, fit, tradeoffs, and decision support between entities or routes.

Process page

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

Use case or audience page

Owns the application of the entity for one role, situation, workflow, or page type.

Audit or question page

Owns diagnosis, scoring, repair, objection, or a focused follow up task.

Bridge or workflow page

Connects clusters, evidence, production stages, products, and the next reader action.

Eight cluster design dimensions

MIRENA checks whether each proposed asset has distinct intent, enough depth, low overlap, and a useful route.

Central entity fit

Does the proposed page strengthen the entity the cluster is built to own?

Distinct user task

Does the asset solve a separate question, decision, process, or application?

Depth and support

Is there enough approved material to justify a focused asset rather than a small section?

Current ownership

Does an existing page already own the same task or entity branch?

Overlap and cannibalization risk

Would the page duplicate the hub, sibling, or protected asset?

Journey and business value

Does the asset move the reader toward understanding, comparison, support, action, or the approved offer?

Internal route value

Can the hub and siblings connect to the asset at a natural point in the journey?

Production readiness

Are sources, examples, evidence, owners, dependencies, and build priority clear?

Eight cluster architecture actions

Every candidate receives a hub, support, merge, split, route, refresh, rejection, or hold decision.

Keep or create the hub

Use one broad asset to own the central entity, orient the reader, and expose the main routes.

Create a focused support page

Use when one task has distinct intent, enough depth, low overlap, and strong cluster value.

Keep the topic as a hub section

Use when the material supports the broad journey but does not justify a separate owner.

Merge duplicate pages

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

Split a mixed asset

Separate distinct page jobs or primary entities that compete inside one URL.

Refresh and reposition an existing page

Change the role, scope, title, hierarchy, and routes when the asset belongs but the current job is unclear.

Add or repair internal routes

Connect the hub, siblings, proof, support, commercial path, and next workflow according to ownership.

Reject or hold the candidate

Pause thin, unsupported, duplicated, off topic, private, or low value page ideas.

Examples

The stronger cluster assigns every related topic a page role, boundary, and internal route.

Review targetEntity SEO cluster

Loose group

Salience, hierarchy, attributes, relationships, placement, audits, and links appear as a flat page list.

MIRENA cluster

The Entity SEO hub orients the field while each focused asset owns one role and links to the closest prerequisites and next tasks.

Review targetProduct cluster

Loose group

Product, features, pricing, comparisons, use cases, reviews, and support pages compete without a hierarchy.

MIRENA cluster

The product page owns the entity while pricing, comparisons, use cases, evidence, and support tasks receive focused roles and routes.

Review targetProcess cluster

Loose group

Guides, checklists, templates, audits, and prompts repeat the same workflow language.

MIRENA cluster

One process hub owns the broad sequence while stage, template, audit, and execution pages receive distinct tasks.

Review targetExisting site section

Loose group

Several old URLs overlap, some pages are thin, and useful support assets are orphaned.

Main job

Finds missing entities, attributes, relationships, support pages, and routes.

Relationship

Identifies the cluster work still required after the baseline is mapped.

Ownership and production decisions

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

Keep on the hub

The topic is foundational or navigational but does not need separate depth.

Assign to an existing support page

An approved asset already owns the focused task or entity branch.

Create a new support candidate

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

Merge, reject, or hold

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

Common mistakes

Weak cluster design creates pages from every keyword, leaves ownership vague, or links without a reader journey.

Using keyword similarity alone

Related phrases do not determine page roles, entity ownership, or user tasks.

Creating a page for every modifier

Many variations belong inside one canonical asset or focused component.

Overloading the hub

The hub should orient and route rather than absorb every support task.

Duplicating support roles

Several pages should not own the same entity, intent, and answer pattern.

Ignoring consolidation

Existing overlap may require merging or repositioning before new pages are added.

Building without internal routes

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

Accepted, held, rejected, blocked, and review needed page decisions with owners and workflows.

Review the route

Entity SEO routes

Move from cluster design into support page planning, conflict resolution, gap auditing, and topical execution.

When should a topic become a support page?

When it has distinct intent, enough depth, low overlap, strong reader value, and a natural internal route.

Can MIRENA repair an existing cluster?

Yes. It can assign ownership, merge duplicates, split mixed assets, refresh weak pages, create missing support, and rebuild links.

What does MIRENA return?

MIRENA can return the central entity record, role matrix, ownership record, build plan, link plan, and final handoff.

Next route

Give MIRENA the central entity, site inventory, query evidence, source context, offers, protected pages, and internal links. It returns the cluster roles, ownership, build order, consolidation, routes, and handoff.

Use topical maps when the architecture is approved, then use Entity Led Briefs to control each page before 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