If a WordPress core update is not showing, first confirm the installed version and the installation you are viewing. Then inspect Dashboard > Updates, the last-check time and any access or connection warning. A missing notification is not proof that the site is current, and reinstalling WordPress is not a sensible first diagnostic step.
This guide is about a missing software-version update, not text or images that stay old after editing a page. For that different problem, use our WordPress changes not showing guide. Keeping those two meanings of update separate avoids clearing public-page caches to solve an administration or deployment problem.
Confirm the release before changing the site
As checked on October 13, 2026, WordPress 7.1.3 remains the latest stable release in the official release list. Our WordPress 7.1.3 owner guide explains that release and the checks after installation. This page addresses the separate question of why an expected update is missing from your dashboard.
Compare the full version number, not just the first two parts. Record the production domain and installed version together. A screenshot from staging, a host’s account overview or an email about another installation cannot establish what the customer-facing site currently runs.
An older-branch security patch is not necessarily an upgrade to the newest branch. Likewise, an announcement about a beta or release candidate does not mean a normal business site should install development software. Do not switch a production site to a testing channel merely to make version numbers match a search result.
Make one fresh check in the right place
Open WordPress through your usual trusted administration address. If your account has access, go to Dashboard > Updates. Note the current version, last-check time, offered version and any exact warning. Use Check again once, then read the result before taking another action.
The official Updates-screen documentation distinguishes core, plugin, theme and translation updates. An empty plugin list does not establish that core is current. A reinstall control is also different from an offer to install a newer version. Do not click either an install or reinstall action just to refresh the screen.
WordPress’s version-check function requests update information from WordPress.org and stores the result. A fresh check helps separate an old result from a continuing problem, but it is not a guarantee that every hosting policy, permission or connection issue has been resolved.
Match the evidence to the next owner
| What you observe | What it establishes | Next safe action |
|---|---|---|
| The installed version already matches the stable release | No newer core version has been identified | Record the result and verify the site’s business functions. Do not reinstall solely to obtain an update notice. |
| A newer version appears after Check again | An update offer is now available | Move to the agreed backup and update process. Finding the offer is not the same as installing it. |
| Updates is missing or access is denied | Your current account or administration context cannot complete this check | Ask the responsible administrator or network administrator to verify the installation. Do not grant broad access as a shortcut. |
| A connection warning names WordPress.org | The site reports a communication problem | Give the exact warning and timestamp to the host or maintainer for a server-side connection check. |
| The host says it manages core releases | The deployment process may belong outside this dashboard | Ask which production version is deployed, what release is approved and when the pending update will be completed. |
| The fresh result says current but the installed version is older | The two pieces of evidence still disagree | Preserve both readings and request a scoped check of the version response, restrictions and deployment target. |
This is a routing checklist, not a diagnosis of your particular site. Several conditions can produce a similar screen. For example, a network-managed installation and a restricted account can both leave an ordinary site user without the controls they expect.
Separate a missing offer from disabled automatic updates
A notice that automatic updates are disabled describes background installation behavior. It does not, by itself, explain every missing manual update offer. In Webless’s administration check for this guide, the screen displayed both an automatic-updates-disabled notice and a manual offer for a newer core version. That observation supports the distinction; it is not a recommendation to disable automatic updates on your site.
Ask your maintainer whether the site uses a host-controlled deployment, a deliberate update restriction or a custom filter. The investigation should identify the responsible setting and why it exists before changing it. Replacing configuration values found in a forum answer can bypass the process that keeps code, backups and database changes coordinated.
If the host provides a managed release process, ask for a specific explanation of any delay, especially for a security release. A vague statement that updates are handled is not completion evidence. Equally, do not trigger an independent dashboard installation while a host deployment is already running.
Read Site Health without treating every warning as the cause
Where available, open Tools > Site Health and read the Status tab. WordPress documents checks for communication with WordPress.org, scheduled tasks and background updates in its Site Health guide. Record the exact failed check rather than sending only the overall score.
A failed scheduled event can be relevant to background work, but it does not prove why one release offer is absent. A healthy public homepage also does not prove that the server can reach an update service. Let the host distinguish outbound connectivity, scheduled checking and installation policy before changing a firewall, cron configuration or cache service.
Share diagnostic details privately with the technician responsible for the site. Do not paste a full environment report, server paths, account details or credentials into a public support thread. Often the first useful handoff needs only the public domain, version numbers, timestamp and exact warning.
Do not force an update before the cause is understood
Stop if the next proposed step involves deleting database options, changing file permissions broadly, renaming all plugins, disabling a firewall, or uploading a replacement package from an unverified source. These actions can affect much more than the missing notice and should not be the default response to it.
A technician can compare the version-check response with the installed code and inspect update-related restrictions. The official WP-CLI core check-update command is one supported way to query update availability. It is a check, not evidence that an installation completed or that the site’s customer journeys work.
If installation has already started and fails, preserve the error and deployment time. That is no longer just a missing-notification issue. Use the site’s established recovery process instead of repeatedly retrying, and avoid a database restore that could erase newer enquiries, orders or content.
What a useful completion record looks like
| Stage | Evidence to keep | What is still unproven |
|---|---|---|
| Detection | Production domain, installed version, offered version and fresh check time | The update has not necessarily been installed. |
| Preparation | A usable files-and-database recovery point and an agreed deployment owner | A backup badge alone does not prove restoration will work. |
| Installation | The completed deployment and a new reading of the installed version | Successful installation does not verify forms, bookings or checkout. |
| Acceptance | Results of the agreed public-page and business-function checks, with any unresolved errors | The result is limited to the paths actually checked, not a guarantee about every integration. |
Before installation, use a restore-tested recovery point and agree how newer business data would be preserved if recovery becomes necessary. Afterward, confirm the installed version independently and check the important desktop and mobile paths. Forms and payments need an authorized test plan, not an unapproved real transaction.
The practical goal is not to make a notification appear at any cost. It is to establish what production runs, why the expected release is or is not offered, who owns deployment and what proves the update finished safely.