Updating WordPress is three jobs that share one dashboard screen. Core is the software. Plugins are the forms, store, SEO, and booking tools. The theme is how the pages look. If you hit Update on all of them at once, a broken checkout does not tell you which piece failed.
This is the process we use with Connecticut shops, contractors, and clinics on shared or managed WordPress hosting. Take a backup you can restore. Then plugins. Then the theme. Then WordPress itself. It is slower than clicking everything. It is also how you keep the site up.
What you are actually updating
WordPress nags you from Dashboard > Updates. Treat that screen as a list, not one chore.
- WordPress core: the files that run wp-admin, posts, and the rest of the site.
- Plugins: contact forms, SEO, caching, security, WooCommerce, appointments, page builders.
- Themes: the active theme, plus a parent theme if you run a child theme.
PHP on the server is not in that list. It is a hosting setting. WordPress 7.0 set the minimum to PHP 7.4 and still recommends 8.3. If the account is years behind, a major WordPress update can fail before the dashboard finishes. Ask your host what PHP version you are on before you jump a major release.
Back up before you click anything
Do not update a live site with no restore point. You need the database and the files from the same moment. A folder copy from last month paired with today’s database is how menus, orders, and photos stop matching.
We published the full walkthrough in How to Back Up and Restore a WordPress Site. Use that, or confirm that host daily copies include both files and the database and that you know how to restore one.
A brochure site can live on a weekly owner copy plus daily host copies. A store or booking site should have a copy from before the update, not “we think the host has something.”
What already updates in the background
Since WordPress 3.7, most sites apply minor and security updates on their own. That is the 7.0.2 / 7.0.3 style patch, not a feature release. You still click Update Now for major versions (6.9 to 7.0, 7.0 to 7.1) unless someone turned on automatic major updates.
Leave minor auto-updates on. Turning them off to “stay stable” is how sites sit on known holes for months.
WordPress 7.1 shipped on August 19, 2026. If you are already on it, you are current as of this writing. If the dashboard is offering 7.1, treat it as a major click, not a background patch.
A safe order
There is no prize for updating everything in one pass.
- Take a backup you can restore.
- If this is a major core jump, skim plugin and theme notes for compatibility. Skip that for a single plugin patch.
- Update plugins. On a store or booking site, do them one at a time and click the live site after each.
- Update the theme (and the parent theme if you use a child theme).
- Update WordPress core last.
- Walk the site.
Why plugins before core: if a plugin is not ready for the new WordPress version, you find out while core is still the old one. You can roll that plugin back without also fighting a half-finished core upgrade.
If a core update is already running, do not start a second one. Let it finish.
WordPress’s own manual upgrade docs go further: deactivate every plugin, replace core files, run the database upgrade, then bring plugins back. That is the right path when a site is already broken or you are jumping several major versions. For a healthy site on current hosting, the dashboard order above is enough.
How to run it
- Log in as an administrator.
- Go to Dashboard > Updates.
- Update plugins first (Plugins > Installed Plugins shows the same nags).
- Update the theme from the same Updates screen, or Appearance > Themes.
- Then click Update Now for WordPress.
- Stay on that tab until it says the update completed. Closing the browser mid-update is a common way to land on a maintenance screen.
If WordPress asks for connection credentials, stop. That means the site cannot write its own files. Guessing old file-transfer passwords usually makes this worse. Open a ticket with your host and ask them to fix file ownership so dashboard updates work.
Do this when you can spare 15 to 30 minutes. Not Friday at 5 p.m. before a weekend you are not answering the phone.
After Update Now
Clear the cache if you run a caching plugin, then click through:
- The homepage
- One interior page that uses a form
- A recent blog post, if you have a blog
- Checkout or booking, if you take money or appointments
- wp-admin, including a quick look at Plugins and Appearance
If a page looks like the old theme for a minute, that is often cache. If it still looks wrong after a hard refresh and a cache purge, restore the backup rather than stacking more updates on a broken site.
If the site breaks or gets stuck
A leftover maintenance screen is the usual scare. During an update, WordPress drops a file named .maintenance in the site root. If the update dies, that file stays, and visitors see “unavailable for scheduled maintenance” that never ends.
Do not keep hitting Update Now. Ask your host to delete .maintenance from the WordPress root, or remove it yourself in the file manager if you know where the site files live. Then check whether the update actually finished (Dashboard > Updates) before you try again.
White screen, login loop, or a checkout that returns an error: restore the backup from before the update. Then update one plugin at a time until you find the one that does not get along with the new core or theme.
If you cannot log in at all, do not start renaming folders unless you already know that workflow. Restore, then open a support ticket.
When to wait, and when not to
Security and minor updates: do them. Waiting “until things settle” is how known holes stay open.
Major feature releases: if you have a heavily customized theme, a page builder, or WooCommerce, waiting a few days while you take a backup is reasonable. Waiting months is not. If you are still on an older 6.x branch with auto-updates off, you are past being careful.
You do not need to chase every 7.1 headline on day one (new media tools, tabs block, extra responsive controls). You do need a current core, current plugins, and a backup you have practiced once.
When to ask your host
Open a ticket from the account that owns the domain if:
- Dashboard updates ask for connection credentials and never finish
- The site is stuck on a maintenance screen and you cannot find
.maintenance - A restore is safer than guessing, and you want the host to roll back the last good copy
- You are not sure which PHP version the account is on before a major core jump
Include the domain, what you clicked (plugin, theme, or core), and what visitors see now. That detail saves a round of questions.
If you host with KDigital Hosting, sign in to your client area and open the ticket there. Managed WordPress hosting includes more of this work for you. On a standard WordPress hosting plan, you still own the click, and you still want that backup from before you start.
