Half the Customers See Last Month's Homepage

Two caches are in play. First, recursive resolvers run by ISPs and public DNS providers cached the old A record and will keep serving it until its 86,400-second TTL expires, which can be up to a full day from the change and longer in resolvers that ignore or extend TTLs. Second, individual browsers may have cached the old HTML page itself, so even a correct DNS answer can render stale content.

Reverting the A record is the wrong move. The moment resolvers refresh, everyone would swing back to the old server, extending the window of confusion, and customers who already reached the new server would be pulled backward. Reverting also risks serving stale prices or inventory. A reversal only makes sense if the new server were broken, and the reports show it is serving correctly to most visitors.

The team controls: the TTL on the record (drop it to 300 seconds now, so the next change is fast), what each server returns, and the redirect rules. It does not control third-party resolvers or client browser caches and cannot force them to flush. Practical steps: measure by querying several public resolvers to estimate the remaining stale fraction, make sure the old server at minimum returns a 301 to the new host rather than stale shopping content, and wait out the TTL before making any further DNS change.

The page is served over HTTPS, but subresources are requested over HTTP, which is mixed content. Browsers treat scripts, stylesheets, iframes, and XHR as active mixed content and block them outright; images are passive, and Chrome attempts to auto-upgrade them but blocks them if the HTTPS fetch fails. The warning padlock follows from any blocked or downgraded subresource.

The blocked JavaScript matters far more than missing cover images. A blocked script typically carries cart, analytics, or checkout logic; a broken cart stops revenue, while a missing thumbnail merely looks bad. The 18 percent drop is more plausibly explained by a stalled cart than by absent artwork, and that hypothesis is testable by watching checkout completion in the logs.

The fix is at the source, not in the browser. Change the stored references from http:// to https:// (or protocol-relative where appropriate) inside the CMS database, templates, and any hard-coded widgets, not just the theme file. Verify the CDN presents a valid certificate for its hostname. Only after confirmation, add a Content-Security-Policy with upgrade-insecure-requests and consider HSTS, because CSP will silently mask remaining http references rather than fixing them.

Each redirect hop costs a round trip on the critical path and, in older clients, can strip the referrer; chains also spread ranking signals across variants and make analytics segmentation messy. If the chain is bare http to https non-www to https www, the first hop lands on a host that immediately redirects again.

Policy: choose one canonical form, for example https://www.harborlinebooks.com, and make every other variant (http non-www, http www, https non-www) return a single 301 directly to it. Use 301 rather than 302 because the move is permanent and the status code is what tells crawlers to consolidate. Update internal links, canonical tags, sitemap entries, and marketing emails to point at the canonical form so users rarely traverse a redirect at all.

Once the certificate and mixed content are fixed, HSTS (start with a short max-age, then raise it) removes the http-to-https hop entirely for returning visitors. Re-check Search Console after the change to confirm the chain collapsed to one hop, and record the canonical decision so the next migration does not reintroduce a variant.