This covers running updates by hand: what to do before, the order to apply them in, and how to tell quickly whether one broke something. If you would rather WordPress did this on a schedule without you, which is the right answer for most sites. There is more on the settings and this page covers the times you still do it manually in enabling automatic updates.
Manual updating earns its place in two situations: a site where a broken page costs money directly and you want to watch each change land, and a site that has been neglected long enough that updating everything at once is genuinely risky.
Before you touch anything
Take a backup and confirm it exists. Not "the plugin says it ran", confirm the archive is there and has a plausible size. This is the entire safety net for what follows, and the ten seconds it takes to check is the cheapest insurance in this article. Managing WordPress backups goes over doing this properly.
Then look at the site before you start, so you know what "working" looks like. Load the homepage, a post, and any form or checkout. It is surprisingly common to update, notice something odd, and be unable to remember whether it was odd yesterday.
The order to update in
Plugins first, then themes, then WordPress core.
The reason is compatibility direction. Plugin and theme authors release updates that support the coming core release ahead of time, so updating them first means core arrives to an environment already prepared for it. Doing core first can leave a plugin briefly incompatible with the version now underneath it.
Within plugins, update in small groups rather than all at once. Four or five, then look at the site. If something breaks you have a short list of suspects instead of thirty. On a well-maintained site you can be less careful; on a site that has not been updated in a year, small groups will save you an afternoon.
Running the updates
Everything pending appears under Dashboard then Updates, and each section can also be updated from its own screen.
For plugins, open Plugins, select the group you want, choose Update from the bulk actions menu and apply. Wait for the screen to report each one finished before navigating away: interrupting an update mid-write leaves mismatched files, which is a worse problem than the one you were fixing.
For themes, update the active theme and the spare you keep for troubleshooting. Delete the others instead of maintaining them.
For core, minor releases are safe to apply directly; they contain security and bug fixes and are deliberately conservative. Major releases change behaviour, and on a site that earns money they are worth applying to a staging copy first.
Check the site after each group
Load the homepage, a single post, an archive page, and anything transactional. Look at the site while logged out as well as logged in, caching and some plugins behave differently for administrators, and a page that is fine for you can be broken for everyone else.
If something looks wrong, the plugin you just updated is the first suspect. Most plugins can be rolled back to a previous version with a rollback plugin; failing that, download the older release from the plugin's page on wordpress.org and install it over the top.
If the site is blank or the dashboard is unreachable, rename the plugin's folder inside wp-content/plugins over SFTP by adding -off to the end. WordPress cannot find it, treats it as deactivated, and the site returns. Fixing common WordPress errors goes into the other failure shapes.
Updating a site that is badly out of date
A site two years behind is a different job, because the gap may include core releases with their own migration steps.
Work in stages. Back up. Update plugins in small groups, checking between each. Then bring core up one major version at a time rather than jumping straight to current: each release handles its own upgrade routine, and skipping several at once means several routines running together with no way to tell which failed.
Expect casualties. A plugin abandoned three years ago may simply not work on a current WordPress and current PHP. Finding a maintained replacement is the fix; keeping the site old to keep the plugin alive means running known-vulnerable code indefinitely.
Check the PHP version afterwards too. Old sites are often pinned to an old PHP release, and a current WordPress with current plugins usually wants something newer. There is more on changing it in configuring PHP settings in cPanel.
Things that make updates fail
An update that never finishes. Usually a timeout on a large plugin. Reload the plugins screen. It often completed anyway. If it did not, install the update manually by uploading the ZIP.
"Another update is currently in progress." A previous update was interrupted and left a lock. It clears by itself after a while; the underlying .maintenance file in the site root can also be deleted directly.
A permissions error. Files are owned by the wrong user, usually after a manual upload. The fix is ownership, not permissions, do not set anything to 777 to work around it, and open a ticket instead.
A commercial plugin showing no update. The licence has lapsed or was never activated for this domain. Nothing warns you clearly; the plugin keeps working and stops receiving security fixes.
How often
Check weekly if you are doing this by hand, and act on security releases the day you hear about them instead of waiting for your normal cycle.
If weekly sounds like more discipline than you will actually maintain, which is the honest answer on most sites; that is the argument for automating it. An imperfect automatic update applied overnight beats a careful manual update that happens twice a year.
On a site in more than one language, every content change has to be made in each. How to Run a Multilingual WordPress Site goes into planning that maintenance.
Updating everything is also the step that resolves most PHP compatibility problems before you meet them. How to Upgrade the PHP Version of a WordPress Site explains the rest of that move.