Content updates and caching
Why a published change can appear on its own page before it appears in listings and related pages
When you publish a change, the record's own public page is normally refreshed straight away. Listings and other pages that refer to it can take longer. This page explains the two refresh paths and what to check when an update has not appeared.
The short version: publishing is what makes a draft public. Saving a draft or editing without publishing does not refresh the public site.
Why your site is cached
Basker serves your public site through a global CDN: a network of edge servers that keep a copy of each page close to your visitors. Caching helps your site absorb on-sales, season launches, and other traffic spikes without slowing down. See How Basker works for the bigger picture.
The trade-off is that a cached page can briefly lag behind the latest published content. Basker manages the refreshes; editors do not need to clear the cache manually.
What happens when you publish
Publishing or updating an already-published record starts two complementary refresh paths.
You publish a record
Draft saves and autosaves stay in preview. Publishing, updating an already-published record, unpublishing, or deleting public content can refresh the live site.
Basker refreshes the record's own route
Where Basker can identify the record's public route, it purges that page immediately. A normal page, event, or post edit should therefore appear at its own URL quickly.
A broader refresh follows
Basker also queues a broader site refresh for ten minutes after the first change in an editing burst. This updates listings, navigation, smart collections, and other pages that may refer to the changed record. Sites using the shared Basker address can have a further shared-router refresh window of up to 15 minutes.
A changed event can be fresh on its own page while the homepage or a collection still shows the earlier version. That is expected during the broader refresh window.
Why timing can feel inconsistent
- Drafts and autosave do not refresh the live site. Your change reaches the public site only when you publish it. See Drafts, preview, and publishing.
- Rapid changes are grouped together. The broader refresh is coalesced, so several publishes during one editing session normally produce one refresh rather than one per save.
- Integration syncs use the broader path. Bulk updates from an app skip the immediate per-page purge and rely on the deferred refresh so a large sync does not send a purge for every record.
- Browsers can keep a short-lived copy. If one device still shows an earlier page after the refresh window, try a hard refresh or a private window before republishing.
Previewing before you publish
You do not have to publish to see how a change looks. Use Preview for the latest draft without relying on the public cache. You can also share a preview link with someone who does not have a Basker account. See Drafts, preview, and publishing.
If an update is still missing
There is no editor-facing "clear the cache" button, and you should not normally need one.
If the affected record's own page is stale, confirm that you published that record and republish it if necessary. If a listing or related page is stale, wait for the broader ten-minute window, or up to 15 minutes on a shared Basker address. If the change is still missing, contact support with both the edited record URL and the stale page URL.