This is the site you are reading. On 14 September 2026 its largest content cluster had 60 pages and one blocked rail: only 2 of 50 supporting articles linked up to the article they supported. Rebuilding the cluster around Decision Ladder Navigation™ took that rail from 2 of 50 to 40 of 40. Every number below can be re-measured from the live site.
What was measured, and on what
The subject of this case is danhnolan.com, a Vietnamese SEO publication with roughly 1,500 pages. The cluster rebuilt was the one around its course hub, which at the time held one pillar, ten tier-one articles and fifty tier-two articles. Measurement ran against the built output, not against the content database, because what a reader receives is HTML.
Three things make this case checkable rather than merely reported. The cluster map lives in one file in the repository, so the structure is data and not an opinion. The before figures were taken before any change was made and written down on the day. And the after figures come from the same script run against the deployed site.
One caution belongs here rather than at the end. This case documents a structural change and measures structural outcomes. It does not report traffic, rankings or revenue, and the sections below do not claim any.
The blocked rail: tier two never linked up
The blocked rail in this cluster was the link from a tier-two article to the tier-one article it exists to support. Decision Ladder Navigation treats that link as mandatory, because a definition page that does not return the reader to the decision it was explaining has ended the journey instead of continuing it.
Measured before the rebuild, on 14 September 2026:
| Check | Before | What it means |
|---|---|---|
| Tier one linking back to the pillar | 8 of 10 | Two tier-one articles were orphans from the pillar's point of view |
| Tier two linking back to the pillar | 44 of 50 | Six supporting articles sat outside the cluster in practice |
| Tier two linking up to its tier-one parent | 2 of 50 | The rail was 4 percent built |
| Orient articles sitting at tier one | 2 | Against the rule that Orient is the foundation layer, not the top |
| One URL occupying two places in the tree | 1 | The navigation had no way to decide where to send it |
| Tier-two entries that were not explanatory articles | 11 | Seven course pages, a booking page and three others filed as definitions |
The 2 of 50 is the finding. Every other number on that list is a symptom of the same cause, which is that the links had been written by hand into individual articles, one at a time, by whoever happened to be editing that article.
What changed: one table instead of sixty hand-written links
The change that produced the numbers below was not a writing project. Sixty links written by hand are sixty places to forget, and forgetting does not raise an error. So the cluster map moved into a single declarative table, and the links that the framework requires are generated from it at build time.
Four decisions carried the rebuild:
- One source for the cluster. Pillar, tier one by rung, and tier two under each tier-one article, all in one file. Changing a member changes every page that mentions it.
- The build stops on a violation. A URL in two places, a pillar inside its own cluster, or a missing rung all fail the build rather than shipping quietly.
- Orient moved down. The two Orient articles at tier one became tier two, under the tier-one articles whose terms they define.
- Non-explanatory pages left the cluster. Seven course pages and a booking page stopped being filed as definitions. No link to them was removed; they simply stopped carrying a navigation strip that promised an explanation.
The numbers after the rebuild
These figures were taken from the built output and from the deployed site, and both agreed. The cluster finished at 8 tier-one articles, spread three at Choose, two at Prove, two at Rate and one at Act, with 40 tier-two articles beneath them.
| Check | Before | After |
|---|---|---|
| Tier two linking up to its tier-one parent | 2 of 50 | 40 of 40 |
| Tier one linking back to the pillar | 8 of 10 | 8 of 8 |
| Tier two linking back to the pillar | 44 of 50 | 40 of 40 |
| Pillar linking down to tier one | Not structured | 8 of 8 |
| Pages carrying the navigation strip | 0 of 48 | 48 of 48 |
| Pages in the cluster not returning 200 | Not measured | 0 |
| Sections on landing pages that answer their own heading | 97 of 161 | 101 of 161 |
The last row is the one worth reading twice. Structure work improved a content measure, because four headings that had been introduced by a label rather than by an answer were rewritten as part of the same pass. It also shows the limit of the change: 60 of 161 sections still did not answer their own heading afterwards.
A second finding, five days later
On 19 September 2026 the same cluster map was checked again, this time for the framework's own definition page. The page defining Decision Ladder Navigation was filed as a tier-two article inside a different cluster, sitting beneath an article about growth operations as a supporting definition.
That is worth recording because of what it demonstrates rather than because of its size. The framework had been applied to nine clusters on the site, and the page that defines the framework was the one page not built with it. Nothing about the structure reported an error, because the structure was internally consistent. It took reading the map for a different purpose to see it.
The fix was to move the page to a top-level URL, where every other pillar on the site already lives, and to publish the specification itself as its own entry point. A redirect covers the 93 internal links that pointed at the old address.
What this case does not show
This case reports structural outcomes and nothing else, and the distinction matters more than the numbers do. A reader deciding whether to spend a week on their own site deserves to know which questions these figures answer and which ones they leave open.
Not reported here, because it was not measured in a way that would survive being quoted:
- Organic traffic before and after. The rebuild ran alongside other publishing on the same site, so no clean attribution is available.
- Ranking positions. Same reason, and positions move for reasons unrelated to internal structure.
- Conversion or revenue. The cluster rebuilt is a course hub, and no isolated measurement of enrolment against structure exists.
- Step-up rates along the four rails. The framework names these as the primary metric, and this site did not have them instrumented at the time of the rebuild. That is a gap in the case, not an argument against the metric.
A framework that only ever reports its wins is not evidence, it is advertising. The honest summary is that the structure went from partially built to fully built, that the state is verifiable on the live site today, and that the business outcome of that change is not established by this case.
How to reproduce this measurement on your own site
Reproducing these figures needs a crawl and four counts, and no part of it depends on the tooling used here. The point of writing the checks down is that a reader can run them before deciding whether any of this applies to them.
- List every URL in one cluster, and mark each as pillar, tier one or tier two.
- Count tier-two pages that carry a contextual link to the tier-one page they support. This is the rail that was 4 percent built here.
- Count tier-one and tier-two pages that carry a contextual link back to the pillar.
- Count pages in the cluster that nothing links to at all.
If the second count is the low one, the cause is almost always the same as it was here: the links exist as an intention rather than as data, so nobody can tell which ones are missing.