5 Common Redirect Problems You Can Fix in 10 Minutes

You configured the redirect. DNS is updated. But when you visit the old domain, something's wrong. Maybe the browser shows a security warning. Maybe it spins forever. Maybe it works for you but not for your colleague sitting three desks away.

Before you start debugging server configs or opening a support ticket, check these five common problems. They account for most redirect failures, and each one takes less than 10 minutes to fix. For redirect fundamentals and setup guidance, see our Complete Guide to URL Redirects.

Key Takeaways

• SSL certificate errors: wait 10-15 minutes after DNS change for automatic provisioning, then test in incognito
• DNS propagation: use whatsmydns.net to check global status - full propagation takes up to 48 hours
• Redirect loops: check browser Network tab for repeating URLs in the redirect chain
• Wrong status code: verify 301 (permanent) vs 302 (temporary) - wrong choice breaks SEO transfer
• Missing path/query: enable path forwarding in your redirect service to preserve deep links and UTM parameters

Problem 1: SSL Certificate Not Yet Provisioned

Your browser shows "Your connection is not private" or ERR_CERT_COMMON_NAME_INVALID. You click Advanced and see something about certificates. The redirect seems broken, but actually, it hasn't even had a chance to run yet.

Here's what's happening: when you visit an HTTPS URL, the browser validates the SSL certificate before it processes anything else. This validation happens during the TLS handshake, which occurs before the server can send redirect instructions. If the certificate doesn't exist or doesn't match the domain you requested, the browser stops with a security warning. Your redirect configuration might be perfect. It just never executes.

Certificate provisioning through Let's Encrypt requires the domain to resolve to the redirect service first. This creates a timing issue: you update DNS, traffic starts arriving, and only then can the service request and install a certificate. The first visitors during this window see certificate errors.

How to diagnose

Visit your old domain over HTTPS and check the specific error message. "NET::ERR_CERT_COMMON_NAME_INVALID" means a certificate exists but it's for a different domain. "NET::ERR_CERT_AUTHORITY_INVALID" means the certificate isn't trusted. For a detailed analysis, use SSL Labs Server Test and look for certificate name mismatches or missing certificates.

How to fix

The fix is usually just patience. After updating DNS, wait 5 to 10 minutes for automatic certificate provisioning to complete, then clear your browser cache or test in an incognito window. If the error persists after 15 minutes, double-check that your DNS records actually point to the redirect service and not your old server.

Once working, visiting the HTTPS URL should redirect you to your destination with a padlock icon in the address bar and no certificate warnings. For the technical details on why HTTPS redirects require proper certificate setup, see How to Redirect with HTTPS.

Problem 2: DNS Not Yet Propagated

The redirect works when you test it, but your colleague sees the old site. Or a customer in another country reports an error while everything looks fine from your desk.

DNS changes don't take effect instantly. When you update DNS records, the change must propagate through DNS resolvers worldwide. Each resolver caches DNS records according to the TTL (Time To Live) value. Until the cached record expires, users hitting that resolver continue reaching the old destination.

Propagation typically takes 2 to 6 hours for most users, though complete global propagation can take up to 48 hours. Some ISPs ignore published TTL values and cache records longer according to their own policies, which is outside your control.

Checking propagation status

Use whatsmydns.net. Enter your domain name, select "A" record type, and click search. The tool queries DNS resolvers in different locations and shows the IP address each one returns. Compare these results to your redirect service's IP address. Locations showing the correct IP have propagated. Locations showing a different IP are still serving cached old records.

How to fix

There's no way to force global DNS propagation. You can verify your DNS records are correctly configured at your registrar, clear your browser cache and test in an incognito window, and then wait. If you're planning a migration, reduce your DNS TTL to 300 seconds at least 24 to 48 hours before making changes. This ensures that once you update the records, propagation happens faster because resolvers aren't holding onto long-lived cached entries.

Once most locations on whatsmydns.net show the correct IP address, the redirect should work for the majority of users. For understanding the difference between DNS-level and server-side approaches, see DNS-Level vs Server-Side Redirects.

Problem 3: Redirect Loop

Your browser shows ERR_TOO_MANY_REDIRECTS or "This page isn't redirecting properly". The page never loads. It just spins.

A redirect loop occurs when URL A redirects to URL B, and URL B redirects back to URL A. The browser follows redirects until it hits a limit (typically 20 hops) and then gives up with an error.

