A blog URL migration checklist that protects every published page
Move a company blog safely with a row-level URL map, controlled launch sequence, proof passes, and clear rollback thresholds.
A website redesign can look complete while the blog underneath it is quietly breaking. The new templates load, the navigation feels cleaner, and the homepage has passed review. Meanwhile, old article links lead to dead ends, image URLs have changed, canonical tags point to the wrong host, and the sitemap lists a mixture of old and new pages.
A blog URL migration checklist should protect every published page, not merely confirm that the new website opens. The central artifact is the URL map. It connects each old public address to a deliberate new outcome and gives the team a row-by-row record it can test before and after launch.
The migration is ready when every meaningful old URL has an owner, a destination, and proof.
Follow one URL before planning the whole move
Choose a representative article and trace its complete journey.
The old page may include the HTML article, a featured image, embedded files, internal links, a canonical URL, structured data, analytics tags, and backlinks from other websites. On the new site, each part must either stay at the same address, move cleanly, or be intentionally retired.
That exercise reveals the real scope of the project. A blog migration is not just a content import. It is a set of public promises encoded in URLs.
Google's site move documentation recommends preparing a mapping from current URLs to their new locations, testing the new site, configuring redirects, and monitoring both old and new URLs. It also advises changing one major thing at a time where possible.
For a small team, the implication is valuable. Do not combine a domain move, a CMS replacement, a complete information architecture rewrite, and a content cleanup into one opaque launch unless the project truly requires it. Each additional change makes a failure harder to locate.
Build the migration map as evidence
Start with a complete export of public blog URLs. Sources may include the current sitemap, CMS records, analytics, Search Console exports, internal crawling, and backlink reports. No single source is guaranteed to contain every meaningful page.
Give each old URL one row with these fields.
Field | Purpose |
|---|---|
Old URL | The exact public address before launch |
Current response | Whether it is live, redirected, missing, or blocked |
Page job | The reader need or business role it serves |
New URL | The exact intended destination |
Outcome | Keep, redirect, merge, or retire |
Content status | Imported, revised, consolidated, or excluded |
Assets checked | Images and downloads that must move |
Internal links checked | Templates and articles that refer to it |
Redirect tested | The observed live response after launch |
Final owner | The person who accepts the row |
The map should not rely on guessed pattern replacements alone. Rules can automate obvious changes, but exceptions need explicit review. Two old articles may be merged into one stronger resource. A retired campaign may have no relevant replacement. A popular PDF may need its own redirect even when the article around it stays unchanged.
Choose the destination by reader equivalence
A redirect is not a disposal chute. It should take the visitor to a page that fulfills substantially the same need.
If an old guide becomes a revised guide at a new slug, the mapping is straightforward. If three overlapping articles become one complete resource, each old URL can point to the new consolidated page when it genuinely answers the same intent.
If no equivalent exists, returning a proper missing response can be more honest than sending every retired page to the homepage. A homepage redirect hides the failure from the project team while giving the visitor a confusing destination.
Write the reason for every non-obvious mapping. That note becomes useful during QA when a reviewer asks whether the redirect is correct or merely convenient.
Prepare a controlled preflight
The new site needs a release candidate that can be inspected before public DNS or routing changes.
Run these checks against the candidate.
Every migrated article has the expected title, headings, body, links, and media
Canonical URLs use the final public host and path
Article structured data matches visible authors, dates, titles, and images
Indexable pages are not carrying temporary
noindexinstructionsThe production robots.txt file is ready and does not preserve a staging block
Sitemaps contain the final canonical URLs only
Analytics and consent behavior work on the new templates
Page performance is acceptable with production-like assets
Do not rely on screenshots alone. Inspect response codes, HTML, headers, structured data, and rendered content. A page can look correct while sending signals that prevent it from being indexed or understood.
Create a freeze window that fits the team
Content often changes while a migration is being prepared. A writer publishes a new article after the first export. An editor updates an old link in the legacy CMS. A product marketer replaces a download. Those changes can vanish if the import snapshot is treated as final.
Set a short freeze window or a documented delta process. During that period, new and changed items must be captured in a final comparison before launch. The smaller the team, the simpler this can be. A shared change log with exact URLs, owners, and timestamps may be enough.
The important point is that the migration has a defined cutoff and a way to reconcile changes after it.
Launch in a sequence you can observe
At launch, activate the new site and redirects, then perform a bounded set of checks before announcing completion.
Begin with critical paths.
The homepage and main blog archive
The highest-value articles
Recently published pages
Pages with strong external links
One example from each redirect pattern
Images and downloads hosted on changed paths
Confirm that old URLs return a direct permanent redirect to the intended new page. Avoid long chains where one old URL moves through several intermediate addresses. Test both browser behavior and server response.
Submit the new sitemap through the normal search tooling and retain the old property or host data where relevant. Do not remove monitoring access the moment traffic moves.
Run three proof passes
One launch-day spot check cannot prove a migration is healthy. Use three passes with different jobs.
The immediate integrity pass
Run this within hours of launch. It catches wrong hosts, missing pages, broken assets, redirect loops, temporary blocks, and template-level mistakes. Compare the live site with the URL map and release candidate.
The discovery pass
Run this after crawlers and users have had time to encounter the new site. Review indexing reports, sitemap processing, crawl errors, logs, and referral patterns. Inspect representative old and new URLs rather than assuming a clean homepage means the archive is fine.
The behavior pass
Run this after enough real traffic exists to compare user journeys. Look for unusual exits, missing conversions, broken downloads, and internal navigation gaps. A technically correct redirect can still send people to a page that does not satisfy the original need.
Each pass should update the same migration map. The map becomes the completion record rather than a planning file that is abandoned at launch.
Define rollback and repair thresholds
Not every issue requires a rollback. A missing image on one low-traffic article can be repaired in place. A site-wide noindex tag, broken redirect rule, or widespread server failure may justify immediate reversal.
Agree on thresholds before launch.
Which failures stop the release
Which failures trigger rollback
Who has authority to make that call
Which team member can change redirects or DNS
Where the previous release can be restored from
How the team communicates the incident
This is less dramatic than it sounds. Clear thresholds reduce hesitation during the first hour when evidence is incomplete and people are under pressure.
Avoid the cleanup launch
A migration feels like a convenient time to delete weak pages, rename every category, rewrite all titles, and merge the entire archive. Some cleanup may be sensible, but mixing every editorial decision into the move makes it hard to distinguish migration effects from content changes.
Keep uncertain pages stable and schedule a later audit. Migrate first, observe the new system, then improve the archive with normal editorial controls. Where consolidation is obvious and approved, document it in the URL map so it remains testable.
The final acceptance record
The migration is complete when the team can produce evidence for the full set of public URLs.
The acceptance record should show the final map, unresolved exceptions, redirect tests, sitemap state, crawl and index checks, asset checks, analytics checks, and the owner of any remaining monitoring.
It should also record what changed beyond URLs. If the CMS, templates, structured data, or analytics implementation changed, name those changes and their separate verification results.
A blog URL migration succeeds when readers reach the right content, old references continue to work, and the new system can be maintained. The visible redesign is only the surface. The durable work is the mapped chain from old promise to new destination, with enough proof that the team can confidently retire the migration project and return to publishing.
