I’ve been tearing my hair out trying to get to the bottom of this issue.
My Netlify site is waterandcarbon.netlify.app, it’s just a basic static HTML site. The live domain is waterandcarbon.com.au and its nameservers point to Cloudflare, which has A & CNAME records for Netlify.
Yesterday, we updated the site and deployed master@HEAD to Production via Bitbucket. The deployment seemed to work, because waterandcarbon.com.au was updated. However it appears most people cannot see the changes. When I visit the Netlify URL waterandcarbon.netlify.app, it shows the old site. I suspect this is what most people are seeing.
Question 1: shouldn’t the netlify.app site always reflect the Production deployment?
The branch deployment URL master–waterandcarbon.netlify.app shows the old site too. However when I click on the timestamp for the latest deploy, it opens https://64afb8940641ae38025c7292--waterandcarbon.netlify.app which reflects the latest version.
I found the Support Guide regarding potential issues with Cloudflare, and since then I’ve turned off the Proxy option on Cloudflare and changed the flattened CNAME to an A record that points to Netlify’s IP address 75.2.60.5. I purged the whole Cloudflare cache, several times. There has been no change after a few hours, from what I can tell.
We have another Netlify site for Staging environment, available at waterandcarbon.pluralagency.com.au (CNAME points to dynamic-chaja-9ace26.netlify.app). Those deployment come from the same BitBucket repo and both URLs show the latest site.
Question 2: Could that Staging site be confusing Netlify somehow?
Question 3: Can anyone tell me what I’m doing wrong? If I can get waterandcarbon.netlify.app to update, I think the issue will be resolved. But I’m still really confused by this scenario.
@nathanmartin thanks for your reply Nathan, I recently made some changes while debugging and now both sites are identical, but still not showing master@HEAD.
The frame of reference is on the following page, which has an article published yesterday: /media-hub/index.html
@nathanmartin yes it’s working for me now too. I could only get it to work after following these exact steps:
Visit the site in Incognito Mode
Clear Google Chrome cookies and image cache
Visit the site normally
If browser cache is the culprit, I’m still so confused, as a site I had never visited before (master–waterandcarbon.netlify.app) was cached with an older version. So it must be CDN cache in combination with my browser cache or something. I hate this!
@JackPlural Nice work resolving it, although obviously a little concerning if the precise cause/fix isn’t concretely known.
To answer your original first question, provided that you don’t have your site locked to a particular deployment, you would expect the .netlify.app URL to always show the latest version of the site.
My developer thinks it’s a cookie, and I can confirm removing all cookies that were added by the domain seems make things switch to the new version of the site.
I noticed Netlify adds the nf_ab cookie, which is used for Split Testing, but I don’t think that feature is activated. However when I deleted only that cookie and refreshed the page, the new version was served immediately. Difficult for me to confirm this behaviour but I wonder if it’s a possible bug?
I believe my junior developer had accidentally enabled Split Testing on this site. It wasn’t obvious in the UI as the Split Testing page says “You need to enable branch deploys”, so I assumed it wasn’t activated. However, the Overview page has a tile like this:
When I turned off Split Testing, cleared my cookies, and visit the production site, the nf_ab cookie is no longer added. I think this will resolve my issue, but I will continue to monitor the site in case I’m wrong.
Hi, @JackPlural. Netlify only adds that cookie when split testing is enabled.
I did confirm that a split test was enabled for that site back in June. That would be the reason that (for 50% of site visitors) the page did not update. I also see that split testing was recently removed again so this issue should be resolved.
If there are any remaining questions or concerns, please let us know.
Hi, @JackPlural. I’m sorry for not being clear because I was just trying to say, “Yeah! What you said.”
I was just +1-ing what you had said and confirming that I saw the same thing you did.
There is an audit log that tracks account activity. You can only see the audit log on the Pro plan or higher. There is documentation about the audit log here:
You can see the logs using the buttons in this screenshot:
So, when I said “I did confirm that a split test was enabled” I had done so using that logging. I was attempting to clarify that the split test being enabled was not a bug or something done by Netlify. It was something manually changed by someone using the account (which is what you had already stated above). I was only agreeing with you.
@luke ah! No worries at all, it was my mistake. Thanks for clarifying the situation and mentioning the logging feature - that will be useful! And thanks for your support here… I thought there were ghosts in the machine for a while there
