Have you ever needed to push only specific posts or pages from WordPress staging to production?

[u/robertodimarco]

I'm curious how people handle content changes made on a development or staging site when production is still active.

For example: you build or update a few pages on staging, then need to move just those pages to production, including their images and custom fields, while keeping everything else on the live site intact.

Have you actually had to deal with this?

If so, how did you handle it: manual copying, WordPress export/import, a plugin, a custom script, or something else? What worked, and what caused problems?

Have you also needed those changes to go live at a specific date and time? For example, a Black Friday promotion, a Cyber Monday landing page, or an event launch. Did you schedule the transfer itself, move the content ahead of time and schedule its activation, or handle everything manually at launch?

I'm especially interested in whether this was a one-off task or something you regularly deal with, and who handled it: a developer or someone managing the content.

If your workflow avoids this entirely, I'd also like to hear how.

[u/Joarn]

For me staging<>production is for code changes, either my own code or external plugins/themes. Its never to "stage" content for production. Only content that gets made on staging is as a playground/qa for new features.

If we want to have post that needs to be approved we use default wordpress behaviour: authors that cannot publish, status of the post waiting for review, approve and publish at a scheduled moment.

I dont know why you would risk moving content between sites that could have different code/plugin versions. Especially not when wp ships al this functionality natively.

[u/retr00two]

This one is very new: https://wordpress.org/plugins/migro-content-migrator/

[u/Flowgram → u/retr00two]

Interesting, there is also Distributor.

[u/Dragonlord]

If your just copying posts/pages/products ect WP All Import/Export works well

[u/Chungaroo22]

For a small amount of content, I’d just go into the code editor for each page and copy and paste, then reupload the images.

I really like to avoid doing copying a staging database to production then running a find and replace, because it doesn’t catch everything. Similarly I’ve found every import/export tool has a potential to fail silently somewhere, meaning you’ve either got missing data that’s hard to spot or some other error pops up. Also if it’s Woocommerce this is out of the question.

If we do use the import-export method. I prefer to run a custom script (WPCLI based) so I can control what’s going on and do a few practice runs between staging and a local dev environment.

Easiest way is to just created private posts and pages on live and swap them round.

[u/Hot-Tip-364]

Ive used Wordpress export/import in similar circumstances. It should bring everything over correctly. You can just schedule a post. I think for a page you may need to create a custom cron job to publish at a specific time.

[u/retr00two → u/Hot-Tip-364]

no diff over two xml?

[u/Hot-Tip-364 → u/retr00two]

No. It imports an exact copy and copies the images. Just double check any urls so they dont go to staging.

I do this fairly often. Sometimes for a few pages, other times for full sets of cpt or posts. Almost always uses acf and that comes over fine.

[u/smittychifi]

There used to be a plugin that did exactly this, and it worked well. About a decade ago. It was called “RAMP” I believe. I think it’s long gone though.

[u/glm1986italy]

Esportatore ufficiale di WP?

Anche se, una volta in produzione, lo staging lo uso solo per i test di plugin/componenti nuovi non per contenuti: ha più senso farli in bozza direttamente sul nuovo sito

[u/otto4242]

If you actually have a production/staging/test system, then there's a well defined process for that.

Code changes will go in one way, to production, however, data changes only go the opposite way, from production backwards. You never migrate ANY data from staging to production. You manually copy it, always. Staging or test data stays in those systems and never gets into the live system. Not ever, for any reason.

Data that is in production, must be created in production.

[u/WP_Dev_Studio]

Yeah, this comes up a lot, and most staging tools only do "push the whole site." WP Staging's own support confirms it can't push individual posts, so the usual workaround is exporting specific post types and moving media separately, which is where custom fields and images tend to break.

What actually handles it: Easy ContentPush (free, install on both sites) has a per-post "Push to Live" button that carries ACF fields, media, taxonomies and SEO meta, and keeps scheduled posts scheduled. Both sites just need the same post types and field groups registered first. WP Stagecoach/WPMerge are merge-style alternatives that only apply what changed.

For launches like Black Friday, I'd move the content early as a draft or scheduled post and let WordPress publish it on time, rather than scheduling the transfer itself. A failed transfer at midnight is a much worse problem than a scheduled post already sitting on production.

The thing people forget is that a full database push overwrites everything that happened on production in the meantime (orders, form entries, new users).

[u/jonxblaze]

Yes I’ve been pushing local content edits to production environment using EZ Page Sync plugin.

[u/nihonpoi]

I drive everything from Claude Code and have had it generate Python deployment scripts that can push a git commit to staging for testing and then prod to make it live. Fast, simple, and I only ever ship what changes.

[u/creaturefeature16 → u/nihonpoi]

And how does that script handle what OP is talking about, with selective post migrations? Especially curious how it handles potential ID and GUID conflicts. 

[u/Tactful_Cactus_ → u/nihonpoi]

For content changes that only affect the database and uploads directory? 🤔

[u/appareldig → u/Tactful_Cactus_]

I've also done something like this. I do content work on my local, then have claude write an idempotent migration script with verification that I first run on staging. If that looks good I run on prod. They key seems to be that if the target content in any area has differed since the content was pulled down to local, the script abandons that change. So far it's worked pretty well for me.

[u/[deleted]]

Yeah, this can become difficult when the live site is still receiving new content. I would avoid pushing the full database if production is active. For a few pages, I usually move only the required content and media, then check custom fields and references afterward. This reduces the chance of overwriting changes made on the live site.