Why your help center keeps filling up with duplicate articles

On a review call a few months ago, a customer told me how their product team had decided to split the docs work. One group would write new articles with a Claude skill, and another would keep existing help content up to date with Pageloop. Docs matter a lot to this team, because their customers lean on the in-app chatbot, and the chatbot answers almost entirely from the help docs.

With nobody dedicated to docs, sharing the load sounded sensible, and I liked the plan until I asked one question: how would the two groups decide between a new article and an update? Nobody had an answer, and the call went quiet for a moment.

That question is usually where duplicate articles begin. When the choice between a new article and an update gets made one article at a time, by whoever happens to be writing, nobody sees the knowledge base as a whole, and overlapping articles about the same feature start to pile up. The fix is to make that call once per release, by someone who can see the whole knowledge base, before anyone starts writing.

Why duplicate articles keep appearing

Most of us know too little about maintaining a knowledge base. I say that as someone who spent nearly a decade in Support, at Zapier and then Postman.

A knowledge manager asks three questions before writing anything:

1. Does this feature need a new help doc, or does it go into an existing one?

2. Which category should it be added to?

3. How does this new doc affect the existing ones?

A Knowledge Manager makes scalable decisions, because they see the KB as a system. They're not thinking about these questions one article at a time.

Everyone else, me included for a long time, tends to answer only the first question, and only for the article in front of them. Writing a new article feels faster than finding the old one, and updating the one article you know about misses the others that mention the same setting. Each choice makes sense on its own. Put enough of them together and you get three articles explaining the same feature in slightly different ways, and an AI chatbot that can't tell which one is right.

It's like a customer sharing a problem versus proposing a solution. Would a PM run to engineering with the customer's solution? So why make arbitrary decisions when it comes to knowledge?

Why splitting new articles and updates between two teams makes it worse

Back to that Product team. The team writing new articles would need to know what already exists. The team updating would need to know what's being added.

Neither team had that view. The Claude skill writing new articles had never seen the help center, and the people keeping existing content current had no idea what new articles were about to land. If they had gone through with their plan, they would end up with a messy, bloated knowledge base very, very quickly.

I don't blame them for not fully understanding the consequences of what was, in fact, a thoughtful decision. They were trying to share the work fairly with no dedicated docs person. Two days after that call, we onboarded their full product team, so new articles and updates went through one place.

I love that documentation is finally becoming a team sport. The only problem: this sport doesn't have a manager.

How to decide between a new article and an update

You can bring the knowledge manager's thinking into every release, with or without a dedicated person. Here's the routine I'd use:

• Start from the release, not the article. List everything that shipped, big or small, before anyone opens an editor.

• Search before you write. For each change, find every existing article that mentions the feature, the setting or the screen. Usually it's more than one.

• Make the call per change. If an existing article owns the topic, update it. Write a new article only when nothing in the knowledge base owns the subject yet. Some changes need both.

• Pick the category on purpose. Put the new article where a customer would look for it, not where the writer happened to be working.

• Check the ripple. When a new article goes live, list the existing articles that should link to it, shorten their sections on the same topic, or point to it instead.

• Keep one decision-maker. Several people can write, but the new-or-update call for a release should sit with one person or one system, so the answer stays consistent.

If you already have duplicates, merge each set into the article that owns the topic and redirect the old URLs, so customers and your chatbot land on one answer. Then use the routine above so the same thing doesn't happen next release. If you're working out who that decision-maker should be, the ownership models in who owns the help center? are a good place to start.

Where Pageloop fits

On Pageloop, every release, no matter how big or small, follows consistent principles for handling new articles and updates.

Pageloop tracks releases wherever they happen: merged pull requests on GitHub, tickets in Linear and Jira, and threads in Slack where someone tags it. For each release, the agent decides whether it needs a new doc, an update to an existing one, or both. It only writes a new page when nothing in your knowledge base already owns the subject. When a new doc is added, it flags the existing docs that need to change with it. A person approves every change before anything is published.

That Product team didn't know they had a duplicate-article problem coming. Pageloop exists because we solve problems our customers don't even know they have.

Photo by The New York Public Library on Unsplash
The Miriam and Ira D. Wallach Division of Art, Prints and Photographs: Print Collection, The New York Public Library. "View of New York from Weehawken--North River.