Most people think a website project is about design.
Fonts, colors, layout, photography. The visible stuff. The stuff you can react to and have an opinion about.
And fair enough — that’s the part you actually look at.
But the most important decision in any website project happens before any of that. And once the site is live, it becomes completely invisible. You’ll never see it. Your visitors will never see it. The only people who’ll ever notice it are you, two years from now, when you’re trying to publish your 87th blog post and everything either works smoothly or makes you want to throw your laptop out a window.
That decision is your site’s architecture. Specifically: how the content is organized.
It’s the skeleton everything gets built on top of. And like a skeleton, you only really notice it when something’s wrong.
What “site architecture” actually means
Let’s strip the jargon. Site architecture is just how you organize the stuff on your site.
Think of it like a library. A library could organize books a hundred different ways — by genre, by author, by publication date, by topic, by reading level. Each of those is a way of organizing. In website-land, we call those taxonomies, which is a fancy word for “a way of grouping things.”
A book can live under multiple taxonomies at the same time. To Kill a Mockingbird is fiction (genre), by Harper Lee (author), published in 1960 (date), about race and justice in the American South (topic), written for adults (audience).
Your website works the same way. Every post or page you publish gets filed under multiple groupings, which lets visitors and search engines find it from different angles.
That’s all architecture is. Decisions about how to group your stuff.
The thing is, those decisions cascade. Get them right, and everything downstream — design, SEO, user experience, internal linking, the editorial process — becomes easier. Get them wrong, and everything downstream becomes a fight.
Why it actually matters
Three reasons, in order of how often clients are surprised by them.
1. Search engines understand organized sites better.
Google (and the AI tools that increasingly stand between you and a visitor) can tell the difference between a site that’s a coherent collection of related content and a site that’s a pile of posts. Sites with clear groupings — “all the posts about cast iron cooking” or “all the 30-minute weeknight dinners” — get understood and ranked better than sites where everything’s just thrown into one bucket.
This isn’t about gaming algorithms. It’s about being legible. Architecture is how you tell a search engine what your site is about.
2. Visitors find more of what they came for.
When someone lands on your sourdough recipe and it’s clearly part of “twelve other bread recipes,” they read more. When they land on the same recipe with no visible context, they read it and bounce.
Good architecture makes those connections automatic. You don’t have to remember to link related content — the structure does it for you.
3. Internal linking, the SEO multiplier almost nobody talks about.
Search engines pay close attention to how the pages on your site connect to each other. Good architecture creates those connections naturally — every category page links to its posts, every post links back to its categories, every related post finds the others. Without architecture, you have to build all of this by hand, and almost nobody does.
Categories, tags, and the part most people get wrong
If you’ve used WordPress for any length of time, you’ve probably bumped into categories and tags. Both are taxonomies — just two different flavors.
Categories are the big buckets. Broad. They can have parent-child relationships (“Cooking” → “Baking” → “Sourdough”). A post usually belongs to one or two.
Tags are descriptive labels. Specific. Flat — no hierarchy. A post might have five or ten.
For a lot of sites, that’s all you need. Categories for the big stuff, tags for the details, done.
But for a lot of other sites, that’s where the trouble starts. Because there are usually multiple ways you’d want to slice your content, and trying to cram all of them into “categories” turns into a tangled mess very quickly.
That’s where custom taxonomies come in. Custom taxonomies are additional category-like systems that exist alongside the default ones. You can have as many as you need.
This sounds nerdy until you see it in action.
A worked example: the recipe blog
Let’s say you’re starting a recipe blog. You publish four kinds of content: individual recipes, weekly meal plans, kitchen equipment reviews, and how-to guides.
If you only used categories, you’d quickly hit a wall. Because the way you’d want to slice your content isn’t one-dimensional — it’s a few different dimensions at once.
Here’s how a thoughtful architecture might look:
- Content Type — Recipe, Meal Plan, Equipment Review, How-To
- Cuisine — Italian, Mexican, Thai, American, etc.
- Meal Type — Breakfast, Lunch, Dinner, Dessert, Snack
- Dietary — Vegetarian, Vegan, Gluten-Free, Dairy-Free
- Cook Time — Under 30 minutes, 30–60, Over an hour
- Tags — specific brands, ingredients, equipment, techniques
Now a single recipe — say, a 25-minute vegetarian Thai curry — can be filed under all five of those at once. And a visitor can find it whether they’re searching for “Thai recipes,” “vegetarian dinners,” or “weeknight meals under 30 minutes.” Three different searches, same recipe, all roads lead there.
That’s the magic of doing this right.
But here’s the part that’s just as important: knowing what not to add.
You could imagine adding a “Season” taxonomy — Spring, Summer, Fall, Winter — because some recipes are seasonal. Sounds reasonable. But in practice, very few recipes are strictly seasonal, and now every time you publish, you have to make a judgment call. Most posts will end up tagged “all seasons” because they technically work year-round, which means the taxonomy isn’t actually filtering anything. You’ve added work without adding value.
This is the trap. Every taxonomy you add is a small tax on every post you publish forever. If a taxonomy doesn’t pull its weight, it shouldn’t exist.
The rule most people get wrong
Here’s the single most useful thing I can tell you about architecture:
It’s much easier to add a taxonomy later than to restructure one later.
If we launch with five taxonomies and add a sixth in year two, that’s an afternoon of work. If we launch with a confused structure and have to re-categorize 200 posts in year two, that’s days of work and a lot of cursing.
So when there’s any doubt, start simple. Add complexity only when you can explain — out loud, in plain language — why you need it. “It might be useful someday” isn’t a reason. “I want to be able to filter by X because readers will look for that” is a reason.
The best architecture isn’t the most elaborate one. It’s the simplest one that still does what you need.
How I stress-test it before we build
Before I write a line of code on a content-heavy site, I do an exercise that takes about thirty minutes and saves about thirty hours later.
I take the proposed architecture and I ask the client to pick five hypothetical posts they’ll want to publish in the first year. Real ones. Specific titles. Then we file each one under every taxonomy we’ve decided to use.
If we can cleanly file all five — every taxonomy applies, no awkward forcing, no “well, this kind of fits but kind of doesn’t” — the architecture is solid.
If we get stuck on one of them, that tells us something important. Either the post doesn’t really fit the structure (and there’s a gap in our thinking), or the structure has a flaw (and we need to fix it before there’s content depending on it).
It’s not a fancy exercise. It’s just trying it before committing to it. But almost nobody does it, and almost everyone wishes they had.
Why this happens before design
Most agencies skip all of this. They jump straight to design, because design is what clients can react to and get excited about. Architecture is invisible, abstract, and harder to make a client feel good about over a Zoom call.
But design built on bad architecture is a nightmare to maintain. The site looks great at launch, and then six months in, you’re publishing content that doesn’t fit anywhere, the navigation gets weird, the related-posts module shows nonsense, and nobody knows why. The answer is almost always that the structure was wrong from the start, and now there’s too much built on top of it to fix without serious pain.
This is why I do architecture work before we ever open a design tool. Not because design isn’t important — it is — but because design is the easy part once the bones are right.
The best architecture is the one nobody notices, because everything just works. Your visitors find what they’re looking for. Search engines understand your site. Publishing the next post takes five seconds because everything has an obvious place to go.
You won’t see it. Your visitors won’t see it. But two years in, you’ll feel it every single day.
That’s the decision worth getting right.
