EZ Page Sync: WordPress Staging-to-Production Sync Plugin

In my last post on pushing WordPress changes from staging to production, I broke down why the usual migration tools are fine for whole-site moves and lousy at pushing one specific page change without collateral damage. I got tired of that gap, so I built around it. The tool’s called EZ Page Sync.

This is the nuts-and-bolts version. If you’re comparing it with WP Migrate, WPvivid, or your own WP-CLI setup, here’s what actually happens between clicking Sync on staging and seeing that page update on production.

What EZ Page Sync Actually Does

Most WordPress migration tools operate at the site level. They dump the database, rewrite URLs, ship the tarball, restore. Whole-site replacement. If production has collected 47 form entries, three WooCommerce orders, and a dozen new comments since you cloned to staging, tough — the migration will happily flatten them.

EZ Page Sync works at the page level. You pick a page or post on staging, click Sync, and only that page — its content, meta, media, taxonomies, and any integration data — is pushed to the matching page on production. Nothing else gets touched. Real form submissions, WooCommerce orders, users, and comments on production stay exactly where they are.

That’s the whole job: push single-page edits from staging to production without dragging the whole site along with them.

The Two-Site Model: Sender and Receiver

You install the same plugin on both sites — staging and production — and assign each one a role:

• Sender runs on staging. It gathers the page data, signs the request, and pushes.
• Receiver runs on production. It verifies the signature, validates the payload, snapshots the current page, and applies the update.

The two sites are linked by a single shared API secret key. You generate the key on one site (Settings → Regenerate Key), copy the exact value into the other, and that’s the authentication layer for every future sync. Both sites hold the identical key. The key is stored encrypted with AES-256-GCM, not in plaintext.

Sync payloads travel directly between your two sites over HTTPS. No relay server. No third-party middleman. Your content stays between the two WordPress installs you control, which is the whole point.

If you need bidirectional sync — say, pulling a hotfix on production back down to staging — you just swap the roles on each site. The shared key already works both ways.

Anatomy of a Single Sync

Here’s what actually happens when you click Sync on a page. Every one of these steps is logged in the Sync Log, and every failure has a specific error code you can look up.

1. Serialize the payload. The Sender collects the post content, title, slug, status, dates, custom meta, ACF fields, taxonomy assignments, and featured/inline media. Media files are base64-encoded and embedded directly in the payload — no separate FTP or filesystem transfer needed.
2. Sign the request. The Sender generates an HMAC-SHA256 signature covering the post ID, a UTC timestamp, a one-time nonce, and a hash of the full payload. That signature is what proves the request came from your staging site and hasn’t been tampered with in transit.
3. Send over HTTPS. Plain-HTTP is rejected outright — no exceptions. Any middlebox that strips TLS will kill the sync before it starts.
4. Verify at the Receiver. Production re-computes the HMAC using its copy of the shared key. Mismatch → rejected as WPS_001. It also checks the timestamp is within a ±5-minute window (WPS_002) and that the nonce hasn’t been used before within its 10-minute TTL (WPS_003). Replayed or forged requests get dropped here before anything is written.
5. Snapshot the current page. Before a single field is touched, the Receiver captures a snapshot of the production page’s current state. Up to five snapshots are kept per post.
6. Apply the update. Content, meta, taxonomies, and media are written to the production database. Media files are matched against the existing library by filename — no duplicate uploads on repeat syncs. Staging URLs found in content and meta are rewritten to production URLs on arrival.
7. Purge caches. WP Super Cache, W3 Total Cache, LiteSpeed Cache, and WP Rocket all get the synced page invalidated automatically, with WordPress’s own post-cache flush as the fallback. If you want more on the caching side of WordPress performance, I covered it in 10 tips for optimizing your WordPress website.
8. Log the result. Success, failure, warnings — every event lands in the Sync Log with a status, duration, destination, and (if it failed) a specific error code.

If anything fails mid-write, the automatic rollback kicks in and restores the snapshot. Production is never left half-updated.

Sync Modes

Not every sync needs the same amount of ceremony. EZ Page Sync gives you a few modes depending on how careful you need to be:

• Full Sync — the default. Content, meta, media, taxonomies, integrations. Use it when you’re publishing a finished page.
• Content Only — just the post body, title, and slug. Perfect for copy tweaks where nothing structural changed.
• Preview — shows the match confidence and any warnings (e.g. a title mismatch on production) without writing anything. Use it to confirm you’re about to hit the right page before you commit.
• Dry Run — runs the entire pipeline end-to-end without a single database write, and returns a diff summary. Use it for high-stakes syncs where you want to see exactly what will change.
• Bulk Sync (Premium) — pushes multiple selected pages in one operation. Handy for coordinated releases.
• Force Sync — explicitly overrides an ambiguous-match warning after you’ve reviewed it. Available on every tier.

Destructive status changes — for example, a sync that would unpublish a live production page — are held back with an explicit warning until you confirm them with a Force Sync. You can’t accidentally take a page dark.

What Gets Synced (and What Never Does)

On the Free tier, page and post content, titles, slugs, status, dates, and URL rewriting are all covered. That’s already enough to run a basic edit-on-staging-publish-on-production workflow.

Premium extends that to:

• All custom post meta (custom fields)
• ACF fields, matched by key with a name-based fallback
• Elementor layouts, including images and Global Widget / Template references remapped to production IDs
• Astra theme meta
• Yoast SEO meta fields
• Taxonomy assignments across every registered taxonomy
• Featured images and inline media attachments
• Custom post types (Free covers page and post)

