# A Better Cache Invalidation Solution for Ghost

**URL:** <https://forum.ghost.org/t/a-better-cache-invalidation-solution-for-ghost/56009>\
**Category:** Share & showcase\
**Created:** [March 11, 2025, 1:59pm UTC](https://forum.ghost.org/t/a-better-cache-invalidation-solution-for-ghost/56009 "2025-03-11T13:59:58Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![jannis](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/jannis/32/39718_2.png) [@jannis](https://forum.ghost.org/u/jannis)\
**Post date:** [March 11, 2025, 1:59pm UTC](https://forum.ghost.org/t/a-better-cache-invalidation-solution-for-ghost/56009/1 "2025-03-11T13:59:58Z")

</div>

I just worked on some infrastructure stuff at Magic Pages and realised that I never properly shared about one of my favourite little details the Ghost team implemented a long, long time ago.

It’s not documented anywhere, so technically it could change at any point (please don’t 😬), but it is, in my eyes, the best way to deal with cache invalidation when you use a CDN in front of your Ghost site: the `X-Cache-Invalidate` header:

> **[A Better Cache Invalidation Solution for Ghost](https://www.magicpages.co/blog/a-better-cache-invalidation-solution-for-ghost/)**
>
> If you've ever run a Ghost site behind a content delivery network (CDN), you've probably encountered the cache invalidation problem: how do you make sure that the embarrasing typo you missed actually gets updated everywhere? Or in technical terms:...

---

<div class="post-metadata">

**Author:** ![jannis](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.ghost.org/jannis/32/39718_2.png) [@jannis](https://forum.ghost.org/u/jannis)\
**Post date:** [March 11, 2025, 9:21pm UTC](https://forum.ghost.org/t/a-better-cache-invalidation-solution-for-ghost/56009/2 "2025-03-11T21:21:14Z")

</div>

Quick addition though:

@muratcorlu pointed out on Reddit that there is the `site.changed` webhook event. So, the statement in the blog post that webhooks cannot invalidate the cache on _all_ changes is simply wrong. No idea how I missed that, but thanks for pointing it out, Murat 😃
