Should I redirect HTTP to HTTPS at the server or CDN level?

HTTP to HTTPS Redirects: Server vs CDN Implementation

If your site already sits behind a CDN, do the HTTP-to-HTTPS redirect at the CDN edge; if it does not, do it at the web server — either way, use a 301 and pair it with an HSTS header. The SEO result is identical (a 301 passes link equity and marks HTTPS as canonical no matter where it fires). The real trade-off is latency and resilience: a CDN answers the redirect from an edge server near the visitor and keeps working when the origin is down, while a server-level redirect is simpler and dependency-free but forces a full round-trip to your origin. Neither is universally "better" — the right answer follows your existing infrastructure.

That's the summary an AI Overview would give you. Here's what it can't show you: the actual request path each approach takes (and where the milliseconds go), a side-by-side decision table you can match to your own setup, and the specific misconfiguration — Cloudflare "Flexible" SSL — that turns a correct-looking redirect into an infinite loop. Those are below.

Server-level redirect Visitor Tokyo Edge (Tokyo) passes through Origin (US) 301 fires here ~180 ms round trip to answer the redirect

CDN-level redirect Visitor Tokyo Edge (Tokyo) 301 fires here Origin (US) never touched ~10 ms — answered at the edge

The migration from unencrypted HTTP to secure HTTPS is one of the most important modernizations for any website. Google explicitly uses HTTPS as a ranking signal, browsers display security warnings for HTTP sites, and user trust increases dramatically with HTTPS. But the implementation of the redirect — server versus CDN — affects page load times, crawl efficiency, failover behavior, and certificate management. This guide covers each trade-off, then gives you a decision table to match against your own stack.

Understanding the Two Approaches

Server-Level Redirects

Server-level redirects are implemented in your web server configuration:

Apache (.htaccess):

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Nginx:

server {
    listen 80;
    server_name example.com;
    return 301 https://example.com$request_uri;
}

How It Works:

1. User requests HTTP URL
2. Request reaches your origin server
3. Server processes the redirect rule
4. Server responds with 301 redirect to HTTPS URL
5. User's browser follows redirect to HTTPS
6. Secure connection established

CDN-Level Redirects

CDN-level redirects are implemented at the edge of the content delivery network:

Cloudflare Page Rules:

Forward URL 301: http://example.com* → https://example.com$1

AWS CloudFront: Configure CloudFront distribution to redirect HTTP to HTTPS

How It Works:

1. User requests HTTP URL
2. Request reaches CDN edge server (geographically close)
3. CDN edge server processes redirect rule
4. Edge server responds with 301 redirect to HTTPS
5. User's browser follows redirect to HTTPS
6. Second request goes to CDN edge over HTTPS
7. CDN edge fetches from origin over HTTPS
8. Content served over secure connection

Performance Implications

Response Time Comparison

Server-Level Redirect:

• Request travels from user → CDN (if used) → Origin Server
• Redirect processed at origin (potentially far away)
• Response time: 100-500ms depending on distance and server response time
• One extra network round-trip

CDN-Level Redirect:

• Request reaches nearest CDN edge location
• Redirect processed at edge (geographically close to user)
• Response time: 20-100ms (much faster)
• Still one extra network round-trip, but from nearby server

Measured Impact:

Server-level: User in Tokyo requesting example.com hosted in US
- HTTP request to CDN edge in Tokyo: 10ms
- CDN forwards to origin in US: 150ms
- Origin processes redirect: 20ms
- Total: ~180ms response time

CDN-level: Same user and location
- HTTP request to CDN edge in Tokyo: 10ms
- Edge processes redirect immediately: 0ms
- Total: ~10ms response time

The CDN-level approach is 18x faster in this scenario.

Scale of Impact

The significance of this performance difference varies by audience:

Global Audience: CDN-level redirects provide massive benefits. Reducing 150-200ms from each redirect request impacts global user experience significantly.

Local Audience: If all users are close to your origin server, the difference is minimal (both approaches similar).

Mobile Users: Mobile networks have higher latency, making CDN-level faster more valuable for mobile users.

Page Load Time: The redirect adds to overall page load time. With HTTP/2 multiplexing, the impact is somewhat reduced but still significant.

Cascading Effect

When you have many HTTP requests (and not just the initial HTML document), the difference compounds:

Scenario: Website making 5 HTTP requests (images, CSS, etc.)
Server-level redirect: 5 × 180ms = 900ms added
CDN-level redirect: 5 × 10ms = 50ms added
Difference: 850ms slower with server-level

