Planning the underlying architecture of any WordPress build is a crucial part of the development process that impacts everything from performance to usability to search engine optimization. WordPress provides a lot of options for structuring a website, and with all of those options, comes a lot of confusion over what should be used and when. 

Should this be a page or a custom post type? 

Does this choice need a custom field or should it use a taxonomy? 

Should this be built as a block or a pattern?

You get the picture.

Gaining a deep foundational understanding of the various WordPress parts and pieces will help you confidently answer these questions and make every project you take on stronger. By not only understanding what the pieces are but how they’re best used, that knowledge easily transfers project-to-project, adapting to the individual needs of each one. You’re no longer mimicking an approach for a feature because someone once told you to build it a certain way, but instead you get why you’re building it that way. 

Understanding the why unlocks a lot of confidence when planning WordPress architecture. Knowing why certain approaches will be taken, how different pieces will fit together and relate to one another, and how logic will connect various parts of a site helps you create a plan before starting a build. 

On the other hand, if you don’t understand why certain solutions are the optimal fit and you’re not thinking through site architecture and just diving in, you can end up:

• Backtracking later on in development, extending timelines, and erasing profits
• Creating set ups that aren’t scalable, leading to major headaches for you and your client down the road
• Damaging the search engine optimization of sites by failing to set up content in a way that search engines can easily digest
• Constructing admin experiences that lack organization, making their management feel overwhelming and cumbersome

All of these mistakes (and more) can be easily avoided by planning your approach from the start. To make educated decisions and plan your build effectively, you need a solid understanding of the pieces WordPress provides you to work with, as well as their benefits and drawbacks, where they shine, and when they should be avoided entirely.

The Importance of Maintainability When Planning Structure

“Maintainability” is a word that gets thrown around often in development. When thinking of similar words like “maintenance,” you’re likely focused on the work necessary to keep up smooth operations, like maintenance on your car by changing the oil. But the “maintainability” of code is not just what’s involved in continued smooth operation, but also how easy it is to modify and extend the behavior.

Often, setbacks in maintainability are made while planning the structure of WordPress sites. It happens by coding yourself into a corner — focusing only on the immediate needs of a project versus taking a more forward-thinking approach.

Early in my development career, I often found myself in this exact situation. I had created a setup that worked fine for the client’s immediate needs but quickly became problematic as they moved beyond them. I’d then get frustrated by a request a client made later that didn’t play nice with my original approach. I remember often indignantly thinking, “Well, had I known this, I would have built it differently!”

Here’s the thing: Sometimes clients do drop game-changing new requests that rightfully require revisiting parts of a build. Other times, a shortsighted approach leaves a project with such little wiggle room that almost anything new presents itself as a problem.

For example, let’s say you’re building an About page with a small team section. Currently, the client only has six team members and the page displays each person’s headshot, name, and title. If your approach is to create a content grid with your page builder of choice, rather than build a custom post type, you’re creating an unfriendly situation that will make building upon its current behavior more difficult.

There will be problems if:

• The client’s team grows substantially
• The client decides they want to group team members, like maybe separating out executives from the rest of the team
• The client wants each team member to have a bio page

This structural decision doesn’t leave much room to accommodate anything beyond what you originally built, without more substantial recoding.

When you look at planning structural decisions, be wary of creating future problems — issues that arise if the client ever wants to do something different than the exact solution you built. It’s going to happen. Clients change their minds and get new ideas. When looking back at structure choices you later regret, the frustrating part is that the better solution usually wouldn’t have been all that different in terms of development time. What’s different is whether future “what ifs” were factored in.

Maintainability is a really important concept to keep in mind when planning the structural elements of a website and making decisions about how you’ll solve specific challenges. If you’re basing decisions only on what is needed today, you’re setting future needs up to wreak havoc on your projects.