We use Google Analytics cookies to understand which pages and tools are useful and improve the site. Privacy policy.

Technical SEO

How many redirects are too many after changing article slugs?

By bumpit Editorial2026-07-264 min read

Every old article URL should reach its closest replacement in one permanent redirect. Chains add latency, complicate crawling, and preserve migration mistakes longer.

Written for an editor or developer consolidating several generations of blog slugs after a redesign, migration, or content merge.

Key facts

  • Google advises avoiding long redirect chains because they can harm crawl efficiency.
  • A moved article should redirect directly to the closest equivalent final URL.
  • Internal links, canonicals, and sitemap entries should use the final URL rather than any redirecting address.

A useful rule: make each important claim understandable and verifiable without requiring the reader to reconstruct your meaning from the rest of the page.

Why redirect chains form

Chains appear when each redesign adds a new rule without updating earlier ones. An article moves from `/post?id=12` to `/blog/old-title`, then to `/guides/new-title`, and the first URL still points to the middle URL. CMS migrations, trailing-slash normalization, HTTP upgrades, and hostname changes can add more hops before the content loads. Browsers hide much of this path, so a final page can look normal while crawlers and users make several requests. Build a redirect map from every historical URL you can find, follow each path, and record the final status. The repair target is simple: every known old URL should point directly to the stable final canonical.

  • Collect old URLs from analytics, backlinks, prior sitemaps, server logs, and content exports.
  • Test with a client that displays every status and Location header instead of only the final page.
  • Flag loops, temporary redirects, homepage fallbacks, and chains longer than one hop.

Sources: 1, 2

Use the status that describes the move

Use a permanent redirect when the move is intended to last. Google documents permanent server-side redirects such as `301` and `308` as strong signals that the target should become canonical. Temporary redirects describe a temporary destination and should not become the default for a finished migration. The target must also match the old page's intent. Redirecting an expired article to an unrelated homepage can look like a soft 404 and frustrates readers who followed a precise link. When no relevant replacement exists, return a genuine missing-resource status and offer useful navigation on the error page without disguising it as the old content.

  • Choose `301` or `308` consistently with the server and method behavior you require.
  • Map merged articles to the guide that contains the old answer, not merely the newest post.
  • Do not use a redirect to hide a legal, access, or indexing problem that the target does not solve.

Sources: 1

Rewrite every old rule to the final destination

After choosing final URLs, flatten the map. If A points to B and B points to C, change A to point directly to C while keeping B to C for visitors who saved B. Repeat for protocol and hostname normalization so one request does not first change HTTP, then hostname, then path, then slash style. Order server rules carefully because a broad pattern can run before a specific article mapping and create another hop. Test the production configuration, not only a local framework route, because CDNs and hosting platforms may add their own normalization. Keep a versioned redirect table so the next migration starts from the full history.

  • Normalize protocol, hostname, path, and slash in the smallest practical number of responses.
  • Place specific content mappings before broad fallback patterns when the platform evaluates rules in order.
  • Retest all historical inputs after any redirect configuration change.

Sources: 1, 2

Update signals that should no longer redirect

A redirect preserves old entry points, but the live site should stop using them. Update navigation, body links, canonicals, hreflang entries, structured data, feeds, and sitemap records to the final URL. Otherwise crawlers keep encountering the redirect and the site keeps advertising an obsolete address. Ask important external publishers to update links when the relationship makes that practical, but keep the redirect even after links change. The final page should declare itself canonical and provide content equivalent to or better than the old article. These steps give users one stable address and reduce the chance that an intermediate URL remains visible in reporting.

  • Crawl internal links and require zero references to redirecting article URLs.
  • List only final successful canonical URLs in the XML sitemap.
  • Update JSON-LD identifiers and social URLs that embed the previous path.

Sources: 1

Monitor migration quality

Measure the migration with status evidence, not a blanket ranking expectation. Check crawl errors, redirect requests, selected canonicals, indexed URLs, and traffic to the final pages. A temporary fluctuation can occur while search systems process changed URLs, but a persistent split often points to missed links, inconsistent canonicals, or a weak destination match. Keep redirects available for as long as old links and bookmarks may be used. Do not remove them after a short reporting window merely because the new URLs have been crawled. A maintained one-hop redirect is inexpensive insurance for readers and accumulated references.

  • Track requests to old paths so high-use legacy URLs remain covered.
  • Inspect representative old and new URLs together in webmaster tools.
  • Review the redirect table during every content merge and domain change.

Sources: 1, 2

Put it to work

Find the highest-impact fix on your site.

Check the complete redirect path, final status, canonical, title, content match, and sitemap signals for migrated articles.

Audit the redirect destination

Sources

  1. 1.Google Search Central: Redirects and Google SearchChecked 2026-07-26
  2. 2.Google Search Central: Troubleshoot crawling errorsChecked 2026-07-26
Published 2026-07-26 · Last reviewed 2026-07-26 · Review due 2026-10-26Search systems and content quality