iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
If a WordPress change saves but visitors still see the old page, start by testing the public URL in a private window. If the new version appears there, a browser or site cache is serving stale content. If it does not, check that you edited the correct page or template, then inspect Dashboard > Updates and Tools > Site Health for delayed checks, blocked requests, permissions problems, Cron failures, or a broken update.
WordPress does not include a page cache by default, but caching can exist in your browser, a WordPress plugin, your host, a reverse proxy, or a CDN. A separate class of problem affects update notices: WordPress checks for available releases about every 12 hours, with randomized timing, so a release may not appear immediately.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →
First, identify which kind of update is missing
“The update is not showing” can describe several different failures. Identify the scope before changing settings; otherwise it is easy to purge the wrong cache or disable a healthy plugin.
| What you observe | Most likely layer | First check |
|---|---|---|
| The editor confirms a save, but logged-out visitors see old text | Browser, WordPress, hosting, reverse-proxy, or CDN cache | Open the exact public URL in a private window, then purge caches in order |
| The new content is missing in every browser, including for administrators | Wrong page, template, homepage assignment, upload location, or an unsuccessful save | Verify the public address and the source used to render the page |
| A new WordPress, plugin, theme, or translation release is absent from the dashboard | Scheduled update check, blocked connection to WordPress.org, or a host/plugin restriction | Use Dashboard > Updates, then review Tools > Site Health |
| An update starts and then reports a download or installation failure | Network access, filesystem ownership, permissions, disk space, or incompatible code | Back up the site and record the exact dashboard error before retrying |
| The site shows a fatal error immediately after an update | A plugin or theme that is incompatible with the current PHP or WordPress version | Use WordPress Recovery Mode and inspect the component named in the recovery notice |
The useful diagnostic axes are visibility (logged-in versus logged-out), layer (browser through WordPress core), timing (immediate save versus delayed update check), scope (one page or the entire dashboard), and error evidence (dashboard message, Site Health warning, PHP fatal, or filesystem error).
1. Confirm that the change was saved, not merely hidden
- Look for the editor’s success notice. A completed “Published,” “Updated,” or equivalent notice indicates that WordPress accepted the request. An error, spinning button, or redirect before the notice means the content may never have been saved.
- Open the exact public URL. Do not rely on the preview tab or a navigation menu. Copy the address visitors use and load it directly.
- Test while logged out. Use a private window or another browser. Administrators can receive an uncached response while visitors receive a cached page, so an administrator view alone is not conclusive.
- Interpret the result. If the private window shows the new content, clear the normal browser cache or the site data for that domain. If it shows the old content too, continue with the cache and source checks below.
A browser can reload an older local copy when it does not recognize a small edit as significant. A private-window test separates that local copy from the server’s response without changing the site.
2. Purge every cache layer that actually exists
Clear caches from the outside in, and only for services enabled on this site. Installing a cache plugin solely to clear a cache that is not present can add another source of stale output and configuration conflicts.
Browser cache
After confirming the private-window result, clear cached files for the affected domain in the browser that displayed the old page. Close and reopen the tab, then request the public URL again. Test a second browser before making site-wide changes; if only one browser is stale, the problem is local.
WordPress cache or performance plugin
Open the active cache or performance plugin’s settings and use its purge, clear, or empty-cache control. Purge the page cache and, when offered, the object or database cache as well. Then load the public URL in a private window. If the plugin has separate cache groups for desktop, mobile, logged-in users, or a homepage, clear the group containing the affected URL.
Hosting or server cache
Managed hosts may cache complete pages at the server level even when WordPress has no cache plugin. Use the host’s cache-purge control or support channel to invalidate the affected site or URL. A plugin purge cannot remove a copy held outside WordPress.
CDN or reverse-proxy cache
If a CDN or reverse proxy is enabled, purge its cache after the WordPress and host layers. Reverse proxies can continue serving the old response until it expires or is explicitly purged. Confirm that the purge completed, then test from a private window and, if practical, a different network.
Free tools Windows power users keep installed
One-click scans. No signup required.
Do not repeatedly edit the post while caches remain. Each additional edit can make it harder to tell whether the underlying save worked or whether only one cache layer changed.
3. Verify the page, template, and source you actually changed
An apparently ignored edit is often a correct edit made in the wrong place. Check these items before modifying code or reinstalling anything:
- Public address: Compare the URL in the browser with the page or post you edited. Watch for a similar slug, a language-specific URL, or a redirect to another page.
- Homepage assignment: In the reading or homepage settings, determine whether the front page displays a list of posts or a specific page. Editing a page that is not assigned as the front page will not change the home screen.
- Template: A block theme, a classic theme template, a site-wide header, and a page-specific template can all control what visitors see. Confirm that the visible element belongs to the template you edited.
- Reusable or global content: A block pattern, widget area, menu, or global style may supply the text or design instead of the page body. Edit the source that renders the element.
- Upload and source location: For images, scripts, stylesheets, or manually uploaded files, verify the destination path, filename, case, and the URL referenced by the page. The official troubleshooting guidance also recommends checking the page source when an upload appears to have no effect.
View the page source or browser developer tools when necessary. If the old text or asset URL is already in the server response, investigate WordPress or caching. If the response contains the new value but the screen does not, investigate browser-side scripts, styles, or a different element covering it.
4. When an update notice is missing, account for update-check timing
A release can be available while the dashboard still shows no notice. WordPress’s troubleshooting FAQ states that a site is programmed to check for updates every 12 hours, but the timing of that check is purely random. The interval is approximate, not a promise that every site will display a release exactly 12 hours after publication.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware match- Open Dashboard > Updates and review the status for WordPress core, plugins, themes, and translations.
- Use the screen’s check or refresh control when available, then revisit the screen later if the release is still absent. Avoid repeatedly clicking during a brief interval; a randomized schedule can still delay the notice.
- Open Tools > Site Health and look for a warning that WordPress cannot reach WordPress.org or that HTTP requests are blocked. Those conditions can prevent the update metadata from arriving at all.
- Check whether a security, maintenance, or hosting policy intentionally disables updates. An absent notice caused by policy is different from a delayed check and requires the administrator who set that policy.
The Dashboard > Updates screen is the control center for core, plugin, theme, and translation updates. If the screen itself loads but one component is missing, compare the component’s installed version with its official release information and inspect Site Health before assuming the release is unavailable to everyone.
5. Repair a failed or stuck update safely
Do not retry a failed update blindly. First make a current backup of the database and site files, and preserve the exact error text. A backup gives you a recovery point if files are partially replaced or a database migration fails.
Rank #3
Download failure
A download failure usually indicates that the site could not retrieve the package or that the response was interrupted or rejected. In Dashboard > Updates, note whether the message mentions WordPress.org, a timeout, SSL, HTTP access, or an unavailable package. Then check Tools > Site Health for blocked HTTP requests or inability to reach WordPress.org. A firewall, host policy, DNS problem, or outbound-request restriction may need to be corrected outside the editor.
Installation failure
An installation failure occurs after WordPress has obtained the package but cannot complete the replacement. Common causes include incompatible code, insufficient permissions, incorrect filesystem ownership, or a directory that is not writable. The Updating WordPress documentation identifies ownership and permissions as common causes. Ask the host or server administrator to verify that the web process can write the directories required for the affected component; do not broadly make every file world-writable as a shortcut.
A lingering maintenance state
During an update, WordPress places a .maintenance file in the site’s root directory. If an update fails and that file remains, visitors may see a maintenance message even though the operation is no longer running. After confirming that no update process is active and retaining your backup, connect with the documented FTP or hosting file manager, enable visibility for hidden files, and remove the root .maintenance file. Then reload the site and retry the update or follow the official manual-update procedure. Do not delete unrelated files or a maintenance marker while another update is still in progress.
Connection and partial-update errors
If the dashboard reports a connection error, treat it as a transport problem first: review Site Health, firewall rules, DNS, TLS certificates, and host-level outbound restrictions. If files were partially replaced, stop repeated retries, restore the backup if necessary, and use the manual update instructions appropriate to the affected component. Keep the error message and timestamps for the host or developer; they often reveal whether the failure occurred during download, extraction, database work, or file replacement.
6. Use Site Health to find blocked requests, Cron, and permissions issues
Tools > Site Health turns a vague “not showing” report into specific checks. Review both the Status and Info areas, and expand each recommendation rather than dismissing it without reading the details.
“Could not reach WordPress.org” or blocked HTTP requests
These warnings explain why update metadata, package downloads, or other scheduled requests may not complete. A firewall or host may block outbound HTTP requests, require a proxy, or reject the site’s TLS connection. The correction may be a server configuration change rather than a WordPress setting.
Background-update failures
Site Health can report that background updates have failed or that an earlier attempt did not finish. Follow the linked details to identify the component and failure type, then use the backup, permissions, and connection checks in the previous section instead of starting several overlapping updates.
Non-writable directories
If Site Health says WordPress cannot write to required directories, plugin and theme updates may fail even when the dashboard and front end work. Verify filesystem ownership and permissions with the host or system administrator. Correct only the affected paths and preserve the server’s intended security model.
Cron and automatic updates
Plugin and theme automatic updates depend on WordPress Cron. If scheduled updates do not run, Site Health may show Cron symptoms or a failed loopback request. Check whether a host-level scheduler replaces or disables WordPress Cron, whether a security plugin blocks loopback requests, and whether the site can make its own HTTP requests.
Automatic-update controls for plugins and themes were introduced in WordPress 5.5. A control can therefore be absent on an older WordPress version, or automatic updates can be disabled by a host or plugin even on a newer version. Confirm the installed WordPress version and the policy controlling updates before interpreting an absent toggle as a software defect.
7. Recover from a fatal error after an update
WordPress Recovery Mode was introduced in version 5.2. When a fatal PHP error is detected during a normal page load, WordPress can send the administrator a recovery link and pause the faulty plugin or theme for that administrator session. This can restore dashboard access without FTP or direct code editing.
- Open the recovery email link. Use the administrator account and the link generated for the incident. If no message arrives, check the administrator mailbox, spam folder, and the site’s mail delivery configuration.
- Read the paused-component notice. Recovery Mode identifies the plugin or theme associated with the fatal error. Record the error text, file path, and PHP function before changing anything.
- Deactivate, update, or repair the component. If a compatible release exists, update it after confirming that the site is backed up. Otherwise deactivate it and contact its developer or replace the affected code with a compatible version.
- Exit Recovery Mode and test normally. Visit the front end and dashboard in a fresh session. Check the page that originally failed and test key forms or commerce functions before re-enabling the component.
Recovery Mode is limited to fatal errors encountered during a normal page load. It does not diagnose a failure that occurs only in Cron or another background task, so use Site Health and server logs for scheduled-update problems.
Choose the next check from the symptom
Only logged-out visitors see the old page
Prioritize cache layers. Confirm the private-window result, purge the active WordPress cache, then the host and CDN or reverse proxy. If administrators see a different response because they bypass caching, that difference is evidence of cache variation rather than proof that the save failed.
Every browser sees the old page, but the editor says it saved
Verify the public URL, homepage assignment, template, and source location. Then inspect the server response or page source. If the old value is returned by the server, continue with server and CDN cache checks; if the new value is returned, investigate front-end scripts and styles.
Recommended Free Tools
Only one plugin or theme update is missing
Check that component’s installed version, update policy, and compatibility. Review Dashboard > Updates and Site Health for a blocked connection or background-update failure. Do not assume that a missing notice means the component has no newer release.
The entire Updates screen is stale or empty
Check the randomized update interval, then test connectivity to WordPress.org in Site Health. A site-wide outbound-request restriction can hide core, plugin, theme, and translation updates at once.
The site broke immediately after updating
Use Recovery Mode for a fatal error on a normal page load. If the error is intermittent, appears only during scheduled tasks, or produces no recovery notice, inspect Site Health and server logs instead.
Quick Recap
Verify the fix before declaring success
- Load the exact public URL while logged out and in a private window.
- Check the page in a second browser or network to detect a cache that only one path still serves.
- Confirm that the expected WordPress, plugin, theme, or translation version is displayed in Dashboard > Updates.
- Reopen Tools > Site Health and ensure the relevant warning has cleared or has a documented, intentional explanation.
- Test forms, menus, search, media, and any feature supplied by the updated component.
- If a maintenance message or fatal error returns, stop retrying and preserve the new error details for the host or developer.
Prevent the next “not showing” incident
- Keep a reliable database and files backup before core, plugin, or theme changes.
- Document every cache layer used by the site and where each purge control lives.
- Review Site Health periodically for blocked HTTP requests, loopback failures, Cron problems, and non-writable directories.
- Decide deliberately which plugin and theme automatic updates are enabled, and record any host or security-plugin policy that overrides the dashboard.
- After publishing important changes, verify the public URL while logged out rather than relying only on the editor preview.
- Keep administrator email delivery working so Recovery Mode messages can be received promptly.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →
