Build the redirect map before a blog migration starts
Build a blog migration redirect map that gives every old URL a disposition, relevant destination, reason, owner, and test result.
The redesign launches on Monday. By lunchtime, an old article shared in a newsletter opens the homepage. A bookmarked guide returns a generic error. A partner's link lands on a page that mentions the same topic but solves a different problem.
The technical redirects may be working exactly as configured. The failure happened earlier because nobody built a blog migration redirect map that made content decisions explicit.
A safe migration starts before the URLs change. Every important old URL needs a destination or a deliberate removal state, a reason, and an owner.
Work backward from launch day
On launch day, the team should be able to test a list of old URLs and know the expected result for each one. That requires four things to exist beforehand.
An inventory of old URLs that people and search engines may still use
A content decision for each URL
A verified new destination when one exists
A person responsible for approving and testing the result
Google's site move guidance recommends preparing a mapping from current URLs to their new locations. For complex moves, it suggests building the old URL list from sources such as sitemaps, analytics, and links. The important editorial addition is to avoid assuming every old page deserves a redirect.
Some pages should be kept at an equivalent destination. Some should be merged into a stronger resource. Some are gone with no suitable replacement. Mapping is a content judgment before it becomes a server rule.
Build the old URL inventory
Start with sources that reveal different kinds of value.
Published inventory
Export URLs from the current CMS, sitemap, feed, or content database. This is the broadest view of what exists.
Search entry points
Use Search Console to find URLs that received impressions or clicks. The purpose is not to preserve every page that once appeared. It is to avoid overlooking an old entry point that still serves a reader need.
Audience behavior
Analytics can reveal pages that start sessions or support meaningful actions. A niche article with modest traffic may still matter to a high-intent audience.
External and internal references
Review important backlinks, navigation, resource hubs, newsletter archives, product documentation, and downloadable files. A migration can break paths outside the blog even when the blog export looks complete.
Merge these sources into one normalized list. Remove fragments. Decide how to handle tracking parameters. Preserve enough source information to explain why a URL is in the map.
Give each URL one of four dispositions
The map becomes useful when the team chooses from a small, explicit set of outcomes.
Keep
The content and purpose remain substantially the same. The URL may stay unchanged, or the old URL may redirect to an equivalent new location.
The destination should satisfy the same reader job. Matching a few nouns is not enough.
Merge
Several old pages combine into one stronger new resource. Record which material survives and where the new destination covers each old page's useful purpose.
A merge is not permission to send every weak page to the most popular guide. The destination needs a real relationship to the old content.
Remove
The content has no useful replacement. It may be obsolete, misleading, or no longer part of the business.
Google advises returning a 404 or 410 for content that was deleted and is not moving. A clear custom error page can still help people navigate, but the server response should communicate that the old resource is gone.
Redirect
The content has moved to one clear destination. Use a permanent redirect when the move is intended to remain. Google's redirect documentation identifies server-side permanent redirects such as 301 and 308 as strong choices when a URL has permanently moved.
Keep this state separate from Merge in the ledger even if both become permanent redirects. Editorially, a one-to-one move and a many-to-one consolidation have different review needs.
Use a five-column redirect ledger
The core map can stay small.
Old URL | Disposition | New URL | Reason | Owner |
|---|---|---|---|---|
| Keep |
| Same reader job, new directory | Technical owner |
| Merge |
| Template becomes part of broader workflow guide | Editorial owner |
| Remove | Time-bound announcement with no replacement | Editorial owner | |
| Redirect |
| File replaced with current edition | Technical owner |
Add optional fields only when they support the migration. Useful additions include source evidence, destination status, redirect type, test result, and notes about canonical tags or noindex rules.
Do not bury the disposition in a free-text notes column. The controlled state is what makes the map reviewable and testable.
Split editorial and technical approval
One person should not quietly make every decision.
The editorial reviewer confirms that the new destination satisfies the old reader job. The technical reviewer confirms that the response, target, canonical signals, and crawl access behave as intended.
This two-owner model catches different failures.
Editorial review prevents irrelevant homepage redirects and weak topical matches.
Technical review prevents loops, chains, temporary rules, blocked destinations, and mismatched canonical URLs.
Google advises avoiding redirect chains and sending old URLs directly to their final destinations when possible. It also warns against redirecting many old pages to an irrelevant single destination, which can confuse people and may be treated as a soft error.
Test in a sequence that exposes failures
Run the map through three checks.
Before launch
Test redirects in the staging or preview environment when possible. Confirm that the new pages exist, can be crawled as intended, and do not retain temporary noindex rules from development.
At launch
Request every important old URL and record the actual response. Confirm the final destination after following redirects. Compare it with the ledger rather than relying on a spot check of the homepage.
After launch
Monitor errors, Search Console, analytics, external feedback, and important referrals. A complete map can still miss URLs created by old parameters, previous migrations, or links outside the inventory.
Keep redirects long enough for people and crawlers to adjust. Do not remove them merely because the new site has been live for a few weeks.
Keep the homepage out of the catchall role
The most damaging migration shortcut is also the easiest to explain. An old URL should not redirect to the homepage simply because the homepage exists.
If a relevant replacement exists, map it. If several pages became one genuinely useful resource, document the merge. If nothing now serves the old reader job, return the appropriate not-found response and help the person navigate from there.
That rule makes the redirect map more honest. It also forces the team to confront the actual content transition before launch day turns every missing decision into a broken path.
Archive the approved map with the release notes. Future editors will otherwise see a redirect and have no idea whether it represents a move, a merge, or a temporary compromise. The reason and owner fields turn the map into institutional memory. They also make the next migration smaller because the team can trace earlier decisions instead of reverse-engineering server behavior.
