Your Sitemap Is Not Your Information Architecture

A list of URLs tells you what you're publishing. Good information architecture determines how someone gets from a problem to a decision.

You can spend weeks researching keywords, organizing hundreds of URLs, and building a perfectly logical sitemap.

Then discover your website makes absolutely no sense to the person using it.

I've spent much of my career building businesses where content and discovery drive growth. One lesson has stuck with me: The way you organize information can be just as valuable as the information itself.

A sitemap is an inventory. Information architecture is the experience.

Start Where the Customer Starts

When we began building Rose Cove, we didn't start with financial products. We started with the problems people recognize.

I need to borrow money. My payments are too high. I need to get out of debt.

Then we mapped what someone might do next, what they'd need to understand, and where they'd go for answers.

What became obvious was how quickly most experiences pushed people toward products.

But someone who needs money might consider a cash advance, credit card, personal loan, or home equity line of credit. The right path depends on urgency, credit, homeownership, and other circumstances.

Products are often answers to questions the consumer hasn't finished asking.

We chose an outcome-first architecture because it better reflected how people actually make decisions. It also opened up a much broader universe of discovery searches, rather than competing exclusively for product-focused keywords.

And with AI increasingly answering commodity product questions, I believe the opportunity to create differentiated value is moving further upstream.

Every Page Needs a Job

A sitemap alone couldn't support the experience we wanted.

We created page archetypes, each with a defined purpose, permitted language, component structure, and rules for connecting to other pages.

Even verbs mattered. We reserved words like compare for pages actually designed to compare alternatives.

Definitions belonged in a glossary. FAQs had to address questions specific to their page. We didn't need another generic article explaining what a personal loan is.

The goal wasn't more content. It was less ambiguity.

We also designed pages for people with short attention spans: answer first, explain second, and use visual components to make complex information easier to understand.

These standards weren't just about consistency. They created a foundation we could scale across hundreds of pages and eventually other verticals.

A Spreadsheet Won't Show You the Dead Ends

This was the hardest part.

You can stare at URLs all day and convince yourself the architecture works. Then draw the journey and discover otherwise.

Consider:

/borrow-money/bad-credit

/personal-loans/bad-credit

Both seem reasonable. But do they answer different questions? Which one owns the intent? How should a consumer move between them?

We sketched journeys on paper, stress-tested them using AI, challenged assumptions with a synthetic consumer research panel, and evaluated readability and comprehension.

The process exposed overlapping pages, missing connections, and product-first dead ends. We pruned URLs, shifted emphasis, and redesigned pathways.

We also learned that people don't always move straight down a funnel.

Sometimes they need to explore another option. Sometimes they need more context before proceeding.

Good architecture helps people move down, across, or back up without getting lost.

I've Seen the Value Compound

At Nitro College, we took a lengthy government FAFSA resource and broke it into individual questions with context and guidance. That experience went on to rank ahead of the government source for relevant searches.

At Sallie, we reorganized scholarship content around scholarship types and consumer behavior across the journey. New content began ranking quickly, helping establish visibility for the vertical on sallie.com.

Neither example proves architecture alone drove search performance. But both reinforced something I've come to believe: Being the source of information isn't the same as creating the best experience for it.

Search engines benefit from clear hierarchy, differentiated page intent, and meaningful internal links. AI-powered search also benefits from content that's easy to interpret and extract answers from.

But those are supporting principles, not the reason to build the experience.

The customer is.

Information architecture takes time. Weeks, in our case. It's tedious work involving diagrams, rules, testing, and decisions about what not to publish.

Yet getting it right makes everything that follows easier: content creation, SEO, user experience, and expansion into new markets.

Keyword research tells you what people ask. A sitemap tells you what pages exist. Information architecture determines how those pages work together.

The sitemap is the inventory. The architecture is the experience. Don't confuse the two.