Check your company’s visibility in AI
Free, with no credit card required.
Your blog has a guide to integrating a store with a warehouse. You are planning a knowledge base article with a very similar title. Do you need both? The answer depends on the reader’s task and the pages’ content, not on where you publish them.
Below is a content planning process for your team and a topic brief to use before publication. The technical recommendations follow Google documentation checked on 4 October 2026. The examples are hypothetical; they do not describe results achieved by Semly customers.
A shared topic does not automatically mean cannibalisation
Two articles can use the same words while helping with different decisions. “How do I choose a warehouse integration?” supports comparison. “How do I prepare data before launching the integration?” supports implementation. A shared product does not require merging these resources.
Here, cannibalisation means pages serving the same need whose coexistence makes the goal harder to achieve — for example, a reader reaches a less complete answer. Two URLs appearing for one query do not, by themselves, prove a problem or a loss of visibility.
Also distinguish overlapping intent from duplicated text. Google explains that some duplication is normal and does not violate its spam policies. Mass-producing unhelpful pages primarily to manipulate rankings is a different issue, covered by Google’s spam policies.
Assign roles according to the reader’s needs
Use the following division as an editorial proposal. A knowledge base can contain a guide, and a blog can contain instructions. The specific task matters more than the section label.
| Location | Main task | Example question |
|---|---|---|
| Blog | Explain the problem, compare approaches and support a decision. | When does integrating a store with a warehouse make sense? |
| Knowledge base | Provide precise requirements, procedures, limitations and operational answers. | What data and permissions should I prepare for the integration? |
| Service page | Describe the current service scope and the next purchasing step. | What does this company’s integration service include? |
A blog article explaining the choice can link to knowledge base instructions. Those instructions can link to the current offering. There is no need to copy the full description everywhere. A brief summary and a clearly labelled link often suffice.
Choose one location for maintaining current service terms. Educational articles can refer to them, but should link to a source maintained by a responsible person. This makes conflicting scope or requirement information easier to spot.
Create one map of the blog and knowledge base
Collect published URLs and planned topics in one inventory. Include a knowledge base on a subdomain: a different hostname alone does not create new value for the reader.
For each entry, record the URL or working topic, language, main question, audience, task after reading, answer scope, original data or example, content owner and review date. Add the closest related resource and the decision about further work.
Do not just look for similar titles. Read the introduction, headings, conclusions and main answer. Two different titles can lead to identical guides, while two similar titles can introduce useful resources with different scopes.
You can assess a planned article even without traffic data. Compare its promised answer with existing pages. If you cannot name an additional benefit, revisit the brief before generating content.
Check warning signs before deleting a page
In Google Search Console, compare queries and pages for the same period, country and device. Check whether visibility shifts between URLs and whether the change accompanies worse results for that need. Account for seasonality, changes to the offering and indexing.
If the blog and knowledge base sit in separate Search Console properties, you need data from both or a domain property covering both hosts. Reports have limitations, and performance data is usually attributed to the canonical URL. The performance report documentation explains how to interpret it.
For AI monitoring, examine the full response and cited URL. A blog appearing for one question and a knowledge base for another may be the intended outcome. An outdated source, conflicting information or a missing answer to an important condition is a stronger reason for editorial review.
There is no universal percentage threshold here that automatically determines cannibalisation. Combine data with an assessment of content and the user’s task.
Keep, differentiate, merge or choose a preferred version?
Decide for a specific pair of resources. Technical changes should follow the agreed content roles.
| Situation | Editorial decision | Next action |
|---|---|---|
| Different questions; both resources have independent value | Keep both. | Clarify titles and add contextual links. |
| Different tasks, but similar scope and conclusions | Differentiate the scope. | Change the brief, examples and final answer, not just words in the title. |
| One need, two incomplete guides | Consider merging. | Preserve useful information in the chosen resource; determine an appropriate redirect when permanently retiring the old URL. |
| Identical or very similar content must remain available at multiple URLs | Choose a preferred version. | Assess canonical settings and consistency with other signals. |
Google’s canonical documentation concerns duplicate or very similar pages. A canonical is a signal, and Google may select another version. It cannot replace differentiating two guides answering different questions.
For permanent content moves, Google describes server-side 301 and 308 redirects. The destination should meet the user’s need. Do not redirect every retired article to the homepage simply to dispose of old URLs.
Do not apply noindex to the entire knowledge base “just in case”. Removing useful pages from search does not fix their briefs. Technical archive cleanup is covered separately in our WordPress duplication guide, in Polish.
Topic brief: define the difference before writing
Complete this brief for every new publication. It is a planning tool, not a Google requirement.
- Main question: what single need are we answering?
- Audience and stage: who is reading, and what do they already know?
- Outcome: what can the reader decide or do afterwards?
- Original value: what example, procedure, data or experience are we adding?
- Closest existing URL: what does it already explain, and what will the new article avoid repeating?
- Topic boundary: which details remain in the knowledge base, blog or service page?
- Maintenance: who checks facts, updates the resource and schedules its review?
For example, the blog answers “Do I need an integration at my order volume?”, while the knowledge base answers “How do I prepare an inventory list?”. The first needs decision criteria. The second needs a data format, requirements and a procedure. The difference lies in the answer, not just the section name.
If a new resource has the same answer and outcome as an existing page, consider updating that page. A new URL needs a justification in the reader’s needs.
Assess SEO and AI responses separately
After a change, return to the agreed questions and URLs. For SEO, check indexing, the selected canonical and performance for the queries under review. In Semly, you can review stored AI responses and their sources to assess whether they point to the right resource and communicate current information.
A brand mention, a page citation and a user visit are different events. Record which one you are assessing. If you lack data, mark the measurement as missing rather than entering zero.
Growth after merging pages does not, by itself, prove that the change caused it. Our article on a before-and-after content update test describes a verification plan. We do not repeat its methodology here.
Google’s guidance for generative Search features stresses useful, original content and SEO fundamentals. Dividing roles between a blog and knowledge base organises work, but guarantees neither rankings nor AI citations.
Editorial checklist for two publishing locations
- I compared the new topic with the blog, knowledge base and service page.
- I can name the main question and the reader’s outcome.
- The difference from existing content is visible in the answer’s scope.
- I know where we maintain current information about the offering.
- I chose an action: keep, differentiate, merge or assess the preferred version.
- Links point to relevant, current resources.
- The person responsible for the site will check technical changes.
- I recorded the content owner, review date and measurement plan.
FAQ: blog, knowledge base and cannibalisation
Can a blog and knowledge base describe the same product?
Yes. They can support different tasks, such as choosing and implementing a solution. Check the question, answer scope and reader’s outcome, rather than shared words alone.
Does a knowledge base on a subdomain prevent cannibalisation?
The subdomain address alone does not differentiate intent or add value. Plan content across both locations before assessing their technical configuration.
Are two URLs for one query proof of a problem?
No. They are a signal to investigate. Assess the reader’s needs, the pages’ content and results under comparable conditions.
Will a canonical solve every topic overlap?
No. It concerns the preferred version of duplicate or very similar content. For different questions, start with scope differentiation and linking; for one need, consider merging resources.
Is an article translation a duplicate that must be merged?
Do not treat full translations as copies in the same language. Google recommends separate URLs and language version annotations, as explained in its multilingual site documentation. Regional versions in the same language need a separate similarity assessment.
Share:
