Open main menu
PricingShowcaseBlogHelp DocsChangelog
Start your free trial

Redirected You Too Many Times? A Step-by-Step Fix

Seeing the 'redirected you too many times' error? Learn how to diagnose and fix it with our step-by-step guide for non-technical teams and Feather users.

Table of Contents
Redirected You Too Many Times? A Step-by-Step Fix
Related Posts
blog_related_media
blog_topic
blog_related_activities
blog_niche
blog_related_tips
unique_blog_element
You publish a post, refresh the page, and your browser throws back a blunt message: “This page isn’t working. [your domain] redirected you too many times.”
For a content manager, that error feels unfair. You didn’t edit server rules. You didn’t touch SSL settings. You just wanted to review the page you published.
Still, this problem matters immediately. When a browser says redirected you too many times, it usually means your site is sending visitors in a circle instead of serving a page. Sometimes that circle is caused by stale cookies. Sometimes it’s a bad rule on the server. Sometimes it starts during a CMS migration when two systems both think they control the same domain.
The good news is that you can narrow it down quickly without being a developer. The best approach is to stop guessing and work through the issue in layers: browser, CMS, server rules, CDN, then SEO recovery.

What the Redirect Loop Error Really Means for Your Site

A redirect loop happens when your site keeps issuing instructions to go somewhere else, but those instructions never end in a real page load.
A simple version looks like this:
  • Page A redirects to Page B
  • Page B redirects back to Page A
  • The browser gives up
A more subtle version is even more common. Your site may try to force http to https, while another setting tries to force https back to http. Or one rule pushes visitors to the www version while another pushes them to the non-www version.
To a visitor, it looks like the site is broken. To Google, it can look the same.
Browsers enforce strict redirect limits, and Chrome typically stops after around 10 to 20 redirects before showing ERR_TOO_MANY_REDIRECTS. Google’s crawlers mirror this behavior and generally won’t index pages that require more than 10 hops, which can lead to de-indexation and lost organic traffic, according to OnDigital’s explanation of redirected too many times.

Why this is more than a temporary glitch

When this error appears on a live page, your content is effectively offline for anyone trying to load it through a browser.
That creates three practical problems:
  1. Visitors can’t access the pageIf someone clicks from search, email, social, or an ad, they hit an error instead of your content.
  1. Search engines can’t crawl cleanlyCrawlers don’t keep following broken instructions forever. If they can’t reach a stable destination, the page may stop appearing in search.
  1. Your redirects stop helping SEO and start hurting itRedirects are useful when they’re intentional and clean. They become destructive when they create loops or long chains.

The plain-English test

If someone on your team asks what’s happening, use this sentence:
That framing helps because it shifts the conversation away from blame. You don’t need to know the final technical cause before taking useful action. You just need to confirm whether the problem is local to your browser or baked into the site’s setup.

Your First Fixes Start in the Browser

Before you message a developer, start with the fastest checks. They often tell you whether the loop is on your device or on the website itself.
notion image

Start with an incognito window

Open the affected page in:
  • Chrome Incognito
  • Safari Private Browsing
  • Firefox Private Window
  • Edge InPrivate
It is significant that private browsing runs without most stored cookies and often without the same extension behavior.
If the page loads in private mode but not in your normal browser, the issue is often local. You’re probably dealing with cached redirect instructions, a stale cookie, or an extension conflict.
If it fails in both places, that points more strongly to a site-side problem.

Clear cookies for that site only

Don’t wipe your entire browser unless you have to. Remove site-specific cookies first.
That’s the common fix because cookies can preserve old login states, protocol preferences, or session data that no longer match the site’s current setup. This is especially common after:
  • a domain change
  • an SSL install
  • a CMS migration
  • changes to login or membership tools
  • switching between staging and live environments
Use your browser’s settings to search for the domain and delete stored cookies for that site.
Then reload the page.

Empty the cached version of the site

Your browser may also be holding onto an old redirect path.
A hard refresh can help, but if the loop persists, clear the cached files for that domain. This is different from cookies. Cache stores files and previous loading behavior, while cookies store session and preference data.
A quick decision guide helps here:
What happened after testing?
What it likely means
What to do next
Loads in private window only
Browser data issue
Clear site cookies and cache
Fails in all browsers on your device
Possible site issue
Test on another device or network
Works on your phone but not laptop
Local browser or extension problem
Disable extensions and retest
Fails everywhere
Server, CMS, or CDN issue
Escalate to site-side checks

