How to Build the Money Tree Diagram for Any Site

A money tree is a site’s SEO Tree drawn from its own internal links, with the money pages marked. The domain is the trunk, each page where someone buys or books is a branch, and each blog post that links up to one of those pages is a leaf on it. Draw it from measured links rather than from memory and it stops being a diagram and starts being a diagnosis: you can see which offers are being fed by your content, which are bare, and which have quietly split into two competing URLs.

Here is ours. Not an illustration — the real thing, drawn from the live internal links on this site, defects and all. Read it from the bottom up: the roots are the proof the market holds about us, the trunk is this domain, each branch is something you can actually buy or a concept we own, and the leaves are the posts that feed each one. Everything after the diagram explains how to draw your own.

The BlitzMetrics money tree

Branch thickness and foliage are set by the measured leaf count, so a fed branch looks fed and a bare branch is drawn bare. Every node is a live link. The same structure repeats as a text outline directly under the diagram, and again as ItemList schema in the page source — so a person, a screen reader and a language model all get the identical map.

---
name: map-your-money-tree
description: Draw any website as a money tree — trunk (domain), limbs (offer groups), branches (money pages and definitive hubs), leaves (posts that link up to them) — measured from the site's real internal links, then diagnose the six defects a sitemap hides and output a dated publishing plan. Use when someone asks "which of my pages actually make money", "why isn't my content converting", "map my site", "audit my internal links", or when a monthly MAA needs a structural section.
author: Dennis Yu — BlitzMetrics / Local Service Spotlight
license: Apache-2.0
version: 1.0 (2026-08-15)
references:
  - https://blitzmetrics.com/money-tree/
  - https://blitzmetrics.com/seo-tree/
  - https://blitzmetrics.com/money-pages-vs-blog-posts/
  - https://blitzmetrics.com/maa/
  - https://blitzmetrics.com/9-triangles-framework-scalable-home-service-businesses/
  - https://localservicespotlight.com/quick-audit/
---

# Map Your Money Tree

**Use this when** you need to know which pages on a site actually earn, and which of the
content already published is feeding them. Not "how much traffic does this page get" —
*what is connected to what, and in which direction.*

