01
02
03
04Sections
A confusing website is usually a structure problem that shows up as a writing problem. Too many audiences, unclear offers, mixed maturity levels and scattered proof all land on the page before anyone has agreed what the site should help a visitor decide. Fix the information architecture first and the copy gets a job it can do.
Information architecture is the set of decisions about what belongs where, what leads, what sits deeper and how one page relates to the next. For a science-led or B2B climate company that serves buyers, investors, technical reviewers and partners at once, those decisions come before the final copy. The same pattern is covered from the reader's side in why climate and science websites become hard to navigate.
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. Each page may be accurate, and a visitor still cannot find the answer to their question. Accuracy is the entry ticket. Usability comes from 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. Large publishers face this too. The team behind the GOV.UK Service Manual has written about improving the manual's own guidance and navigation, and a growing company's website needs the same periodic restructuring.
Map the organisation before the website
Before anyone draws a sitemap, the leadership team needs answers on a short set of business questions. What the company sells and which offers are core. Which audiences matter most this year. What stage each product or market has reached. Which claims need evidence and what proof already exists. Which pages exist because a team owns them and no visitor needs them.
If those answers are unclear, a sitemap workshop will reproduce the confusion in boxes. This is the step where website projects most often turn out to be positioning projects, and it is cheaper to find that out before design starts. We wrote about the underlying problem in offer architecture.
Two cases where the structure had to change first
Fair Carbon works in blue carbon. Its site had to serve project leaders, investors, validators and accreditation bodies, and the routes for those groups had become hard to follow. Each audience arrived with a different decision to make and met the same tangle of pages. Our work with Fair Carbon covered strategy, research, identity, web and launch, in that order. Who the site served and what each group needed next was settled before any page was written.
Fronterra shows the same problem from another angle. The company develops and operates forest carbon and biodiversity projects in Peru, and its public face read like a mission-led initiative. Shorter copy alone would have left that impression in place. Repositioning Fronterra as a principal operator meant the hierarchy itself had to surface the operator, the projects, the evidence and the commercial proposition. Once the architecture carried that, the copy had a job it could perform.
Give each page one main job and disclose depth gradually
Most B2B climate and science websites need to do some combination of five jobs.
- Orient
- Recognise
- Explain
- Prove
- Move
Orient tells the visitor what the company is and why it matters. Recognise shows each audience that the company understands their problem. 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. 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. 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 it deserves more than a disclaimer at the foot of the page.
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 that 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. 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. Predictability is the test.
Ecommerce research is useful here because retailers measure navigation failure in lost sales. Baymard Institute publishes a body of research on ecommerce homepage and category navigation, with its methodology published alongside. A climate company with four products and three audiences faces a smaller version of the same problem, and the same habit of plain, predictable category names helps.
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 this kind of exercise as tree testing, used to evaluate menu labels and categories. Ask them to find the following.
- What the company sells.
- Whether it works for their use case.
- The strongest proof.
- The technical detail.
- The right next step.
If they struggle, visual polish will only make the confusion look finished. Fix the structure, test again, then write. Information architecture is strategy made navigable. A site feels simple when someone has decided what leads, what supports, what belongs deeper and what no longer earns a place, and the copy gets much easier once those decisions are made. The companion piece on why climate tech websites look like NGOs covers the signals the finished pages send.
If your site has grown by accretion and nobody can say what it is for, our website work starts with the architecture.
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