WordPress can update itself, and on most sites it should. The reason is unglamorous: when a plugin vulnerability is disclosed, the patch and the exploit become public at the same moment, and automated scanning for unpatched installs starts within hours. A site that updates itself overnight is out of that window. A site waiting for someone to log in and click is in it for as long as that takes.
The question worth spending time on is not whether to enable automatic updates but which categories to automate, because they carry very different risk. This covers the settings, the constants that control them, and where manual review still earns its keep.
Turning it on in the dashboard
Plugins. Open Plugins in the dashboard. Each row has an Automatic Updates column with a link to enable it. Turn it on for everything, then reconsider individually if you have a specific reason not to.
You can do the whole list at once: select all plugins, choose Enable Auto-updates from the bulk actions menu, and apply.
Themes. Open Appearance then Themes, click a theme, and enable automatic updates in the details panel. Do this for the active theme and for the one spare you keep for troubleshooting, and delete the rest rather than maintaining them.
Core. Minor releases update automatically already. Major releases are offered but not applied. The Updates screen shows a link to switch to automatic updates for all new versions, including major ones, if you want that.
Controlling it from wp-config.php
The constants are useful when you want the same policy across sites, or want to prevent someone changing it from the dashboard.
All core updates, major included:
define( 'WP_AUTO_UPDATE_CORE', true );
Minor releases only, which is the default behaviour stated explicitly:
define( 'WP_AUTO_UPDATE_CORE', 'minor' );
Core updates off entirely:
define( 'WP_AUTO_UPDATE_CORE', false );
Do not set that last one because a major release once caused trouble. It disables the security updates too, and those are the ones that matter most.
One constant disables all automatic updating, including plugins and themes:
define( 'AUTOMATIC_UPDATER_DISABLED', true );
It exists for sites managed by external tooling that applies updates itself. On an ordinary site it is a mistake, and it is worth checking whether a previous developer left it in place; it is a silent setting, and a site can sit unpatched for years behind it while the dashboard looks normal.
What to leave manual
Major core releases on a site where a broken page costs money directly are worth reviewing. Apply them on a staging copy, click through the flows that matter, then apply to production. That is a real trade-off, made deliberately, on a small number of updates per year.
It is not a reason to leave plugin updates off. Plugin vulnerabilities are exploited at scale within hours; a major core release is a compatibility question, not a race.
Highly customised plugins: ones you or a developer modified directly: also need review, because the update overwrites the modification. The better fix is to stop modifying plugin files: move the change into a child theme or a small custom plugin so updates stop being dangerous.
Commercial plugins fail differently
Paid plugins usually check a licence before offering updates. If the licence has lapsed or was never activated on this domain, the plugin will not update at all, and automatic updates will not change that.
Nothing warns you clearly. The plugin keeps working, and quietly stops receiving security fixes. Check licence status on every commercial plugin at least once a year, and treat an expired licence as a security issue instead of a billing one: a plugin that cannot be patched has to be replaced.
Make sure you hear about it
WordPress emails the site administrator when an automatic update runs or fails. Those emails matter, and they go to the address in Settings then General, which on many sites is a mailbox nobody reads.
Point it at an address you check, and preferably not one hosted on the site itself: when the site has a problem you want the notification to arrive anyway.
Then actually load the site the morning after an update. Automatic updates make breakage less likely, not impossible, and a thirty-second look at the homepage and one deep page catches almost everything.
Backups are what make this safe
Automatic updates are worth enabling on any site, but they are much easier to live with when you can undo one. A tested backup turns a bad update from a crisis into a ten-minute restore. Managing WordPress backups deals with the schedule and the restore drill that proves the arrangement works.
For the wider picture of where updates sit among the other defences, securing WordPress against vulnerabilities orders them by how much risk each one actually removes. Updates come first, and by a wide margin.