INFORMATION ARCHITECTURE

A site structure built around how your visitors think, not how your business is organised

Most websites in Nepal are structured around internal departments, donor reporting categories, or product catalogues that mirror back-office systems. Visitors arrive with a question and leave without an answer because the navigation was never built for them. We restructure your site from the visitor's point of view, producing a sitemap and content hierarchy that makes the right page findable on the first attempt.

Sitemaps delivered before a single design file is opened · Content audits that surface duplicate and orphaned pages · Navigation labels tested against how real visitors describe what they need · Handover documentation your developer and designer can act on immediately
This is for you if

Information architecture work is right for you if any of the following describes your situation.

Your website navigation reads like your staff directory. Visitors see department names, programme codes, or internal team labels that mean nothing to someone arriving from a search result. The site makes complete sense to your team and almost none to anyone else. This is the most common structural problem we encounter with NGO and service-sector sites in Nepal, and it is entirely fixable before design or rebuild begins.

The site has grown over years. Pages exist for every project, every report, every event. There is no internal linking strategy. A visitor who lands on one page has no guided path to related content or to an enquiry form. Search engines cannot determine which pages matter. Content keeps accumulating but the site keeps underperforming.

You have a brief for a new website. A developer has been shortlisted. Design work is about to start. What has not been done yet is the structural work: deciding what pages the site needs, how they relate to each other, what the navigation should say, and how a visitor moves from arrival to conversion. Starting design before that is decided produces a site that looks polished but functions poorly. IA work done first means every design and development decision has a clear structure to follow.

What's broken

These are the four structural problems we find most consistently on Nepali websites.

Navigation labels built for insiders

Menus use terms like "Programme Areas," "Thematic Clusters," "Vertical Units," or product codes that staff use internally. A visitor searching for a specific service or answer does not know which label to click. The site requires insider knowledge to navigate, and most visitors do not have it.

No clear path from landing page to enquiry or action

A visitor arrives on a page, reads it, and then has no obvious next step. There is no link to a related service page, no prompt toward a contact form, no logical continuation of the journey. The site presents information but does not guide the visitor anywhere. Conversion rates stay low not because the offer is weak but because the path is missing.

Duplicate pages on the same topic with no internal linking

The site has three pages about the same service, written at different times by different people, none of which links to the others. Search engines split ranking signal across all three. Visitors who find one never discover the others. This is a structural problem, not a content problem, and it requires a sitemap decision, not more writing.

A URL structure that resets with every site rebuild

Each time the site is rebuilt, URLs change. Old links break. Search rankings reset. Any backlinks earned by the previous site stop working. A deliberate URL structure, set before the build begins, persists across redesigns and protects the search visibility the site has accumulated.

What we engineer

An information architecture engagement covers seven deliverables, each building on the last.

Discovery Workshop

A structured session with your team to understand your audience, their questions, your business goals, and the constraints your site currently operates under. This session determines the scope and direction of all subsequent IA work.

Content Audit (Existing Sites)

A full inventory of every page currently on your site: what exists, what is duplicate, what is outdated, what is orphaned, and what should be consolidated, redirected, or removed. For organisations with large legacy sites, this audit alone reveals structural problems that no redesign brief has ever captured.

User Journey Mapping

We map the paths your visitors take: where they enter the site, what questions they are trying to answer, what actions they want to take, and where the current structure forces them off the path. The output is a set of journey maps that inform every structural decision that follows.

Sitemap Document

A complete, annotated sitemap showing every page the site should contain, how pages are grouped, what the hierarchy is, and how sections relate to each other. This is the foundational document that design and development work from.

Navigation Label Recommendations

Specific label recommendations for primary navigation, secondary navigation, and footer links, written in the language your visitors use rather than your internal terminology. Where relevant, we provide label testing results from card sorting or tree testing exercises.

Page Template Outlines

For each key page type, a content zone outline showing what content belongs on the page, in what order, and what each zone is meant to accomplish for the visitor. These outlines guide content writing and design layout decisions.

URL Structure and Internal Linking Plan

A recommended URL architecture that is logical, stable across rebuilds, and consistent with how the sitemap is organised. Accompanied by an internal linking strategy that connects related pages and guides visitors and search engines through the site's priority content.

What changes

After an IA engagement, four things are measurably different about how your site performs.