Disable extensions one by one

Privacy tools, ad blockers, script blockers, and SSO helpers can interfere with redirects.
This matters most when the affected page includes:
  • Login flows through Google, Microsoft, or another SSO provider
  • Cookie consent tools that redirect before showing content
  • Security extensions that rewrite tracking or referral behavior
  • VPN or proxy browser tools that alter requests
Turn extensions off temporarily, then reload the page.
Don’t disable everything and move on too fast. Retest after each major extension type so you can identify the offender. If one extension breaks the page, that doesn’t necessarily mean your site is healthy, but it does tell you the browser isn’t the only variable.

Try a second device and a second network

This is the simplest way to answer a big question: Is it me or the site?
Test the page on:
  • your phone on mobile data
  • another laptop
  • a coworker’s machine
  • a different browser profile
If everyone sees redirected you too many times, stop spending energy on local cleanup. The problem is probably upstream.

What to report if you need help

When you escalate, send a short note with specifics:
  • the exact URL that fails
  • whether the homepage fails too
  • whether private mode changed anything
  • whether another device reproduced the issue
  • whether this started after a domain, SSL, plugin, or CMS change
That summary saves time. Instead of “the website is broken,” you’re handing over a useful diagnostic record.

When browser fixes are enough

Browser-side fixes usually solve the issue when the loop is tied to old session data, login cookies, or local cache. They do not reliably solve problems caused by bad redirect rules, conflicting domain settings, or proxy/CDN misconfiguration.
If you’ve tested private mode, cleared site cookies, cleared cache, disabled extensions, and tried another device, you’ve done the right first-pass triage. At that point, the next step is to inspect the rules that control where the site sends people.

Finding the Loop in Your Server and Redirect Rules

When browser testing doesn’t fix the issue, the redirect loop usually lives in the site’s actual routing logic.
Imagine a postal worker with conflicting instructions. One label says “forward all mail to the new office.” Another says “send everything back to the original branch.” The package never reaches the recipient.
notion image

The most common server-side causes

The majority of loops I see fall into a few predictable buckets.

HTTP and HTTPS rules fighting each other

This is still one of the biggest causes of the error.
During Google’s HTTPS push starting in 2014, redirect errors spiked by over 300% as sites rushed migrations without proper server configuration. By 2018, nearly 50% of the top 1 million sites reported redirect loop issues caused by mixed HTTP/HTTPS content, according to Search Engine Land’s guide to too many redirects.
In practice, that often means:
  • the server forces HTTPS
  • the application thinks the request is still HTTP
  • the request gets redirected again
  • the cycle repeats

www and non-www conflicts

If one rule says example.com should become www.example.com, but another tool or host setting pushes it back, the browser gets trapped.
This often happens when different systems control redirects at different layers:
  • your web host
  • your CMS
  • your CDN
  • your domain platform

Old redirect rules still active

Some sites accumulate redirects over time from rebrands, old landing pages, deleted blogs, and migration projects.
One line may be correct by itself. The problem starts when it interacts with older logic that nobody removed.

What to ask your developer or host to check

You don’t need to edit server files yourself to ask smart questions.
Send a request like this:
That wording gets better results than “it says too many redirects.”

Good redirect logic versus bad redirect logic

You’re looking for one clear canonical destination.
For example, choose one final version of the domain:
  • https://example.com
  • or https://www.example.com
Then make every other version go directly there.
Bad setups usually have one of these patterns:
Pattern
What goes wrong
HTTP redirects to HTTPS, but app reverses it
Endless protocol loop
Non-www redirects to www, but CDN reverses it
Domain loop
URL A redirects to B, B redirects to C, C redirects back to A
Circular chain
CMS plugin handles redirects while server also handles them
Duplicate logic

Files and settings that often contain the problem

Depending on the stack, support may need to inspect:
  • .htaccess on Apache
  • Nginx server configuration
  • CMS redirect plugins
  • host-level redirect settings
  • control panel domain forwarding rules
