Custom WordPress website development in Westwood

Categories and tags cover the simple case. Many WordPress sites need more than that. A directory of case studies might need filtering by industry, by service type, and by outcome, all at once. None of those axes maps onto a blog category. A custom taxonomy earns its place here. It is a separate classification system attached to one or more content types, with its own terms and its own hierarchy.

The first choice is shape: hierarchical, like categories, or flat, like tags. Hierarchical taxonomies work well when terms nest naturally, a service list with sub-services. Flat taxonomies suit attributes that do not nest: a color, a format, a use case. Pick the wrong shape and it shows up later. An editor tries to file something under two parent terms at once, and the interface will not allow it.

Scope is the second decision. A taxonomy can attach to a single post type, or to several. Sharing one taxonomy across post types sounds efficient. Sometimes it is. But every term list then carries irrelevant terms for at least one of those types. Splitting the taxonomy earlier is cheaper than untangling it two years in.

Term counts matter more than editors expect. A taxonomy with six terms behaves like a filter. One with sixty behaves like a search problem, and the theme needs a search box or an autocomplete field instead of a plain checkbox list. Nobody plans for sixty terms on day one. It happens gradually, until the admin screen that felt tidy at launch turns into a scroll of near-duplicate names nobody cleans up.

Templates are where the payoff shows. A well-built taxonomy gets its own archive template and its own breadcrumb logic, so a term page reads like a real page rather than a generic list. Skipping this step is common. It is why so many taxonomy archives sit thin, unstyled, and quietly excluded from navigation, even though the taxonomy itself does useful work underneath.

Migrating from tags to a proper taxonomy later is possible, but it is not free. Existing tag relationships have to be mapped to new terms. Permalinks tend to shift. Any external link pointing at the old tag archive breaks unless a redirect is added. Deciding taxonomy structure during the build avoids a rewrite that touches every piece of content at once.

Name the taxonomy after what an editor is actually choosing, not after the technical concept behind it. Service area reads clearer than classification. A term list that matches how the team already talks about the content gets used correctly from the first week, instead of needing a training session.

Every edit to a WordPress post can save a full revision row in the database. It is a complete copy, not a short note of what changed. A page revised twenty times over its life leaves twenty rows behind it. Nobody deletes them by default. Nobody notices, either, because a single extra row is invisible. A few thousand of them is a different story.

Autosave makes this worse first. WordPress saves a draft copy at a fixed interval while an editor is still typing. Each of those autosaves can also land in the revisions table. A long editing session, stopped and restarted a few times, can produce more autosave rows than the actual published version ever needed.

None of this shows up on the front end. A revision row sits quietly in the posts table with a status that keeps it out of every normal query. It stays invisible to a visitor. It stays invisible to most editors browsing the admin list too. It shows up instead in the size of the database itself, and in the time it takes to back up, migrate, or search that database once revisions outnumber real content by a wide margin.

The default settings favor never losing an edit over keeping the table small. That is fine for light editing and a small archive. It is a poor fit for several editors writing daily, syncing changes back and forth, or scheduled content touched dozens of times before it goes live.

A revision limit set in the site configuration caps how many are kept per post. A scheduled cleanup can prune what already piled up. Neither change removes the value of revisions. An editor can still compare two drafts. An editor can still recover a paragraph someone deleted by accident. It simply stops the table from growing without bound in the background.

Plugins add their own version of the same problem. Page builders and form plugins often keep their own history tables alongside the native one. They track every save with the same enthusiasm, and the same lack of cleanup. A slow admin screen, months after launch, is often explained by three or four separate revision systems running at once. None of them pruned. All quietly doing the same job in parallel.

Checking table size is a five-minute task. It is worth doing again after launch, as well as before it. A site that felt fast on day one can slow down a year later for reasons that have nothing to do with traffic. The cause, more often, is a table nobody ever trimmed.