Sign In

Targeted WordPress Content Sync

Targeted content sync publishes the public effects of WordPress content changes without crawling the complete site. It is available with an active Professional or Agency subscription, like incremental publishing, and runs through a saved scheduler rule plus the external @smart-cloud/publisher-exporter queue runner.

What a rule tracks​

Each rule selects one or more public, publicly queryable post types with stable permalinks. WordPress journals their public transitions, including:

  • publish and published-content updates,
  • taxonomy and sticky-state changes,
  • unpublish, trash, and permanent delete,
  • permalink, author, and publication-date changes that affect enabled public surfaces.

The rule can reconcile post-type and taxonomy archives, the configured posts page, optional author and date archives, pagination, and the sitemap chain. Use Explicit listing routes for Query Loop pages or other listing surfaces whose queries WordPress cannot infer reliably. Routes must be site-relative, one per line, such as / or /insights/.

This is why publishing or changing one post can update several static files: the post itself may be only one member of a listing, archive, pagination, and sitemap impact set.

Establish the baseline first​

A successful normal full or incremental publish must establish a verified baseline before targeted work can deploy. The baseline binds the rule to the current WordPress release, source and target, rewrite behavior, sitemap setup, selected scope, and trusted crawl manifest.

Run another normal publish when the admin reports New baseline required. Typical causes are a theme or plugin release, permalink or sitemap changes, rewrite changes, a different deployment target, or edits to the content-sync scope. Content sync stops safely instead of broadening into an implicit full crawl when its baseline is stale.

Scheduler and retry behavior​

The WordPress scheduler does not start Node.js by itself. Run publisher-exporter queue-runner from cron, a systemd timer, Windows Task Scheduler, or CI. A one-minute runner tick is recommended; the rule's own interval controls how often demand is evaluated.

The runner processes a closed journal range. New changes that arrive during the run become trailing work for a later job. Equivalent demand is coalesced, and failures use bounded retry backoff while preserving the checkpoint. The committed cursor advances only after deploy, CloudFront invalidation, and final verification succeed.

If you abandon a retry from the Jobs screen, Static Publisher clears its local plan and checkpoint but does not acknowledge the journal range. A future scheduler tick can therefore create a fresh job for the same outstanding work.

Safe updates and deletions​

For published content, the runner renders the new public URL and the affected navigation surfaces. For unpublish, trash, delete, or permalink changes, it uses the last exact public URL recorded before the transition. WordPress trash aliases ending in __trashed are rejected as deletion targets.

Remote deletion is manifest-owned: content sync can tombstone only an output path already present in the trusted crawl manifest. It never lists the full S3 prefix to guess what should be removed, so unrelated or remote-only objects are preserved. Asset-wide cleanup remains the responsibility of a normal full or incremental reconciliation.

WordPress multisite​

Include multisite subsites is off by default. With it off, the rule tracks only the site that owns the Static Publisher runtime.

Enable it only when:

  • WordPress is running as a multisite network,
  • SmartCloud Static Publisher is network-activated,
  • the included subsites use the same origin with path-based URLs and share the configured static output namespace.

Turning it on tracks matching post types across the network and gives every event its site identity. It also changes the rule scope, so run a new normal publish afterward. Independently hosted or domain-mapped subsites need separate Publisher targets; they are not silently treated as paths of the main site.

Operational checks​

The Scheduler Settings screen shows observed and committed sequences, lag, baseline readiness, trailing work, retry attempts, and the latest operation. For a healthy completed run, the observed and committed sequences match, lag is zero, the baseline is ready, and no content-sync job or checkpoint remains active.