Not all requests will be HTTP (some may be HTTPS from the start), but any HTTP requests experience the delay.

SEO Implications

Crawl Efficiency

Both approaches have similar SEO implications, but with subtle differences:

Server-Level:

• Googlebot follows redirect to origin server
• Wastes crawl budget slightly (extra request to origin)
• Still processes 301 correctly
• Search engines update index appropriately

CDN-Level:

• Googlebot's request is processed at CDN edge
• Same crawl budget consumption
• Still processes 301 correctly
• No practical difference in SEO

Ranking Impact

No difference in ranking impact between the two approaches:

• Both use 301 redirects (permanent)
• Both pass ~90-99% link authority
• Both properly signal HTTPS as canonical
• No SEO reason to prefer one over the other

Search Console Signals

Both approaches properly:

• Redirect HTTP to HTTPS
• Signal HTTPS preference
• Update search console crawl records
• Maintain ranking authority

Security Implications

HSTS (HTTP Strict Transport Security)

Server-Level Implementation:

HTTP request → Server → HTTPS redirect
First request is always unencrypted (vulnerable to downgrade attack)

CDN-Level Implementation:

HTTP request → CDN edge (can enforce HSTS policies)
Similar vulnerability exists

Both approaches have the same vulnerability: the initial request is unencrypted.

HSTS Header Solution:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

When served over HTTPS, this header tells browsers to always use HTTPS for future requests, preventing downgrade attacks. Works with both server-level and CDN-level redirects.

Certificate Management

Server-Level:

• Your origin server needs valid HTTPS certificate
• Must manage certificate renewal and updates
• Certificate must match domain name

CDN-Level:

• CDN typically provides certificates (LetsEncrypt or shared certs)
• CDN handles certificate renewal automatically
• Origin server may not need public certificate (can use self-signed for origin-to-CDN communication)

CDN-level approach simplifies certificate management.

Mixed Content Warnings

Server-Level with CDN:

• Complex setup: CDN forwards HTTP requests to origin
• Origin must handle redirect
• Potential for mixed content warnings if not configured carefully

CDN-Level Only:

• Simpler: All requests go through CDN
• Less chance of mixed content issues
• Cleaner security configuration

Infrastructure Considerations

Existing CDN Usage

If You Already Use CDN:

• Implement redirects at CDN level (leverage existing infrastructure)
• Simpler configuration (one place to manage rules)
• Better performance (already paying for CDN, leverage it)

If You Don't Use CDN:

• Server-level redirects simpler (no new service dependency)
• No additional cost
• Adequate performance for most audiences

Origin Server Simplicity

Server-Level Advantages:

• Everything handled at origin
• No external dependencies
• Self-contained configuration
• Works the same everywhere (no CDN-specific syntax)

CDN-Level Advantages:

• Origin server configuration unchanged
• Easier to switch between CDN providers
• Cleaner separation of concerns

Failover and Reliability

Server-Level:

• If origin server fails, HTTP redirects also fail
• Users can't even reach HTTPS error page
• Less resilient

CDN-Level:

• CDN can serve redirects even if origin is down
• Better availability
• More resilient architecture

Server vs CDN: The Decision Table

Factor	Server-level (Nginx/Apache)	CDN-level (Cloudflare/CloudFront/etc.)
Redirect latency (distant users)	100–300 ms (full trip to origin)	10–50 ms (answered at nearest edge)
Redirect latency (local users)	Negligible difference	Negligible difference
SEO / link equity (301)	Identical	Identical
Works when origin is down	No — origin serves the redirect	Yes — edge answers independently
Certificate management	You manage origin cert + renewal	CDN provisions & renews public cert
Where the rule lives	Origin config, versioned with app	CDN dashboard / API, separate surface
External dependency	None	Requires the CDN service
Loop risk	Low	Higher if SSL mode is "Flexible"
Best when...	You have no CDN and want zero new dependencies	You already run a CDN and serve a global audience

The one-line rule: already on a CDN → redirect at the edge; no CDN → redirect at the server; in both cases add HSTS. Don't add a CDN solely to move the redirect — the latency win only matters for a geographically spread audience.

Watch Out: The "Flexible SSL" Redirect Loop

The most common way a correct-looking redirect breaks is a mismatch between the browser-to-CDN hop and the CDN-to-origin hop. If Cloudflare's SSL mode is Flexible, the edge fetches your origin over plain HTTP — and if your origin also has an HTTP-to-HTTPS redirect rule, it 301s the edge back to HTTPS, forever.

