A few weeks ago I noticed two posts on my Next.js blog were dragging each other down in Google. Both targeted the same keyword. Both got ~80% of the way to page 1 and stalled. Neither ranked for anything else either.

Classic keyword cannibalization. I'd written them three weeks apart, didn't remember the first when I wrote the second, and Google couldn't decide which one to surface, so it surfaced neither.

This post walks through how I diagnosed and fixed it, plus the date-handling gotcha that almost made things worse. Code at the bottom.

How to spot cannibalization

Open Google Search Console - Performance - Queries. Click any keyword you care about. Look at the "Pages" tab.

If two URLs show impressions for the same query, with neither clearly dominating, you have cannibalization. Google is split, it can't tell which one is canonical for that intent.

The symptom: both posts hover around position 8–15. Neither breaks through.
The diagnosis in my case took 30 seconds:

• /blog/podcast-to-linkedin-posts (published March 7)
• /blog/podcast-to-linkedin-posts-guide (published March 25)

Same primary keyword. I'd literally forgotten about the older post when I wrote the newer one.

The decision: merge, not delete

Three options when you have two competing posts:

1. Delete the loser, bad idea, you lose every backlink pointing at it
2. Add noindex to the loser, Google ignores it, but inbound link equity is wasted
3. Merge into one canonical URL + permanent redirect, the only option that preserves everything

The keep/redirect decision: I picked the older URL as the survivor. Three reasons:

• Older posts usually have more inbound links
• Older URL has longer SERP history with Google
• If the newer post has substantially better content, you merge the content INTO the older URL — not the other way around

So: the survivor's URL stays. The content gets the best of both posts. The loser URL gets a permanent redirect.

The architecture problem

Here's where it got interesting. My blog isn't markdown files on disk. It's inline JSX in src/app/blog/[slug]/page.tsx — one big posts: Record<string, BlogPost> map.
So "merging" wasn't a file operation. It was:

1. Edit the survivor's entry in the map
2. Remove the loser's entry
3. Configure a redirect at the framework level, not at the post level

For Next.js, the cleanest way to handle that is next.config.ts:

// next.config.ts
const nextConfig = {
  async redirects() {
    return [
      {
        source: '/blog/podcast-to-linkedin-posts-guide',
        destination: '/blog/podcast-to-linkedin-posts',
        permanent: true,
      },
    ]
  },
}

export default nextConfig

One gotcha worth knowing: permanent: true emits a 308, not a 301. Both are "permanent redirect" from Google's perspective and link equity transfers identically, Google confirmed this back in 2016. But if you have monitoring rules that specifically check for 301, you'll need to adjust them. I verified the behavior in production: Google indexed the redirect correctly within 48 hours.

The date-handling gotcha

This is where I almost made things worse. When you update a post substantially, you want to signal freshness to Google. The naive fix:

// DON'T do this
{
  slug: 'podcast-to-linkedin-posts',
  date: '2026-04-25', // overwriting the original publishedAt
  // ...
}

Bad move. You just:

• Broke your RSS feed (subscribers see a "new" post that's not actually new)
• Lost the publishedAt signal that Google's freshness algorithm relies on for trust history
• Confused anything that depends on chronological ordering (sitemap-sort, related-posts logic, archive pages)

The right fix is to add an updatedAt field separately:

// post interface
interface BlogPost {
  slug: string
  title: string
  date: string          // never change after publish
  updatedAt?: string    // bump on substantial edits
  // ...
}

And in the JSON-LD render:

// app/blog/[slug]/page.tsx
const jsonLd = {
  '@context': 'https://schema.org',
  '@type': 'Article',
  datePublished: post.date,
  dateModified: post.updatedAt ?? post.date, // <-- the key line
  // ...
}

In the masthead, render the "Updated" line conditionally:

<time>{formatDate(post.date)}</time>
{post.updatedAt && (
  <>
    {' · '}
    <time>Updated {formatDate(post.updatedAt)}</time>
  </>
)}

Now Google sees both signals cleanly: when the post was first published (rank-trust history) and when it was last meaningfully updated (freshness boost).

The cleanup grep

Before celebrating, find every internal link pointing at the old URL and update it:

# find every reference to the loser slug
rg "podcast-to-linkedin-posts-guide"

Don't trust your memory. I had 4 internal links scattered across other blog posts that pointed at the loser. Without updating them, every reader gets an extra redirect hop, and a little link equity leaks each time.

Also check:

• Footer / nav components
• Any sitemap generator (mine iterates the posts array, so it self-cleaned — but check yours)
• Schema markup generators
• Any hardcoded references using the full https:// URL form
• Middleware (in case you have other redirect logic that could conflict)

The verification

After deploying:

next build, make sure nothing breaks
Hit the loser URL in browser, watch DevTools Network tab, should be 308 to survivor
Hit the survivor URL, should render with both datePublished and dateModified in JSON-LD (verify with Google Rich Results Test)
Request indexing in GSC for the survivor URL, speeds up Google's re-evaluation from weeks to days

What to expect

Realistically: 2–4 weeks before you see ranking movement. Google needs to:

• Crawl the redirect
• Consolidate signals onto the survivor
• Re-evaluate ranking based on the unified, deeper content

In my case I closed three cannibalization pairs in one session on my blog at castnova.app. I'll know in three weeks whether the consolidation lifts the affected URLs into page 1.

The bigger lesson

Cannibalization compounds. Two posts - both stall. Five posts on overlapping intents - your whole topical cluster underperforms, because Google can't form a clean ranking signal for any single one.

The fix is mechanical (merge + redirect + grep), but the prevention is editorial: before publishing a new post, search your own blog for related keywords. If something already exists, extend it instead of writing a parallel post.

If you're running a Next.js blog with inline posts (not MDX files), the merge operation is even simpler than the markdown file case, one map edit, one config entry, done. The hard part isn't the code, it's catching yourself before you write the duplicate post in the first place.