Don't Rebuild in Production: How to Manage WordPress Changes

Category: WordPress

A small text change can usually be published directly. A new form solution, an update to multiple plugins or a rebuild of page templates should, however, be tested before customers see the result. Even so, many WordPress changes are treated as if they carry the same level of risk: Some make every change directly on the website, while others move the entire database back and forth between testing and production.

Both approaches can cause problems. Direct changes can create visible errors, while indiscriminate database transfers can overwrite new enquiries, orders and editorial work. The business therefore needs a simple change model that specifies what can be done where, who approves it, and how the change is deployed to production.

Start with three types of changes

The most important thing is not to build a complicated development process. It is to distinguish between changes with different levels of risk. A practical classification is content, configuration and code.

1. Content

This normally includes text, images, links, documents and existing Gutenberg blocks. Such changes can often be made directly in production, provided the editor can preview the page and follow a simple review routine.

The exception is major restructuring. If a central service page is to be completely rebuilt, it may be safer to create a draft, duplicate the content or work within an agreed time frame. The aim is to prevent an unfinished page from becoming available or multiple editors from changing the same content at the same time.

2. Configuration

Configuration includes settings for themes, plugins, forms, analytics tools, access control, payment solutions and caching. These choices are often stored in the WordPress database. As a general rule, they should be tested in a separate environment before being applied in production.

A seemingly minor setting can affect the entire website. Changes to permalinks, image processing, form notifications or caching can affect pages that were not part of the task.

3. Code and structure

Changes to themes, blocks, integrations, templates and custom-developed functionality should be developed and tested outside production. The files should be version-controlled so the team knows what has changed and can revert to an earlier state.

This category also includes changes that appear visual but are actually structural: new page templates, a changed main menu, new content types or a rebuild of Gutenberg patterns.

Use the environments for different purposes

A well-organized WordPress setup usually has a production environment and at least one test environment. For more extensive development, it is also useful to have a separate local development environment.

• Production: The website customers use. Approved content and fully tested changes are published here.
• Test environment: A controlled copy where updates, configuration and new features are tested before launch.
• Local development environment: The workspace for code changes, troubleshooting and technical development.

The test environment must resemble production closely enough for the testing to be meaningful. Using the same PHP setup, core plugins, theme and relevant integrations reduces the risk of something working in testing but failing after launch.

At the same time, the test environment must not indiscriminately send email, process real payments or transfer data to external systems. Such connections should be disabled, replaced with test modes or directed to dedicated test accounts.

Don't move the entire database without a plan

WordPress stores both content and many technical settings in the database. This makes migration more complicated than copying a few files. If the production database is replaced with an older copy from the test environment, new work may disappear.

This may include:

• new or updated pages and posts
• form submissions stored in WordPress
• new users and changed permissions
• orders and customer data in WooCommerce
• comments, registrations or other submissions
• settings changed after the test copy was created

The team should therefore clarify what is to be moved back before work begins. Code files can often be deployed in a controlled manner without replacing the content. Database changes must be handled more selectively, documented or repeated manually in production.

For larger launches, a short content freeze may be sensible. The organization then agrees to limit editorial changes and submissions during a specific period. For an active online store or a website receiving many enquiries, full database replacement is rarely a responsible standard method.

Gutenberg Requires a Clear Migration Plan

Gutenberg makes it easy to build pages, but the distinction between content and functionality is not always clear. A standard text block is content. A custom-developed block may depend on code in the theme or a plugin. A synchronized pattern may be stored in the database, while a template may be tied to the theme setup.

Before a Gutenberg change is deployed to production, you should therefore clarify:

1. Is this standard page content, a pattern, a template or a custom block?
2. Is the necessary code already available in production?
3. Will the change affect existing pages that use the same pattern or template?
4. Can editors still update the content without breaking the layout?
5. Does content need to be moved, or can it be built in a controlled way in production after the functionality has been launched?

A robust solution is often to launch blocks, styles and templates first. The editorial team can then build or update content using the finished components. This reduces the need for risky database synchronization.

Create a standard production deployment checklist

A change is not finished simply because it works on the developer’s screen. It must be checked in the right context. The checklist does not need to be long, but it should be used consistently.

Before the change

• Describe what will be changed and which pages or features may be affected.
• Take an up-to-date backup that can actually be used for rollback.
• Clarify who approves the functionality, content and visual result.
• Decide whether editorial work must be paused during the launch.
• Define what triggers a rollback.

During deployment

• Move only the files, settings or content elements that are necessary.
• Record the changes in a simple change log.
• Clear relevant caches in a controlled manner.
• Avoid combining several unrelated changes in the same deployment.

After deployment

• Test the most important pages on mobile and large screens.
• Submit a real test response through key forms.
• Check login, search, navigation and any purchase flows.
• Look for visual shifts and unexpected errors.
• Check that performance has not noticeably deteriorated.

Testing should be based on customer journeys, not just individual technical features. If the change concerns a contact form, you should follow the entire process from the landing page to the notification and confirmation being received.

Separate maintenance from development

Updating WordPress, the theme and plugins is ongoing maintenance. New templates, integrations and features are development. When these are combined in the same delivery, it becomes harder to identify the cause if something goes wrong.

A practical approach is to have dedicated maintenance windows for updates and separate production deployments for functional changes. Critical errors may naturally require faster action, but routine work should be planned.

Updates should first be tested in the staging environment, with particular attention to forms, Gutenberg editing, login, search, integrations and e-commerce functionality. After updating production, repeat a brief check. This is more useful than simply confirming that the administration area still opens.

Assign one person responsibility for the decision

A good technical solution is of little help if no one owns the process. The company should have a named person who can approve production deployments, coordinate the editorial team and assess whether the change should be implemented or postponed.

This does not mean that the same person should develop, test and approve everything. The point is to ensure that the decision does not fall between the web agency, IT department, marketing department and suppliers.

For every change, it should be possible to answer four questions briefly: What will be changed? Where has it been tested? Who approved it? How do we roll back if the result is not as expected?

A simple rule that prevents many problems

Direct publishing is suitable for limited, low-risk content changes. The staging environment is suitable for updates, configuration and functional changes. A local development environment is suitable for code and technical troubleshooting.

What matters is not how many environments the company has, but that everyone understands what they are for. When changes are classified, the database is handled carefully and deployment follows a standard checklist, WordPress becomes easier to maintain without making customers serve as test subjects.