Practical Implementation Recommendations

For Most Websites: CDN-Level

If you use a CDN (Cloudflare, Akamai, AWS CloudFront, etc.), implement redirects at the CDN level:

Advantages:

• Better performance for global users
• Simpler origin server configuration
• Better availability/failover
• All redirects in one place
• CDN handles certificate management

Implementation Example (Cloudflare):

Always Use HTTPS setting: Enable
This automatically redirects all HTTP to HTTPS at edge

For Sites Without CDN: Server-Level

If you don't use a CDN and want to avoid adding one:

Advantages:

• No external dependencies
• Simple, straightforward configuration
• Works immediately without CDN setup

Implementation Example (Apache):

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

For Maximum Performance: Both Levels

Some organizations implement redirects at both levels:

CDN Level: Quick redirect to HTTPS

HTTP → HTTPS at CDN edge

Server Level: Backup redirect

If request somehow reaches origin over HTTP, redirect to HTTPS

Benefit: Handles edge cases and provides defense in depth

Drawback: Adds complexity with minimal additional benefit

Mixed Scenarios and Best Practices

Scenario: Using CDN for Static Content Only

Setup:

• CDN caches images, CSS, JavaScript
• Dynamic content served from origin over HTTPS
• HTTP requests exist for origin content

Best Practice:

• Implement server-level redirect at origin
• Configure CDN to serve cached content over HTTPS
• Ensure all CDN requests originate from origin over HTTPS

Scenario: Multiple Origins with CDN

Setup:

• CDN configured to route traffic to multiple origins
• Different origins for different content

Best Practice:

• Implement CDN-level redirects (cleaner, single configuration)
• Ensure all origins support HTTPS
• Don't rely on individual origin redirects

Scenario: Third-Party Services and Embeds

Consideration: If your site uses HTTP-based third-party embeds, browsers may show mixed content warnings even with HTTPS redirects

Solution:

• Update all third-party services to HTTPS
• Use protocol-relative URLs (//example.com instead of http://example.com)
• Update redirects don't solve this; must update actual embed URLs

Monitoring and Validation

Verify Redirects Working

Test from Multiple Locations:

# Test HTTP redirect
curl -I http://example.com

# Should show:
# HTTP/1.1 301 Moved Permanently
# Location: https://example.com

# Test HTTPS works
curl -I https://example.com
# Should show: HTTP/1.1 200 OK

Browser Testing:

• Visit HTTP version in browser
• Verify automatic redirect to HTTPS
• Check address bar shows HTTPS with padlock
• No security warnings

Check for hidden multi-hop chains — a redirect that "works" can still be slow if it takes several hops (HTTP → HTTPS-www → HTTPS-non-www). Each extra hop adds a round trip and wastes crawl budget. Paste your URL below to see the full chain:

Monitor Performance

Server-Level Only:

• Use tools like Google PageSpeed Insights
• Monitor Core Web Vitals
• Track redirect response times in server logs

CDN-Level:

• Check CDN analytics for redirect performance
• Monitor response times from different geographic locations
• Verify edge servers properly redirecting

Migration Checklist

When migrating from HTTP to HTTPS:

1. Obtain HTTPS Certificate: Purchase or use free certificate (LetsEncrypt)
2. Configure Server/CDN: Set up HTTPS support on destination
3. Implement Redirects: Choose server-level or CDN-level
4. Add HSTS Header: Force HTTPS for future requests
5. Update Internal Links: Change all internal links to HTTPS (prevents redirect)
6. Update External References: Gradually get external sites to update links
7. Update Sitemaps: Change sitemap URLs to HTTPS
8. Verify Search Console: Monitor migration in Google Search Console
9. Test Thoroughly: Verify from multiple browsers and locations
10. Monitor for Issues: Watch error logs for problems

Conclusion

Both server-level and CDN-level HTTP-to-HTTPS redirects properly accomplish the goal of forcing secure connections. However, CDN-level redirects provide significantly better performance for global audiences by processing redirects at geographically close edge servers. For websites already using CDNs, implementing redirects at the CDN level is the clear choice—you leverage existing infrastructure for better performance with minimal additional complexity.

For sites without CDN infrastructure, server-level redirects provide adequate functionality without introducing external dependencies. The performance difference is negligible for audiences concentrated near your origin server. Regardless of which approach you choose, combine it with an HSTS header to provide defense-in-depth security and prevent downgrade attacks. The goal—ensuring all traffic uses HTTPS—is easily achieved with either approach; the choice primarily affects performance and infrastructure simplicity.