If your team maintains redirects in a sheet, compare that list against what’s active in the hosting dashboard. The mismatch is often the clue.
A practical primer on permanent redirect handling can help when you’re reviewing cleanup plans or validating how old URLs should behave. This guide on how to do 301 redirect is useful background before you approve a bulk change.

Use logs and redirect traces, not guesswork

A redirect loop can look mysterious from the browser, but server logs usually make it obvious.
Ask support for:
  • the redirect chain for the affected URL
  • the status codes returned in sequence
  • the exact layer issuing each redirect
  • the first rule that starts the loop
If you’re doing broader cleanup, it can also help to perform a comprehensive SEO audit so you’re not fixing one redirect loop while leaving duplicate canonicals, broken internal links, or stale sitemap entries untouched.
Here’s a short explanation to send a technical team:
That sentence changes the quality of the response you get.

A few signs the issue is not just one page

If support reports any of these, think broader than a single broken URL:
  • homepage and blog both fail
  • login pages redirect repeatedly
  • only HTTPS version fails
  • only custom domain fails while temporary domain works
  • staging and live behave differently
That usually means the problem is structural, not editorial.

One useful habit for content teams

Keep a simple redirect change log.
Include:
  • the date
  • the URL changed
  • who changed it
  • where the redirect was added
  • why it was added
You don’t need a fancy system. A shared document is enough. Without that history, redirect troubleshooting turns into archaeology.
Before you escalate further, watch this walkthrough if you want a visual explanation of how redirect tracing works in practice:

How Your CMS Can Cause Redirect Loops

Not every redirect loop starts in server files. Sometimes the CMS creates the problem, or at least makes it harder to spot.
That’s why two sites with the same domain setup can behave very differently. One has a clean publishing layer. The other has plugins, theme logic, custom fields, and inherited settings all trying to control the same URL behavior.
notion image

WordPress problems tend to be layered

WordPress is flexible, which is useful until multiple pieces of the stack all make redirect decisions.
Common examples include:
  • the WordPress Address and Site Address not matching
  • an SEO plugin forcing one domain format
  • a redirect plugin adding rules on top of host-level redirects
  • a theme or custom code redirecting logged-out users
  • membership or multilingual plugins rewriting paths
None of these are unusual on their own. The issue is overlap.
A non-technical team often sees only the final symptom: “the page won’t load.” But from the CMS side, the actual problem may be that the site stores one preferred URL while the server or CDN serves another.

No-code publishing setups usually reduce moving parts

Modern publishing platforms often reduce loop risk by removing plugin sprawl and keeping URL handling more opinionated.
That doesn’t make them immune. It does mean there are fewer places for a redirect rule to hide.
If your team is comparing stacks or trying to understand what a CMS is responsible for, this overview of what is a content management system is a useful baseline. It helps separate content workflow issues from infrastructure issues.

Migration is the most overlooked danger zone

In this regard, many standard guides fall short.
A key underserved angle is redirect loops during CMS migrations. Teams moving to no-code platforms from legacy systems often run into problems caused by incomplete DNS propagation or conflicting rules left behind in the old hosting environment, as noted by SolidWP’s discussion of too many redirects.
That matters because migration isn’t a stable state. For a while, multiple systems may all think they should answer for the same domain.

What that looks like in real life

A content team migrates from an old blog setup to a new publishing platform.
At the same time:
  • the old host still has a force-HTTPS rule
  • the new platform expects the custom domain to finish connecting
  • the CDN still points at the old origin
  • a domain forwarding rule remains active
  • some users see the new version, others don’t
From the outside, it looks random. It isn’t random. It’s overlapping authority.

A practical CMS comparison

Here’s the difference in how content teams usually experience this problem:
Setup type
Typical redirect risk
What content teams can check
Plugin-heavy WordPress
Multiple overlapping rules
Site URL settings, redirect plugins, recent plugin/theme changes
Custom legacy CMS
Hidden application logic
Ask where redirects are stored and who controls canonical domain behavior
No-code publishing platform
Fewer moving pieces, but migration/domain issues still matter
Domain connection status, old host rules, DNS cutover timing

Questions to ask during or after a migration

If your site started showing redirected you too many times right after a migration, ask these in one message:
  • Which platform is currently the source of truth for the live domain?
  • Are any redirects still active on the previous host?
  • Is the custom domain fully connected on the new platform?
  • Are both systems trying to enforce HTTPS or domain preference?
  • Was any domain forwarding left on at the registrar or host level?
