WordPress & Web Development / Deployment guide
Before pushing a WordPress staging site live, identify exactly which files, database content, and environment settings the deployment will replace. Keep newer live orders, users, submissions, and posts intact. Test the intended change on staging, prepare a current recovery point, deploy the smallest complete change, and verify production workflows afterward.
A successful preview does not make every push option safe. Staging is a separate copy: production may have collected new data while you were testing. This checklist helps a site owner or developer decide what should move and what must remain authoritative on live.
“Does this action replace live data, or merge the particular changes I need?” If you cannot answer that from the tool’s documentation and deployment preview, stop before confirming the push and ask the host or implementer.
01 / Understand why a copy is not a merge
WP Engine’s environment-copy documentation warns that pushing the entire database overwrites production and can lose newer orders or users. WordPress.com’s staging-sync guidance gives the same practical example: an order placed after the staging copy was created can disappear when the older database is copied back.
Hypothetical example: you clone a shop on Monday, redesign a product page on Tuesday, and prepare to deploy on Friday. Live has continued accepting purchases. A full database replacement can move the design while also restoring Monday’s view of the business. The desired layout change and the unwanted data rollback arrive together.
This applies beyond stores. Comments, memberships, form entries stored by plugins, stock adjustments, and editorial changes can all diverge between copies. Identify every system that writes to the live site during the work.
A backup is a recovery tool, not an automatic merge engine. Restoring it later may also remove activity recorded after that backup. Our WordPress export versus full backup guide explains recovery coverage; here, the goal is to avoid replacing current production data in the first place.
02 / Classify the change before choosing a push
Write a short change list. Separate code, uploaded assets, database content, and environment configuration. A visible edit may involve more than one layer.
| Change | Likely items to investigate | Deployment question |
|---|---|---|
| Custom theme or plugin code | Changed files, dependencies, possible database updates | Can the tested code be deployed without replacing content? |
| Page-builder layout | Page data, metadata, templates, global settings, media | Is there a supported content or template transfer method? |
| New image or download | Asset file and its WordPress references | Will both the file and its relationships arrive? |
| Plugin setting | Database options or plugin-specific storage | Can the exact setting be reapplied without replacing unrelated options? |
| Host configuration | Runtime, redirects, cache, access restrictions | What does this host copy or retain? |
Kinsta’s push documentation illustrates the available distinctions: files only, database only, selected files or tables, and everything. It also lists page-builder layout changes as database-related. Copying theme files alone is therefore not a general solution for moving a redesigned page.
For Elementor, check the supported template import and export workflow and its plan-dependent options. Determine whether your transfer includes global styles, dependencies, and the assets required by the page. Rehearse the result rather than assuming a template is a complete site copy.
Selected tables still require dependency knowledge
A table selection is not necessarily a record-level merge. Several features can share tables, and a single feature can depend on several tables. WooCommerce’s High-Performance Order Storage documentation describes dedicated order tables; storage mode and extensions affect the data relationships you must preserve.
Do not use a generic “exclude these tables” list as your entire deployment plan. Have the developer identify the actual schema, authoritative data, and dependencies. A code update that requires a schema change also needs a tested update procedure, even when the deployment leaves the existing database in place.
03 / Isolate staging from real customers and services
Check staging controls immediately after cloning, before running test actions. A copied API credential or destination address can still connect the clone to a real external service. Treat each integration as a separate item to inspect.
- Access: use the host’s supported restriction mechanism and give reviewers appropriate access.
- Payments: confirm sandbox or test credentials and the selected gateway mode.
- Email: capture test messages or route them to controlled recipients.
- Integrations: inspect CRM, shipping, accounting, newsletter, and automation destinations.
- Scheduled work: check renewals, imports, exports, and other background jobs.
WooCommerce’s test-order documentation notes that test orders can trigger emails and appear in analytics. A successful sandbox payment alone does not establish that every side effect is isolated.
WooCommerce Subscriptions has its own staging detection, but its documentation explicitly warns that email managed by WordPress, WooCommerce, or other plugins may still be sent. Verify the actual protections instead of treating “staging” as a universal off switch.
Also check webhooks. WooCommerce documents event notifications that can invoke behaviour on another system when orders or customers change. Point tests at a supported test destination or pause the staging integration through its documented controls.
Document which restrictions, test keys, email overrides, and job controls belong only to staging. Before deployment, identify whether any of them are included in the selected files, settings, or database content.
04 / Rehearse the release and recovery plan
Record the staging copy date and compare it with recent live activity. If you refresh staging from production, preserve your work first: a refresh can overwrite the changes you were preparing to ship. Use the supported workflow for your host and development setup.
Test the proposed deployment method, not just the final page appearance. If you intend to import a template, rehearse that import into a disposable copy. If you intend to update a plugin, test the same version and relevant database-update steps. Keep a record of the exact release you approved.
Choose checks based on the affected business process. A header change needs navigation and mobile checks; a checkout extension needs cart, payment-state, order, notification, and account checks. Confirm that the code works with the production runtime and required dependencies.
Prepare a fresh, usable recovery point for the live site and confirm who can restore it. Identify what happens to new activity if rollback becomes necessary. For a file-only release, reverting the changed code may be preferable to restoring an older database, provided the code and schema remain compatible.
Where deployment requires replacing or migrating changing data, agree a maintenance window and a deliberate method for controlling writes. A maintenance page alone should not be assumed to stop API requests, background jobs, or external payment notifications. The implementer must account for the channels your site actually uses.
05 / Deploy with a clear source and destination
Read the confirmation screen slowly. Verify the source, destination, selected files, selected database content, and configuration effects. “Push” and “pull” are labels relative to the tool you are using; confirm the actual direction.
- The approved staging change and version are identifiable.
- The destination is the intended live site.
- Current live data will remain intact or has an explicitly tested migration plan.
- Recovery access and the release owner are available.
- Staging-only settings are excluded or have a documented production replacement.
- The selected operation matches the rehearsed method.
Check more than the files/database toggles. Kinsta documents environment-setting effects during pushes, while WP Engine separately documents how its copy tool handles configuration. Host implementations differ; do not assume a “files only” label describes every consequence of the operation.
For URL changes, use the host’s or application’s supported migration handling. Check for references to the staging hostname in links, media, callbacks, and generated assets. Avoid an improvised database-wide text replacement: the right procedure depends on the data format and application.
Deploy one defined release and wait for the operation to complete. If it reports an error, inspect the actual destination and tool logs before repeating it. A timeout does not reliably tell you whether a copy completed, partly completed, or never started.
06 / Verify production beyond the homepage
Check the live URL in a fresh browser session and as an authorised user where the feature requires it. Clear relevant caches through supported controls after deployment, then confirm you are seeing the new release. A cached screenshot can conceal a failed change.
| Area | What to confirm | Useful evidence |
|---|---|---|
| Content and design | Changed pages, navigation, media, mobile layout | Live URLs and a short review record |
| Recent data | Known pre-deployment orders, users, or submissions still exist | Reference IDs checked without exposing personal data |
| Business workflow | Forms, account access, and affected transactions behave correctly | Controlled checks and relevant logs |
| Production settings | Correct gateway mode, email destination, integration endpoints, and job controls | Configuration reviewed by the owner |
| Public discovery | Expected indexing behaviour, canonical URLs, and redirects | Page source, response headers, and URL checks |
Do not switch a live gateway into test mode just to repeat staging tests. Follow the payment provider’s documented production-verification procedure. Confirm both the customer-facing result and the internal record or notification that should follow it.
Check that staging access restrictions, temporary maintenance controls, or unintended noindex directives did not reach live. Equally, ensure the staging environment retains its own intended protections after the release. These are different destinations with different purposes.
If acceptance checks fail, stop further changes and use the recovery plan. Preserve the error details and reconcile any activity received during the deployment or recovery interval. Repeated full restores can make that reconciliation harder.
07 / Record the release and refresh staging deliberately
Keep a concise record of the change, release time, deployment scope, operator, recovery point, verification results, and any outstanding issue. This gives the next maintainer a concrete starting point if a problem appears later.
Once the release is accepted, decide when to refresh staging from live. Preserve any unfinished work first and recheck integration isolation after cloning. Do not allow an old staging copy to become the unquestioned source for the next deployment.
The repeatable process is simple to describe: classify the change, rehearse its transfer, protect current data, deploy the intended scope, and verify the live workflow. The exact buttons and migration mechanism should come from your host and the applications involved.
Frequently asked questions
Can I push the entire staging site live?
Sometimes, such as before a site has launched, but first confirm that replacing destination content is intended. An active site needs explicit handling for every newer live record and relevant configuration.
Will a files-only push move Elementor page edits?
Do not assume so. Page-builder layouts commonly involve database content. Use a supported content-transfer method and verify templates, global settings, and media dependencies.
Does refreshing staging immediately before deployment prevent data loss?
It reduces the age of the copy but does not stop live from changing afterward. It can also overwrite staging work. A refresh needs a controlled workflow, not just a recent timestamp.
Is a backup enough to make a database push safe?
No. It provides a recovery option, but replacement and restoration can both lose later activity. Confirm the deployment’s data handling and recovery consequences before pushing.
List the exact changes you want to release and the live data that must survive. Review the deployment tool’s replacement behaviour, then rehearse the smallest complete transfer before confirming the production operation.
Sources and editorial notes
Primary documentation from WordPress.com, Kinsta, WP Engine, Elementor, and WooCommerce was checked on 24 October 2026. Host tools and subscription features differ. The shop timeline is hypothetical; this guide does not claim a hands-on deployment test or a universal table-exclusion recipe.
Add comment