You connected a domain to Blogger, but the browser now shows “too many redirects”, switches repeatedly between two addresses, or never reaches the article. This is a redirect-loop problem—not necessarily a failed domain purchase or a reason to reinstall your theme.
To fix a Blogger custom domain redirect loop, first identify exactly which address is redirecting to which other address. Then inspect Blogger's own settings and any forwarding rules at the domain provider. Avoid changing several DNS records at once; that makes the source of the loop harder to find.
How a redirect loop happens
A redirect tells the browser to visit a different URL. A loop occurs when the destination sends the browser back to an earlier URL in a chain. For example, one service may forward example.com to www.example.com, while another service forwards www.example.com back to the root domain.
HTTPS rules can also conflict. A domain provider, proxy, or CDN may insist on one protocol while Blogger expects another. The result can be a repeated chain that ends in a browser error.
Step 1: Record the exact URLs that fail
Test these addresses separately, using your actual domain:
https://www.example.comhttp://www.example.comhttps://example.comhttp://example.com
If the blog is intentionally hosted at blog.example.com rather than www, adjust the tests accordingly. Note which URL works, which loops, and whether a specific post behaves differently from the homepage.
Don't clear your entire browser history as the first “fix.” A private window is useful to rule out an extension or cached redirect, but persistent loops usually require inspecting site configuration.
Step 2: Check the domain Blogger thinks is primary
Open Blogger → Settings → Publishing. Confirm that the custom domain matches the subdomain you intend to serve. Inspect Redirect domain if you use a root-domain redirect.
Google's official custom-domain guide explains the relationship between the Blogger subdomain and the optional root redirect. Make a note of the current settings before changing them.
If your domain is already saved correctly, do not remove the custom domain just to test a theory. Start with conflicting external rules.
Step 3: Look for competing forwarding rules
Visit the domain registrar's DNS and forwarding dashboard. Search for URL forwarding that sends www to the root domain, or the root domain to a different hostname. A second redirect applied by a CDN can conflict with the forwarding rule.
Temporarily changing a live site's forwarding can affect readers and search visibility. Take a screenshot or export the existing settings first, identify the exact conflict, and change only one rule at a time. If the domain hosts other services, coordinate before altering its root A records.
Step 4: Confirm the CNAME points to Blogger
For a normal www Blogger connection, the documented blog CNAME points to ghs.google.com. A separate security CNAME verifies your blog and account. The custom-domain setup article covers those records in detail; here the goal is only to confirm they have not been overwritten or proxied unexpectedly.
If your provider has a proxy feature, compare the current behavior with its documented DNS-only mode. Do not assume an orange-cloud or “accelerated” setting is compatible with Blogger's certificate and redirect flow.
Step 5: Check HTTPS without creating a second loop
Inspect Blogger → Settings → HTTPS for the availability and HTTPS redirect settings. If the domain provider also forces HTTPS, verify that these rules agree rather than opposing each other.
Google's Blogger HTTPS help explains certificate and redirect behavior. If Blogger is still provisioning HTTPS, allow time for that process before trying multiple unrelated fixes.
Step 6: Test the final destination of a redirect
When testing, look for a short, one-way path to the intended secure address. Ideally, readers requesting the root domain end up at the chosen https://www or https://blog address and stay there.
A browser's developer tools or a reputable HTTP redirect checker can show each hop. Avoid entering private credentials into third-party tools. If the chain bounces between the same two addresses, you've located the conflict that needs attention.
Step 7: Read the redirect chain, not just the browser error
The message ERR_TOO_MANY_REDIRECTS tells you the browser stopped following redirects; it does not identify which setting created them. The useful evidence is the sequence of responses. On a desktop browser, open Developer Tools, select the Network tab, enable Preserve log where available, then reload the failing URL. Look for the first navigation request and each HTTP redirect response.
For each redirect, record the status (commonly 301, 302, 307, or 308) and the destination in the Location response header. A simplified example is http://example.com → https://www.example.com → http://example.com. That second jump back to the start points to conflicting hostname or HTTPS rules. If you are not comfortable using Developer Tools, ask your hosting or domain provider to check the redirect chain; you do not need to change the theme to collect this evidence.
A successful final response usually serves the intended page instead of redirecting again. Test one actual post address as well as the homepage. A working homepage does not prove every permalink is reachable, especially after a recent domain change.
Step 8: Separate DNS problems from HTTPS certificate problems
DNS tells the browser where to connect; an HTTP redirect tells it which URL to request next. A CNAME pointing to the wrong destination can cause a domain to fail, but it is not by itself proof of a redirect loop. Confirm that the Blogger host CNAME uses the subdomain shown in your setup and points to ghs.google.com, and that the unique security CNAME has not been removed. For root-domain redirection, follow Blogger's own four-A-record instructions rather than copying values from an unrelated hosting guide.
If HTTPS is unavailable or the browser displays a certificate warning, check certificate provisioning separately. Google's custom-domain instructions note that domains using CAA DNS records must authorize letsencrypt.org for Blogger to create or renew the certificate. A certificate error and a repeated 301/302 loop are different symptoms; treat them differently.
Allow DNS changes time to become visible. Google advises waiting at least an hour after updating the CNAME records before repeating setup, and notes that redirection from the Blogspot address to a newly connected domain can take up to 24 hours. Those are processing expectations, not a reason to keep changing otherwise-correct records every few minutes.
Step 9: Check proxies and forwarding without breaking other services
If the domain uses a CDN, reverse proxy, or registrar forwarding service, inspect its active redirect rules and HTTPS behavior. A proxy may enforce a different protocol or hostname than Blogger does. In that situation, use the provider's documented configuration and check which layer actually sends the response. Do not switch SSL modes or disable proxying blindly, especially when the domain also runs email or other subdomains.
Write down every original record and rule before making a change, including TTL values. Change one identified conflict at a time and retest. If your custom address is blog.example.com, do not automatically apply instructions intended for a www blog or its root domain: the hostname and the intended redirect destination must match your setup.
If you are still deciding which blogging arrangement fits your needs, our guide to hosted blogging platforms explains the broader trade-offs. For an already connected Blogger domain, though, focus this diagnosis on the current redirect configuration rather than starting a platform migration.
Step 10: Recheck Search Console only after the live URL works
Google Search Console may keep an older Redirect error in its reports even after you have corrected the live behavior. First confirm that the intended HTTPS URL opens publicly, reaches the correct post, and does not bounce between hostnames. Then inspect that exact final URL with URL Inspection and use the live test where appropriate. The historical indexing report and the live test answer different questions.
Google's redirect guidance recommends direct, understandable redirects to the preferred URL and cautions against unnecessary chains. A live test that succeeds is useful evidence of current accessibility; it does not promise immediate indexing, ranking, or a cleared historical report. Allow Google to recrawl the corrected URL, and use validation when the relevant Search Console workflow offers it.
What not to do while troubleshooting
- Do not delete the Blogger custom domain, change the theme, and replace DNS records all at once.
- Do not add a second root-to-www or HTTPS redirect if Blogger or your provider already performs the intended redirect.
- Do not assume a
?m=1mobile parameter is the source of a root-domain redirect loop without checking the actual response chain. - Do not treat a DNS propagation delay, SSL certificate error, and HTTP redirect loop as the same problem.
- Do not redirect unrelated or missing articles to the homepage merely to hide a separate 404 problem.
Do not confuse redirect loops with other errors
- DNS error: The hostname does not resolve or points to the wrong service.
- Certificate warning: HTTPS is unavailable or incorrectly configured.
- 404: The browser reaches a site, but a specific path does not exist.
- Redirect loop: The browser receives repeated location changes and never reaches stable content.
Each problem has a different fix. Avoid redirecting every broken post to the homepage simply because a custom domain was recently connected.
Frequently asked questions
Does a redirect loop mean Blogger deleted my posts?
No. A redirect loop concerns how the browser reaches URLs. Your content may still be present in the Blogger dashboard.
Should I turn off HTTPS to fix the loop?
Not automatically. Identify which rule causes the conflict. Disabling security without diagnosing the redirect can create a different problem.
Why does www work but the root domain fail?
The root redirect may be missing or conflicting with external forwarding. Check the root-domain configuration separately from the www CNAME.
How long should DNS changes take?
Propagation varies by provider and cached records. Some changes appear quickly; others can take longer. Recheck the official setup instructions before repeatedly changing correct values.
Safe troubleshooting order
Write down the failing URLs, inspect Blogger's Publishing and HTTPS settings, locate any external forwarding, verify the blog CNAME, and change only the proven conflict. Test the homepage and several real post URLs after each targeted fix.