Two pages, one title, and the result you did not choose
Two pages with the same title have asked a search engine to choose between them for the same query. It will choose, it will not tell you why, and the one it picks is frequently not the one you would have.
The short answer
Two pages sharing a title tag compete for the same result, and the engine picks one, usually not the one you would. It is almost always a template producing the collision rather than a person: a paginated series with no page number, a filter that does not alter the title, or a product variant set. Fix the template, not the pages.
Cannibalisation, described precisely for once
The word gets used loosely enough to be useless, so here is the mechanism. For a given query a search engine generally shows one result per site. When several of your pages are plausible candidates, one is selected and the others are held back. Nothing is penalised. What you lose is the ability to decide which page represents you.
A shared title is the strongest way to create that situation on purpose without meaning to. The title is the most weighted statement a page makes about its own subject, so two pages making an identical statement have declared themselves interchangeable, and a system taking them at their word will treat them that way.
The compounding part is that signals split as well. Each candidate accumulates its own links, its own clicks and its own history, so instead of one page with a strong case you have three with a third of one each. Then the selection rotates, because the candidates are close and the tiebreak is unstable, and you get a position that moves for no reason you can trace to anything you did.
The symptom worth recognising: a page whose ranking oscillates while nothing about it changes.
Two URLs swapping places in the results week to week is what selection between near-equal candidates looks like from the outside. Teams usually respond by editing the page that is currently losing, which adds a fourth candidate's worth of signal to a set that was already split. Check the titles first.
Four templates that manufacture collisions
Hand-written titles collide occasionally, and usually on two pages nobody thinks about. Generated titles collide in the hundreds, and the pattern is always one of these.
- Pagination that does not number itself. Twelve pages of a blog archive, every one titled
Blog | Fielding Cutlery. Numbering the second page onward is the entire fix and it is a one-line template change. - Faceted URLs inheriting the category title. Every filter combination reports itself as the category. The filter values are known to the template, so either put them in the title or stop letting those URLs be indexed.
- Product variants as separate URLs. Six sizes of one item, six URLs, one title. This one is often better solved by not having six URLs at all, since a variant is a property of a product rather than a different product.
- A template with a fallback nobody expected to fire.The title falls back to the site name when a field is empty, and then a batch import leaves that field empty on ninety records. The fallback did its job; the collision is a data problem wearing a template problem's clothes.
There is a fifth case that is not a collision at all and gets reported as one: the same title on the same page reachable at two addresses. That is not a titling problem, it is a duplicate URL, and renaming one of the titles would be the wrong fix by a wide margin.
A collision is a property of a set, not of a page
Nothing about a title, read on its own, indicates whether it is unique. The check is a comparison against every other title you publish, which means the whole set has to be collected before the answer exists.
This one needs the full crawl
Knowing a title is duplicated means holding every other title on the site next to it, so this finding does not exist until the whole set has been collected.
The instant search on this site audits a single page, so rather than show you a verdict it cannot support, this guide sends you to the place the check actually runs.
If what you need is help writing the title rather than finding the twin, the title guide covers length, truncation and why Google sometimes replaces yours.
Rewriting a collision without inventing a difference
The wrong fix is to make the strings distinct. Adding a number, a city or a category to two otherwise identical titles produces two unique strings and leaves you with two pages competing for the same query, which was the actual problem.
The right fix starts by deciding whether both pages should exist. Three outcomes, and only one of them involves writing a title.
- They are the same page. Consolidate. One survives, the other redirects, and the title question disappears with it.
- They are different pages with the same intent. Merge the material into the stronger one. Two mediocre pages about the same question are worth less than one good one, and the title was telling you so.
- They are different pages with different intents. Now write the titles, and write them from the intent rather than from the subject.
How to sharpen a carbon steel knifeandWhy carbon steel holds an edge longer than stainlessare the same subject and different questions, and the titles should look as different as the questions do.
The test for the third case: if you can imagine one person typing both queries in the same session, you probably have one page. If you can imagine two different people, you have two.
Does this affect AI search?
Less than it affects search, and for a reason worth understanding rather than dismissing. A retrieval system is not choosing one result per site to display, so the selection mechanism that makes cannibalisation painful in a results page does not have a direct equivalent. Two pages with the same title can both be retrieved.
What does carry over is the split. The reason one of your pages would be chosen as the best answer is partly the accumulated weight behind it, and dividing that weight across three candidates makes each of them a weaker candidate in any system that ranks anything. That applies to a chunk-level retriever as much as to an index.
There is also a plain readability argument. A title is one of the shortest, clearest statements of what a document is, and it is used heavily when something has to summarise or disambiguate a source. Three documents claiming the same title are three documents a summariser cannot tell apart, and the resolution it reaches for is the URL, which was never written to be read.
Why sharing a title outranks sharing a description
These two checks come from the same templates and the same afternoon, and one is Important while the other sits at the bottom of the scale. The difference is what each tag is used for. A description is copy shown next to a result, and it is frequently rewritten by the engine anyway. A title is treated as a claim about the page's subject, and duplicating a claim changes which of your pages gets considered.
It stays below Critical because no page is removed. Every URL in a collision remains indexed and reachable, and a search for a phrase unique to the losing page will still find it. What you lose is control over the competitive query, which is expensive and not fatal.
The rating also reflects diagnostic value out of proportion to the fix. Duplicate titles are the cheapest way to discover duplicate pages, unwanted indexable URLs and broken template fallbacks, all of which are larger problems that happen to announce themselves here first. A check that surfaces three other findings earns its place above a cosmetic one.
Listing every title you publish, once
If you have a sitemap, you have the input for this, and the whole check is a sort and a count.
# every URL in the sitemap, then its title, then the collisions
curl -s https://example.com/sitemap.xml \
| grep -o '<loc>[^<]*</loc>' \
| sed 's/<[^>]*>//g' \
| while read -r url; do
title=$(curl -s "$url" \
| tr '\n' ' ' \
| grep -o '<title>[^<]*</title>' \
| sed 's/<[^>]*>//g')
printf '%s\t%s\n' "$title" "$url"
done > /tmp/titles.tsv
# titles used more than once, worst first
cut -f1 /tmp/titles.tsv | sort | uniq -c | sort -rn | awk '$1 > 1'
# the URLs behind one of them
grep -F "$(cut -f1 /tmp/titles.tsv | sort | uniq -c | sort -rn \
| awk '$1 > 1 {sub(/^ *[0-9]+ /, ""); print; exit}')" /tmp/titles.tsvTwo things to expect in the output. Pagination will be the largest group, and it is the easiest thing on this page to fix. And an empty title appearing several times means a template fallback is firing, which is a different and more urgent problem than a collision.
Run it against the sitemap rather than a crawl and you get a useful side effect: any collision it finds is a collision between two URLs you deliberately submitted for indexing, which removes the argument that the duplicates do not matter.
Questions this check raises
- What is keyword cannibalisation?
- Two or more of your own pages competing for the same query, so neither accumulates the signals that would rank either one. Duplicate titles are the clearest form of it: the engine has two candidates it cannot tell apart, picks one, and the other earns nothing. It is a self-inflicted problem, not a competitive one.
- Do duplicate titles cause a penalty?
- No. There is no penalty for duplicate titles, and treating it as one leads people to make defensive changes that do not help. The cost is dilution: two pages splitting the signals one page would have concentrated, and an engine choosing between them without your input.
- How do I fix duplicate titles across hundreds of pages?
- Change the template that produces them, not the pages. Almost every collision at scale comes from one pattern: pagination without a page number, filters that do not alter the title, or variants sharing a product name. Add the distinguishing variable to the template once and every collision it caused resolves.