Shopify www / non-www redirect loop or ERR_TOO_MANY_REDIRECTS — primary domain, Cloudflare Flexible SSL, A/CNAME.

Several products can look like “the store URL will not open.” They do not share a settings panel. This page is only when www and apex (non-www) redirect into each other, or the browser shows ERR_TOO_MANY_REDIRECTS / redirect loop on the marketed hostname while DNS and certificates may already look Connected. A hostname that fails TLS / stays Connecting / SSL pending without a clean redirect chain is custom domain / SSL not connecting. A storefront that opens but stays on Enter using password / Coming soon is password page stuck online. This page is only: www / non-www redirect loop.

Six ordinary reasons the loop keeps spinning: primary domain unset so both hosts fight, Cloudflare Flexible SSL bouncing HTTP↔HTTPS with Shopify, Shopify domain redirect plus Cloudflare Page Rules / Bulk Redirects plus registrar forwarding all owning www↔apex, A / CNAME still pointing at an old host that redirects the other way, Markets country domains adding another hop, or you are debugging SSL pending / password page instead. Walk them in that order. You already pay for Shopify Domains. You do not need another seat to stop a redirect loop.

Open Settings → Domains. Screenshot which hostname is Primary and the status chip for apex and www. From a terminal, curl -I https://www.example.com and curl -I https://example.com and note every Location: hop (do the same for http://). In Cloudflare (if used), screenshot SSL/TLS mode (Flexible / Full / Full strict) and any Page Rules or Bulk Redirects that mention www or apex. At the registrar, screenshot domain forwarding / masking.

Honest proof: if the Location headers bounce www → apex → www (or http → https → http), stay on this page. If dig fails or TLS never completes and Domains shows Connecting / SSL pending with no clean Connected hosts, leave for custom domain / SSL not connecting. If the host finally loads Enter using password / Coming soon, use password page stuck online. Do not mix those proofs.

Both apex and www can show Connected while neither is Primary, or while ads / email / bio share one host and Shopify treats the other as primary. Shopify then redirects one way; a second owner (Cloudflare, registrar, old host) redirects the other way. Buyers never land — they loop.

Fix: Settings → Domains — set the hostname you actually market as Primary. Confirm the non-primary host is listed and Connected so Shopify can redirect it once toward primary. Do not leave “no primary” after a domain cutover. SSL-pending and password-page settings live elsewhere; they do not pick a primary for you.

Cloudflare Flexible means the edge speaks HTTPS to the buyer but HTTP to the origin. Shopify insists on HTTPS and redirects HTTP to HTTPS. Cloudflare then rewrites again. The browser sees ERR_TOO_MANY_REDIRECTS even when dig looks fine and Domains may already say Connected. This is the classic Flexible + Shopify loop — different from orange-cloud blocking certificate provisioning (that is the SSL-pending playbook).

Fix: for Shopify hosts, move SSL/TLS off Flexible — typically Full or Full (strict) only after Shopify owns a valid cert, or set the records to DNS-only (grey cloud) until Domains is Connected and the redirect chain is one hop. Re-test curl -I on both www and apex over http and https. Do not “fix” Flexible by adding yet another Page Rule that forces HTTPS both ways.

Three owners love the same job: Shopify Domains redirect (non-primary → primary), Cloudflare Page Rules / Bulk Redirects / Redirect Rules (www → apex or apex → www), and registrar forwarding / masking. When two of them disagree on direction, you get a loop. Markets country domains can add a fourth hop if mis-primary’d.

Fix: pick one owner of www ↔ apex redirects — prefer Shopify once both hosts are Connected and Primary is set. Delete or disable competing Cloudflare redirect rules and registrar forwarding for those hostnames. Re-run curl -I until each host has a single, predictable Location (or 200 on primary). Password page and SSL pending are still different products.

If apex A still points at an old Vercel / Netlify / Squarespace / parking IP that 301s to www, while www CNAME points at Shopify which 301s back to apex (or the reverse), you get a loop that looks like a “Shopify bug” but is just two hosts answering. Leftover AAAA records can send some networks to the old owner only.

Fix: dig / nslookup apex A / AAAA and www CNAME. Point both at Shopify’s current recommended targets from Settings → Domains. Remove conflicting A / AAAA / CNAME and old host redirects. If Domains never leaves Connecting / SSL pending after DNS is fixed, switch to custom domain / SSL not connecting — that playbook owns certificate provisioning, not this loop.

A hostname that fails TLS / stays Connecting / SSL pending, or where Cloudflare orange-cloud blocks certificate issuance, is custom domain / SSL not connecting. A storefront that opens on the custom domain but stays on Enter using password / Coming soon is password page stuck online.

The only honest test for this page: curl -I (or DevTools Network) shows a redirect loop or ERR_TOO_MANY_REDIRECTS between www and apex (and/or http and https); fixing Primary, Flexible SSL, competing redirect owners, and A/CNAME targets collapses the chain to one hop. Anything else is a different product.

Stay DIY if you can spend one afternoon on the list above: prove the redirect chain and Primary, move off Cloudflare Flexible (or DNS-only until settled), keep one redirect owner, fix A / CNAME, and stop confusing SSL pending / password page with a www loop. That is the whole playbook. No agency required. Short answers also live on the merchant FAQ. Related pages: custom domain / SSL not connecting, password page stuck online.

Pay for help when the work is not the redirect row — it is connecting the stack you already have so lead capture is not dying in DMs, storefront and checkout-ready exceptions land in a channel you already check, and the live store is one workflow instead of a spreadsheet plus a Slack bot you forgot. That is the Latch AI Ops install.

What $997 USD one-time buys: lead capture on the live store, ops alerts in a channel you already check, and a checkout-ready workflow. 72 hours after collaborator access, not after payment. One live Shopify store. Access plus a delivery thread. Store URL collected at checkout. Not a SaaS seat, not a theme rebuild retainer, not a conversion guarantee, not a brand or theme job.

Other shops’ public ranges, not testimonials: a checkout / ops install typically runs $500–$2,500. A full ops consulting block typically runs $2,000–$5,000. $997 is the cheap end of that work, sold as a 72-hour install of three systems — not as an earnings number or conversion-lift claim.

What it does not buy: more orders, recovered revenue, a forever one-hop redirect, or a case study. Latch AI Ops has not published customer proof because there are no customers yet. You are buying the install.

Checkout is on Whop. Operator is Nico. United States offer. You can revoke collaborator access after handoff. We do not take owner passwords.