What Does My Duplicate Topic Check Catch, and What Does It Miss?

How do I avoid publishing the same article twice?

I avoid publishing the same article twice by running a duplicate topic check against every live post before I write anything new. The check compares the meaningful words in a proposed URL slug against every slug in the archive and flags overlaps. Strong overlaps are rejected outright. Weaker ones go to a human review before the topic is locked.

This blog now holds more than 1,500 posts on GTM, AI search, automation, and Webflow. At that size, memory stops working. I cannot remember whether I wrote about pricing page chat or channel retirement eight months ago. The archive can.

The check is simple, and that is the point. But simple tools have blind spots, and I would rather show you mine than pretend it is perfect. Here is what it caught and missed while planning today's posts.

How does the check actually work?

The check strips common words from a proposed slug, like "how," "the," "for," the current year, and broad terms such as "AI" and "SaaS." It reduces the remaining words to rough stems, then counts how many appear in each live slug. Four or more shared stems is a collision. Two or three means I compare the two topics by hand.

Stripping broad words matters. Nearly every post here mentions AI, SaaS, or GTM somewhere, so those words would make everything look like a duplicate. Removing them leaves the words that carry the actual topic, such as "pricing," "chatbot," "backfill," or "outage."

The check also runs an exact match on the full slug, and it logs the top three overlaps for every topic I lock. That log is useful later. When I come back to a topic months from now, I can see what it was closest to and why I decided it was different enough.

It is the same principle I suggest to clients worried about keyword cannibalization on a Webflow site. Find overlap before it ships, not after two pages start competing.

What did the check catch today?

Today the check caught a clean duplicate. I proposed a post on when to move a workflow from Zapier to n8n, and it flagged an existing post on when to move an automation from Zapier to code with four shared stems. The reader's decision was nearly identical, so I dropped the idea instead of writing a second version.

That is the check doing exactly its job. Without it, I would have written a perfectly reasonable article that split attention with an older one. Two posts on the same decision confuse readers and give search engines and AI assistants two half-answers instead of one strong one.

It also caught several near-misses in the review band. A post idea about publishing a SaaS roadmap matched an existing post on whether to publish a roadmap. A changelog idea matched a live post on changelogs that market the product. Both got cut after a quick read.

What did the check miss today?

Today the check missed a duplicate that uses different words for the same idea. I proposed a post on sunsetting a channel that stopped working. The check scored it low, because the existing post uses "killing" a channel and "how long to give" it. Same decision, different vocabulary. A manual keyword search caught it.

That miss is the main weakness of any word-overlap method. People describe the same problem in many ways. "Sunset," "kill," "shut down," and "retire" all mean the same thing here, and a stem counter does not know that.

It also nearly missed a security page topic. My proposed slug shared only two stems with two existing posts about what belongs on a security page for B2B software. Two stems lands in the review band, so I checked by hand and dropped the idea. The rule worked, but only because the review step was not skipped.

The existing channel post, how long to give a channel before killing it, is a good example of why the human step stays in the process.

What does the check flag that is not really a duplicate?

The check also raises false alarms. Words like "should," "first," and "or" are not in its stopword list, so two unrelated questions phrased the same way can score high. A topic on whether a small SaaS should list on review sites first scored three against a post about selling to the champion or the budget holder first.

Those two articles have nothing in common except sentence structure. A human sees that in a second. The check does not. False alarms cost a little time, which is fine. A missed duplicate costs a published article that should not exist, which is worse.

I lean the threshold toward false alarms on purpose. I would rather review ten harmless overlaps than publish one duplicate. That tradeoff is a choice, and it is the right one for an archive this size.

Why does this matter beyond my own blog?

This matters because any team publishing at volume faces the same risk. Google's spam policies describe scaled content abuse as many pages generated mainly to manipulate rankings. Publishing many distinct, useful answers is not that. Publishing near-copies of the same answer starts to look like it. A duplicate check keeps the purpose of each page honest.

I wrote about the latest spam update in my post on what B2B sites should check after the September 2026 spam update. The core question in that post applies here too. Would a reader be glad this page exists, or would they find the same answer one link away?

The same logic applies to programmatic pages, glossary entries, and comparison pages. Volume is not the problem. Sameness is.

How would I make the check smarter?

I would make the check smarter by adding synonym groups for common verbs and by comparing titles and opening paragraphs, not just slugs. Grouping "kill," "sunset," "retire," and "shut down" would have caught today's miss. Comparing the first answer paragraph would catch posts that use different words to reach the same conclusion.

Embeddings are the obvious next step. Turning each post's opening into a vector and comparing meaning instead of words would catch most synonym misses. I have not added it yet. It adds cost and another system to maintain, and for now the manual review step handles the gap.

The honest lesson is that the cheap check got most of the value. The human review got the rest. Adding a smarter model would shrink the review list, not remove it.

What should a team copy from this?

A team publishing regularly should copy three parts: a full export of live URLs before planning, an automatic overlap check with a strict threshold and a review band, and a written log of what each new topic was compared against. Those three habits prevent most duplicate content without any expensive tooling.

You can build the first version in a spreadsheet. Export your sitemap or CMS slugs, split them into words, and count overlaps with a formula. It will be crude. It will still catch the obvious repeats that slip through when a busy team plans content from memory.

Then keep the human step. The most useful moment in the whole process is the thirty seconds where someone reads two titles side by side and asks whether a reader would want both.

What should you do next?

Export every live URL on your blog, pick your next five planned topics, and check each one against the list by hand or with a simple overlap count. Drop or reframe anything that answers the same reader decision as an existing post. Then write down your rule so the next planning session follows it.

If you publish often, consider automating the check and logging the results. It takes an afternoon to build and saves you from your own memory.

If you want help setting up a content pipeline with a duplicate check built in, reach out. I am happy to share what has worked for me and what has not.