The short answer
Preserve valuable URLs; redirect only when the destination is genuinely equivalent.
Before a redesign launches, export every discoverable and valuable old URL. Keep proven paths unchanged where practical. For each necessary move, send the old URL through one permanent server-side redirect to the closest relevant final page, then update internal links, canonicals, and the XML sitemap to use that destination directly.
Do not send the entire retired site to the homepage. Do not ship chains, loops, or destinations that return errors or noindex.
Five redirect rules
A redirect protects a route—not an abstract score.
- 01
Preserve before moving
If a URL already earns qualified traffic, links, citations, or conversions and the page role remains the same, keeping it avoids an unnecessary migration variable.
- 02
Map by user intent
Send the old page to the destination that completes the same decision. Matching a word in the slug is not enough.
- 03
Go directly to final
Old URLs should redirect in one hop to a successful, indexable, canonical page. Flatten historic chains before launch.
- 04
Update every internal route
Navigation, contextual links, canonicals, hreflang where relevant, schema URLs, and sitemaps should reference the final URL—not rely on the redirect.
- 05
Keep and monitor
Retain redirects for at least the period Google recommends and longer when users, bookmarks, campaigns, or external links still depend on them.
The redirect map
Make every decision reviewable before launch.
| Old URL | Disposition | New destination | Evidence to record |
|---|---|---|---|
| /old-service | 301 / direct replacement | /services/core-service | Same offer, intent, proof, and conversion route |
| /city-service-a | 301 / consolidated | /service-areas | No distinct local value; destination covers the served territory honestly |
| /case-study-old | Keep URL | Unchanged | Existing links and traffic; redesign changes presentation only |
| /expired-promo | 404 or 410 | None | No replacement with equivalent purpose |
Your working sheet should also contain response code, final response, canonical, indexability, internal links updated, traffic, backlinks, conversion history, owner, test status, and notes. A useful migration is auditable row by row.
Pre- and post-launch proof
Test the map as a system, not a sample of favorites.
- crawl and join old plus staging inventories;
- review every high-value destination manually;
- detect chains, loops, missing mappings, and redirects to redirects;
- check canonicals, noindex, robots, navigation, and sitemaps;
- test forms, calls, analytics, and mobile templates.
- crawl every mapped old URL against production;
- confirm one-hop final responses and intended content;
- inspect priority destinations in Search Console;
- watch server errors, traffic, conversions, and selected canonicals;
- retain the baseline so changes have context.
The broader website migration SEO checklist places this redirect work inside the complete launch sequence.
Failure patterns
Most redesign losses are predictable before launch.
- Everything to homeUnrelated pages lose their specific destination and users lose the answer they expected. Map relevant replacements or retire the URL honestly.
- Chains and loopsHistoric moves stack together or point back into themselves. Rewrite the rule so every old URL reaches the final owner directly.
- Redirected assets onlyImages and files are considered while the actual landing pages are missed. Start from complete inventories, analytics, links, sitemaps, and indexed URLs.
- Destination contradictionThe redirect lands on a page whose canonical points elsewhere, carries noindex, or returns a soft 404. Validate the entire destination state.
- Internal dependenceThe new site still links to old routes and makes redirects part of normal navigation. Update every owned route to the final URL.
Connect diagnosis to execution
The correct control is the one the evidence calls for.
MooseRank's technical SEO and site foundation work connects the diagnosis to implementation, live validation, and the pages that support qualified demand.
As an Long Island search engine optimization company, MooseRank keeps technical decisions tied to the service, market, page owner, and customer action the campaign is meant to grow.
Protect the search path
Fix the constraint with the clearest business consequence.
Bring the page, migration, or indexing problem. MooseRank will trace the evidence, choose the right control, and define what complete looks like.
Straight answers
Common questions
01Should I use a 301 or 308 redirect for a website redesign?+
Both are permanent server-side redirects and are appropriate for permanent URL moves. Use the status your platform supports reliably and consistently. The quality of the destination and the absence of chains matter more than choosing between those two permanent codes.
02Should every old URL redirect to the homepage?+
No. Redirect each old URL to the closest relevant replacement. Redirecting many unrelated pages to the homepage creates a poor user experience and can be treated as a soft 404.
03Do 301 redirects lose all SEO value?+
Google recommends permanent server-side redirects for permanent moves and uses them as a strong canonical signal. A move can still cause temporary fluctuation while URLs are recrawled and processed, especially when content, architecture, and URLs all change together.
04How long should redesign redirects remain in place?+
Google recommends keeping redirects for at least one year, and users or old links may benefit from keeping useful redirects longer. Do not remove them merely because the new site has been live for a few weeks.
05When should an old page return 404 or 410 instead of redirecting?+
When the page is intentionally gone and there is no genuinely relevant replacement. A clear not-found response is better than forcing users and crawlers onto an unrelated page.
Primary sources
Google documentation reviewed
- Google Search Central: Redirects and Google Search
- Google Search Central: Site moves with URL changes
- Google Search Central: HTTP status codes and errors
- Google Search Central: Canonicalization
Research note: official documentation was reviewed September 21, 2026. The diagnostic frameworks and examples are MooseRank's application of those documented mechanisms to service-business websites; they are not Google ranking-factor labels or guarantees.
About the author
The Moose
The Moose is the Founder of MooseRank and writes about SEO strategy, AI search visibility, and the evidence businesses should use to make better search decisions.
Meet The Moose and the MooseRank system