Before
After
Before Menus use terms like "Programme Areas," "Thematic Clusters," "Vertical Units," or product codes that staff use internally. A visitor searching for a specific service or answer does not know which label to click. The site requires insider knowledge to navigate, and most visitors do not have it.
After When the site is structured around visitor questions rather than internal categories, people stop leaving the site in frustration. Pages that answer specific questions become findable from the navigation, not just from search.
Before A visitor arrives on a page, reads it, and then has no obvious next step. There is no link to a related service page, no prompt toward a contact form, no logical continuation of the journey. The site presents information but does not guide the visitor anywhere. Conversion rates stay low not because the offer is weak but because the path is missing.
After The user journey mapping and internal linking plan ensure that no page is a dead end. Visitors are guided from informational pages toward contact, enquiry, or purchase pages in a way that feels logical rather than pushed.
Before The site has three pages about the same service, written at different times by different people, none of which links to the others. Search engines split ranking signal across all three. Visitors who find one never discover the others. This is a structural problem, not a content problem, and it requires a sitemap decision, not more writing.
After A clear sitemap, a logical URL structure, and a deliberate internal linking strategy give search engines a coherent picture of what the site is about and which pages are most important. Rankings for priority pages improve because ranking signal is no longer diluted across duplicate content.
Before Each time the site is rebuilt, URLs change. Old links break. Search rankings reset. Any backlinks earned by the previous site stop working. A deliberate URL structure, set before the build begins, persists across redesigns and protects the search visibility the site has accumulated.
After When designers and developers receive a completed sitemap, page templates, and navigation labels before they begin, they make fewer structural decisions mid-project. Scope does not expand because someone in week three asks "do we need a page for this?" The answer is already in the sitemap.
How it works

Process

  1. 01

    Diagnostic

    Week 1

    We review your existing site, identify the top structural problems, and confirm the scope of the engagement. You receive a one-page summary of what we found and what the IA project will address.

  2. 02

    Research and Audit

    Weeks 1 to 2

    Discovery workshop with your team, content audit of the existing site, and user journey mapping based on your audience and goals. This phase produces the raw inputs that all structural decisions are built on.

  3. 03

    Sitemap and Architecture

    Weeks 2 to 3

    We build the sitemap document, navigation labels, page template outlines, and URL structure. Each element is reviewed with your team before it is finalised.

  4. 04

    Handover

    Week 3 to 4

    All deliverables are packaged into a handover document your designer and developer can act on immediately. We walk your team through the structure in a handover session and remain available for questions during the design phase.

Common questions

Frequently asked questions about Information Architecture

Does an IA engagement require us to rebuild the site from scratch?

Information architecture work is independent of whether you rebuild or restructure an existing site. The sitemap and structural recommendations apply equally to a full rebuild, a redesign of an existing site, or a phased restructure where you reorganise content without changing the design. We make a recommendation based on what we find in the content audit.

How long does an IA project take?

A standard IA engagement takes three to four weeks from kick-off to handover. Larger sites with hundreds of existing pages may take five to six weeks if the content audit phase requires more time. We confirm the timeline during the diagnostic before the engagement begins.

What is the difference between a sitemap and a wireframe?

A sitemap defines what pages exist and how they relate to each other. A wireframe defines what content and layout elements appear on a specific page. IA work produces the sitemap. Design work produces wireframes. The sitemap must exist before wireframes are useful, because you cannot design a page well until you know what its role is in the overall structure.

Do you run card sorting or tree testing with real users?

Card sorting and tree testing are included in engagements where the audience is accessible and the navigation decisions are genuinely uncertain. For most projects, we use a combination of existing analytics data, competitor analysis, and the discovery workshop to inform navigation labels. We will recommend user testing if the site structure is complex enough to warrant it.

Will the IA work be handed over in a format our developer can use?

All deliverables are delivered as structured documents your developer and designer can read and act on without interpretation. The sitemap is delivered as a visual diagram and a written document. Navigation labels, page templates, and URL structure are provided as annotated reference documents. We also offer a handover session where we walk through the deliverables with your team.

Our team

The people behind the work

Not a black box. Real specialists you can call, with their names on the work.

Niraj Raut

Niraj Raut

Founder — Ecommerce SEO
Keshab Joshi

Keshab Joshi

PPC Expert
Hawrry Bhattarai

Hawrry Bhattarai

Google Ads Expert
Arogya Rijal

Arogya Rijal

SaaS SEO Expert
Start here

Your site structure is either working for your visitors or working against them

If your navigation reflects how your organisation is structured rather than how your visitors think, the problem is not your content or your design. It is the architecture underneath them. We diagnose the structural issues, build a sitemap that makes sense for your audience, and hand over a document your designer and developer can build from immediately.