Progressive JSON does not update

Progressive JSON freshness depends on four stages: generation, writing, origin reading, and external delivery. Identify which stage still has the old value.

Find the actual JSON request

Open the browser Network panel, reproduce the archive or faceted-search interaction, and select the request that returns the data.

Record:

• sanitized request URL;
• status and content type;
• response body field that is stale;
• X-POM-Cache or X-POM-Progressive-Archive-Cache;
• CDN status and age headers;
• whether the same value appears in the initial HTML.

If the browser never makes a progressive request, diagnose the page builder or front-end behavior before the JSON cache.

Confirm the runtime settings

Open Settings → POM Cache → General and review the progressive JSON runtime:

• the JSON master must be enabled;
• writes must be enabled to create new artifacts;
• the WordPress read fallback must be enabled for cached reads through WordPress.

Optional direct Apache reading is a separate deployment layer. A disabled WordPress fallback does not prove that an installed Apache rule is inactive.

Prove generation and writing

Clear Progressive JSON Cache for the current site, then request the affected route.

A new file is written only when:

• the producer supplies a safe relative .json path;
• the payload is non-empty valid JSON within the maximum size;
• the generation context marks it cacheable;
• the write filter allows it;
• the destination is writable.

Refresh Progressive JSON Cache Contents. If the count remains at zero, inspect generation, path validation, cacheability, maximum size, and permissions. The HTML file count is unrelated.

Interpret response headers

An early PHP JSON hit reports:

X-POM-Cache: Served static JSON cache from PHP; phase=early

A POM Theme WordPress fallback cache hit can report:

X-POM-Progressive-Archive-Cache: hit

Generation can report generated-cacheable or generated-dynamic. A dynamic value means the response was deliberately not persisted.

An Apache direct hit has no PHP-generated diagnostic header. Verify it at the web-server layer.

Check invalidation

Progressive JSON has independent purge settings for post, term, and translation changes. Settings-change purging is an opt-in developer integration.

Test the exact change:

1. warm the JSON route;
2. edit the source;
3. observe whether JSON files are removed;
4. request again;
5. confirm the regenerated body contains the change.

A custom importer, API sync, or custom-table update must call a public JSON purge helper after its transaction succeeds. Do not clear once per item in a bulk job.

Check key variants

Locale, post type, pagination, and public filter context can produce different paths. Make sure you cleared and requested the same variant. A changed slug or key format can leave an old tree until the current-site JSON store is cleared.

Finish with Apache, CDN, and browser

Once the PHP origin response is current:

• verify the Apache rule maps to the same file;
• invalidate the exact CloudFront objects;
• retest with edge status and age headers;
• exclude browser cache, service workers, and client-side storage.

Do not broaden JSON paths or cache personalized API responses as a workaround for a missed invalidation.