How to Merge Pages Without Losing Rankings

You lose rankings in a merge for four reasons: the merged page no longer answers queries the old pages ranked for, the redirects are wrong or slow, signals around the pages still point at the old URLs, or someone panics at a normal dip and changes things mid-recrawl. This guide is the runbook for avoiding all four once you have decided to merge: capture a baseline, build a query-preservation map, write a merge spec, follow a launch-day checklist, and know what Search Console should show in the weeks after.

Whether to merge at all, and which page should survive, is covered in content consolidation: when to merge, prune or leave a page alone. If you are merging because two pages compete for the same searches, start with how to find and fix keyword cannibalization.

Before you start: confirm it is one intent

A merge only works when the pages serve the same search intent. Two pages that rank for overlapping words but answer different needs, such as a template and an article about writing one, should be differentiated, not merged. A quick test: search the main query of each page and compare the top ten results. If they show mostly the same pages, searchers treat the queries as one need and one page can serve both. If the results are different, keep two pages. The search intent guide covers how to read the results page in more detail.

Step 1: Capture the baseline

Once the redirects are live, the old URLs’ data stops growing, and over the following months the history you need to judge the result becomes harder to pull together. Export it first, for every page involved, the winner included:

• Query-and-page pairs for the last three months from the Search Analytics API, Looker Studio or the BigQuery export. The interface export gives separate query and page tables, not the pairs you need.
• Clicks, impressions and average position per page, weekly, for the last 16 months if you can, to see seasonality.
• Search features each page holds today: a featured snippet, a video, an image.
• Links from other sites to each URL, from a backlink tool.
• Internal links pointing at each source URL.
• Key events by landing page from GA4, so you measure business value and not just clicks.

Remember that query rows will not add up to page totals: Google leaves anonymized queries out of query-level tables but counts them in totals, as explained in its performance data deep dive. Use page totals for the before-and-after comparison, and query rows for the preservation map.

Step 2: Build the query-preservation map

This is the step most merges skip, and the main reason they lose traffic. Each source page ranks for queries the winner does not. If the merged page has nowhere that answers them, those clicks are gone, no matter how good the redirects are.

List the queries that bring each source page its clicks. A practical cut-off: the top queries that together make up about 80% of each source page’s clicks, plus any query where the page sits in the top five. Then give every query a home on the merged page:

These numbers are illustrative. The last row matters as much as the others: deciding a query does not belong on the merged page is fine, as long as you decide it and point it somewhere. What you must avoid is losing a query by accident because its section was cut during editing.

Step 3: Write the merge spec

One page, agreed before anyone edits. It keeps writers, developers and SEO working from the same plan:

A merge is a substantial change, so the winner’s visible updated date and dateModified should move. See what counts as a real content update.

dash.morrison.app/lumenpay.com/chat

Illustration

lumenpay.com/Merge plan: expense guides

What do you want to know about lumenpay.com?

Ask about your website content...

Search ConsoleAhrefs

Claude Sonnet 5.5

Step 4: The launch-day checklist

Do these in order, on the same day. The order matters: the merged content must be live before anything redirects to it.

1. Publish the merged content on the winner URL and check it renders, with its self-referencing canonical.
2. Switch on the redirects. A permanent, server-side 301 or 308 from each source straight to the winner. Google’s redirect documentation treats both as a strong signal that the target is canonical, and temporary redirects as a weak one.
3. Flatten old chains. Any older URL that redirected to a source should now point directly at the winner.
4. Test every redirect: a single 301 or 308, landing on a 200. Test again after the next deploy or CDN change.
5. Update internal links to point at the winner directly. Redirects handle links you cannot edit; your own should not depend on them.
6. Update the sitemap. Remove the source URLs and update the winner’s lastmod. Google’s site-move guidance suggests keeping a temporary sitemap of old URLs while you monitor, so they are recrawled and the redirects are seen sooner; remove it after a few weeks.
7. Request indexing for the winner with URL Inspection. Google says crawling can take from days to weeks and asking again does not speed it up.
8. Annotate the date in Search Console with a custom chart annotation, and log the merge in your redirect log: source, target, date, reason.

Keep the redirects for at least a year; Google’s site-move guidance says generally at least one year, and from a user’s point of view indefinitely is better if other sites still link to the old URLs.

Step 5: What to expect in the weeks after

Google has to recrawl each source URL to see its redirect, then reprocess the winner. During that time the numbers move around. The timings below are rules of thumb for a merge of a few pages on a site Google crawls regularly; Google’s own documentation only says that changes can take days to weeks to be picked up, and that rankings can fluctuate while a move is processed.

Compare like with like. The baseline is the sum of all pages involved over the same weeks before the merge, or the same weeks a year earlier for seasonal topics. Comparing the winner after with the winner before makes every merge look like a win; comparing it with the old winner alone hides losses on the sources’ queries.

Normal dip or real problem?

Do not change the merged page in the first two weeks unless something is clearly broken. After that, these patterns point to specific causes:

Undoing a merge is rarely the answer, because it puts Google through a second round of reprocessing. Consider it only when the month-three comparison is clearly worse and the cause is the last-but-one row: two intents that should never have shared a page.

Where Morrison fits

Morrison connects to Search Console, so chat can pull the queries for each page involved and draft the preservation map, read the pages themselves to list what each uniquely contributes, and check backlinks through Ahrefs. Morrison writes the merge spec as a document in the canvas, ready to download as Markdown. Its site index shows the HTTP status and redirect target of every URL, so after launch you can filter for source URLs that are not yet redirecting, and a weekly automation can report the winner’s clicks against the baseline. For a site-wide consolidation programme, a workflow can pull the top Search Console queries for every page in a segment, up to 500 pages a run, so you can spot the overlaps and then plan each merge in chat. See content consolidation planning.

Key takeaways

• Baseline first: export query-and-page pairs and page totals for every URL before any redirect goes live.
• Preserve queries on purpose: every query worth keeping gets a section on the merged page, or a deliberate home elsewhere.
• One spec, one launch day: content, permanent one-hop redirects, internal links, sitemap, recrawl request, annotation.
• Measure against the combined baseline after about three months, and diagnose by symptom rather than reacting to week-one noise.