Those questions help support teams stop looking only at the browser error and start tracing ownership.

What content managers can safely do themselves

You can usually confirm a lot without touching code:
  • check whether the temporary platform URL works
  • compare the live custom domain against preview or internal URLs
  • note whether the homepage fails but draft previews load
  • list every system involved in the move, including host, CMS, CDN, and domain registrar
  • document exactly when the error began
That timeline matters. If the issue started immediately after switching platforms, the migration itself is part of the diagnosis.

What usually doesn’t work

These actions waste time when the root cause is a migration conflict:
  • repeatedly clearing your browser data
  • republishing the same article
  • changing slugs at random
  • adding more redirect rules before removing the old ones
  • assuming the new CMS is broken without checking the previous host
The cleaner approach is simpler. Pick one canonical domain, one serving platform, and one place where redirects are managed. Then remove or disable anything else that still tries to control the route.

Checking Your CDN and SSL Certificate Settings

When the browser looks clean and the CMS checks out, the next likely culprit is the layer between the visitor and your server.
That usually means your CDN, proxy, or SSL configuration.
notion image

Why CDN settings create loops so easily

A CDN can rewrite requests before they ever hit your origin server.
That’s helpful for speed and security, but it also means you now have another layer that can:
  • force HTTPS
  • redirect one hostname to another
  • cache old redirect responses
  • apply page rules or edge rules
  • pass the wrong protocol information to your origin
If your server and CDN disagree about what the final URL should be, visitors bounce between them.

The SSL mode mismatch problem

One of the most common examples is a proxy forcing HTTPS at the edge while the origin server handles traffic in a way that triggers another redirect.
The pattern usually looks like this:
  1. Visitor requests a secure URL
  1. CDN forwards the request in a different mode than the origin expects
  1. Origin issues a redirect to “fix” the protocol
  1. CDN repeats the cycle
For content teams, the important point isn’t the exact handshake. It’s the symptom. If the site broke after changing SSL, connecting a CDN, or altering proxy settings, those changes belong at the top of your suspect list.

What to inspect in your CDN dashboard

Look for settings related to:
  • SSL or TLS mode
  • Always use HTTPS
  • edge redirects
  • page rules or redirect rules
  • cache purge history
  • origin certificates
  • hostname forwarding
If the dashboard has both a global HTTPS rule and separate redirect rules for hostnames, review them together. Individually they may look fine. Together they can conflict.
A practical SSL setup guide like install SSL cert is useful if you need a quick reference for how certificate layers and secure routing are supposed to align.

HSTS can make a fixed issue feel unfixed

HSTS tells browsers to always use HTTPS for a domain.
That’s good when configured properly. It’s frustrating when the site had a previous SSL mistake, because the browser may keep forcing secure behavior even after you’ve changed the server.
If someone says, “We fixed it, but I still get redirected you too many times,” HSTS or cached secure behavior may be why their browser still behaves differently from a fresh device.

A simple way to isolate CDN involvement

Ask your technical contact one question:
That distinction matters. If the CDN is issuing the redirect, your application team may not see the problem in CMS settings. If the origin is issuing it, the CDN may be exposing an existing misconfiguration.

Signals that point strongly to CDN or SSL issues

These patterns often show up:
Symptom
Strong clue
Site worked before enabling proxy/CDN
Proxy rules likely involved
Temporary platform URL works, custom domain fails
Domain proxy or SSL mismatch
HTTP works oddly, HTTPS fails completely
Certificate or protocol enforcement issue
Some users still report loops after a fix
Cached redirects or HSTS behavior

What to ask support to do

You don’t need to propose technical commands. Just request a controlled review:
  • check current SSL mode
  • confirm the origin has a valid certificate
  • compare CDN redirect rules with origin redirect rules
  • purge cached redirects after changes
  • test the final canonical hostname only
That last point is important. Teams often test too many variants during troubleshooting and reintroduce confusion.
If your team recently changed certificates, enabled a CDN, or moved the domain to a new platform, don’t assume the issue is “still DNS” or “probably cache.” In many cases, the loop is the product of one security layer correcting another security layer in the wrong direction.

