301 Redirects: Move URLs Cleanly
Key takeaways
- A 301 is a permanent server-side redirect and a canonicalisation signal for Google Search.
- Map old URLs to relevant new destinations instead of sending everything to the home page.
- Avoid chains and loops by redirecting each old URL directly to its final destination.
- Update internal links, canonicals, hreflang and sitemaps to reference new URLs.
- Test response codes and destinations, then monitor crawling, indexing and traffic after launch.
What is a 301 redirect?
A 301 redirect is an HTTP response that says a resource has moved permanently to another URL. A browser or crawler requests the old address, receives the redirect and follows the Location header to the destination.
Google's current redirect guidance says its indexing pipeline uses permanent redirects as a signal that the target should be canonical. The same guidance recommends a permanent server-side redirect when a page's search-facing URL has changed.
That makes a 301 useful for permanent URL changes, not for concealing every untidy status code. Redirects are plumbing. They should carry users somewhere useful, not simply make the dashboard quieter.
When should you use a 301 redirect?
Use a 301 when the old URL has a clear, permanent replacement. Common cases include a changed slug, an HTTP to HTTPS move, a domain migration or a merged page with a genuinely equivalent destination.
Use a temporary redirect when the change is temporary and the source URL should remain the search result. Google's documentation distinguishes permanent redirects, which signal the target as canonical, from temporary redirects, which do not provide that same signal.
If content has been removed and there is no useful replacement, a 404 or 410 can be more accurate than an irrelevant redirect. Google's site-move guidance explicitly says deleted or unmerged content should return a 404 or 410.
Where should an old URL redirect?
Redirect it to the closest useful equivalent that satisfies the same intent. Build a one-to-one mapping wherever the content has a genuine successor.
Do not redirect every discontinued product, old article or campaign page to the home page. That destination may be technically live while being contextually useless. If several old pages were deliberately consolidated into one stronger resource, document that many-to-one mapping and check that the destination covers their important intent.
Start with URLs found in sitemaps, analytics, server logs, Search Console and backlink reports. The site-move documentation recommends using these sources to identify important old URLs before creating the map.
Why should you avoid redirect chains?
A redirect should normally take the requester straight from the old URL to the final live URL. Chains add requests, slow navigation and make migrations harder to audit.
A chain looks like old A to old B to new C. Replace it with old A to new C and old B to new C. A loop, where URLs redirect back to one another, prevents the destination from loading at all.
Crawl the complete legacy list, not just links found on the new site. Old URLs may still receive visits from bookmarks, external links and search indexes even after they disappear from navigation.
Which signals must change after a URL move?
Internal links, canonical tags, hreflang annotations and sitemaps should reference the final new URLs. Do not make crawlers pass through redirects you control.
Google's site-move guide says each new URL should have a self-referencing canonical, multilingual annotations should use the new URLs, and internal links should be updated. It also recommends preparing a sitemap containing the new URLs.
The canonical tags guide explains how redirects and canonical tags can reinforce the same preferred URL. The XML sitemap guide covers why submitted URLs should be canonical and indexable.
How do you test a 301 redirect?
Request the old URL without automatically following redirects, record the status and Location header, then request the final destination. The old URL should return the intended permanent status, and the destination should return a successful response with the expected content.
Test representative rules and every high-value mapped URL. Check uppercase variants, trailing slashes, query strings and encoded characters where the platform handles them differently. Bulk patterns deserve edge-case tests because one elegant rule can create a very comprehensive mistake.
Then crawl the new site to find internal links that still point to redirecting URLs. Review canonicals, hreflang, structured data URLs and XML sitemaps separately because a page crawl may not expose every source.
Do 301 redirects preserve rankings?
A 301 supports consolidation, but it does not guarantee unchanged rankings or traffic. Relevance, content, internal signals, crawl timing and migration quality still matter.
Google states in its site-move guide that 301 and other permanent redirects do not cause a loss in PageRank. The same page warns that significant moves can produce temporary ranking fluctuations while Google recrawls and reindexes the site.
Treat those statements together. A permanent redirect is not a ranking penalty, and a migration is not instant. The word permanent is about destination intent, not a promise that every chart stays perfectly horizontal.
How should you monitor after launch?
Monitor old and new URLs through server logs, analytics and Search Console while validating the redirect map repeatedly. Watch for redirect errors, unexpected 404s, old URLs still receiving bot requests and new URLs excluded from indexing.
Submit the new sitemap and keep it free of redirected URLs. Compare important landing-page traffic and conversions, not only total clicks. Sample live old URLs from each redirect rule to catch configuration changes after deployment.
SAGEO's log file analysis guide shows how request data can reveal what crawlers actually fetch. That is more reliable than assuming a migration spreadsheet has become reality through optimism.
Limitations
This guide does not provide server-specific configuration or guarantee search performance. Redirect behaviour can be affected by application logic, content delivery networks, caching, proxies and hosting rules. A domain migration also requires broader DNS, certificate, analytics and Search Console planning.
For high-risk migrations, validate the URL map in staging, test production responses immediately after launch and preserve a rollback path for faulty rules.