Common causes: an HTTP to HTTPS redirect that conflicts with another rule and bounces back to HTTP. A www to non-www redirect that conflicts with a non-www to www redirect. Two different services (your DNS provider and your redirect service) both trying to redirect the same domain. Or the classic mistake: olddomain.com redirects to newdomain.com, but a forgotten rule on newdomain.com redirects certain traffic back to olddomain.com.

Finding the loop

Open your browser's developer tools (press F12, or right-click and select Inspect) and go to the Network tab. Visit your old domain and watch the redirect chain unfold. Each redirect appears as a separate request. Look for repeating patterns: if you see the same URL appear twice in the chain, you've found your loop. Alternatively, use an online redirect checker like redirect-checker.org or httpstatus.io to visualize the complete chain.

How to fix

Once you've identified where the loop happens, remove or modify the conflicting rule. For HTTP/HTTPS loops, ensure only one system handles the protocol upgrade. For www/non-www conflicts, pick one canonical version and make sure all rules point to that single destination. If multiple services are fighting over the domain, disable the redirect in one of them.

After fixing, use the same tools to verify the chain now ends at your final destination without looping back.

Problem 4: Wrong Redirect Status Code

The redirect works perfectly for users. They type the old domain, land on the new one, no errors. But weeks later, you notice the old URLs still appear in Google search results. Or your SEO team reports that ranking signals aren't transferring to the new domain.

The culprit is usually a 302 (temporary) redirect where you needed a 301 (permanent).

A 301 tells browsers and search engines: "This page has permanently moved. Update your records." Search engines transfer ranking signals to the new URL and eventually remove the old URL from their index.

A 302 tells browsers and search engines: "This page has temporarily moved. Keep the old URL in your records." Search engines may continue showing the old URL in search results because they expect it to come back.

Using 302 for a permanent move (like a domain rebrand) means search engines hesitate to transfer SEO value. They're waiting for you to bring the old domain back, which you never intend to do.

How to diagnose

Open your browser's developer tools (F12) and go to the Network tab. Visit your old domain and click on the first request to see its details. Look for the status code: 301 Moved Permanently is what you want for domain migrations, rebrands, and consolidations. 302 Found means temporary. You can also use httpstatus.io or redirect-checker.org to check without developer tools.

How to fix

The fix takes two minutes: log into your redirect service, change the redirect type from 302 to 301, and save. The change takes effect immediately for new requests. Search engines will recognize the permanent status during their next crawl.

For guidance on when to use each type, see 301 vs 302: Which Should You Use?

Problem 5: Path and Query Parameters Not Forwarded

You visit olddomain.com/products/widget and expect to land on newdomain.com/products/widget. Instead, you land on just newdomain.com. Or you click a campaign link with UTM parameters and arrive at the destination with all tracking information stripped away.

This happens when the redirect is configured to send all traffic to a single destination URL without preserving the original path or query string. It's a common default setting that works fine for simple domain-to-domain redirects but breaks deep linking.

For sites with product pages, blog posts, or marketing campaigns using UTM parameters, losing the path means users land on the homepage instead of the specific content they requested. Losing query parameters breaks analytics tracking and campaign attribution. Your marketing team won't know which emails drove traffic because the utm_source parameter vanished during the redirect.

How to diagnose

Visit a URL that includes both a path and query parameters, something like olddomain.com/some/path?utm_source=test. Check where you land. If you end up on newdomain.com without the path, path forwarding is disabled. If you end up on newdomain.com/some/path but the query string is gone from the address bar, query forwarding is disabled.

How to fix

Log into your redirect service dashboard and enable path forwarding (sometimes called "path preservation" or "URI forwarding"). Query string forwarding may be a separate setting. Save the configuration and test again. Most redirect services offer these as simple toggle options.

After enabling, verify by visiting olddomain.com/test/path?param=value and confirming you land on newdomain.com/test/path?param=value with everything intact.

Frequently Asked Questions

Related Guides

• 301 vs 302 Redirect Guide - When to use permanent vs temporary redirects
• How to Redirect with HTTPS - SSL certificate handling for secure redirects
• DNS-Level vs Server-Side Redirects - Choosing the right approach for your infrastructure
• Redirect Analytics - What to monitor after migration goes live

Ready to Redirect?

redirect.pizza provides DNS-level redirects with automatic SSL certificate provisioning, built-in diagnostics, and path forwarding. Free tier supports up to 5 domains with 250,000 hits per month. Get started for free or view enterprise features.