How Do You Merge Two Blogs Into One Without Losing Traffic?

How do you merge two blogs into one without losing traffic?

Inventory both archives, decide which URL survives for every overlapping topic, redirect the losers permanently to the winners, and move everything at once rather than in dribs. Then watch Search Console for a few weeks while Google works through it. The risk is in the inventory, not the redirects.

I get handed this job more often than you would think. A company rebrands and ends up with an old blog on a subdomain and a new one on the main site. Two products merge. A founder starts writing on a separate domain for a side project that becomes the main project.

Whatever the cause, the situation is the same: two archives competing for the same queries, neither one strong. Here is the sequence I follow, in order, on a real merge.

When is consolidating actually the right call?

When both archives target the same audience and the same topics, and neither has enough authority on its own. Consolidation is the right move when you are splitting one story across two places. It is the wrong move when the two blogs genuinely serve different readers who would be confused to find each other's content.

The test I use is whether a single reader would plausibly want both. If your engineering blog and your marketing blog have different subscribers with different jobs, merging them makes your homepage worse for both groups. Keep them separate and fix the internal linking instead.

But if one blog is simply older, thinner, and forgotten, and the other is where you actually publish now, you do not have two audiences. You have one audience and one abandoned property that is quietly competing with you for your own keywords.

What should you inventory before touching anything?

Every URL on both sides, with its title, publish date, current organic traffic, number of referring domains, and the primary query it ranks for. Export it to a spreadsheet. Do not skip the traffic and link columns, because those are what decide which URL survives when two posts cover the same topic.

Pull the URL list from each site's sitemap, crawl both sites with Screaming Frog or a similar crawler, then cross-check against Search Console and Google Analytics so you catch pages the sitemap missed. Referring domain counts come from Ahrefs, Semrush, or whichever link tool you already pay for. The gap between those two lists is itself informative, and it is the same gap I wrote about in why your sitemap and your index coverage disagree.

Add one more column that nobody thinks of: whether anything else on either site links to that URL. You will need this later when you are fixing internal links, and gathering it now while you are already in the data costs you almost nothing.

Then tag every row with a topic label. Not a category, a topic. Two posts about pricing pages get the same label even if one lived under Strategy and the other under Conversion. The labels are how you find the overlaps, and the overlaps are the whole job.

How do you decide which URL survives each pair?

Keep the URL with the stronger link profile, then break ties on traffic, then on which one sits on the domain you are keeping. Content quality is not the tiebreaker, because you can rewrite content. You cannot easily rebuild links that point at a URL you deleted.

This surprises people. The instinct is to keep the better-written post. But the better-written post can be pasted into the stronger URL in ten minutes, and then you have both advantages. Keep the address, upgrade the contents.

Where two posts partially overlap, merge them into one genuinely better piece rather than keeping both and hoping. A merged post that answers the whole question beats two posts that each answer half of it and compete with each other for the same result.

Where one post has no real counterpart, it just moves. Same content, new address, permanent redirect from the old one. The only posts that should disappear entirely are the ones you would be embarrassed to publish today and that nobody links to or reads.

Which redirects should you use, and for how long?

Permanent ones, and for longer than you think. Google's site move documentation says to use HTTP permanent redirects if possible, such as 301 and 308. It is also specific about duration, advising you to keep the redirects for as long as possible, generally at least one year after the move.

A year is a floor, not a target. I leave redirects in place indefinitely unless there is a concrete reason to remove them, because the cost of keeping a redirect rule is close to zero and the cost of breaking a link someone bookmarked in 2023 is a lost visitor who will not tell you.

Where the redirect rules live depends on your stack, whether you manage them in Webflow, in WordPress, or at the edge in Cloudflare. Wherever they live, redirect each old URL to its specific new equivalent, never to the homepage or a category page. A bulk redirect to the homepage is the single most common way people destroy a merge. It tells Google the old page has no successor, and the rankings it held go nowhere useful. If you want the longer version of why, I wrote about what a 301 actually tells a search engine.

Google also has a view on sequencing. For smaller sites its recommendation is to move all URLs simultaneously rather than one section at a time, while larger sites may move a section at a time. Unless your archive is genuinely large, do it in one go. A staged merge means running two half-broken states instead of one clean cutover.

How do you handle Search Console and sitemaps?

Submit the new sitemap in Search Console. Google's documentation says that at that point you can remove the old sitemap, since Google will use the new sitemap going forward. If your merge involves a different domain or subdomain, file a Change of Address request as well.

That Change of Address distinction matters and people get it wrong. It applies to changing domain names or subdomains. If you are merging two sections within the same domain, there is no Change of Address to file, and looking for the button will only confuse you.

Keep both Search Console properties verified after the merge. You need the old one to watch the redirected URLs drain and the new one to watch them arrive. Deleting the old property on cutover day removes the only view you have of whether the move is working. I have covered the mechanics of this in more detail in using Change of Address after a domain move.

Google monitors these moves through the Sitemaps report, the Index Coverage report, and the Search queries section, and those are exactly the three places you should be looking too. Set a calendar reminder for one week, one month, and three months, because you will otherwise check obsessively for four days and then never again.

How long does the move take to settle?

Longer than your patience. Google's own documentation says a small to medium-sized website can take a few weeks for most pages to move, and larger sites take longer. Plan for a visible dip during that window, and do not reverse course in week two because the graph looks bad.

The reversal is the real danger. A merge produces a scary-looking chart in the first fortnight, someone panics, the redirects get pulled, and now you have a site that has moved twice and settled nowhere. Decide before you start what level of dip you will tolerate and for how long, and write it down so the decision is not made by whoever is most anxious on a Tuesday.

What I do want you to watch in that window is errors rather than traffic. Redirect chains, redirects that land on 404s, and pages that return a 200 when they should redirect. Those are real problems you can fix. A wobbling traffic line is just Google doing the work.

What breaks after the move that nobody expects?

Internal links. Every link inside your surviving content still points at old addresses, so your own site becomes a chain of redirects. Also expect broken images from the retired domain, email templates linking to dead URLs, and any automation that writes to the old blog's CMS.

Fix the internal links properly rather than relying on the redirects to cover for you. A redirected internal link works, but it is slower, it dilutes the signal, and it makes future audits harder because every report is full of expected noise. I keep a whole method for this in fixing internal links that point to redirects.

Then check the places outside your site that you control. Your email footer. Your newsletter archive. Your social profiles. The links in your product's help documentation. None of these are covered by any SEO checklist and all of them point at addresses that just changed.

Finally, audit for orphans. A merge frequently strands posts that were only reachable from a category page that no longer exists. They still resolve, they still sit in the sitemap, and nothing links to them any more. That is the exact situation I described in auditing orphan pages on a large blog, and a merge is the most efficient way to create dozens of them at once.

What should you do next?

Export both URL lists this week and tag them by topic. That single spreadsheet will tell you how big the job actually is, which is usually smaller than feared on the overlap side and larger than feared on the internal linking side. Do not write a single redirect until the tagging is done.

Then block one focused day for the cutover rather than spreading it across a month. Merges go wrong in the gaps, when half the redirects are live and the other half are in someone's draft branch. One clean cutover, then a quiet three weeks of watching.

If you are staring at two archives and not sure which one should win, or you want someone to run the inventory and the cutover for you, reach out. This is a job where an outside pair of eyes saves real money, because the expensive mistakes all happen in the first hour. Let's chat.