Somebody on your team just finished a page in staging and now wants it on the live site without dragging the rest of the unfinished work along. Or you built a landing page on a client’s development install and need it on their production domain by Friday. Either way, the question is the same: can you actually push one specific page from one WordPress install to another, or are you stuck exporting the whole database and hoping nothing breaks along the way?
Short answer: yes, you can move a single page (or a handful of pages) between WordPress sites, and there are several ways to do it depending on how much control you want and how much risk you’re willing to accept. The long answer is that “just the page” is rarely just the page, it drags featured images, Advanced Custom Fields data, shortcodes that reference plugins the target site might not have, and internal links that quietly point back to the wrong domain. Below is what actually works, what breaks, and how to pick the right method for your situation.
Why This Is Harder Than It Sounds
A WordPress page isn’t really one thing. In the database it’s a row in wp_posts, but that row is surrounded by dependents: rows in wp_postmeta for every custom field, template setting, and SEO plugin value; a featured image reference that points to an attachment ID that may or may not exist on the target site; taxonomy relationships if the page uses categories or custom taxonomies; and possibly Gutenberg block markup that references block-specific attributes tied to a particular plugin version.
Move the page without its dependents and you get a page that loads with missing images, a blank hero section because the page builder’s meta didn’t come along, or raw shortcode text sitting on the front end instead of rendered content. This is the actual reason “just copy the page” trips people up, not because WordPress makes it deliberately difficult, but because a page is a small ecosystem, not a standalone file.
Method 1: WordPress’s Native Export/Import Tool
Tools >> Export in wp-admin lets you export specific content types, including individual pages, as a WXR file (an XML format WordPress invented for this exact purpose). On the target site, Tools >> Import >> WordPress reads that file back in.
What this actually captures well: the page content itself, its title, slug, publish date, author (matched by username or reassigned), and standard taxonomy terms. It also brings along the featured image and any inline images referenced in the content, downloading them fresh onto the target site during import rather than assuming they already exist there.
What it tends to miss or mangle: postmeta added by third-party plugins isn’t guaranteed to survive the round trip. Page builder data (Elementor, Divi, Beaver Builder) is stored almost entirely in postmeta as serialized arrays, and while the core WXR importer does bring meta fields across, plugin-specific data that references internal IDs (other posts, other pages, image attachment IDs baked into the builder’s JSON) can point to IDs that don’t match anything on the destination site. The page builder loads, but a background image or a linked button silently fails.
Practical fix: after importing, open the page in its builder on the destination site and manually re-save it once. Most builders re-resolve their internal references on save, which cleans up phantom image links. It’s a five-minute step that avoids a much longer debugging session later.
Method 2: Migration Plugins Built for Selective Content
If you’re doing this more than once, a dedicated plugin earns its keep. A few options handle single-page or selective migration more gracefully than the stock exporter:
- WP All Import / WP All Export, built around CSV and XML pipelines with field mapping, so you control exactly which meta keys transfer and how they’re renamed on the way in. Overkill for one page, genuinely useful if you’re moving pages regularly between a staging and production environment with slightly different plugin stacks.
- All-in-One WP Migration, normally thought of as a full-site tool, but its extension ecosystem includes selective export by post type and by specific post IDs, which lets you scope an export down to exactly the pages you need.
- Duplicator, primarily a full-site packager, but useful if the “single page” actually needs its supporting infrastructure (a custom post type, specific plugin settings) moved alongside it. Not the right tool if you genuinely want just one page and nothing else.
The common thread with all three: they give you a mapping step where you can see what’s about to move and adjust it before committing, which the native exporter doesn’t offer. That visibility is worth the setup time if page migrations are a recurring task rather than a one-off.
Method 3: Staging-to-Production Selective Push (Managed Hosts)
If your host runs a proper staging environment, WP Engine, Kinsta, Flywheel, and Pressable all offer this, you may have access to a “selective push” or “smart push” feature that lets you choose specific files and specific database tables to sync from staging to live, rather than the entire environment.
This is genuinely the cleanest method when it’s available, because the host’s push logic already understands how to reconcile IDs between the two environments instead of blindly overwriting. The catch is granularity: most hosts let you push by table, not by row, so pushing “the posts table” from staging to live will overwrite every post and page currently on the live site with whatever’s in staging, not just the one page you edited. Read your host’s documentation on this carefully before pushing, because a table-level push executed carelessly can undo unrelated content changes that happened directly on production while you were working in staging.
The safer pattern here: build and finish the page in staging, then use the host’s file-and-media push (safe, additive) but handle the actual page content by copying it manually, either through the block editor’s copy-all-blocks feature (select all content in the editor, copy, paste into a new page on the live site) or through the export/import method above for the single page, rather than a full database table push.
Method 4: The Editor Copy-Paste Trick (Underrated for Simple Pages)
For pages without complex page-builder data, this is the fastest option and the one most people overlook. Open the page in the WordPress block editor on the source site, select all blocks (Ctrl/Cmd+A), copy them, then open a new page on the target site and paste. WordPress’s block editor serializes blocks into a portable format on copy, and pasting into another WordPress install (even a completely unrelated one, as long as it’s a reasonably current version) reconstructs the blocks correctly, including embedded images, which get uploaded fresh to the target media library automatically.
Limitations: this only captures the content in the editor canvas. It won’t bring page-level settings like a custom page template, featured image, SEO meta title and description, or ACF fields that live outside the standard content area. You’ll need to set those manually on the new page. For a simple content page, blog-post-style content, no exotic layout, this is often faster than any export/import workflow, and it sidesteps ID collision problems entirely since nothing references internal database IDs.
Method 5: Direct Database Work (For People Who Are Comfortable With SQL)
At the far end of the control spectrum, you can query the source database directly, pull the relevant row from wp_posts along with its associated rows in wp_postmeta, and insert them into the target database. This is the method with the most control and the most ways to shoot yourself in the foot.
The core problem is IDs. Every post, attachment, and term in WordPress is referenced by a numeric ID, and that ID is almost certainly already taken by something else on the target site. Insert a row with ID = 42 and your target site probably already has a post 42 that you’re about to silently step on, unless you let the target database auto-assign a fresh ID. Once you do that, though, every piece of postmeta that references the old ID, internal links, gallery shortcodes referencing image IDs, ACF relationship fields, needs updating to the new ID, and shortcode-embedded IDs in serialized PHP arrays are especially unforgiving: change the string length of a serialized value without recalculating its byte-length prefix and PHP’s unserializer throws an error rather than gracefully degrading.
Recommendation: don’t do this by hand unless you genuinely understand serialized PHP data and are prepared to use a proper search-and-replace tool (WP-CLI’s wp search-replace command handles serialized data safely) rather than a plain text find-and-replace, which corrupts serialized arrays almost every time.
Watch Out For These Four Things Regardless of Method
Attachment IDs and the media library. Images referenced by shortcode or gallery block often store the numeric attachment ID rather than the URL. If that ID doesn’t exist on the target site, the image silently disappears from the front end even though the page itself loads fine. Always re-check every image and gallery block after a migration.
SEO plugin meta. Yoast, Rank Math, and All in One SEO all store their own custom fields in postmeta, focus keyword, meta description, canonical URL override, social sharing image. These are frequently the first thing to get dropped in a partial export because they’re plugin-specific rather than core WordPress fields. Check the SEO tab on the moved page before publishing.
Internal links baked into content. If the source page links to other pages on the source domain by full URL rather than relative path, those links keep pointing to the old site after the move. A find-and-replace pass on the domain, run through WP-CLI’s search-replace to keep serialized data intact, catches this.
Redirects for SEO continuity. If the page existed publicly on the source site and is being retired there in favor of the new location, set up a 301 redirect from the old URL to the new one. Skipping this step is how a page that’s ranked well for months quietly loses its search position because Google now sees the old URL as gone with nothing pointing to where the content actually lives.
A Worked Example: Moving a Landing Page From Staging to Production
Say you built a new pricing page on a staging subdomain using the block editor with a handful of ACF fields controlling the pricing table. Here’s a workflow that’s held up well across a few dozen client migrations:
- On the staging site, open the page and confirm which ACF field groups are actually populated. Note the field group name so you can check it survived the move.
- Export just that page through Tools >> Export, selecting the specific page rather than “all content.”
- Before importing on production, check whether the ACF field group itself (the definition, not the data) already exists there. If the field group was created directly in staging and never synced to production as a JSON field group definition, the data will import but the fields won’t display correctly in the editor, even though the raw postmeta is technically present.
- Import the WXR file on production, assigning the author to an existing production user rather than creating a new one.
- Open the imported page immediately and check the featured image, ACF fields, and any embedded images. Re-upload anything missing before it becomes a “someone will notice eventually” problem.
- Check the SEO plugin tab. If focus keyword and meta description didn’t carry over, that’s usually because the SEO plugin uses a different postmeta key prefix on production (different plugin version, or Yoast vs Rank Math) than what was exported.
- Set the page live, then check Google Search Console a few days later to confirm it’s being crawled correctly if this page replaces an already-indexed URL.
The reason to check ACF field group definitions specifically is one of the more common failure points in page migrations: WordPress happily imports the postmeta values (the data sitting in the fields), but if the target site’s ACF setup doesn’t know those fields exist as a structured group, the values sit in the database orphaned, invisible in the admin editor even though they’re technically there and will still render on the front end if the theme template calls them directly. This is confusing to debug because the page can look completely broken in wp-admin while displaying perfectly on the live front end, or the reverse.
Using WP-CLI for a Cleaner, Scriptable Move
If you have SSH access to both environments, WP-CLI offers a more controlled path than clicking through the admin UI, especially if you need to repeat the same move across multiple pages or multiple client sites with an identical structure.
A typical pattern: export the specific post with wp export --post_type=page --post__in=123 on the source, which generates a WXR file scoped to that one page ID. Transfer the file to the target server, then run wp import that-file.xml --authors=create on the destination. Follow immediately with wp search-replace 'staging.example.com' 'example.com' --skip-columns=guid scoped to the imported content if the page contains any hardcoded internal links pointing back to the source domain. The --skip-columns=guid flag matters here: WordPress uses the GUID as a permanent identifier and changing it after the fact can create duplicate-content confusion for feed readers and some caching layers, so it’s generally left alone even when the domain in visible content and links gets updated.
This approach is worth the setup time specifically because wp search-replace is serialization-aware. It correctly recalculates the byte-length prefixes in serialized PHP arrays when it changes a string inside them, which is precisely the operation that corrupts data when done with a manual find-and-replace in a text editor or database GUI. If your page’s page-builder or ACF data contains any serialized arrays referencing the domain (surprisingly common in exported page builder settings), this is the safe way to fix them.
Common Questions People Run Into
Will moving a page break its comments? Comments are tied to the post ID, and if you’re using the native export/import tool, WordPress does bring comments along as part of the WXR file, reassociating them with the newly created post ID on the target site. If you’re doing a direct database copy without care, comments referencing the old post ID by foreign key will need that reference updated manually or they’ll orphan.
What happens to the page’s URL slug if something with that slug already exists on the target site? WordPress appends a numeric suffix automatically (page-name-2) rather than overwriting the existing page, which is safe but might not be what you want if the intent was actually to replace an existing page. Check for slug collisions before importing, and rename or delete the conflicting page on the target site first if replacement is the goal.
Does the page’s revision history come along? No, not through standard export/import. Revisions are typically excluded to keep the export file size reasonable. If revision history matters for compliance or editorial reasons, a full database-level migration (or at minimum, a targeted SQL export of the wp_posts rows where post_type = 'revision' and the parent ID matches) is the only way to preserve it.
Can I push a page from a subdirectory multisite install to a standalone WordPress site? Yes, the underlying database structure is the same regardless of whether the source is a multisite subsite or a standalone install, the export tool doesn’t care about network context, it just pulls the post data for whichever site ID you’re currently working within.
Which Method Should You Actually Use?
For a one-off, simple content page: use the block editor copy-paste trick, then manually set the featured image and SEO fields. Fastest path, fewest moving parts.
For a page built with a heavy page builder (Elementor, Divi) that needs to move intact: use WordPress’s native export/import for that specific page, then open and re-save it in the builder on the destination site to resolve any dangling internal references.
For recurring migrations between staging and production on a managed host: use the host’s selective push for files and media, and handle the actual content transfer through export/import or copy-paste rather than a blanket database table push, to avoid overwriting unrelated production changes.
For bulk or repeated page migrations with custom field mapping needs: invest the setup time in WP All Import/Export, since the field-mapping control pays for itself after the second or third migration.
For anyone comfortable with SQL and WP-CLI: direct database work gives full control, but only use wp search-replace for domain and ID updates, never a plain text editor, or you’ll corrupt serialized data and spend the afternoon debugging a white screen instead.
None of these methods are wrong. They trade off differently between speed, safety, and how much of the page’s supporting data actually survives the trip. Pick based on how complex the page is and whether you’re doing this once or as a repeated part of your workflow.
Interesting Reads:
How To Convert A WordPress Site To A Static HTML Website
Should Business Continuity Plan Be Applied To A WordPress Site