A 301 redirect is usually the right choice when a URL has moved permanently, while a 302 is intended for a temporary change. This guide explains the difference between 301, 302, 307, and 308 redirects, then provides a reusable checklist for migrations, HTTPS changes, campaigns, redirect-chain troubleshooting, and routine website audits.
Overview
Redirects tell browsers, crawlers, and other clients that a requested URL should lead somewhere else. The status code communicates whether the change is expected to be temporary or permanent, and in some cases whether the original request method must be preserved.
For most permanent URL changes, use a 301 redirect. Examples include replacing an old product URL, consolidating duplicate pages, moving from an old domain to a new domain, or changing a site from HTTP to HTTPS. A 301 generally gives search engines a durable signal that the destination should represent the old URL.
Use a 302 redirect when the original URL is expected to return or when the change is temporary. Common examples include a short-term campaign destination, temporary maintenance routing, or a controlled experiment where you do not want to treat the destination as a permanent replacement.
When preserving the request method matters, consider the method-preserving alternatives: 307 for a temporary redirect and 308 for a permanent redirect. This distinction is particularly important for developers working with form submissions, APIs, and non-GET requests. If you are unsure whether a server, framework, or client handles these codes as intended, test the complete request flow before deploying.
| Status | Use it when | Practical note |
|---|---|---|
| 301 | The URL has moved permanently | Common choice for site migrations, URL changes, and HTTPS enforcement |
| 302 | The change is temporary | Keep the original URL as the long-term address |
| 307 | A temporary move must preserve the request method | Useful for technical workflows involving POST or other methods |
| 308 | A permanent move must preserve the request method | Test application and client compatibility carefully |
The short answer to “which redirect should I use?” is: choose 301 for a genuine permanent move, 302 for a temporary change, and 307 or 308 when preserving the HTTP method is a requirement.
Checklist by scenario
Permanent URL change or content consolidation
- Confirm that the destination is the closest relevant replacement, not simply the home page.
- Map each old URL to one final destination.
- Use a 301 unless your application specifically requires a method-preserving permanent redirect.
- Update internal links, XML sitemaps, canonical references, structured data URLs, and navigation.
- Keep the redirect in place long enough to support users and systems that still request the old address.
HTTP to HTTPS migration
- Install and validate the SSL certificate before enforcing HTTPS. See the SSL certificate errors troubleshooting guide if browsers report certificate problems.
- Redirect each HTTP URL to its HTTPS equivalent with a single permanent redirect.
- Check images, scripts, stylesheets, fonts, forms, and third-party resources for mixed-content issues.
- Update absolute URLs in the CMS, application configuration, canonical tags, and sitemap.
- Confirm that both the apex domain and the preferred www or non-www version resolve consistently.
Temporary promotion, maintenance, or testing
- Use a 302 when the original URL remains the intended long-term address.
- Set an owner and review date so the redirect does not remain indefinitely by accident.
- Verify that the destination reflects the user's expectation and that tracking parameters are handled consistently.
- Remove or replace the temporary redirect when the campaign or maintenance window ends.
Domain or hosting migration
- Build a complete old-to-new URL map before changing DNS or hosting.
- Set redirects at the web server, proxy, or application layer with a clear fallback plan.
- Test representative pages, files, language versions, login paths, and important query-string behavior.
- Monitor errors and traffic after launch. A website uptime monitoring guide can help organize checks for availability and incident response.
- Review DNS records separately from HTTP redirects. DNS points a hostname to infrastructure; it does not replace URL-level redirect rules. Use this DNS records guide to verify the underlying configuration.
What to double-check
A redirect audit should test more than whether one URL eventually loads. Use a crawler, browser developer tools, command-line requests, or a suitable HTTP header checker to record the full response path.
- Status code: Confirm that the source returns the intended 301, 302, 307, or 308 response rather than a soft redirect through a page rendered with JavaScript.
- Destination: Confirm that the final URL is correct, accessible, canonical, and relevant to the original request.
- Chain length: Look for old URL to intermediate URL to another intermediate URL to final URL sequences. Replace the chain with one direct redirect where possible.
- Loops: Test for patterns such as HTTP redirecting to HTTPS while a proxy or application sends HTTPS back to HTTP.
- Final response: The destination should return the expected success or application response, not a 404, 5xx error, blocked resource, or unexpected login page.
- Variants: Test uppercase and lowercase paths where relevant, trailing slashes, URL encoding, query strings, www and non-www hostnames, and both HTTP and HTTPS.
- Signals: Update canonical tags, internal links, sitemaps, hreflang references, and campaign URLs so they point directly to the preferred destination.
For a broader infrastructure review, pair the redirect audit with a backup plan. The website backup strategy checklist covers what to preserve before a major URL or hosting change.
Common mistakes
- Using a 302 for a permanent move: This makes the site's intent less clear and can leave temporary rules in place after a migration.
- Redirecting every old URL to the home page: This creates a poor user experience and may not provide a meaningful replacement for the requested content.
- Creating redirect chains: Chains increase complexity and make troubleshooting harder. Point old URLs directly to their final destinations.
- Leaving redirects inside redirects: When a destination later changes, update the original rule rather than adding another hop.
- Ignoring non-HTML assets: PDFs, images, feeds, API endpoints, and downloadable files may have their own URL dependencies.
- Changing DNS and redirects at the same time without a plan: Separate DNS validation from HTTP testing so an outage is easier to isolate.
- Skipping rollback preparation: Export current rules, save URL mappings, and document the previous configuration before deployment.
When to revisit
Run this checklist before a domain change, rebrand, URL restructuring, HTTPS rollout, hosting migration, seasonal campaign, or major CMS release. Revisit it after changing reverse-proxy rules, web-server configuration, routing middleware, caching, or DNS management workflows. It is also useful during quarterly or annual website maintenance, especially when teams have added temporary redirects without a formal expiration process.
For a repeatable audit, keep a simple record containing the source URL, intended status code, final destination, test date, owner, and result. Re-test a sample of priority URLs after deployment, then check logs and monitoring for unexpected 404s, redirect loops, certificate errors, and server failures. If the site runs on WordPress, include redirects in the wider WordPress hosting performance checklist. If infrastructure is changing, use the hosting migration checklist alongside this one.
Before publishing a redirect change, ask three final questions: Is the move truly temporary or permanent? Does the chosen status preserve the request method when necessary? Can a user and crawler reach the final, secure, relevant URL in one step? Clear answers will prevent most 301 versus 302 errors and provide a reliable foundation for ongoing URL management.
