Redirects Explained: 301 vs. 302, Setup, and Validation

A redirect sends a request for one URL to another URL. Use it for moves, URL consolidation, or temporary changes. Choose the response according to whether the move is permanent and whether the original HTTP method must be preserved, then connect each old page directly to an appropriate destination.

Compare redirect statuses

See RFC 9110's redirection semantics. Redirecting an article GET is different from redirecting a form or API POST. Confirm whether replaying its data to the destination is intended.

Understand the search implications

For permanent moves, consider 301 or 308; temporary moves commonly use 302 or 307. Google treats redirects as canonicalization signals, but a 302 destination is not permanently barred from indexing. Other signals and circumstances also matter. A 301 does not guarantee full ranking or traffic preservation. Follow Google's redirect guidance.

A canonical declaration is a strong signal for choosing among duplicate or similar URLs, not an instruction that moves visitors. It should not replace a redirect when users also need to reach the new address.

Build an old-to-new URL map

Choose destinations that satisfy the old page's purpose. Sending every old URL to the homepage can frustrate visitors and fail to provide a relevant replacement. For consolidation, determine which content and intent survive in the destination.

Include real query strings, trailing slashes, case variants, language paths, and host variants in the test plan. Review the broader CMS migration requirements before implementation.

Scope the configuration carefully

CMS or hosting features

Specify the source, destination, status, and scope. Decide whether the CMS, server, or CDN owns the rule; duplicate rules across layers can create chains or loops.

Apache

An illustrative exact-path rule is “RedirectMatch 301 ^/old-page$ /new-page”. It targets /old-page, not an entire domain migration. The regular Redirect directive also handles prefix matching, so check unintended descendant paths. Validate syntax and behavior against Apache's mod_alias documentation.

.htaccess is useful where shared hosting prevents access to the main configuration. Where main configuration is available, consider it for performance and operational reasons; moving rules into .htaccess is not inherently a speed improvement.

Nginx

An illustrative exact-location rule is “location = /old-page { return 301 /new-page; }”. Its scope differs from placing a return at server level. Review existing locations and query-string requirements, run configuration checks, and validate in a suitable environment before applying a rule to production.

Validate the whole request path

A final visible page does not reveal every intermediate response. Use browser developer tools or another authorized HTTP inspection method. Investigate 403 denials and 502 upstream failures separately rather than attributing every failure to the redirect rule.

Monitor and retain redirects

Track old-URL requests, failures, new-page indexing, and comparable search performance. Google's site-move guidance recommends retaining redirects as long as possible, generally at least one year. This is not a rule to remove them after one year or a guarantee of completed ranking transfer. External links and bookmarks can justify longer retention.

Use the Search Console workflow to review the move. If reverting, align redirects, canonicals, internal links, and sitemaps together to avoid a circular old/new relationship. Record the owner, change date, configuration layer, tests, and rollback conditions.

Test representative cases before broad rollout

Choose examples covering articles, image references, query strings, language paths, and forms. A short rule can still affect an entire host, so validate its scope as well as the URL count. Compare observed responses with the mapping before expanding deployment. Maintain one rule inventory and owner so another team does not introduce an overlapping redirect later.