---
name: link-leaves-to-branches-branches-to-trunk
description: "Link each story to the guide or service it helps prove."
category: SEO & Content Architecture
stage: —
definitive_article: /seo-tree
status: complete
---

# Link leaves to branches, branches to trunk

Link each story to the guide or service it helps prove. This task adds useful links between those pages. Start with the site map and the page each story helps prove.

**The path:** Checked parent map → Contextual upward links → Useful evidence links back → Link QA

**Start when:** The current content map names the owning topic and real offer destinations for the selected supporting pages.

## Inputs

- [Map actual content roles](https://local-service-spotlight.github.io/task-library/?task=map-content-hierarchically-root-trunk-branches-leaves#task-map-content-hierarchically-root-trunk-branches-leaves) with current entity home, actual topic/offer branches and supporting pages.
- [Choose the right entity destination](https://local-service-spotlight.github.io/task-library/?task=follow-entity-linking-decision-tree#task-follow-entity-linking-decision-tree) and the selected pages’ [Goals, Content, Targeting: the result, source material and people served](https://blitzmetrics.com/gct-business-strategy/) briefs, source revisions and publication scope.
- The specific source-to-target link plan, existing useful links and known destination status.

## Steps

1. Read the selected page and its mapped parent before editing. State the connection in the reader’s terms: what the story shows and which method or offer helps next. Reject a mapped relationship that exists only because of a shared keyword; update the map with the actual finding.
2. Add a contextual link from the supporting story or execution record to the canonical method it uses. Where it genuinely helps, connect relevant proof to the real service or buying page and practical how-to. Keep the story’s unique evidence rather than replacing it with a copy of the whole method.
3. On the owning method or topic page, make the entity home and relevant offer path understandable. Use the current Directory convention: the home is the trunk and off-site proof supplies roots. Do not invent another homepage/root URL or chain every reader through an unnecessary layer.
4. Add relevant cross-links where one method actually depends on or explains another. The tree is a useful primary hierarchy, not a ban on lateral paths. Check prerequisites and downstream actions by their actual task contracts; neighboring catalog entries are not automatically real dependencies.
5. Link the hub back to useful verified examples with a sentence or two explaining what each shows. A case or meta article can both support its hub and be discoverable from it. Prioritize relevant credible evidence; a historical example remains dated proof and does not establish a new counted execution.
6. Review names and anchor phrases with [entity linking, choosing the right home for a named person or topic](https://blitzmetrics.com/entity-linking/). Natural descriptive body links are the work here; useful navigation remains valid. A two-word entity name need not be padded to meet a word count, and repeating the same link several times does not add distinct supporting posts.
7. After authorized release, check the actual normal pages and destinations, then save the link log and map changes. Record any missing parent, broken target or inaccessible source for the right owner. Pass the observed change set to QA and measurement without promising a ranking or conversion lift.

## Definition of done (QA checklist)

Quality assurance (QA) means checking the actual result against its agreed requirements. Follow the [Article Guidelines](https://localservicespotlight.com/article-guidelines/).

- [ ] Each upward link follows a meaningful relationship and reaches the verified owning destination.
- [ ] The tree’s labels and useful cross-links are accurate; no duplicate home node or artificial one-way-only rule is imposed.
- [ ] Evidence links back to supporting pages are useful and specific, with current public readbacks.
- [ ] The exact output, source revision, reviewer evidence and remaining owner action are saved.
- [ ] For any reader-facing output, the short grade-five opening states the reader’s useful outcome and supporting method or proof. The body delivers that promise; a useful authentic visual appears in the first screen. Retain exact text and quoted reviewer evidence.

## Example(s)

**Fictional teaching example. This is not a client result or proof of a completed run.**

A fictional course has a main method guide and a dated student exercise. The exercise links to the guide for the full method; the guide links back with a note about what the exercise demonstrates. A relevant course page remains the buying path. This two-way connection is useful navigation, not a reason to duplicate the guide in the exercise.

## Handoff and Content Factory context

[Check the placed links](https://local-service-spotlight.github.io/task-library/?task=step-5-qa-links-against-google-guidelines#task-step-5-qa-links-against-google-guidelines) receives source, target, anchor, context and public readback. [Publish the checked site directory](https://local-service-spotlight.github.io/task-library/?task=publish-seo-tree-site-directory#task-publish-seo-tree-site-directory) receives changes to the actual map, and [Measure the accepted change set](https://local-service-spotlight.github.io/task-library/?task=step-6-measure-and-iterate-with-maa#task-step-6-measure-and-iterate-with-maa) receives the release dates.

This task supports the [Content Factory: Produce, Process, Post and Promote](https://blitzmetrics.com/content-factory/). Identity, proof, access or coordination can support several stages. Use the real inputs and receiving owner above; this task does not create unrelated transcripts, clips or ads merely because the diagram has four stages.

## Start with an agent

Give the [AI worker](https://blitzmetrics.com/build-agents/) this recipe, the real inputs, desired result and actions already authorized. Ask for the saved output, sources, checks and next owner. A [skill is a written recipe](https://localservicespotlight.com/plugin/); loading one does not prove account access or perform the task. Use the [installation guide](https://localservicespotlight.com/install/) if reusable setup is needed. A ZIP is a source snapshot, not an access grant or automatic update.

Use the app’s actual supported tools and verified file/account access. Keep a missing human verification step with its real owner. Recurring work needs its own configured job, trigger, timezone and observed result; this guide creates no schedule. Before any media playback, mute the player and set its volume to zero. If silence cannot be verified first, use captions, frames, metadata or another silent check.

## Record the real execution

Open the run record when work begins. Keep one execution ID, starting recipe revision, real inputs and current state. Write the [meta article, the record of this execution](https://blitzmetrics.com/meta-article-prompt/) with actual steps, results, checks, failures and next owner. Writing is required; public release follows existing authority. Link it to this recipe and the [Task Library](https://local-service-spotlight.github.io/task-library/).

Reuse the same execution ID for internal checks, revisions, retries and meta writing. A blocked run stays open with its dependency and owner, without an invented finish time. Dated public examples and distinct verified execution counts remain separate. Propose the smallest source-backed recipe improvement when the actual evidence reveals a defect.


<!-- factory-layer:start -->

## Factory chain (do not treat this as isolated)

- **Phase:** —
- **Importance:** 3/5 `●●●○○` — frequency 3, revenue 3, gating 2 (supporting)
- **Suggested previous station:** —
- **Suggested next station:** —
These stations are generated neighbors, not verified prerequisites or handoffs. Follow the task’s actual Inputs and Handoff sections.
- **Handoff:** Save this task’s actual output, source, date and checks where the receiving owner can read them. Follow the Inputs and Handoff sections for its next step.

## Model routing (same factory, any engine)

- **This task's lane:** `any` — Any capable chat model (Claude, ChatGPT, Grok, Gemini). SOP following, drafts, checklists.
- **Single-engine path:** Use the capable AI app you already have. Check its required tools and access before starting. Pass the actual result and proof to the next task.
- **Optional multi-engine:** A tested local model may draft; a stronger model may review facts and voice. Use supported tools for approved actions. Pick models from observed quality and cost; a model name does not prove it can run this task.
- **Never** store the working state in one vendor's memory. Files in the Content Library are the bridge.

<!-- factory-layer:end -->
## Definitive article & links

- [Maintained source guide](https://blitzmetrics.com/seo-tree/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=link-leaves-to-branches-branches-to-trunk#task-link-leaves-to-branches-branches-to-trunk)
- [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Definitive article and task recipe standard](https://blitzmetrics.com/definitive-article-guide/)
- [How recipes and run records fit together](https://localservicespotlight.com/meta-articles/)

## Review and evidence still needed

The inherited contributor status is `complete`. It is preserved, not promoted by this rewrite. That label alone does not prove document readiness, account access, an actual execution or a client result.

The fictional example teaches the method and does not fill a real-run evidence gap. A named semantic reviewer must check the actual opening, full method, sources and handoff. Check the useful opening visual in the normal rendered guide at the current required desktop and mobile sizes, including 1280 × 800 and 390 × 844. Source readability checks do not prove public presentation or task execution.