WordPress blog architecture: what I go through before anyone hits publish

I have a version of this conversation at least a few times a year. Someone comes to me with a WordPress site that has been running for a while, anywhere from six months to several years, and something has gone wrong. It still works. It is just messy. Posts are buried, the navigation stopped making sense somewhere around post fifty, and the category list has grown into something nobody would have designed on purpose. Somewhere in the conversation they say some version of: "I didn't know it would end up like this."

That's the architecture conversation, arriving late.

Before I take my boat out on Lake Erie for anything beyond a day sail, I do a route plan. I can navigate on the fly, and sometimes I have to, but the decisions I make before I cast off shape every decision I make once I'm on the water: where I can anchor overnight, how long each leg takes, what I do when the weather shifts. WordPress architecture is the same kind of thinking, just for your content instead of your passage. You can skip it and still get somewhere. You'll just spend a lot of time tacking against the wind.

When I work through architecture with a client, I'm really asking one question: what decisions do you need to make now that you'll be glad you made in year two? There are only a few that truly compound, but they compound hard. Here are the three I start every new site conversation with.

Categories and tags do different jobs

This surprises people. Most WordPress sites I see treat categories and tags as interchangeable. You use whichever one you thought of first, you end up with forty-seven categories and two hundred tags, and neither one helps a reader find what they're looking for. The navigation looks populated but it doesn't actually go anywhere useful.

Here is how I think about the split. A category is where a post lives. A tag is something a post is about. A post lives in one home (in rare cases two, but usually one) and it can be about many things.

Say you run a training blog. "Excel Training" might be a category. The posts that live there are all about Excel training. Within those posts, you might tag specific topics like VLOOKUP, pivot tables, or conditional formatting, because a reader might want to find every post that mentions pivot tables regardless of which section of the site it sits in. The category gets them to the neighbourhood. The tag gets them to the specific house.

The practical test I use: if someone clicked that label in your navigation, what would they expect to find? A section of the site with a clear theme? That's a category. A filtered view across different sections? That's a tag. WordPress's built-in taxonomy system is flexible enough that you can add custom taxonomies when the standard two don't fit your content. But most sites don't need custom taxonomies on day one. They need the standard two used correctly and with discipline.

Get this right early and your site navigation builds itself as the content grows. Get it backwards and you will eventually hit the point where you have seventy categories that all look like tags, and nothing is cleanly organized. I have seen sites where there are more categories than there are posts in most of them, and nobody can explain why the category list looks the way it does. It grew, and nobody ever sat down to design it.

Permalink structure is a long-term commitment

This is the one that bites people hardest, and the one that is most expensive to fix after the fact. Your permalink structure is the shape of the URLs across your entire site. You can change it later, but "later" comes with a real cost. Every link that exists to your old URLs breaks. Every bookmark someone saved, every link embedded in another site, every result a search engine has indexed: all of it needs to be redirected to the new structure.

You can manage it. Redirects exist for exactly this situation, and the tooling for them is mature and well understood. But you are doing cleanup work for a decision that was free to get right at the start, and that is the part that stings.

WordPress gives you several permalink options out of the box. The structure I recommend for most content-focused sites includes the category slug: /blog/category-name/post-name/. That gives you a hierarchy both readers and search engines can parse. You can look at any URL and know where in the site that post lives. It also means your categories do double duty: they organize your navigation and they organize your URL structure at the same time.

The structure I steer people away from is date-based: /2024/03/post-name/. It made sense when blogs were journals and chronology was the primary way people navigated content. For most sites now, a date baked into the URL makes evergreen content feel stale before its time. A post about how to structure your WordPress categories does not benefit from having 2021 in its URL in 2026.

If your site is already live and the permalink structure is working against you, that is a conversation worth having carefully before you touch anything. A redirect audit before the switch can prevent a lot of downstream problems. If you want to talk through what that looks like, my WordPress consulting page walks through how I approach that kind of engagement.

When to think about custom post types

The default WordPress post type works well until it does not. For a lot of sites, the standard set covers everything you need: title, content, date, featured image, category, tags. A personal blog, a small business with a news section, a training provider posting regular articles. Standard posts handle all of that fine, and there's no reason to make things more complicated than they need to be.

Where standard posts run out of room is when your content has a repeating structure that prose doesn't naturally capture. A staff directory is a classic example. Every entry has a name, a title, a photo, a bio, maybe a department. You could do that with standard posts and just use the title and body fields, but then every post needs to follow the same unwritten format, nothing enforces it, and nothing makes the data queryable in any useful way. A custom post type with proper fields gives you a staff member as an actual object that the site can render consistently every time, without relying on whoever is doing the data entry to remember the format.

For media organizations, educational institutions, and government clients, I run into this constantly. Event listings, course catalogs, resource libraries, case studies with structured metadata, faculty profiles, archived reports. The earlier in the project you plan for these, the cleaner the implementation. The later you realize you need them, the more existing content you are retrofitting into a new structure, which is neither fast nor fun.

This is day-one work for some sites and a distraction for others, and I don't push it on clients who don't need it. If you're starting a new site and you're not sure whether you'll need custom post types, you probably don't need them yet. But if you can already see the pattern, if you keep describing your content as "a bunch of X that all have the same fields," that's a signal. Have that conversation at the start, before you have three hundred entries in a structure that wasn't built for them.

Architecture decisions compound. A site with good structure in week one gets easier to manage over time, because the navigation makes sense and new posts fit the established pattern without anyone having to think about it. A site with no real structure drifts, slowly enough that it is easy to ignore. Posts get harder to find, the category list grows in ways nobody planned, the URLs that made sense at twenty posts feel arbitrary at two hundred, and the people who manage the site develop workarounds, and then the workarounds need workarounds.

None of this is catastrophic. WordPress is forgiving, and most of it can be fixed. But the cleanup is always more work than the upfront conversation would have been, and it usually happens at the worst possible time, when the site is busy and nobody wants to touch the URL structure. And cleanup on a site somebody else built carries its own risk, which I wrote about in what to find out before you clean up an inherited site.

If you are planning a new WordPress site, or if your existing one is showing these symptoms, the first step is usually a short conversation about what the site is actually for and how the content will grow. That's usually enough to work out which two or three decisions matter most for your specific situation. If that sounds useful, reach out. I'm glad to help you work through it.