To move a SaaS blog without breaking access to its articles, make an old-to-new URL map before changing routes. Give each article one decision: move it to a relevant live page, keep its URL working, or retire it without an unrelated redirect. Then release the destination and redirect changes, update links, and test the public results. Google’s site-move guidance recommends mapping existing URLs to their corresponding new URLs before the move.
Assign every old article URL an outcome
Export published URLs from your CMS and sitemap, then compare them with recently visited URLs and articles that receive links or search traffic. Start with important posts, but do not stop there: the migration map needs a decision for every old article URL you intend to handle. Google recommends using sources such as sitemaps, analytics, server logs, and your CMS to build that inventory.
Use the fields below as a working sheet. Record the old URL, whether the article is moved, retained, or retired, its intended destination or error response, an owner, and the result of a live test. Keep “planned” separate from “tested”: a redirect rule in a configuration file is not proof that a visitor reaches the right article. The observed results in this fictional example illustrate how to fill in the sheet after release; they are not measurements of a real site.
The fictional example below is a selective move: the old domain remains active, so one post can retain its exact URL there. In a full move from example.com to example.net, an article with the same path has still changed URL; map and redirect its old-domain address too. For a moved article, choose the page that actually answers the old article’s question. If no similar replacement exists, Google advises returning 404 or 410 rather than redirecting the removed page to an unrelated destination.
| Old URL | Decision | Destination or response | Owner | Expected live test | Illustrative observed result |
|---|---|---|---|---|---|
https://example.com/blog/setup | Moved | https://example.net/blog/setup | Website team | Old URL redirects permanently and directly; new article loads. | Old URL: 301 directly to new URL. New article: 200. |
https://example.com/blog/security | Retained | Same URL on the still-active old domain | Website team | Article loads at its original URL without a move redirect. | Original URL: 200; security article loads. |
https://example.com/blog/legacy-import | Retired; no similar replacement | 404 or 410 | Website team | Old URL returns the intended error status, not a homepage redirect. | Old URL: 410; no redirect. |
Release destinations before old links point to them
Prepare the new article pages, redirect rules, canonical URLs, sitemap, and inbound-link edits from the same mapping sheet. Give your website team the redirect map; the exact configuration depends on your host or CMS. Google recommends server-side permanent redirects for moved URLs. Point each old URL at its final relevant destination rather than routing it through an intermediate URL.
If your team can deploy the new pages, redirects, and updated internal links together, release them as one coordinated change. If releases are separate, publish and check the new destination first, then activate its redirect and update links pointing to it. Leave the retained example at its original address, and configure the retired example to return its chosen error status. Do not redirect every retired post to the blog home simply to avoid a 404.
Change internal links to point straight to the new article URLs, including links in older posts, navigation, and relevant product pages. Set each moved page’s canonical annotation to its new URL and include new URLs in the new sitemap. Google’s migration guidance calls for updated internal links and a sitemap of new URLs; redirects should not be the permanent route for links you control. If two posts are being merged because they answer the same question, make that editorial decision using the separate guide to overlapping SaaS blog posts.
Test the public URLs, not just the rules
After release, visit and check the response for each row in the mapping sheet. Begin with the most important articles, then work through the remaining rows. Record the observed result and a fix owner beside any mismatch; this turns the map into a release test rather than an archive of intentions.
- For each moved article, request the old URL and confirm it returns the configured permanent redirect to the intended final URL without an extra hop. Open the destination and confirm that the expected article, not an error or generic page, loads. Google recommends permanent redirects for moved pages with a clear replacement.
- For retained and retired articles, check the actual status: the retained post still loads at its unchanged URL; the retired post returns
404or410if it has no similar replacement. A page displaying “not found” while returning200is a soft-404 problem described by Google. - On moved destinations, inspect the canonical URL and confirm the page is available to crawlers. Check that the new sitemap lists new article URLs, and follow internal links from the blog index and a few older posts to make sure they reach their intended pages directly.
Watch important articles after launch
Keep a short priority list of articles with important traffic, links, or product journeys. Recheck their old-to-new paths after deployment and inspect the new URLs in Search Console if a page is not behaving as expected. Compare indexing and search performance over time rather than treating launch-day results as a verdict: Google notes that processing a move happens URL by URL and recommends keeping redirects as long as possible, generally at least a year.
For a domain or subdomain move, consider Search Console’s Change of Address process; it is not the step for a path-only change on the same domain. If one destination has an indexing problem, use the separate article indexing guide for URL-level diagnosis rather than remapping the whole blog.
This continuity work matters for articles published through Ranks because Ranks says the content lives on your own blog. Your website team still needs to make and test the site changes. If connected, Ranks’ read-only Search Console overview can show clicks, impressions, and average position over time; use Search Console itself for detailed page filters and URL Inspection. Those trends help flag articles worth investigating, but they do not replace the live URL tests.
