---
title: "Auto-purge"
description: "What gets purged on publish and purging from your own hooks."
requested_language: sk
language: en
translation_notice: "This page isn't translated yet"
url: https://docs.systhema.app/sk/payload/cloudflare/purging
version: unreleased (main)
docs_index: https://docs.systhema.app/sk/llms.txt
---
> This page isn't translated yet. Showing English.


Every seam that already revalidates Next.js also purges the matching Cloudflare edge cache, so an edit invalidates both caches together:

## What gets purged

| Trigger                                                        | Purges                                                                             |
| -------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
| Page publish/update/delete                                     | The page's paths (old + new, including descendants) and the homepage when affected |
| Component used across pages                                    | Every page that renders it                                                         |
| Form used across pages                                         | Every page that renders it                                                         |
| Redirect create/update/delete                                  | The redirect's `from` path                                                         |
| Post publish/unpublish/update/delete (Posts module)            | Every path the post hooks revalidate, in every affected locale (see below)         |
| Category or tag edit/delete, author byline change              | Every path the post hooks revalidate, in every affected locale (see below)         |
| Upload file or alt change on an image posts use                | The posts that render it, their listings and the homepage                          |
| Upload's alt text changes                                      | The whole zone (whole-site purge — other upload changes don't trigger a purge)     |
| Header, Footer, or SEO global save                             | The whole zone (`purge_everything`)                                                |
| A general-settings change that revalidates everything          | The whole zone (`purge_everything`)                                                |
| General Settings → Troubleshoot tab's "Revalidate site" action | The whole zone (`purge_everything`)                                                |
| The `/systhema/revalidate` route (`paths: '*'` or a list)      | The whole zone, or the matching URLs                                               |

The [Posts module](https://docs.systhema.app/sk/payload/posts/roles-and-freshness.md#revalidation-isr-freshness) purges the same paths it revalidates: the post's permalink (and its old permalink when it moved or was unpublished), the homepage, every archive-template Page and every Page embedding a `posts` block (the category, tag, author and archive listings), and the sibling posts whose Related rail shows it. A category whose slug changes under a `{category}` permalink also purges the affected posts' old URLs. A body-only edit of a published post purges only that post. Each save issues one purge with every affected locale's public URL.

## How auto-purge behaves

Auto-purge is a **guarded no-op**: it does nothing unless Cloudflare is enabled and the effective auto-purge toggle is on, and it **never throws** — a purge failure is logged and swallowed so it can never break a Payload hook or a page publish.

**The `autoPurge` toggle precedence**: the persisted `cloudflare` global's `autoPurge` field, when the global exists and is readable, always overrides the `cloudflare` plugin option's `autoPurge` default. This lets a project change the behavior from the admin UI without redeploying. The effective value is cached in memory for a few seconds per Payload instance so a burst of revalidations during a bulk edit doesn't issue a database read per path.

**The `siteUrl` requirement**: purging specific paths needs an absolute URL, built from `siteUrl` (the plugin option) or, when that's omitted, the Payload config's `serverURL`. If neither resolves, path-level auto-purge silently skips the Cloudflare leg (logging a warning) while the Next.js revalidation still runs — pages are never left un-revalidated because Cloudflare couldn't be reached.

**Cache rules restricted by method must include `PURGE`.** Cloudflare evaluates cache rules with the request method `PURGE` when it purges a single URL. A rule that caches HTML only for `GET`/`HEAD` makes every purge report success while evicting nothing, so add `PURGE` to the rule's method list (or drop the method condition).

## Purging from your own hooks

Collections you add yourself are not covered by auto-purge. Call `autoPurgePaths` from `@systhemaui/payload` next to your own `revalidatePath` calls. It takes the Payload instance and public paths (or absolute URLs on a site you publish through), builds absolute URLs from `siteUrl`, groups them by zone, and follows the same rules as auto-purge: a no-op unless Cloudflare and auto-purge are on, and it never throws. Import it only from server code; the root entry is not client-safe.

```ts
import type { CollectionAfterChangeHook } from 'payload'
import { autoPurgePaths } from '@systhemaui/payload'

export const revalidateEvent: CollectionAfterChangeHook = async ({ doc, req, context }) => {
  if (context?.disableRevalidate) return doc

  const { revalidatePath } = await import('next/cache')
  const paths = [`/events/${doc.slug}`, '/events']
  for (const path of paths) revalidatePath(path)
  void autoPurgePaths(req.payload, paths)

  return doc
}
```

On a multilingual site, pass each locale's public path (for example `/hu/esemenyek/...`, or the full URL on a locale domain), not the internal route you revalidate.