---
name: build-money-tree-site-diagram
description: "See which parts of your site help people find what you sell."
category: SEO & Content Architecture
stage: Post
definitive_article: https://blitzmetrics.com/money-tree/
status: needs-work
---

# Build a Money Tree site diagram

See which parts of your site help people find what you sell. This guide draws a tree from the links your pages really have. Start with your full page list and the offers people can buy.

**The path:** Published URLs + offer list → Measured body links → Tree and text view → Owned fixes

**Start when:** An eligible managed site needs its existing monthly tree rebuild or a specifically authorized structure audit.

## Inputs

- [Inventory pages and their purpose](https://local-service-spotlight.github.io/task-library/?task=step-1-inventory-content-and-establish-gct-per-page#task-step-1-inventory-content-and-establish-gct-per-page) with published posts, pages, content types, current body output, date and crawl coverage.
- The actual home, navigation, services and method pages; canonical targets, previous tree and its count definition.
- The maintained Money Tree renderer/source contract and authorized site scope; private measurements only from connected, verified sources.

## Steps

1. Read the current [Money Tree, a site map whose branch sizes show measured supporting links](https://blitzmetrics.com/money-tree/) procedure and existing renderer contract. Confirm the site is eligible and its owner, publication rail, previous run and scope. Use the real home/domain as trunk, existing audience or offer groups as limbs, real method or buying pages as branches, and off-site identity proof as roots.
2. Fetch all published URLs from the supported source and reconcile with the crawl. Include both WordPress Posts and Pages where present. Use rendered article bodies to expand builder or shortcode links, while retaining the source revision and extraction boundaries; list unreadable or missing pages explicitly.
3. Extract actual internal body links and build an inbound index. Count each published post once per branch even if it links there several times. Keep page-to-page links separate and exclude theme navigation from this leaf count. Normalize only documented equivalent URL forms; do not erase meaningful query parameters blindly.
4. Identify the branches from the site’s current navigation, services and topic owners. Follow and record redirects. Group confirmed aliases with a union of distinct source posts, naming the old paths and duplicates as findings. Similar titles alone do not prove two live offers are the same branch.
5. Generate the dated clickable diagram, matching linked text outline and truthful structured metadata from that same checked data. Branch weight follows the source-defined count; bare branches remain bare. Label a simplified opening view and link directly to the full tree so no omitted branch disappears from the review.
6. Check all in-scope offers are represented, nodes resolve or are clearly held, and the three representations agree. Reproduce counts from the saved snapshot rather than expecting a changing live site to freeze. Review useful labels and coverage at desktop and mobile sizes; decoration must not invent supporting leaves.
7. Prepare the public structural view and authenticated private measurement view separately. Keep client leads, revenue and priorities out of public HTML, hidden data, metadata and alt text. When release is authorized, verify the normal URL against the exact saved source and retain rollback evidence.
8. Record bare branches, split destinations, redirects, broken targets and relevant proof gaps with exact URLs, counts and owners. Use verified comparable revenue only for a revenue ranking; disconnected data remains unknown. Hand the accepted tree and deltas to the existing review owner without creating another schedule.

## Fleet rollout and money-page proof

Keep one current public-safe Money Tree per eligible managed site, using the
existing agent-runtime `money-tree/` renderer, source contracts and accepted
run identity. The actual home/domain is the trunk, buying/service destinations
are branches, and relevant published supporting articles/videos are leaves.
Link real nodes to their canonical destinations and retain unknown branches.
The tree is evidence of site structure; it must never imply unmeasured results.

Each buying page has meaningful relevant proof above the fold, evidence beside
material outcome claims, and relevant proof near its primary buying action.
Use the full tree or its useful branch where it explains the offer, alongside
real project scenes, attributable results and source videos. Give supporting
leaves a relevant buying destination and a practical how-to link when useful.
Keep public wording confident and specific: state the sourced moment once;
remove repeated caveats, internal review scores and unsupported claims.

Public trees contain public structure and content counts only. Private sessions,
leads, bookings, conversion rates, revenue, finances and priorities stay behind
authenticated client access, including alt text, metadata, hidden DOM and JSON-LD.
NOT_CONNECTED is not zero. Preserve the existing roster, site authorization,
CMS/deployment/rollback and public/private gates; a schedule or current recipe
is not a release receipt. Reconcile `monthly-client-money-tree-maa` before adding
any clock. Check priority buying pages and named relationships weekly; rebuild
other eligible site trees monthly through their existing owning function.

## 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/).

- [ ] Every scoped offer and topic branch comes from the site, with no invented nodes or missing bare branches.
- [ ] Distinct source-post counts, alias handling, crawl date and extraction boundaries can be reproduced.
- [ ] Public diagram, text and metadata agree; private values are absent from every public representation.
- [ ] Each priority finding has a specific next task and owner; structural counts are not claimed as measured sales.
- [ ] Every branch in the service/navigation scope is represented
- [ ] Counts are reproducible and links resolve or are flagged
- [ ] Diagram, outline and schema agree
- [ ] A simplified opening map states its selection and coverage and leads directly to the complete tree; meaningful groups preserve the scoped tree's actual breadth without invented nodes or decorative leaves
- [ ] Each count states its source-defined measure and date; "published posts linking to this offer" is not presented as all relevant proof, all customers or all published content
- [ ] The first 2–3 sentences explain the reader's situation, why the tree matters and how connecting relevant proof to real offers helps the reader choose a next step; no unmeasured conversion or revenue promise
- [ ] Private metrics never enter public markup
- [ ] Each defect has a destination and next action
- [ ] Record the exact source revision, actual result and evidence; retain failure, partial, blocked and unknown states.
- [ ] Write the execution's meta article and link the canonical task. Publication is a separate action under the current authority.
- [ ] Keep this parent job's internal retries, checks and agent contributions on the same execution ID; derivatives and revisions add no runs. A separately scoped and documented child execution may have its own ID with parentExecutionId, without adding a second completion to this parent recipe.
- [ ] Verify permissions for publishing, sending, spending, scheduling or changing access before that action. A task record does not grant them.
- [ ] 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 service site has two offers and five posts. Three distinct posts link to the first offer; none link to the second. One post repeats its link three times, so it still counts once. The tree shows counts of three and zero. Without connected lead data, the team can plan relevant proof links but cannot name either offer the top seller.

## Handoff and Content Factory context

[Prepare the Friday MAA report](https://local-service-spotlight.github.io/task-library/?task=submit-weekly-maa-report-every-friday#task-submit-weekly-maa-report-every-friday) receives the accepted public tree, private evidence when authorized, branch deltas and owned actions. [Plan relevant links and orphan repairs](https://local-service-spotlight.github.io/task-library/?task=step-3-identify-money-pages-and-orphan-pages#task-step-3-identify-money-pages-and-orphan-pages) receives exact structural defects; [Collect verified measurements](https://local-service-spotlight.github.io/task-library/?task=collect-verified-weekly-measurements#task-collect-verified-weekly-measurements) owns missing source connections.

The source places this task in Post within the [Content Factory: Produce, Process, Post and Promote](https://blitzmetrics.com/content-factory/). Produce captures real sources, Process makes the selected useful assets, Post releases approved work, and Promote distributes proven work. The actual handoff above determines what this task must supply.

## 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:** Post
- **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:** Draft URL or WP post ID, slug, author user ID, featured-image media ID. Promote reads the live URL, not the draft.

## 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/money-tree/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=build-money-tree-site-diagram#task-build-money-tree-site-diagram)
- [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/)

### Primary method references

- [Google’s crawlable link requirements](https://developers.google.com/search/docs/crawling-indexing/links-crawlable)

## Review and evidence still needed

The inherited contributor status is `needs-work`. 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.