Custom domain doesn't update but netlify.app version does

Hi,
For the past while I’ve noticed that when I update my site darraghmckay.com I can’t see the new content until I do a hard refresh and empty cache.

Similarly, crawler bots can’t find the new pages when I paste the links in messenger/slack etc. It sees the netlify 404/page not found page.

However, darraghmckay.netlify.app updates just fine.

If I had to guess I would say it’s a DNS config issue but I’ve moved the site over to Netlify DNS and the problem still persists.

The page I’m trying to view is this:
Working: Portfolio | Darragh Mc Kay
Not working: Portfolio | Darragh Mc Kay

hey @darraghmckay - are you still seeing a mismatch?

I checked the links you provided and the content looks identical to me, can you confirm this is still not working?

Hi, thanks for checking it.
I actually am still seeing the issue:

It can’t find the “project” I added last night, because it’s serving an old version of the app.

It only happens if you’ve ever been to my site I think which leads me to believe it’s DNS or caching issues.

The js file being loaded on my custom domain is:

While the js file being loaded on the netlify domain is:

Notice the different hashes

It looks like this build from Apr 27 at 6:58 PM is the one I’m seeing on darraghmckay.com
Netlify App

Whereas the most current build, Wed 29 at 12:55 AM is the one I see on the netlify domain

Hi there!

As far as I can tell we are serving identical content on Portfolio | Darragh Mc Kay on every single CDN node, and we haven’t served files from any deploys except the most recent one since you deployed, as far as I can tell from our internal logs. Of course, since you have a redirect for /* we’ll serve your index.html for missing files.

So I think that one or more of the below is true:

  • something other than that path is the “wrong content” and you’ve sent us a link to where you see the wrong content, rather than where it’s hosted.
  • or you have some situation like a service worker that is misconfigured.
  • or your use of unnecessarily chunked/asset fingerprinted files causes an old tab to try to load an old file (more details in this post about that)

The second or third ones seem most likely, if you can fix with a cache clear. To fix the second one, check out this article: International Service Worker Caching Awareness Day

While I don’t see an active service worker on your site, it is still part of your most recent deploy. Perhaps you once had one active, and it needs to be deregistered from your local browser?

EDIT: we also have this useful article on service workers you might find helpful!

Hi, thanks for the reply.

The thing is, clearing the cache does fix the issue, which is why you can’t see it, but I’m intentionally not clearing my cache so I can try and get to the root of this.

This has happened with every deploy I’ve made over the past month or so. And every time I link my site to friends they can’t see my updated content which is very frustrating.

Can you clarify what you mean by this?

something other than that path is the “wrong content” and you’ve sent us a link to where you see the wrong content, rather than where it’s hosted.

As for service workers, there’s never been one associated with this site, but I do understand that they cache the site, so thank you for linking that.

To your 3rd point, this happens after many refreshes, so it’s not just an old tab. The only thing that fixes it is to do a hard refresh and emptying cache. At which point I usually get the Netlify 404 page (maybe not anymore since I added the redirect) and then another refresh or two usually brings up the right page.

Is there any way you can validate that the DNS is configured correctly?

I’m really sorry, and thank you for your help.
It likely was service worker related. I didn’t realise there was one running (created with create-react-app). I’ve removed it for now and unregistered it, which won’t solve for existing viewers but should help going forward.

Thanks again both, for your help.

1 Like

fantastic - we were still scratching our heads over this one, but we likely would have suggested a service worker issue as a next step of something to take a look at!

1 Like