Sections
The guide in short
- Map the organisation firstAgree offers, priority audiences, maturity and proof before any sitemap.
- Give each page one jobOrient, recognise, explain, prove or move, with depth one click deeper.
- Show maturity and proof where doubt arisesLabel commercial, pilot and research status on the page that makes the claim.
- Name navigation in the visitor's wordsUse nouns a visitor can predict and leave room for what comes next.
- Test the structure before designAsk an outsider to find the offer, the proof and the next step from the sitemap alone.
Fair Carbon works in blue carbon, one of the most technically difficult areas of nature finance. When Fair Carbon came to us, its original platform had routes for project leaders, investors, validators and accreditation bodies, alongside maps, guidance, resources and project information. Nothing was missing. The difficulty, as we set it out in our Fair Carbon case study, was how those pieces worked together. Navigation had become hard to follow, important information was spread across the platform, and visitors had to work to see where they belonged and how the parts of Fair Carbon connected. The audiences themselves were already known, so the work was to organise the site around them.
In our interview with John Vermilye, a co-founder of Fair Carbon, published in February 2024, he set out who those audiences were. "The primary beneficiaries of Fair Carbon are the community-driven projects focused on protecting and restoring blue carbon ecosystems such as mangroves, seagrass, and salt marshes." And on the other side of the market, "The second group of beneficiaries includes the demand side, namely the buyers." He was describing his organisation's purpose, and the description already held the split a sitemap needs. The organisation knew who it served, and the site had to be rebuilt around what each of them came to do. Our research and workshops with the team set out the audiences and what each needed before the identity or the site was touched, and that work became the basis for the story, the identity and the digital experience. Where those answers are unclear, a sitemap workshop reproduces the confusion in boxes.
Why complex companies accumulate pages
Websites grow by accretion. A new product gets a page. A funding round adds an investor section. A new market creates another use case, the technical team asks for a science page, marketing adds resources and partnerships add programme pages. Nobody removes the old material. After a few years the navigation mirrors the organisation chart, and each page may be accurate while a visitor still cannot find the answer to their question. Accurate pages are the minimum. A site becomes usable through the order the pages sit in and the paths between them.
Different visitors arrive with different questions. A buyer wants to know whether this solves an operational problem. An investor is weighing whether this is a credible company and opportunity. A technical reviewer wants to inspect the mechanism and the evidence, a partner is looking for where they fit, and a candidate wants to know what the company is trying to build. The site needs one clear front door and paths that deepen from there.
Map the organisation before the website
Before anyone draws a sitemap, the leadership team needs to answer five business questions. The first is what the company sells and which offers are core. The second is which audiences matter most this year, and the third is what stage each product or market has reached. The fourth is which claims need evidence and what proof already exists. The fifth is which pages exist because a team owns them and no visitor needs them. Brighter Future does not start a sitemap or a design until leadership has answered all five. This is the step where a website project can turn out to be a positioning project, and it is cheaper to find that out before design starts. Our piece on offer architecture covers the underlying problem.
The same order holds when the organisation is new. The Decision Room, which convenes closed-door capital conversations in Zürich, needed a site to explain the model, show what was still forming, route different participants and carry the organisation from one annual edition to the next. Our case study records that the site grew from a single page in May 2026 to 18 pages by September. Each of those jobs was a business decision about the model before it was a page.
Give each page one main job and disclose depth gradually
- Orient
- Recognise
- Explain
- Prove
- Move
Most B2B climate and science websites need some combination of those five jobs. Orient tells the visitor what the company is and why it matters. Recognise shows each audience that the company understands its problem, and at Fair Carbon we wrote that job down audience by audience. Project developers needed guidance, buyers and investors needed confidence, policymakers needed evidence and market context, and the wider ecosystem needed accessible knowledge. Explain makes the product and mechanism legible. Prove surfaces evidence, deployments, science and track record. Move makes the sensible next step obvious. Every major page should have one dominant job from that set, because a page that tries to do all five equally becomes long and vague.
Depth then works in layers. Interface designers call this progressive disclosure. For a technical company it means the proposition and the strongest proof sit high, with technology, science and deployment detail one click deeper. The commercial reader learns whether the product matters without learning every mechanism first, and the technical reader can still reach the detail past the marketing layer.
Make maturity and proof visible where the doubt arises
Science-led sites often blur what is commercially available, what is in validation, what is in research and what is still planned. That blur creates avoidable credibility risk, especially with investors who will check. Explicit labels such as commercial, deployed, pilot, validation, co-development, research and planned belong on the product and project pages where the reader forms a view. Maturity is part of the information architecture and deserves a place on the page, well above any disclaimer at its foot.
Proof works the same way. A single large "Proof" page leaves the rest of the site abstract. If buyers doubt performance, put performance evidence beside the product claim. If investors need evidence of execution, show deployments near the investment case. If a scientific claim needs a method, link the method from the claim. The evidence page can still exist as the deep source the rest of the site points into.
Navigation should describe the visitor's world
Internal teams often want labels like "Solutions", "Capabilities", "Innovation" and "Ecosystem" because they feel broad enough to hold everything, and broad labels tell the visitor very little about what sits behind them. Prefer nouns a visitor can predict, such as Products, Applications, Technology, Deployments, Science, Company and Insights. The exact set depends on the business. The site we rebuilt for Fronterra, which develops and operates forest carbon and biodiversity projects in Peru, uses Company, Projects, Approach, Track record and Evidence, labels a buyer or investor can predict before clicking. Our piece on why climate tech websites look like NGOs describes how that rebuild made the operator visible.
The architecture also needs room for content that does not exist yet. A new programme, project or research stream should be able to enter a reusable structure without earning another top-level navigation item. Fair Carbon's site became a platform for projects, resources, research and future programmes, and the organisation has since grown around new programmes using the same digital language. Designing only around today's content reproduces the organisation chart every time the company grows.
The same discipline helps retrieval. Descriptive headings, explicit page subjects, crawlable evidence and one canonical page for each important question make the route through the subject clearer for people and for search or AI systems. In both cases a visitor should be able to find the answer without knowing the internal structure of the company.
Test the architecture before the design
Show someone outside the company the sitemap and a one-line summary of each page, with no visual design at all. Nielsen Norman Group describes tree testing as a way to evaluate menu labels and categories. Ask the person to find what the company sells, whether it works for their use case, the strongest proof, the technical detail and the sensible next step. If they struggle, visual polish will only make the confusion look finished. Fix the structure, test again, then write. A site feels simple when someone has decided what leads, what supports, what belongs deeper and what no longer earns a place, and once those decisions are made the copy has a job it can do.
Our website work covers this architecture, the copy and the design together, and can include the build. The Fronterra site was rebuilt around the questions its buyers and investors ask.
Sources and further reading
Tell us what needs to move.
Bring the brief if it is clear. If it is unclear, tell us where the work is stuck.
Bring us the problem
01
02
03
04
05