Restructuring a website with the decision ladder: a measured case

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:

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:

1. 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.
2. 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.
3. Orient moved down. The two Orient articles at tier one became tier two, under the tier-one articles whose terms they define.
4. 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.

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.

1. List every URL in one cluster, and mark each as pillar, tier one or tier two.
2. 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.
3. Count tier-one and tier-two pages that carry a contextual link back to the pillar.
4. 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.

Frequently asked questions about this case

These are the questions readers ask most often about this Decision Ladder Navigation case study. Each one is answered directly from the deposited specification, in a few sentences, so that the answer can be read, quoted and cited on its own without the rest of this page.

Did the DLN rebuild increase traffic or rankings?

This case does not say, because it was not measured in a way that could be quoted. The rebuild ran alongside other publishing on the same site, so traffic, rankings and revenue could not be attributed to it. The case reports structural outcomes only.

Which link was missing before the rebuild?

The missing link was the one from each tier-two article up to the tier-one article it supports. On 14 September 2026 only 2 of 50 tier-two articles had it; after the rebuild, 40 of 40 did.

Why did hand-written links fail?

Hand-written links failed because each one was added to one article at a time by whoever was editing it, and a forgotten link raises no error. Moving the cluster map into one table and generating the links from it removed that failure.

Why are step-up rates not reported in this case?

Step-up rates are not reported because the site did not have them instrumented at the time of the rebuild. The framework names them as the primary metric, so their absence is a gap in this case, not an argument against the metric.

What happens when the cluster map breaks a rule?

When the cluster map breaks a rule, the build stops. A URL in two places, a pillar inside its own cluster or a missing rung fails the build instead of shipping quietly.