This is the structural half of [MAA](https://blitzmetrics.com/maa/). The leaf counts are
the Metrics. The bare and split branches are the Analysis. The publishing list at the end
is the Action. Redraw it monthly and the delta is the report.

## The one idea

**A leaf counts only when it actually links.**

Not when it is topically related. Not when it sits in the right category. Not when someone
meant to link it. The link is the measurement; everything else is a plan. Every number this
skill produces must be reproducible by re-running the crawl.

---

## The five layers

| Layer | What it is | How you know |
|---|---|---|
| **Root** | Off-site proof of the entity: Knowledge Panel, Wikidata, LinkedIn, YouTube, podcast appearances, press, review profiles. | It is not on the domain and you cannot edit it directly. |
| **Trunk** | The domain and its home page — the entity home. | It is the URL you would put on a business card. |
| **Limb** | A group of branches sharing an audience or a job — the offers, the method, a vertical. | It is how the site's own services page already groups things. |
| **Branch** | A money page, or a definitive article that owns a concept. | Someone converts on it, or it is the one canonical page for a topic. |
| **Leaf** | A post that links **up** to a branch. | It is dated, it flows through a feed, and its body contains a link to its branch. |

Roots and trunk are **Why**. Limbs and method branches are **How**. Money branches are
**What**. Leaves are **Proof**. A stranger — or a language model — should be able to read
all four off one page.

---

## Inputs

- The domain.
- Read access to every published URL and its **rendered** body (not raw — page-builder and
  shortcode markup must be expanded so the links inside are visible).
- The site's own services page and main navigation, for the branch list and its grouping.
- Optional: the previous run's tree, for the delta.

---

## Procedure

### 1. Inventory every published URL
Posts and pages both, with id, URL, title, publish date, and rendered body.

On WordPress:
```
GET /wp-json/wp/v2/posts?per_page=100&page=N&status=publish&_fields=id,link,title,content,date
GET /wp-json/wp/v2/pages?per_page=100&page=N&status=publish&_fields=id,link,title,content,date
```
Page until the `X-WP-TotalPages` header runs out. On any other stack, use a crawler that
returns rendered HTML. De-duplicate by (type, id) — retried requests double-count silently.

### 2. Extract internal links from every body
Match `href` values on the site's own host. Normalise: drop the query string and fragment,
force a trailing slash, lower-case the host. **Make the set unique per source page** — a
post linking to the same branch five times is one leaf, because the first link is the one
that carries the value.

```js
const RX = /href="https?:\/\/(?:www\.)?example\.com(\/[^"#?]*)/g;
const outs = [...new Set([...html.matchAll(RX)].map(m => m[1].replace(/\/+$/,'') + '/'))];
```

For a personal brand site, also match the company domains — its money pages usually live
on another host, and they still count as branches.

### 3. Build the inbound index
Invert the map: for every URL, the list of posts and the list of pages that link to it.
Count them **separately**. Theme headers and footers are pages linking to pages; only body
links from posts are leaves.

### 4. Name the branches from the site, not from memory
Take the money pages off the services page and the main navigation, in the grouping those
pages already use. Add the definitive articles — the pages that own a concept. Do not
invent a tidier taxonomy than the one the site presents to a visitor: if your tree
disagrees with the navigation, the tree has just found its first defect.

### 5. Resolve redirects and duplicates before counting
Request each branch URL and follow the chain. Merge redirected URLs into one branch and
**report the merge** rather than hiding it. Two live 200s for one offer is a split branch,
not two branches. This is the step everyone skips and where most findings are.

### 6. Draw it to scale
Branch thickness and foliage density from the leaf count on a **square-root** scale, so a
300-leaf branch does not visually annihilate a 30-leaf one. Bare branches drawn bare.
Nothing placed by hand — if the drawing is prettier than the site, the drawing is lying.

### 7. Publish it on the site it maps
As a live page with every node a real link — never a screenshot. Ship three synchronised
forms on the same URL: the diagram (inline SVG), the identical structure as a **visible**
text outline, and `ItemList` JSON-LD naming each branch, its role, its content type and its
inbound count. The picture is for humans; the other two are for agents.

---

## The six defects — and where each one routes

Diagnosis is worthless without a destination. This is a scan that names the department.

| # | Defect | What it looks like | What it costs | Routes to |
|---|---|---|---|---|
| 1 | **Bare branch** | A live money page with zero posts linking to it | Nothing on the site has ever pointed a visitor at the thing you sell | Content — one customer story per bare offer |
| 2 | **Split branch** | Two live URLs for one offer (usually a page and a post) | Internal links divide; neither ranks as well as one would | Plumbing — pick one, 301 the other, consolidate |
| 3 | **Redirect tax** | Many internal links pointing at a URL that 301s | Every link takes the slow road; often includes the main nav | Plumbing — rewrite links to the destination |
| 4 | **Broken target** | Internal links pointing at a 404 | Invisible in analytics, because nobody clicks a link they cannot see | Plumbing — restore or repoint |
| 5 | **Inverted tree** | Leaf counts fall as price rises | The cheapest offer carries the most proof; the most expensive carries none | Strategy — decide what you are actually selling |
| 6 | **Canopy with no branches** | Hundreds of posts linking to each other and almost nothing structural | Looks enormously productive, converts nothing | Personal brand — wire the proof to an offer |

Also check the roots. A tree with no off-site proof — no Knowledge Panel, no consistent
`sameAs`, no third-party corroboration — is standing in loose soil no matter how good the
canopy looks. That routes to entity/authority work.

---

## The QA gate — nine checks, all must pass

A wrong tree is worse than no tree, because people act on it.

1. **Every node resolves.** Status recorded for each branch; no 404s; every 301 shown as a redirect rather than silently followed.
2. **Counts are reproducible.** Re-run the crawl; identical numbers. Drift means the extractor is matching something other than links.
3. **Counts are unique per source.** One post linking three times counts once.
4. **Navigation excluded.** Only body links from posts are leaves.
5. **No branch invented.** Every branch appears in the site's own navigation, services page, or definitive-article set.
6. **No money page missing.** Cross-check against the services page and main menu. A money page absent from the tree is the worst error — an invisible bare branch reads as a branch that does not exist.
7. **Duplicates consolidated.** Split URLs appear as one branch, flagged, with both URLs named.
8. **Text outline matches the diagram.** Same nodes, counts and order — that is what agents and screen readers read.
9. **Date and method stated.** A tree without a crawl date is a claim, not a measurement.

---

## Output

1. **The diagram** — inline SVG, every node an anchor, light/dark, no runtime JS.
2. **The text outline** — visible, nested, live links, counts, health flags.
3. **The schema** — `ItemList` JSON-LD, one entry per branch.
4. **The findings** — the defects above, each with the specific URLs and counts.
5. **The action list** — dated, ordered by cost-to-fix, one line per bare branch.
6. **The delta** — versus the previous run. Any branch still bare after a redraw is a branch nobody has decided to sell.

## Definition of done

- Every branch on the services page and main nav appears in the tree.
- Every count is reproducible and every URL resolves or is flagged.
- The page carries diagram + outline + schema on one URL.
- Every defect names a destination, not just a problem.
- The next publishing action is unambiguous to someone who did not run the audit.

## Cadence

Monthly on an active site. The value is in the delta, not the snapshot. A metric you look
at once is a screenshot.

---

*Method: <https://blitzmetrics.com/money-tree/> · Framework: <https://blitzmetrics.com/seo-tree/> ·
Page-versus-post rule: <https://blitzmetrics.com/money-pages-vs-blog-posts/> ·
Want it run for you: <https://localservicespotlight.com/quick-audit/>*

What our own tree says about us

Read the two limbs against each other and the diagnosis is uncomfortable and useful. The method limb is thick: 302 posts link to the Content Factory article, 222 to the SEO Tree, 177 to the definitive-article guide. The offer limb is thinner at almost every level — the Content Factory programme page, which is the thing someone actually buys, carries 73. We are four times better at teaching the method than at pointing anyone toward the thing that sells it.

Three specific defects, all of which were invisible until the tree was drawn:

• 115 posts link to /quickaudit/, which 301-redirects to /quick-audit/ — and the main navigation still points at the redirected form. Fifty more link to the destination directly, and two link to both. One branch, 163 distinct posts once the overlap is removed, most of them taking the long way round.
• 45 posts link to /i-love-to-e-e-a-t/, which returns 404. Another 93 link to /i-love-to-eeat/, which redirects to /eeat/. One definitive article, three URLs, one of them broken.
• Dollar a Day still lives at two live URLs, /dad/ with 97 posts and /dollar-a-day/ with 31. Same offer, two branches, split authority — the same collision that started this whole thread, one level up.

The Local Service Spotlight tree has a different failure: the newest offers on the services page — the Home Service Growth System and the two packages beneath it — have no posts linking to them at all. They were built and never fed. And the twelve vertical Quick Audit pages, one each for HVAC, roofing, plumbing, legal and the rest, had zero leaves until the money tree itself linked to them, which now makes that post the only leaf on each of the twelve.

The dennisyu.com tree is the most instructive of the three, because it is the worst. There are 1,560 published posts on it. The most linked-to destination on the whole site is a post about Marko Sipila, with 60 inbound links. The AI Builder Program — the offer in the main navigation — has 13. /the-process/ has zero. /stories/ has zero. It is an enormous canopy attached to almost no branches: a decade of proof that is not connected to anything anyone can buy. If you were looking for a reason to draw your own tree before writing another post, that is it.

Common questions

How is this different from an internal-linking audit?

An internal-linking audit tells you which pages have few inbound links. A money tree tells you which offers have few inbound links, and shows the gap next to the price. The unit of analysis is the branch, not the URL, so a page and its duplicate collapse into one thing and the answer is about the business rather than about the site.

How often should it be redrawn?

Monthly for an active site. The tree is the metrics half of an MAA loop; a metric you look at once is a screenshot, not a measurement. The value is in the delta — which branches thickened, which stayed bare, which new page arrived and was never fed.

What if a site has almost no content?

Draw it anyway, and draw it bare. A new personal-brand site with one offer and four posts produces a tree with one branch and four leaves, which is an honest picture and an obvious publishing plan. Bare trees are more useful than mature ones, because the next action is unambiguous.

Does this work off WordPress?

Yes. Nothing in the method depends on the CMS — it needs a list of URLs and the links inside each one, which any crawler produces. We use the WordPress REST API because it is exact and cheap on our own sites; a static-site build gives you the same data more directly.

Should the money tree itself be a page or a post?

Either, as long as there is exactly one URL for it. The page-versus-post rule is strict for money pages, which must be pages so they keep their place in the hierarchy and their page-builder layout. For a definitive article the binding rule is the other one: one topic, one URL, and every related post links into it.

Now yours — what the tree is, and how to draw it

Everything below is the method that produced the diagram above: what the five layers mean, how to measure a site instead of sketching it, the six defects a tree exposes that a sitemap hides, the nine-check QA gate every tree has to pass before it is published, and how to publish it so humans and agents read the same structure. The two live trees drawn by this method on our other sites are Local Service Spotlight and dennisyu.com — the second is the worst of the three, which is exactly why it is published.

What a money tree is, and why it is not a sitemap

An XML sitemap is a flat list of every URL on a site. It answers one question — what exists — and it answers it for crawlers. It says nothing about which of those URLs makes money, nothing about which pages support which, and nothing about whether any of it hangs together. A site with 1,783 orphaned posts and a sitemap listing all 1,783 looks, in the sitemap, exactly like a healthy site.

An HTML sitemap page is a little better and still mostly a table of contents. Neither one shows the thing that actually determines whether content earns anything: what links to what, and in which direction.

The money tree shows exactly that. It is built on the SEO Tree, which is how we think about content structure — root, trunk, branches, leaves, with authority flowing up the tree and specificity flowing down. The money tree adds one thing: it marks which branches are money pages, and it draws every branch at the thickness its real inbound links justify. A branch with eighty posts feeding it is drawn eighty-posts thick. A branch with none is drawn as a bare twig, because that is what it is.

Dennis put the mechanism plainly: the leaves gather the light, which is attention, search traffic, and the click off a boosted post, and the branches turn it into revenue. A post that links to no money page is a leaf on the ground. It may be beautifully written. It is not feeding anything.

First principles: why this shape and not some other

The tree is not a metaphor we liked the sound of. It is the only shape that holds all three of the marketing triangles at once, which is why it keeps reappearing in the Nine Triangles.

• GCT — Goals, Content, Targeting. The branches are the goals, the leaves are the content, and which limb a branch hangs from is the targeting. Drawing the tree forces those three into the same picture, in that order. Most content plans state a goal, then produce content that connects to a different goal, and nobody notices because the two live in separate documents.
• AEC — Audience, Engagement, Conversion. Leaves are where audience and engagement happen. Branches are where conversion happens. The tree makes the funnel geometric: if a leaf does not connect upward to a branch, there is no path from engagement to conversion, and you can see the gap rather than infer it from a report.
• MAA — Metrics, Analysis, Action. The leaf counts are the metrics. The bare and split branches are the analysis. The publishing list that falls out of the tree is the action. A money tree is a complete MAA loop rendered as one picture, which is why we redraw it rather than write a status report.

The tree also carries Why, How and What — the frame we teach for explaining any business — in its vertical order, which is the reason it works on people as well as on crawlers:

• Why lives in the roots and the trunk. The roots are off your site: the Knowledge Panel, the LinkedIn profile, the podcast appearances, the press, the reviews — everything the market says about you that you do not control. The trunk is the entity home you do control. Together they answer why anyone should believe a word of it.
• How lives in the limbs and the method branches: the definitive articles that own each concept you practise.
• What lives in the money branches: the specific things a person can buy.
• Proof lives in the leaves: the named examples, published in public, each one hanging off the branch it proves.

That is the whole argument for drawing it. A stranger — or a language model — landing on a site with a money tree on it can see in one screen who this is, how they work, what they sell, and what evidence supports each claim, with a live link at every node. That is a far stronger signal of expertise than a page that asserts expertise.

The five layers, defined

One rule governs the whole structure: a leaf counts only when it actually links. Not when it is topically related, not when it is in the right category, not when someone intended to link it. The link is the measurement. Everything else is a plan.

How to build one — the method

1. Take an inventory of every published URL

Every post and every page, with its type, its slug, its publish date, and its rendered body. On WordPress the REST API gives you this at /wp-json/wp/v2/posts and /wp-json/wp/v2/pages with per_page=100; you page through until X-WP-TotalPages runs out. Pull the rendered content, not the raw content, so that shortcodes and page-builder markup are expanded and the links inside them are visible.

2. Extract every internal link from every body

Match href values on your own host and normalise them: strip the query string and fragment, force a trailing slash, lower-case the host. Keep the set unique per source page, so that a page linking to the same branch five times counts once. The first link to a page is the one that carries the value; repeating it does not multiply anything.

3. Build the inbound index

Invert the map. For every URL on the site, you now have the list of posts that link to it and the list of pages that link to it. Count those separately — navigation and footer links live in the theme, not the content, so a page-to-page count behaves very differently from a post-to-page count. Leaves are posts.

4. Name the branches from the site, not from memory

Take the money pages off the services page and the main navigation, in the grouping those pages already use. Then add the definitive articles — the pages that own a concept. Do not invent a tidier taxonomy than the one the site actually presents to a visitor; if your tree disagrees with your navigation, the tree has just found its first defect.

5. Resolve redirects and duplicates before you count

This is the step everyone skips and it is where most of the findings are. Request each branch URL and follow the redirect chain. If /quickaudit/ 301s to /quick-audit/, those are one branch with the inbound links of both — and the fact that most of them point at the redirected form is a finding in itself. If two live URLs both return 200 for the same offer, that is a split branch, not two branches.

6. Draw it to scale

Branch thickness and foliage density are set by the leaf count, on a square-root scale so that a branch with three hundred leaves does not visually annihilate one with thirty. Bare branches are drawn bare. Nothing is placed by hand; if the drawing is prettier than the site, the drawing is lying.

7. Publish it on the site it maps

The tree belongs on the site it describes, as a live page with every node a real link — not as an image in a slide deck. A screenshot cannot be crawled, cannot be clicked, and is out of date the day after it is taken.

The six defects a tree exposes that a sitemap hides

1. The bare branch. A live money page with zero posts linking to it. It is not that the page is underperforming; nothing on the site has ever pointed a visitor at it.
2. The split branch. Two live URLs for one offer — usually a page and a post, or an old slug and a new one. Internal links divide between them, and neither ranks as well as one would. This is the exact failure that started the money pages versus blog posts discussion.
3. The redirect tax. Dozens or hundreds of internal links pointing at a URL that 301s somewhere else. It works, so nobody fixes it, and every one of those links takes the slow road — often including the link in the main navigation.
4. The broken target. Internal links pointing at a URL that returns 404. Nothing in an analytics dashboard surfaces this, because nobody clicks a link they cannot see.
5. The inverted tree. Leaf counts that fall as price rises — the cheapest offer carries the most posts and the most expensive carries the fewest. Extremely common, because cheap offers are easier to write case studies about.
6. The canopy with no branches. Hundreds or thousands of posts that link to each other and to almost nothing structural. The site looks enormously productive and converts nothing.

The QA gate: nine checks before a tree is published

A wrong tree is worse than no tree, because people act on it. Every tree we publish has to pass all nine:

1. Every node resolves. Request each branch URL and record the status. No 404s, and every 301 shown as a redirect rather than silently followed.
2. Counts are reproducible. Re-run the crawl; the numbers must come back identical. If they drift, the extraction is matching something other than links.
3. Counts are unique per source. One post linking to a branch three times counts once.
4. Navigation links are excluded. A theme header that links to every money page from every page would make every branch look healthy. Only body content counts.
5. No branch is invented. Every branch appears in the site’s own navigation, services page, or definitive-article set.
6. No money page is missing. Cross-check the tree against the services page and the main menu. A money page absent from the tree is the worst possible error, because a bare branch you cannot see reads as a branch that does not exist.
7. Duplicates are consolidated. Split URLs appear as one branch, flagged, with both URLs named.
8. The text outline matches the diagram. Same nodes, same counts, same order — because the text version is what an AI agent and a screen reader read.
9. The date and method are stated. A tree without a crawl date is a claim; a tree with one is a measurement.

Publishing it so agents can read it too

A picture of a tree is worth nothing to a language model. Every tree we publish ships in three synchronised forms on the same URL:

• The diagram — inline SVG, so it scales, prints, works with the page’s own dark mode, and needs no plugin. Every node is a real anchor, so the links in the drawing are the same links a crawler follows.
• The text outline — the identical structure as nested lists with live links, counts and health flags, visible on the page rather than hidden. This is what gets quoted.
• The schema — an ItemList in JSON-LD naming each branch, its role in the tree, its content type, and its inbound post count, so the relationship survives being parsed by something that never sees the picture.

That third form is the point Dennis keeps making about what comes after search. When an assistant is asked who a company is and what it is good at, it does not read a sitemap and it cannot see a diagram. It reads structure. A money tree published this way hands it the structure explicitly: here is the entity, here is what it sells, here is the method behind each offer, and here are the named, dated examples that prove each one — with a URL at every node it can verify. That is also, not coincidentally, exactly what a human buyer wants on the first visit.

Why the skill file and the sales page ship in the same block

Under the tree above there are two doors. One hands you the whole skill file so you can run this yourself; the other books a free Quick Audit so we run it for you. Both start from the identical diagnosis. That pairing is deliberate, it is the same pairing we put under every demonstration we publish, and it is worth explaining because most people get the logic backwards.

A scan is worthless unless it names a department

Think about how an emergency room actually works. Nobody walks in and gets sent straight to cardiology. You get triaged, then scanned, and the scan produces a diagnosis whose entire job is to route you: chest pain plus this ECG goes to cardiology, this fracture pattern goes to orthopaedics, this scan goes to oncology. The scan is not the treatment. The scan’s value is that it turns a vague complaint into a specific destination.

Marketing diagnostics almost never do this. They produce a score, or a list of 400 issues sorted by a tool’s own severity guess, and then stop. The person is left holding a number and no next step, which is why most audits get read once and filed.

The money tree is built to route. Each of the six defects has exactly one destination, and the table under the diagram states it plainly: a bare branch is a content problem, a split URL is a plumbing problem, an inverted tree is a strategy problem, a canopy with no branches is a personal-brand problem, shallow roots is an entity problem. The Quick Audit is the intake desk — free, and it exists to produce the diagnosis, not to sell you the first thing on the list.

This is just MAA with the Action step made physical

Every instrument we build is the same loop in a different costume, which is why the Metrics, Analysis, Action triangle keeps showing up. The leaf counts are the Metrics. The six defects are the Analysis. The routing table is the Action — and a routing table is a better Action than a recommendation, because it survives being read by someone who was not in the meeting.

The failure mode we are designing against is an MAA loop that stops after Analysis. That is what a dashboard is: metrics and analysis with the action left as an exercise for the reader. It feels rigorous and it changes nothing. Any instrument we publish has to close the loop or it does not ship.

Giving away the skill does not cost us the work

The obvious objection is that publishing a complete, runnable skill file cannibalises the paid service. It does not, and we have already run this experiment. Second Ring — our consent-first network mapping tool — publishes its audit parser, its evidence-scoring rules and its test results under Apache-2.0, and sells the hosted workspaces, the permissioned contributor graph and the human coordination on top. The open-core write-up puts it in one line: free intelligence, paid coordination and distribution. The code can be copied; the relationships cannot.

The money tree divides the same way. The measurement is deterministic — crawl, extract, invert, count. Any competent agent can do it, this month more easily than last month, and pretending otherwise just makes us look like we are hiding something trivial. What is not deterministic is the part after the diagnosis: deciding which bare branch is worth feeding first, writing a customer story that a stranger believes, consolidating a split URL without losing rankings, and doing it every month until the tree changes shape. That is judgement and follow-through, and it is what people actually pay for.

There is a second reason, and for us it is the bigger one. Publishing the method is how the AI Builder Program works at all. We are trying to create a million digital marketing jobs. You cannot train young adults to do this work using material you refuse to publish. Every skill file we release is simultaneously a lead magnet, a training asset and a hiring filter — the people who run it before talking to us are the people we want to work with.

The rule this generalises to

Any time we demonstrate something, the demonstration ships with both halves:

1. The how — the skill file, the AI-readable metadata, and the definitive article, so a human or an agent can reproduce the result without us. Our own publishing standard already requires all three artifacts together: a skill is not done until it has a page.
2. The door — the free audit that produces the diagnosis, and the routing table that says which service each finding belongs to.

A demonstration with only the first half is a blog post. With only the second half it is an advert. With both, it is an instrument — and an instrument is the only one of the three that a stranger will still be using next month.

This is why every site in our fleet gets its own money tree rather than a link to ours. A tree that lives somewhere else is a report about you. A tree on your own domain, with your own offers as the branches and your own posts as the leaves, is part of your site — and it is the page that shows a human and a language model, in one screen, who you are, how you work, what you sell, and what evidence sits under each claim.

Related

• The SEO Tree — the framework the money tree is built on, and how content should connect.
• Money pages versus blog posts — what makes a page a money page, and why turning one into a post costs you.
• The Nine Triangles — GCT, AEC and MAA, the first principles the tree renders.
• How to create a definitive article — how a branch earns the right to be a branch.
• Entity linking — the rules for which link goes where.
• The Content Factory — where the leaves come from.
• Second Ring — the same open-core pattern applied to relationship mapping.
• The skill publishing standard — why every skill ships as a file, an article and a page.