After an SSL certificate is installed, several things start trying to force HTTPS at once — the host, a plugin, .htaccess, the CDN, and WordPress itself. Each redirects to what it thinks is correct, and if one of them is unaware the connection is already secure, the browser bounces between them. The certificate is rarely the problem.
Before you buy, one quick look
Read-only, and do it in a private window.
Try the site with https:// typed explicitly. Then try http://. Note which loops and which does not.
If HTTPS loads cleanly when typed directly, the certificate is fine and the fault is entirely in the redirect rules — which is the common case and exactly what this fixes.
Too many redirects after SSL change
Installing SSL has put the site into a redirect loop. We find which layer is redirecting and leave a single clean path to HTTPS.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
This or something else?
| Loop started when SSL was installed | This fix covers it |
| Loop with no SSL change | Infinite redirect loop on homepage |
| Browser warns the certificate is invalid | SSL certificate configuration errors |
| Page loads but shows insecure content | Mixed content resolution |
| Only the login page loops | Login redirect loop fix |
What you are seeing
- Too many redirects, starting when the certificate was installed
- It may affect the whole site or only the admin
- Typing https directly may work while http loops
- It may have worked briefly then started looping
Common causes
- A force-HTTPS plugin duplicating a redirect the server already performs
- A CDN terminating SSL and passing the request to the origin as insecure
- Site URL and Home URL still set to http in the database
- An .htaccess rule redirecting to https on a connection already using it
- A load balancer not passing the header that tells WordPress the connection is secure
What we do
- Take a full backup before touching anything
- Trace the redirect chain from outside and identify every layer involved
- Establish where SSL is terminated and what the origin actually receives
- Remove duplicate redirects and keep one authoritative rule
- Update URL settings safely, without locking anyone out
- Verify all four combinations of protocol and www resolve in one hop
What is included
- A site loading cleanly over HTTPS from any URL variant
- One redirect rule rather than several competing ones
- A note listing every layer that was forcing HTTPS
- The pre-fix backup, kept for 30 days
Not included
- Issuing or renewing the certificate itself, which is a separate service
- Mixed content cleanup inside your content, which is separate
- CDN configuration on an account we cannot access
- Design changes or content work
Questions about this fix
Is my certificate broken?
Almost never. Certificate problems produce a browser security warning, not a redirect loop. A loop means the certificate is working and too many things are trying to enforce it at once.
I installed a force-HTTPS plugin. Should I remove it?
Possibly, and the answer depends on what else is redirecting. If the host already forces HTTPS, the plugin is a second opinion that causes the loop. If nothing else does, the plugin is doing something useful and stays.
Everything is behind Cloudflare. Does that change things?
It is one of the most common causes. If Cloudflare terminates SSL and talks to your origin over plain HTTP, WordPress sees an insecure connection and redirects — and Cloudflare sends it back. It is a settings fix on both sides.
Will this affect my search rankings?
A prolonged loop will, because the site cannot be crawled. Fixed properly, moving to HTTPS is neutral to positive. We make sure the surviving redirect is a permanent one so link equity passes correctly.
Why did this only start after the certificate was installed?
Because installing it is usually what triggers several systems to start redirecting to HTTPS at once — the certificate itself works fine; it's the sudden disagreement between host, plugin and server about who's responsible for the redirect that goes wrong.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.