Your SEO Recovery Plan After Fixing the Redirect Loop

Once the site loads again, it’s tempting to move on. Don’t.
A redirect loop blocks access. Search engines may need time to trust the page again, revisit it, and restore visibility. Current guides often skip this part, but for startups that depend on organic traffic, rankings can take days or weeks to recover, and proactive steps like submitting updated sitemaps and requesting recrawls in Google Search Console can speed that process, according to Network Solutions’ discussion of the too many redirects error.

What to do right after the fix

Handle recovery in this order:
  1. Verify the final URL returns normallyCheck the exact pages that were failing, not just the homepage.
  1. Inspect the affected URLs in Google Search ConsoleUse URL Inspection to confirm Google can fetch the page now.
  1. Request indexing for key pagesFocus on revenue pages, high-ranking articles, and core landing pages first.
  1. Resubmit your sitemap if neededThis helps reinforce the current structure after a disruption.

What to monitor over the next stretch

Watch for signs that recovery is progressing:
  • affected URLs return to the index
  • impressions begin to reappear
  • clicks recover on the pages that dropped
  • crawl issues stop showing for those URLs
Don’t panic if everything doesn’t bounce back overnight. What matters is whether Google can now reach the correct destination cleanly and consistently.

Don’t skip the business review

After a loop incident, review more than technical status.
Check:
  • top pages that lost visibility
  • campaigns pointing to affected URLs
  • internal links that may still hit redirected versions
  • canonical tags on recovered pages
If your team needs outside help because the issue exposed broader SEO weaknesses, use a clear evaluation process instead of hiring the first agency that promises a quick rebound. This guide on how to choose the best SEO company is a reasonable checklist for screening support.

Frequently Asked Questions About Redirect Errors

Is “redirected you too many times” always a server problem

No. It can start in the browser through stale cookies or cached redirect behavior.
That said, once you’ve tested private mode, cleared site data, and reproduced the issue on another device, the problem is usually on the site side.

Can one broken plugin cause the whole site to fail

Yes.
A redirect plugin, SEO plugin, login tool, multilingual plugin, or security layer can issue rules that affect the entire domain. This is especially common in WordPress when several plugins overlap with host or CDN redirects.

Should I keep adding redirects until the error stops

No. That usually makes the situation worse.
If there’s already a loop, adding more redirect logic without removing conflicting rules often creates a longer chain or a harder-to-find circular path.

Is clearing cache enough

Sometimes, but not reliably.
Cache clearing helps if the browser is holding onto old behavior. It does not solve a bad canonical domain rule, a broken HTTPS setup, or a CDN-origin conflict.

How do I know whether the homepage issue is also affecting blog posts

Test more than one URL.
Check:
  • homepage
  • one blog article
  • one category or tag page if you use them
  • one landing page
  • one login or contact page if applicable
If only one page fails, the problem may be URL-specific. If multiple page types fail, assume a broader configuration issue.

Can redirects hurt SEO even if there isn’t a full loop

Yes.
Long redirect chains are weaker than a direct route. A clean, single-hop redirect is easier for users and crawlers than a path that bounces through multiple versions.

What should I document before asking for help

Send a short incident summary with:
  • the exact failing URL
  • when the issue started
  • what changed before it started
  • whether private mode helped
  • whether another device reproduced it
  • whether the temporary or preview domain still works
This gives support enough context to investigate the correct layer faster.

What’s the best way to prevent this from happening again

Use fewer systems to control redirects.
That means:
  • one canonical domain choice
  • one place for redirect management
  • fewer overlapping plugins
  • careful review during migrations
  • post-change testing after SSL, CDN, or domain updates

If the site works now, can I ignore the incident

You shouldn’t.
Check Search Console, review affected URLs, and make sure the fix holds across devices and page types. A redirect issue that “looks fixed” can still linger in cached layers or secondary rules.
If your team wants a simpler publishing setup with fewer moving parts, Feather is worth a look. It lets you publish from Notion to an SEO-friendly site without the plugin sprawl, maintenance overhead, or technical complexity that often turns small configuration mistakes into bigger visibility problems.

Ready to start your own blog while writing all your content on Notion?

Notion to Blog in minutes

Start your free trial

Written by

Tibo