Duplicating an article to publish an article
Somewhere in your content system there is one article that works. It has the right template, the right category, the right fields. When something new needs to go out, you open it, duplicate it and overwrite every field. You have done this for so long that it no longer feels like a workaround. It is the process.
It is worth saying plainly: this is not normal, it is not your fault, and you are not the only team publishing this way. It is what happens when a platform is built by an outside team, never properly handed over, then left for years to accumulate content types, tags and templates nobody is authorised to retire. Every workaround becomes the procedure once it is the only path that reliably works. The structure decays, the decay compounds, and the people who publish absorb the cost.
What you can learn without the code
The usual reason nothing happens is access. The original developers are gone, your technical team never had the repository, and everyone assumes that without the code nobody can say what the system does. That assumption is wrong.
A content model audit works from the outside in. The administration interface shows every content type, field, template and taxonomy term, because editors have to see them to use them. The published content shows which of those are actually in use, how consistently, and since when. Between the two you can reconstruct most of the model without opening a single file of code. The same exercise separates what is broken from what is merely unfamiliar, and those are not the same problem: one has to be changed, the other written down.
This makes a first step possible that needs no rebuild budget, no new supplier and no recovered codebase. It needs an administrator login and time from whoever publishes most.
Reading the model out of the content
Start with the list of content types. For each one, count the published items that use it and note when the most recent was created. Types with a handful of items and nothing new in years are dead. Do the same with templates: the ones nobody has selected since the build are theoretical, not real.
Then the taxonomy. Export every tag and category with its usage count. Tags used once are not a taxonomy, they are a free text field with a dropdown in front of it. Look for pairs that mean the same thing in different spellings, categories superseded but never closed, and a newer set of categories sitting on top of an older one with neither fully adopted.
Finally, sit with the person who publishes most and watch one article go out. Every field they skip, every value they always copy and every step they do outside the system is a note about the model.
Taxonomy first, templates second
Once you can see the mess, the instinct is to go straight to templates, because templates are what editors touch and what the next article will look like. Resist it. A template is a fixed arrangement of fields and taxonomy choices. Build one on a taxonomy that still carries two generations of categories and the template inherits every one of those mistakes, now harder to fix because a working template depends on them.
Rationalise the taxonomy first. Decide which categories survive, merge the duplicates, retire what is dead, and write down the rule for adding new terms so the list stops growing by accident. Only then design templates, and design the small set that covers the large majority of what actually gets published rather than the full theoretical range. The test is not how many templates you end up with. It is whether the next article can go out by choosing one instead of duplicating the last one.
Repair or rebuild
Either answer can be right, and neither is decidable before the audit, whose job is to replace instinct with evidence. The criteria are not about volume. A few hundred articles can carry more structural decay than 50,000 when the model beneath them has been left alone for a decade, so being small is not a reason to wait.
Four things decide it. The structural distance between the model you have and the one you need: a taxonomy that can be merged is a repair, one that must be reinvented is closer to a rebuild. The viability of the platform: still supported, still updated, still something you can hire for. Your in house capability to own the result, including the code, the hosting and the administration rights nobody currently holds. And the cost of today's workarounds, paid again on every article that goes out.
If you are sure the platform is the problem, it sometimes is. More often the model is, and an unaudited model follows you onto the new platform with a migration bill attached.
What an audit hands you
A fixed fee audit produces a document, not a proposal. Its table of contents is the audit scope outline that goes with this post: an inventory of content types and templates with usage, a taxonomy map with merge and retire decisions, a usage analysis, editor workflow observations, prioritised recommendations, and a repair or rebuild position with the evidence behind it.
If you are the technical contact who inherited this system with no history, it is the first written description the platform has had, and it works as a brief for any supplier, including your current one. The document is yours.
