WordPress makes updates easy by design — one click per plugin in the dashboard, or automatic background updates if you’ve enabled them. “Manually updating” means bypassing that built-in flow, and there are three common reasons to do it: the dashboard updater fails mid-process and leaves the site in maintenance mode, your hosting configuration disables the FTP filesystem access the dashboard updater needs, or you’re managing a staging environment not connected to the WordPress.org update server.
Whatever the reason, the methods are straightforward. What matters is the sequence — backup and changelog check first, update second, verification third.
Before you update: backup and changelog
Read the changelog before touching anything. Every plugin in the WordPress.org repository has a changelog tab on its plugin page — scan it for the phrases “breaking change,” “minimum PHP version,” “WooCommerce compatibility,” or “migration required.” A breaking change means the plugin’s API changed in a way that may require theme or code updates alongside the plugin update. Finding that after the fact is significantly worse than finding it before.
For premium plugins not in the repository, the changelog is typically in the plugin vendor’s account dashboard or their release notes page. Check it regardless.
After reading changelogs, take a backup — not “schedule a backup,” but run one manually right now with WPVivid or UpdraftPlus and wait for it to complete. An automated daily backup that ran 20 hours ago is not a useful restore point if a plugin update introduces a fatal error at hour 21. Confirm the backup file exists in remote storage (Google Drive, Dropbox, or S3) before proceeding. If anything goes wrong, this backup — not yesterday’s — is what you’ll restore from.
If the site is on a live production domain, consider testing the update on a staging copy first. See how to create a WordPress staging site for the process. For routine plugin updates on a stable site, a manual backup is usually enough — staging first makes more sense for major version jumps, or plugins that modify the database schema (WooCommerce, membership plugins, table-creating plugins).
Update order when doing multiple updates: plugins first, then themes, then WordPress core. The reverse is where conflicts usually surface — a core update can expose a compatibility issue with an outdated plugin, but updating the plugin first removes that problem.
Method 1: WordPress dashboard (one plugin at a time)
The dashboard updater is the standard path. “Manual” here means updating one plugin at a time rather than bulk-updating everything at once — the discipline that makes it straightforward to identify which plugin caused a problem if one does.
Go to Plugins → Installed Plugins. Hover over any plugin showing an “Update Available” notice and click “Update Now.” Wait for the “Updated successfully” confirmation before moving to the next plugin. On a site you haven’t updated in a while, check the frontend between updates — a plugin that was silently incompatible with another is much easier to identify when you know exactly which update introduced the break.
If the update button is absent or greyed out, two things typically cause this: WordPress can’t write to the filesystem (add define('FS_METHOD', 'direct'); to wp-config.php if you’re on a VPS with correct file ownership), or a premium plugin’s license key isn’t validated (commercial plugins validate via API before enabling update delivery). Resolve those before switching to FTP.
Method 2: FTP via FileZilla
FTP is the fallback when the dashboard isn’t accessible — a fatal error is showing, wp-admin is returning a 500 error, or you’re doing a handover where you have server credentials but not dashboard access.
Download the plugin zip from wordpress.org (Advanced View → Download) or from the premium plugin’s account area. Extract it on your local machine — you need a folder containing the plugin files, not a nested zip-inside-a-zip.
Connect to your server in FileZilla using your hosting FTP credentials. Navigate to /wp-content/plugins/. Before uploading the new version, rename the existing plugin folder — append -old to the folder name (e.g. contact-form-7 → contact-form-7-old). This renamed folder is your rollback: if the new version breaks something, rename it back and the old version is immediately active again. Upload the new plugin folder, then activate it in Plugins → Installed Plugins if it deactivated during the process.
Once you’ve confirmed the new version works correctly, delete the -old folder from the server. Don’t leave renamed folders accumulating — they don’t affect site function but they clutter the plugins directory and confuse future diagnostic work.
Method 3: cPanel or Plesk File Manager
The same process as FTP, done in the browser through your hosting control panel rather than a separate FTP client.
In cPanel: File Manager → navigate to public_html/wp-content/plugins/. Right-click the existing plugin folder, select Compress, and create a zip backup. Then right-click the folder and rename it with -old appended. Click Upload and upload the new plugin zip directly to the plugins directory. Once uploaded, right-click and Extract.
Plesk users follow the same pattern via Plesk → Files → httpdocs/wp-content/plugins/.
After extraction, verify the folder structure. The plugin folder should contain PHP files directly inside it, not another nested folder with a version number in the name. WordPress expects /wp-content/plugins/plugin-name/plugin-name.php. Some zip archives from premium vendors include a version number in the top-level folder name — if you see /wp-content/plugins/plugin-name-2.4.1/, rename it to /wp-content/plugins/plugin-name/ before activating.
Method 4: WP-CLI (fastest with SSH access)
WP-CLI is the fastest method when you have SSH access. Kinsta, WP Engine, Cloudways, and most managed WordPress hosts include it. Most VPS setups do too — run wp --version to confirm.
To see which plugins have updates available:
wp plugin list --update=available --format=tableTo update a single plugin:
wp plugin update contact-form-7To update all plugins at once — use with a fresh backup already taken, not on a production site without one:
wp plugin update --allWP-CLI also handles version rollback directly. To install a specific previous version:
wp plugin install contact-form-7 --version=5.9.5 --forceThe --force flag overwrites the currently installed version. Use this when rolling back after a failed update — find the version number from the plugin’s changelog on wordpress.org, then force-install it via this command.
After updating: what to check
Every update needs a verification pass, not just a glance at the dashboard success message.
Load the frontend in a private or incognito browser window to avoid cached views. Check the homepage, one interior page, and any page that directly uses the plugin you just updated — a WooCommerce update means checking the product listing, cart, and checkout. A form plugin update means submitting a test form from a real email address and confirming the notification arrives.
Open DevTools → Console and look for JavaScript errors. Plugin updates that break frontend JavaScript almost always throw console errors — catch them here rather than waiting for a user report.
If you see unexpected warnings in wp-admin after the update, run a quick health check:
wp site health checkPlugin conflicts are the most common post-update problem. If something is broken but restoring the backup isn’t the right move yet, the plugin conflict diagnosis guide covers the deactivation bisection method for isolating which combination of plugins is causing the issue.
When a plugin update breaks your site
If the site breaks after an update, restore from the backup you took before updating. WPVivid and UpdraftPlus both restore from remote storage in under five minutes on most setups. Don’t try to debug a broken production site while users are hitting it — restore first, diagnose on staging second.
If you don’t have a recent backup (which is why the pre-update backup step is non-negotiable), you can disable the broken plugin via FTP without a full restore. Connect via FileZilla, navigate to /wp-content/plugins/, and rename the plugin folder — append anything to break the path (e.g. akismet → akismet-disabled). WordPress can no longer locate the plugin’s main file and deactivates it automatically on next page load. A PHP fatal error caused by the plugin stops immediately.
If the update left WordPress stuck in maintenance mode — the “Briefly unavailable for scheduled maintenance” message that persists after the update finishes — a .maintenance file was not cleaned up from the WordPress root directory. Delete it via FTP or File Manager and the site returns to normal. The WordPress maintenance mode fix guide has the full steps if the file isn’t in the expected location.
To roll back to a previous plugin version: go to the plugin’s wordpress.org page → Advanced View → Previous Versions, download the specific version, and replace the current plugin folder via FTP as described in Method 2. Via WP-CLI: use wp plugin install plugin-slug --version=X.Y.Z --force. For premium plugins, the vendor’s account area usually keeps a downloadable history of previous releases.
For situations where a plugin update caused data loss, corrupted the database, or broke WooCommerce order processing in a way a simple file rollback won’t fix, emergency rescue with same-day response handles post-update breakages that go beyond file replacement.
Plugin updates are the most frequent recurring maintenance task a WordPress site has. If you’re doing them manually every week across multiple sites, a WordPress maintenance care plan covers updates, pre-update backups, and post-update verification on a set schedule. For the full picture of what monthly WordPress maintenance involves beyond plugin updates, the WordPress maintenance guide covers every recurring task and its correct frequency.
