The Complete Guide to URL Redirects in 2026: HTTPS, 301/302, and Domain Management at Scale

What is a URL Redirect?

A URL redirect forwards visitors from one web address to another using 301 (permanent) or 302 (temporary) status codes. DNS-based services automate HTTPS certificates for 5 to thousands of domains without server management, preserving SEO rankings during migrations, rebrands, and domain consolidations. This eliminates the manual certificate management that typically makes redirects a full-time DevOps burden.

Why URL Redirects Matter

Website migrations break links. Rebrands leave old URLs pointing nowhere. Domain consolidations lose SEO value.

The cost of broken redirects:

• SEO value lost when using incomplete mapping or redirect chains
• Hours of DevOps time per complex redirect configuration
• Security warnings that cause most users to abandon the visit before any redirect can run
• Lost revenue from broken customer bookmarks and backlinks

URL redirects fix this, but only when implemented correctly with HTTPS support.

Most teams face the same problem: making HTTPS work across dozens or hundreds of domains without becoming a full-time job.

Understanding Redirects: Domain vs Internal

What Is a URL Redirect?

A URL redirect sends browsers and search engines from one web address to another. The server returns a 3xx HTTP status code meaning “content moved: look here instead.”

Visit oldbrand.com/page → redirect → land on newbrand.com/page.

Domain-Level Redirects (DNS-Based)

Domain-level redirects route traffic between different domains: oldbrand.com → newbrand.com.

These require DNS configuration to point your domain to the redirect service. The DNS records direct traffic to the service's edge network, where the actual redirect happens at the HTTP(S) layer after the TLS handshake completes. When a domain routes through a DNS-based redirect service, you can also map paths beneath it:

• oldbrand.com → newbrand.com
• oldbrand.com/about → newbrand.com/company/info
• oldbrand.com/pricing → newbrand.com/plans

What DNS-based services do:

• Accept traffic routed via DNS to their edge network
• Handle HTTPS/SSL certificates automatically
• Process redirects at global edge locations
• Provide analytics on redirect traffic

What they don't do:

• Modify your website files
• Access your web server
• Change your site's internal structure

Note: Some services (like redirect.pizza’s Business tier) include a Web Application Firewall (WAF) for additional security protection.

Internal Redirects (Server-Based)

Internal redirects manage changes within one website: /old-page → /new-page on yoursite.com.

These are handled by your CMS or web server configuration (WordPress, Apache, Nginx, IIS). You’re modifying routing within your existing infrastructure.

Note: redirect.pizza handles domain-to-domain redirects. Page-to-page redirects within the same domain are managed by your CMS or web server, unless the entire domain is routed through redirect.pizza with path forwarding enabled.

The HTTPS Challenge

Why HTTPS Redirects Fail

Browsers validate SSL certificates before processing redirects. The sequence:

1. User types https://olddomain.com
2. Browser performs SSL/TLS handshake
3. Browser validates certificate
4. If certificate invalid → security warning → most users leave
5. Only then would redirect execute

Domain registrar “forwarding” breaks here. They forward HTTP traffic fine, but HTTPS requests find no valid certificate. Result: “Your connection is not private” error that causes most users to abandon the visit before any redirect can run.

Manual SSL Management Doesn’t Scale

Manual approach requires:

• Valid SSL certificate for every redirected domain
• Certificate installation on infrastructure
• Renewal process (Let’s Encrypt = every 90 days)
• Monitoring for expiration
• Troubleshooting certificate errors

10 domains = tedious. 100 domains = full-time job. 1,000 domains = impossible without automation.

How DNS-Based Services Solve This

DNS-based redirect services provision certificates automatically:

1. You point domain’s DNS records to the service
2. Service detects configuration via DNS polling
3. Service requests certificate via ACME protocol using Let’s Encrypt or ZeroSSL
4. Service validates domain control via ACME challenge
5. Certificate issued and installed automatically
6. Automatic certificate renewals before expiry with fallback between issuers

Zero manual work. No certificate files to manage. No renewal scripts. No expiration warnings. No certificate installation required.

Works for:

• Apex domains (example.com) via A records
• Subdomains (www.example.com) via CNAME records
• Wildcard certificates (*.example.com) for subdomain coverage (available from Pro and up)

Time to activation: DNS propagation typically completes within minutes to 24 hours, after which certificate provisioning is automatic.

301 vs 302: Decision Framework

HTTP Status Codes Explained

Note on browser caching: Aggressive caching means browsers remember 301s longer (good for performance, but harder to change if you make a mistake). This is why testing with 302 first is sometimes recommended before switching to 301.

Decision Framework: Which Redirect Type?

Use 301 when:

• Old domain will never serve content again
• Rebranding is complete and permanent
• Consolidating domains after merger/acquisition
• Standardizing on www or non-www permanently
• Migrating to new URL structure forever
• You want SEO value transferred to new URL

Use 302 when:

• Testing new domain before full migration
• Running seasonal campaign (e.g., holiday microsite)
• Temporary maintenance or downtime redirect
• A/B testing different landing pages
• Geographic testing before permanent rollout
• Old URL will serve different content later

Key question: Will the old URL ever serve different content?

• No → Use 301
• Maybe → Use 302
• Unsure → Default to 301 for business changes

SEO Impact and Best Practices

According to Google Search Central, both 301 and 302 redirects pass link signals (often called “PageRank”). The key to preserving SEO value is complete URL mapping and avoiding redirect chains, not the status code choice alone.

301 redirect timeline:

• Week 1–2: Search engines discover redirect
• Week 2–4: Link signals begin transferring
• Month 2–3: Most signals transferred
• Month 3–6: Old URLs disappear from index

Keep 301 redirects active for minimum 1 year, as recommended by Google’s John Mueller. Longer is better. Many sites keep them permanently.

Common SEO mistakes:

• Redirect chains (A → B → C instead of A → C)
• Incomplete path mapping (losing deep link value)
• Removing redirects too soon (before search engines fully re-index)

Implementation Guide

Step 1: Configure Your Redirects

Most DNS-based services offer free tiers (typically 5 domains, 250,000 monthly requests).

Basic setup:

1. Create account
2. Add source domain (oldbrand.com)
3. Add destination URL (https://newbrand.com)
4. Choose redirect type (301 or 302)
5. Configure options:
   • Path forwarding ON:oldbrand.com/about → newbrand.com/about
   • Query parameter forwarding ON: Preserves ?utm_source=email parameters
6. Add both apex and www:
   • oldbrand.com → https://newbrand.com
   • www.oldbrand.com → https://newbrand.com

Dashboard displays required DNS records, for example:

• Apex: Type A, Name @, Value 89.106.200.1
• WWW: Type CNAME, Name www, Value edge.redirect.pizza

For detailed DNS setup instructions specific to your provider (GoDaddy, Namecheap, Cloudflare, etc.), consult your service’s provider guides.

Step 2: Update DNS Records

Head to your domain registrar or DNS provider.

Critical: Remove conflicts first

• Delete existing A/AAAA records for apex
• Delete existing CNAME for www
• Disable registrar “Domain Forwarding” (conflicts with DNS-based redirects)

Create new records:

• For apex domain (IPv4):
  • Type: A
  • Name: @ (or leave blank)
  • Value: 89.106.200.1
  • TTL: 3600 (or automatic)
• For apex domain (IPv6):
  • Type: AAAA
  • Name: @ (or leave blank)
  • Value: 2a12:5240::1
  • TTL: 3600 (or automatic)
• For www subdomain:
  • Type: CNAME
  • Name: www
  • Value: edge.redirect.pizza
  • TTL: 3600 (or automatic)

Platform-specific notes:

• Cloudflare: Set Proxy to DNS only (grey cloud). Use the A and AAAA targets for apex and the CNAME target for subdomains exactly as shown in your dashboard.
• GoDaddy: Disable “Forwarding” feature in domain settings.
• Network Solutions: Disable their forwarding service first.

Step 3: Verify DNS Propagation

DNS changes take 5 minutes to 24 hours to propagate globally.

Check propagation:

• Use tools like whatsmydns.net or dnschecker.org
• Green checkmarks = DNS propagated to that region
• Service dashboards poll every few minutes and show status

Manual testing:

# Mac/Linux
dig oldbrand.com

# Windows
nslookup oldbrand.com
  

Look for your service’s IP address in the ANSWER section.

During propagation: Some users reach old servers, others reach the redirect service. This is normal. ISPs cache DNS at different rates.

Step 4: SSL Certificates Provision Automatically

Once the service detects correct DNS configuration:

1. Requests certificate via ACME protocol (Let’s Encrypt or ZeroSSL)
2. Validates domain control via ACME challenge
3. Certificate issued automatically
4. Certificate installed automatically
5. Auto-renewal configured (before expiration)

Monitor in dashboard:

• Status transitions: “Requesting certificate” → “Active”
• Expiration date displayed
• Renewal status visible

Test HTTPS:

• Visit https://oldbrand.com
• Should redirect to https://newbrand.com
• No security warnings
• Click padlock icon → verify valid certificate

Managing Redirects at Scale

Five or ten redirects work through web interfaces. Larger migrations with hundreds or thousands of domains need different approaches. Scaling requires bulk CSV configuration, pattern-based rules using regex/wildcards, and programmatic API access.

Creating a Redirect Map

Before implementing hundreds of redirects, document your strategy:

Spreadsheet columns:

• Source domain
• Destination URL
• Redirect type (301/302)
• Path forwarding (Yes/No)
• Query parameter forwarding (Yes/No)
• Project/department tags
• Notes

Audit all domains:

• Check registrar accounts
• Review DNS providers
• Search corporate documentation
• Check old marketing campaign assets

Organizations often discover forgotten domains still receiving traffic: old campaign sites, acquisition domains, test environments. Dashboard analytics show hit counts per redirect, helping you prioritize which domains matter most and which can be archived.

Bulk Import via CSV

Most services support CSV bulk import, for example:

source,destination,type,path_forward,query_forward,tags
oldbrand.com,https://newbrand.com,301,true,true,rebrand-2025
www.oldbrand.com,https://newbrand.com,301,true,true,rebrand-2025
blog.oldbrand.com,https://newbrand.com/blog,301,true,true,rebrand-2025
shop.oldbrand.com,https://newbrand.com/shop,301,true,true,rebrand-2025
  

Best practice:

• Test with 5–10 redirects first
• Verify functionality
• Import remaining in batches
• Monitor for errors

Pattern-Based Rules with Regex

Wildcard subdomains (available from Pro and up):

*.oldsite.com → https://newsite.com
  

Covers blog.oldsite.com, shop.oldsite.com, help.oldsite.com, etc.

Note: Wildcard redirects require an _acme-challenge NS record for certificate validation.

Regex for complex path transformations:

Old structure: blog.com/2024-01-15-article-title
New structure: blog.com/posts/2024/01/15/article-title

Pattern:     blog.com/(\d{4})-(\d{2})-(\d{2})-(.*)
Destination: blog.com/posts/$1/$2/$3/$4
  

Common regex patterns:

# Old WordPress dates to new structure
/(\d{4})/(\d{2})/(.*) → /blog/$1/$2/$3

# Product IDs to new URL format
/product-(\d+) → /products/$1
  

redirect.pizza vs Alternatives: Comparison

When to Use Each Solution

Choose redirect.pizza when:

• Redirecting 5+ domains with HTTPS
• Need zero infrastructure management
• Want automatic certificate handling
• Need analytics per redirect
• Scaling to hundreds or thousands of domains
• Team lacks DevOps resources for manual setup

Choose Cloudflare Redirect Rules / Bulk Redirects when:

• Already using Cloudflare for DNS
• Need advanced rules (geo-targeting, device type)
• Want DDoS protection bundled
• Comfortable with rule syntax

Choose Registrar Forwarding when:

• Only need HTTP (no HTTPS requirement)
• Redirecting to homepage only
• Single domain, no scale needs
• Free tier acceptable

Choose DIY (Apache/Nginx) when:

• Need complete control over redirect logic
• Have DevOps resources available
• Already managing own infrastructure
• Complex conditional redirects required
• Want to avoid external dependencies

Key Differentiators

redirect.pizza’s advantages:

• Purpose-built for domain-level redirects (not a general CDN)
• Hit count analytics per redirect (available from Basic and up; raw analytics from Business and up)
• Generous free tier (5 domains, 250,000 requests)
• Zero certificate management (fully automated)
• Simple bulk import (CSV, no scripting needed)
• Enterprise features available (WAF, SAML SSO, dedicated IPs, 100% uptime SLA)

Best Practices Checklist

Before Migration

• Audit all current URLs receiving traffic (use analytics)
• Document redirect map in spreadsheet (source → destination)
• Identify high-value pages for custom path mapping
• Check destination URLs are live and accessible
• Notify stakeholders of migration timeline
• Set up monitoring for destination URLs

During Setup

• Use 301 for permanent moves (not 302)
• Enable path forwarding to preserve URL structure
• Enable query parameter forwarding to preserve UTM parameters
• Add both apex and www as separate redirects
• Remove conflicting DNS records before adding new ones
• Test in staging before production (if possible)

After Implementation

• Verify DNS propagation globally (whatsmydns.net)
• Test HTTPS on all redirected domains
• Check redirect speed from multiple locations
• Monitor analytics for traffic patterns
• Watch for 404 errors at destination
• Keep redirects active minimum 1 year (preferably permanently)

Common Mistakes to Avoid

• ❌ Redirect chains: A → B → C (should be A → C)
• ❌ Wrong redirect type: Using 302 for permanent rebrand
• ❌ Missing www variant: Only redirecting apex domain
• ❌ No path forwarding: Losing deep link value
• ❌ Removing redirects too soon: Less than 1 year active
• ❌ No monitoring: Not catching broken destinations
• ❌ Forgetting query parameters: Losing UTM tracking

FAQ: Common Questions Answered

Conclusion: Simple Solution for a Complex Problem

Domain-level redirects preserve traffic and SEO value during website changes. Traditional management requires servers, configuration files, and manual SSL certificates.

DNS-based services eliminate that overhead:

• Point DNS records to the service
• Certificates provision automatically
• Redirects work globally at edge locations
• Analytics show traffic patterns
• Zero ongoing maintenance

Key decisions:

• Use 301 for permanent moves (passes link signals)
• Use 302 only for temporary changes
• Enable path forwarding to preserve deep links
• Keep redirects active minimum 1 year

Scale requires planning:

• Document strategy before implementation
• Use pattern-based rules to avoid manual configuration
• Integrate via API for automation
• Monitor analytics to catch issues

Whether managing 5 domains or thousands, the pattern is the same: DNS-based automation instead of infrastructure, correct redirect types, continuous monitoring.

Ready to Simplify Domain Redirect Management?

redirect.pizza’s Free Tier Includes:

• 5 source hostnames
• 250,000 requests/month
• Automatic SSL certificates
• Path & query parameter forwarding
• Limited support
• No credit card required

Start free in minutes →

Need enterprise features?

• Unlimited domains
• SAML SSO (Business)
• WAF - Web Application Firewall (Business)
• Dedicated IPs (Enterprise)
• 100% uptime SLA (Enterprise)
• Invoice billing
• Priority support

Learn more →