A Senior DevOps Engineer breaks down three real-world methods for safely updating live WordPress sites, moving from risky “cowboy coding” to a professional, automated workflow.

So, You Need to Edit a Live WordPress Site? A DevOps Guide to Not Getting Fired.

I still remember the 3 AM phone call. A junior dev, trying to be helpful, decided to “quickly” edit the functions.php file on a major e-commerce client’s site. Directly. Via FTP. A single misplaced semicolon and a cached version of the white screen of death took the entire site offline during a flash sale. The frantic scramble to restore from a backup cost the client five figures in lost revenue. That’s not a mistake you make twice. That panic is why the question “How do you guys make changes on a live WordPress website?” hits such a nerve for so many of us in the trenches.

First, Let’s Understand Why This Is So Painful

Unlike a modern static site or a decoupled app, a standard WordPress installation is a tightly-coupled monolith. Your code (themes, plugins, core files) lives on the filesystem, but your content and configuration (posts, pages, user data, plugin settings) live in a MySQL database. When you make a change, you’re often touching both. Simply copying files from a staging server to production isn’t enough, because you’ll overwrite any new posts, user signups, or WooCommerce orders that happened on the live site. This conflict between the filesystem and the database is the root of 99% of WordPress deployment headaches.

The Three Paths: From ‘Hold Your Breath’ to ‘Sleep Soundly’

Over the years, I’ve seen and implemented a few different strategies. Let’s break them down from the quick-and-dirty to the truly professional.

Solution 1: The ‘Hold Your Breath’ Method (Quick & Dirty)

This is for emergencies or for sites where a proper staging environment just doesn’t exist. It’s cowboy coding, but with a helmet on. I don’t love it, but sometimes you have to do what you have to do.

1. Engage Maintenance Mode: Use a proper maintenance mode plugin (like WP Maintenance Mode or SeedProd). This shows users a friendly page instead of a broken site while you work.
2. Take a Database Snapshot: Before you touch a single file, SSH into the server and take a database backup. If you have wp-cli installed, it’s a lifesaver.

wp db export live_backup_before_changes_`date +%Y-%m-%d_%H%M`.sql

3. Make Your Changes: Now, and only now, do you make your changes via SFTP or the theme editor (shudder). Whether it’s uploading a new plugin or tweaking a CSS file, do it quickly.
4. Test Immediately: Disable maintenance mode and immediately test the functionality you changed. Clear all server and browser caches.
5. Rollback Plan: If things break, you immediately restore the database and re-upload the original files you changed.

Darian’s Pro Tip: If you manage any WordPress site, demand that your host provide SSH access and wp-cli. Using the command line to manage plugins, users, and backups is non-negotiable. It’s the difference between a 30-second database export and a 10-minute struggle with phpMyAdmin.

Solution 2: The ‘Sensible Adult’ Method (A Proper Staging Workflow)

This is the baseline for any professional project. It involves creating a separate, non-public copy of your site where you can make and test changes safely before pushing them to the live environment. The core principle here is Code moves up, Data moves down.

Your workflow looks like this:

1. Sync Down: Copy the latest database and uploads from Production down to your Staging server. Tools like WP Migrate DB Pro are fantastic for this, as they handle the tricky task of find-and-replace on URLs.
2. Develop & Commit: Make your code changes (theme files, new plugins) on your Local machine and manage them with Git.
3. Deploy to Staging: Push your Git branch and deploy the code to the Staging server. Test thoroughly. Let the client or marketing team review it.
4. Deploy to Production: Once approved, deploy the same Git commit to Production. This is for CODE ONLY. You are not touching the production database (prod-db-01), so you don’t lose any new orders or user data.

Warning: The database is still tricky. If your changes involve new plugin settings or creating a new page in the admin, you might have to manually replicate those specific settings on the production site after you deploy the code. It’s annoying, but it’s safer than a full database push.

Solution 3: The ‘Cloud Architect’ Method (The Read-Only CI/CD Pipeline)

This is how we handle high-traffic, mission-critical WordPress sites at TechResolve. It’s the “nuclear option” because it fundamentally changes how you interact with WordPress, but it’s virtually foolproof.

The core idea: The production server’s filesystem is read-only. You cannot install or update plugins from the WP Admin dashboard. You cannot edit theme files. All changes must go through an automated pipeline.

A simplified workflow:

1. A developer commits a change to a plugin in a Git repository.
2. The commit triggers a GitHub Action (or a Jenkins job).
3. The pipeline automatically runs tests, builds assets (like compiling SCSS to CSS), and bundles the new code.
4. Upon approval, the pipeline securely connects to the production servers.
5. It puts the site into maintenance mode, deploys the new code bundle, runs any necessary database migrations (using wp-cli), clears the cache, and takes the site out of maintenance mode.

A very basic deploy script in the pipeline might look something like this:

# --- Start Deployment to Production ---

# Announce maintenance
wp maintenance-mode activate

# Sync the new code from our build artifact
rsync -avz --delete ./build/wp-content/themes/my-custom-theme/ user@prod-web-01:/srv/www/wp-content/themes/my-custom-theme/

# Run any database updates required by plugins (e.g., WooCommerce)
wp core update-db
wp wc update

# Clear all the things
wp cache flush
wp rewrite flush --hard

# We are live!
wp maintenance-mode deactivate

# --- End Deployment ---

This approach forces discipline. It makes deployments predictable, repeatable, and safe. It’s overkill for a small blog, but for a business that depends on its website, it’s the only way to operate.

So next time you’re about to hit ‘Update’ on a live production plugin, take a deep breath. Think about that 3 AM phone call. Decide if you want to hold your breath, be a sensible adult, or build a system that lets you sleep soundly at night.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions