Restructuring a site around Decision Ladder Navigation™ costs one labelling pass over every main URL, one link map with five columns, and usually two new pages. Nothing on this page is for sale, so the cost here is counted in units of work rather than in currency. Count the units first and you will know within an hour whether the work is worth starting.
What you are paying for, when nothing is being sold
The Rate rung of Decision Ladder Navigation answers what something costs. On a site that publishes a framework rather than selling a service, that cost is not money, and pretending otherwise would be the exact failure this rung exists to prevent. What you are paying is attention, decisions and rework, and all three can be counted before you commit any of them.
Three kinds of cost appear in every restructure of this shape:
- Decision cost. Someone has to say what each page is for. This cannot be delegated to a crawler and it cannot be done page by page as you go, because the decisions interact.
- Writing cost. The gaps the labelling pass exposes are almost always the same two pages, and they have to be written rather than rearranged.
- Rework cost. Changing URLs, updating internal links and handling redirects. This is the part that gets underestimated and the part that hurts when it is wrong.
The five drivers of the cost
Five things drive the cost of restructuring around Decision Ladder Navigation, and only one of them is the number of pages. Read down the list and mark which ones apply to you, because a site that triggers one driver is a week of work and a site that triggers four is a different project.
| Driver | Cheap when | Expensive when |
|---|---|---|
| Number of main URLs to label | Under about 40, one person can hold the whole map in their head | Hundreds, and the map has to become a file before it becomes useful |
| How many pages hold two rungs | Few, and splitting them is an editing job | Many, because each split is a new URL, a new redirect and new links |
| Whether URLs have to change | Labels change but addresses stay, so no redirect work at all | Addresses move, which pulls in redirects, internal link rewrites and sitemap changes |
| Whether the links are data or prose | Links are generated from one table, so a change costs one edit | Links are hand-written into articles, so every change is as many edits as there are articles |
| Whether a Rate page already exists | There is a page with actual prices or actual cost drivers on it | Price has been avoided, so a page has to be written and a decision has to be made before it can be |
The fourth driver is the one that compounds. A site whose internal links are prose pays the labelling cost once and the maintenance cost forever, because every later change reopens every article.
A unit-count estimate you can do in twenty minutes
An estimate in units of work transfers between teams in a way that an estimate in hours does not. Count these five numbers for one cluster, and you will have a description of the job that anyone can price against their own rates.
- URLs to label. Every page that a visitor can reach from the menu or from search. One decision each.
- Pages holding two rungs. Each one becomes two pages, so count it twice: once as a split and once as a redirect.
- Links to map. One row per link, five columns each: anchor text, context sentence, from URL, to URL, rung. Links with no role do not get a row and do not get built.
- Pages to write. Usually the Rate page and the Act page. Count any rung with zero pages as one page to write.
- Redirects to configure. One per URL that moves, plus one per page that gets split.
The case study on this site gives one worked example of those counts on a 60-page cluster, including the count that turned out to be the blocked one.
What is in scope and what is not
Scope is where restructures overrun, because the labelling pass exposes every other problem the site has at the same time. Decision Ladder Navigation is a structure framework, so the boundary is drawn at structure, and everything the pass merely reveals belongs to a different piece of work.
| In scope | Not in scope |
|---|---|
| Assigning one decision role to each main URL | Rewriting the body copy of pages that are already on the right rung |
| Splitting pages that hold two rungs | Redesigning the visual design of any page |
| Building the five-column link map and the links it specifies | Acquiring external links |
| Writing the pages that a missing rung requires, usually Rate and Act | Building the product or service those pages describe |
| Menu labels, breadcrumbs and the next step on each page | Migrating platforms or changing the content management system |
| Redirects for URLs that move as part of the restructure | Cleaning up redirects that were already broken before the work started |
Write the boundary down before starting. The labelling pass will find thin pages, duplicate pages and pages nobody remembers commissioning, and every one of them is a real problem that is not this problem.
The most expensive part, and how to avoid paying for it twice
The most expensive part of this work is changing URLs, and the expense is not the redirect itself. It is that a URL appears in more places than anyone expects: in the body of other articles, in the sitemap, in structured data, in a stylesheet selector, in course material, and in whatever else was written before anyone thought the address was permanent.
On this site, moving one page to a shorter address touched 205 references across 107 files, and one of them was an attribute selector in a stylesheet that the first pass missed because it was only looking at content and templates. A redirect covered the reader-facing case, but the stylesheet rule stopped matching and a button lost its styling silently.
Two habits keep that cost down. Decide the address at the same time as the decision role, so a page moves once rather than twice. And search for the old address everywhere, not only where content lives, because the places that will not raise an error are exactly the places worth checking.
Why no hour figure is published here
There is no hour range on this page, and the reason is that publishing one would be inventing it. The only implementation data available to the author comes from a single site, rebuilt by one person with heavy tooling assistance, over a small number of days. That is one data point from one unusual setup.
An hour figure taken from that and printed here would look like a benchmark and would behave like a guess. It would also be the wrong shape of answer: the variance between a 40-page site with stable URLs and a 400-page site whose addresses all move is far larger than anything an average could carry.
The unit counts above are published instead, because they transfer. Count your units, apply your own rate, and you have a number that describes your site rather than someone else's.
Questions about what a restructure costs
Four questions come up whenever someone prices this work: whether a restructure can be split across clusters, what the smallest version worth doing is, whether it needs a developer, and whether any of this is a sales page for a service.
Can this be done incrementally, one cluster at a time?
Yes, and one cluster at a time is the recommended order. Pick the cluster around your most important pillar, finish it completely, and measure the four rails before starting a second one. A half-finished restructure across five clusters is harder to reason about than an untouched site.
What is the smallest version of this work that is still worth doing?
Apply the two operating rules and stop there. Give every main URL exactly one decision role, and give every page exactly one next step. That is a day of work on a small site, it needs no link map and no new pages, and it removes the two failures that cost the most.
Do I need a developer?
Only for the fourth driver. Labelling, splitting and writing are editorial work. Turning the link map into generated links rather than hand-written ones is a build-time change, and that is the part that decides whether the maintenance cost is one edit or fifty.
Is there a paid service behind this page?
No. This page and the framework it belongs to are published so that the method spreads, and applying it in your own work, including paid client work, needs no permission. The Rate rung is here because the framework requires every ladder to answer what the work costs, not because something is being sold.