What never gets synced — WordPress housekeeping meta is excluded automatically. That means _edit_lock, _edit_last, _wp_old_slug, _wp_old_date, _pingme, _encloseme, and the plugin’s own internal sync-tracking keys stay untouched. If you have your own meta keys you want excluded, you can add them in Settings.

Media is where a lot of WordPress workflows get annoying fast. Instead of giving production filesystem access to staging, EZ Page Sync bundles the media into the payload itself, base64-encodes it, and matches files against the production media library by filename when they arrive. Existing attachments are reused. A single Overwrite Existing Media setting decides what happens on filename collisions.

Snapshots and Rollback

Every sync captures a pre-sync snapshot of the target page’s current state on the Receiver. That snapshot is the escape hatch when something goes wrong — and something eventually will.

Rollback works two ways:

• Automatic — controlled by the Auto Rollback on Failure setting, on by default, available on every tier. If a sync fails partway through — a database write error, an invalid payload, a media upload glitch — the page is restored from the snapshot immediately. Production is never left half-updated.
• Manual (Premium) — the Rollback Manager tab lists stored snapshots for any page and lets you restore any of them with one click, even days after a “successful” sync you’ve changed your mind about.

Up to five snapshots per post are kept. Free tier retention is 30 days; Premium extends that. Rolling back never touches media files — only post data is restored, so your uploads directory doesn’t move.

The Security Model

This is the part that matters if you’re even thinking about pointing a tool like this at production.

• HMAC-SHA256 request signing. The signature covers the post ID, timestamp, nonce, and a hash of the full payload. A request can’t be forged or tampered with in transit without invalidating the signature.
• Replay protection. Each request carries a one-time nonce with a 10-minute TTL — reuse the same nonce and the request is rejected (WPS_003). The timestamp must also fall within a ±5-minute window (WPS_002), which is why clock drift on either host is a real problem worth watching for.
• HTTPS enforced. Plain-HTTP is rejected outright (WPS_013). No downgrade path.
• Rate limiting. The Receiver accepts at most 60 sync requests per hour per sender IP (WPS_005). Health-check pings don’t count against the limit.
• IP allowlist (Premium). Restrict the Receiver to known sender IPs, with CIDR ranges for IPv4 and IPv6. Forwarded-IP headers are only trusted from your configured Trusted Proxy IPs — no header-spoofing attack surface.
• Encrypted key storage. The API Secret Key is stored with AES-256-GCM authenticated encryption on both sites. Not plaintext in wp_options.
• WordPress capability checks. Every admin action requires the appropriate capability and is nonce-protected. The plugin doesn’t invent its own permission model — it uses WordPress’s.

And this is the big one for me: your sync traffic moves directly between your own two sites. No relay server. No third party touching your content.

Free vs. Premium — the Honest Split

Free isn’t a teaser tier. If you’ve got one staging site, one production site, and you just need to move page and post edits between them, the Free version does that and keeps doing it. No time limit. No forced downgrade nonsense.

Premium is for when your setup gets more complicated:

• More than one destination (staging → pre-prod → production, or multi-site publishing)
• Running both roles on a single site at once (for relay chains)
• Custom post types beyond page and post
• ACF, custom meta, Yoast, taxonomy, media, and Elementor sync
• Astra theme meta
• Bulk sync
• IP allowlist
• Rollback Manager UI
• Extended log retention and CSV export
• Role-based settings access

If a Premium license lapses, nothing gets deleted — configuration beyond the Free caps just goes inactive until the license is active again, then reactivates automatically. No data loss, no ransom.

WordPress and Hosting Requirements

• WordPress 6.9+ on both sites
• PHP 8.1+
• MySQL 5.7+ or MariaDB 10.3+
• HTTPS on both sites (plain-HTTP syncs are rejected)
• The plugin installed and activated on both staging and production
• Advanced Custom Fields is optional and auto-detected — if you sync ACF fields, ACF must be active on both ends
• WordPress Multisite is not currently supported

Installing and Connecting Two Sites

EZ Page Sync isn’t distributed through the WordPress.org plugin repository — you install it by uploading the plugin zip directly (Free downloads from ezpagesync.com, Premium builds are delivered through your Freemius account). The full walkthrough lives in the docs, but the setup is pretty straightforward:

1. Install and activate EZ Page Sync on staging and production.
2. On the Settings tab of each site, pick a role — Sender on staging, Receiver on production.
3. Regenerate the API Secret Key on one site, copy the exact value into the other.
4. On the Sender, add the Receiver’s full site URL under Destinations.
5. Click Test Connection on the Sender. If it comes back green, you’re ready.
6. Head to the Sync Pages tab, pick a page, and hit Preview or Sync.

That’s basically it. First-time setup is usually about five minutes, and most of that is just generating the key and pasting it into the other site.

Where EZ Page Sync Fits in Your WordPress Workflow

If your current WordPress deploy workflow is working and you’re not babysitting it every time, keep using it. Migration plugins and WP-CLI pipelines are still perfectly fine for whole-site moves.

But if you’re updating pages on staging every week and the push-to-production part is where things start feeling sketchy, this is the problem EZ Page Sync is built for: page-level sync, signed transport, automatic rollback on failure, no relay server, and a free tier that handles single-destination page and post pushes.

Download the Free version and run it on a staging site you already control. You’ll know pretty quickly whether it fits the way you work. If you need custom post types, ACF, or multi-destination sync, that’s where the Premium tier comes in.

If you want a straight answer on whether it’d fit your WordPress setup, get in touch. I’m happy to talk through the edge cases before you waste time testing the wrong thing.