301 Redirect: Permanent Redirect

What a 301 decides

A 301 Moved Permanently response sends a browser or crawler from a source URL to a destination URL. It is a statement about the URL relationship, not a promise about rankings or traffic. Google documents permanent redirects as a canonicalization signal: the destination is the candidate that should appear in Search when the move will not be reversed.

The decision has two parts. First, the old resource must have a genuinely durable replacement. Second, the destination must answer the same or a more useful intent. A discontinued product that has no reasonable successor may need a 404 or 410 rather than a redirect to a category or home page. Redirecting every retired URL to one broad page makes the relationship unclear for people and crawlers.

zoom_in

When a permanent redirect fits

Use a 301 when the old URL has moved for the long term: a renamed page, a consolidated duplicate, a protocol or host consolidation, or a documented page-level site migration. Map old pages to their closest surviving equivalents. This preserves a useful path for a visitor following an old bookmark or external link and gives crawlers an unambiguous route to review.

Good match

An old guide is replaced by a new guide covering the same task; the redirect is one hop to that new guide.

Poor match

A retired item is sent to an unrelated landing page simply because it exists.

Not a move

The page may return later or is being tested briefly; treat that as a temporary-routing question instead.

For a migration, make the redirect map before changing navigation. Each row should record the source path, the selected destination, the rationale, the response observed after release and an owner for exceptions. Use a page-level map and test the final response path; that keeps a broad host rule from silently flattening thousands of unrelated pages into the home page.

Implementation and checks

1. List the legacy URLs that can receive visits or links, then choose one final, indexable destination for each meaningful page.
2. Configure the redirect at the server or platform layer where it returns an HTTP 301 and a Location header before page content is served.
3. Update internal links, XML sitemaps and canonical references to the final URL; they should not keep pointing at the redirect source.
4. Request the source URL and follow the chain. Record the status sequence, final URL and whether the final page returns a successful response.
5. Re-crawl the affected set after release. Investigate loops, multi-hop chains, redirect-to-redirect rules and destinations that are blocked or noindexed.

curl -I https://example.com/old-page
# Expect: HTTP/2 301 and a Location header
curl -IL https://example.com/old-page
# Inspect every hop and the final response

The exact configuration syntax depends on the platform. The lasting invariant is more important than a copied rule: a source should resolve in one hop to the intended canonical destination. Keep temporary infrastructure rules and content moves separate so that reversing a maintenance change does not also dismantle a migration map.

Failure modes and limits

A frequent false conclusion is that any 301 “passes authority” mechanically. Search engines evaluate several signals and recrawl on their own schedule. What can be verified is narrower: the server returns the intended status, the target is reachable and indexable, the map is relevant, and site-owned references use the final URL. Do not use a fixed percentage for link value or a guaranteed time to replace a result.

• A chain appears after a second migration rule is added; replace it with a direct source-to-final rule.
• A redirect loop occurs when a host or protocol rule contradicts a page rule; test both HTTP/HTTPS and host variants.
• A 301 lands on a 404, noindex page or blocked route; repair the destination before treating the source mapping as complete.
• A legacy sitemap remains published; remove redirected URLs so the sitemap declares only final indexable pages.