A guide to redirect types, SEO, performance, security, and testing.
- Redirect Types: When to Use Which
- SEO Best Practices
- Performance & Architecture
- Security: Preventing Open Redirects
- Testing & Monitoring
- Contributing
Not all redirects are created equal. Picking the wrong one can cost you rankings, confuse users, or break form submissions.
| Code | Meaning | When to use |
|---|---|---|
| 301 | Moved Permanently | Changing a URL forever, migrating domains, HTTP to HTTPS |
| 302 | Found (Temporary) | Short-term maintenance, A/B testing, temporary content moves |
| 307 | Temporary Redirect | Same as 302 but preserves the HTTP method (POST stays POST) |
| 308 | Permanent Redirect | Same as 301 but preserves the HTTP method |
- Google Search Central: Redirects and Google Search: Guide to how Google interprets common redirect types. Covers server-side redirects, meta refresh, JavaScript redirects, and other client-side redirect methods, with implementation examples for Apache, Nginx, and PHP.
- MDN Web Docs: Redirections in HTTP: Reference for HTTP redirect status codes. Covers permanent, temporary, and special redirects, plus HTML meta refresh and JavaScript alternatives, with precedence rules.
- Ahrefs: 11 Types of Redirects & Their SEO Impact: Practical breakdown of common redirect types with examples. Explains how Google treats each one for canonicalization and links, plus how to verify redirect behavior in Search Console.
Use 301 for permanent moves (domain changes, URL restructuring, HTTP→HTTPS). Use 302 for temporary situations (downtime pages, promotions, A/B tests). If your forms or API calls go through the redirect, prefer 307 and 308 to preserve the request method.
Google treats 301 as a strong canonicalization signal: link equity consolidates to the new URL. A 302 keeps the original URL indexed. Get this wrong and you can split your ranking signals across two URLs.
Redirects can affect indexing, canonicalization, and traffic during migrations. Mistakes can lead to ranking and crawl issues.
Every old URL should map to the closest equivalent on the new site. Redirecting everything to the homepage (a "blunt redirect" or "site-level redirect") is a common mistake. Google treats irrelevant redirects as soft 404s, meaning you lose all the link equity from the old page.
Good:
/old-product-page→/new-product-pageBad:/old-product-page→/homepage
A redirect chain happens when URL A goes to B, B goes to C, and C goes to D. Each hop adds latency and dilutes link equity. Google recommends keeping it to one hop.
- Google Lighthouse: Avoid multiple page redirects: Explains why chains hurt Core Web Vitals and how Lighthouse flags pages with two or more redirects. Includes stack-specific guidance for Drupal and React Router.
Fix chains by updating your redirect map to point old URLs directly to the final destination.
After setting up redirects, update every internal link to point directly to the new URL. This eliminates unnecessary hops and lets crawlers discover the new URLs naturally. Use a crawler like Screaming Frog to find all internal links still pointing to old URLs.
After a migration, submit your new sitemap in Google Search Console and keep the old sitemap active until Google has processed all the redirects. This helps Google discover the mapping faster.
Keep an eye on the Index Coverage report for spikes in 404s, soft 404s, or redirect errors. The URL Inspection tool lets you verify individual redirects are being processed correctly.
- Google Search Central: Redirects and Google Search: Reference for how Google processes redirects. Explains permanent and temporary redirects, server-side and client-side methods, and implementation examples for Apache, Nginx, and PHP.
- Ahrefs: 11 Types of Redirects & Their SEO Impact: Covers how to verify Google is consolidating link signals correctly using Search Console's external links report, plus a diagnostic method for detecting when redirects are treated as soft 404s.
- RedirHub: Migration Checklists: Step-by-step checklists for domain migrations, platform rebrands, HTTPS migrations, and M&A scenarios. Covers pre-launch planning, redirect mapping, and post-launch monitoring.
Redirects add latency. A single redirect can add 200-500ms. A chain of three redirects can delay the page by over a second. Where you process redirects matters.
Processing redirects at the CDN or edge layer can reduce origin load and latency.
Where to process redirects, from fastest to slowest:
- CDN/Edge (Cloudflare, Fastly, Akamai): Sub-millisecond response, no origin hit
- Reverse Proxy (Nginx, Caddy, Traefik): Single-digit milliseconds, on your infrastructure
- Application Layer (Node.js, PHP, Django): 10-100ms+ depending on framework and database calls
- Client-Side (JavaScript, meta refresh): Full page load + render before redirect fires
- Chrome for Developers: Avoid multiple page redirects: Covers the performance cost of redirect chains and how Lighthouse measures them. Shows how each redirect adds a full network round trip for resources in the critical rendering path.
- Cloudflare: URL Forwarding docs: How to configure redirects at the edge using Bulk Redirects, Single Redirects, and Page Rules. Edge redirects avoid origin hits entirely.
- Fastly: Redirects at the Edge: Setting up redirect logic in VCL at the CDN layer for zero-latency redirects.
Resources needed for first paint (CSS, fonts, above-the-fold images) should never go through redirects. Each redirect on a critical resource delays rendering for all users. Use your browser's DevTools Network tab with "Preserve log" enabled to spot redirected resources in the waterfall.
An open redirect is when your application takes a user-supplied URL and redirects the browser there without validation. Attackers exploit this to make phishing links appear to come from your domain.
https://yoursite.com/redirect?url=https://evil-site.com
A user sees yoursite.com in the link and trusts it, but lands on evil-site.com. Because the redirect originated from your domain, browsers and email filters are less likely to flag it.
- Avoid user-controlled redirect targets. If you don't need redirect parameters, don't add them.
- Use an allowlist of known-safe URLs. Map short names or tokens to full URLs server-side instead of accepting raw URLs as input.
- Use relative paths only. If the redirect must be dynamic, only accept paths like
/dashboardand prepend your domain. - Validate any URL input. Check the protocol (
httpsonly), domain (your allowlist), and path before redirecting. - Add an interstitial page. Show users they're leaving your site with the full destination URL displayed.
- OWASP: Unvalidated Redirects and Forwards Cheat Sheet: Security reference covering dangerous patterns in Java, PHP, ASP.NET, Rails, and Rust, plus prevention strategies including URL validation, token-based redirect mapping, and interstitial pages.
- OWASP: Server-Side Request Forgery Prevention Cheat Sheet: URL validation techniques that apply to redirect security. Covers DNS resolution checks, allowlist approaches, and network-layer controls.
Setting up redirects is half the work. Verifying they work correctly is the other half.
- Every redirect returns the expected status code (301 vs 302)
- The destination URL is correct (no typos, no broken paths)
- No redirect chains longer than one hop
- Canonical tags on destination pages match the new URL
- HTTPS is enforced (no downgrade from HTTPS to HTTP)
- Old URLs are not in sitemaps, new URLs are
- No redirect loops
curl -I -L: Quick command-line verification. Add-o /dev/null -w "%{url_effective}\n"to see the final destination.- Screaming Frog SEO Spider: Desktop crawler with redirect chain visualization. Free for up to 500 URLs.
- Lighthouse / PageSpeed Insights: Flags multiple redirect chains affecting performance.
- Google Search Console: URL Inspection: Check how Google is processing individual URLs after a migration.
- whatsmydns.net: Verify DNS propagation when changing domains or CDN providers.
- Search Console Index Coverage: Watch for 404 spikes and redirect errors in the days after launch.
- Traffic monitoring: Organic traffic typically dips 10-20% immediately after a major migration, then recovers within 2-8 weeks. A dip beyond 30% or recovery taking longer than 12 weeks signals redirect issues.
- Backlink monitoring: Use Ahrefs or Semrush to verify referring domains are hitting your redirects correctly. Lost referring domains → lost link equity.
- Crawl budget: Google doesn't crawl redirects infinitely. If you have 100,000+ redirects, monitor crawl stats to ensure Google isn't wasting budget on old URLs.
- Google Search Central: Redirects and Google Search: Implementation examples for Apache, Nginx, and PHP. Explains how different redirect methods affect Google's processing.
- Chrome for Developers: Avoid multiple page redirects: Performance testing methodology for redirect chains and stack-specific fixes.
- RedirHub: Migration Checklists: Testing checklists with URL inventory scripts, redirect mapping templates, and monitoring plans for different migration scenarios.
Contributions welcome! Please read CONTRIBUTING.md first.
