Written for WordPress 7.1.2. Last verified September 23, 2026, against WordPress.org documentation and Make WordPress Core posts.
Short answer: WordPress changes not showing up usually means something is serving a stored copy of the old page. Work from the inside out: confirm the change actually saved, hard-refresh your browser, compare a private window with your logged-in view, then purge your page cache, your host's server cache and any CDN, in that order. If you edited a block theme's files and nothing moved, a saved Site Editor customization is overriding them.
You do not need to clear everything blindly. The useful question is which copy of the page you are looking at, and who else sees it. The table below answers that in about a minute.
Which layer is hiding your change?
A cache keeps a copy of a page so the site does not rebuild it for every visit. That copy goes stale the moment you edit. Match your symptom to a row, then go to the step it names.
| What you see | Most likely layer | Go to |
|---|---|---|
| Nobody sees the change, not even you | The change never saved or published | Step 1 |
| Only your usual browser shows the old version | Browser cache | Step 2 |
| New version when logged in, old version in a private window | Page cache (plugin, host or CDN) | Steps 3 to 5 |
| Text updated, but colors or spacing did not | Cached stylesheet, or Styles or Customizer not saved | Steps 1 and 2 |
| You edited a theme file and nothing changed | Site Editor customization overriding the file | Step 6 |
| Some visitors see the new page, some the old | Copies stored on a CDN | Step 5 |
The steps are ordered by cost. The first checks take seconds and change nothing on your site. The last one deletes work, so it comes last.
Step 1: WordPress changes not showing up for anyone? Check the save first
Before blaming a cache, confirm WordPress has the change at all. Three places catch most people.
The post or page status. Open the post and check its status in the settings sidebar. The WordPress.org Post Status documentation defines Draft as an incomplete post, Pending as waiting for a user who can publish, and Future as scheduled for a later date. A scheduled post is not live yet. A Private post is visible only to logged-in users with the right permissions, so a logged-out check will never show it.
The Site Editor save list. In a block theme, Appearance > Editor saves several things at once. The WordPress.org Site Editor documentation, updated for 7.1, says that clicking Save lists every synced pattern, navigation menu, template and template part you changed, and you can save all of them or only some. Anything you leave out stays unsaved. The same page notes that header and footer edits apply to every page that uses them.
The Customizer. On a classic theme, Appearance > Customize previews changes. Nothing reaches visitors until you click Publish. Block themes hide the Customizer unless a plugin needs it.
If you are unsure what was saved, compare the versions with visual revisions before you touch any cache.
Step 2: Rule out your own browser
Your browser keeps copies of pages, stylesheets and images so repeat visits load faster. It is the cheapest layer to test.
- Hard-refresh the page: Ctrl + F5 or Ctrl + Shift + R on Windows, Cmd + Shift + R on a Mac.
- Open the same URL in a private or incognito window.
- Check on your phone using mobile data instead of your home Wi-Fi.
If the private window shows the new version and your normal window does not, the stale copy was only in your browser. Clearing that browser's cached files for the site finishes the job, and nobody else was affected.
Stylesheets are the usual holdout. A page can show new text while the old CSS file stays cached, which is why a color or spacing change often lags behind a wording change. A hard refresh downloads the stylesheet again.
Step 3: Log out and look again
This one test separates "my browser" from "my site." Many page caches are set up to skip logged-in users, so you see a freshly built page while visitors get the stored copy. You can edit for an hour, see every change, and your visitors see none of it.
A private window shows you the site as a logged-out visitor. If it shows the old version on two different devices, the stale copy lives on the server side, not in your browser. Carry on to Step 4.
If the private window shows the new version, you are done. Your visitors see what you see.
Step 4: Ask Site Health whether a page cache exists
WordPress can tell you whether it detects a page cache, with no plugin and no code. Go to Tools > Site Health and open the Status tab. Look for a result that begins "Page cache."
This check arrived in WordPress 6.1, according to the Make WordPress Core post New cache Site Health checks in WordPress 6.1 (published October 6, 2022, read September 23, 2026). The WordPress developer reference explains how it works: WordPress looks for an active page cache plugin and makes three requests to your homepage, checking for caching response headers such as cache-control, expires, age and etag.
What each result means for you:
- "Page cache is detected and the server response time is good": a page cache exists. Purging it in Step 5 is your next move.
- "Page cache is not detected but the server response time is OK": WordPress found no sign of one. Read that as "not proven," not "absent," because a cache that sends headers outside the list can go unnoticed.
- "Unable to detect the presence of page cache": the check could not reach your homepage. The reference points to the loopback request test as the likely cause.
The Make Core post also says the check runs only in a production environment, so a staging copy will not show it.
Make sure you are editing the right site
That production note hides a common trap. If your host gives you a staging copy, it is easy to edit one site and view the other. Go to Tools > Site Health, open the Info tab and expand WordPress. It lists the site's addresses and its Environment type.
If the address in that panel does not match the address you are checking in the other tab, you edited a different copy of the site. No amount of cache clearing will fix that. Make the change again on the site your visitors actually use, or ask your host how their staging copy gets pushed to the live one.
Step 5: Purge caches from the inside out
When the stale copy is on the server side, clear the layers in order, starting closest to WordPress:
- Your caching plugin, if you have one. Most include a purge or clear option on their settings screen, and many add one to the admin toolbar. Clear all pages, not only the one you edited, because your homepage and archive lists hold copies of the post too.
- Your host's server cache. Some hosts cache pages at the server whether or not you installed anything. The purge option lives in the hosting control panel and its label varies, so check your host's own help pages.
- Your CDN, if you use one. A content delivery network stores copies in many locations. Purge from its dashboard.
- A persistent object cache, if your host provides one. It stores database results rather than whole pages. Site Health runs a separate persistent object cache check, added in the same 6.1 release. Flushing it happens in your host's panel.
Why the order matters. Each outer layer refills from the one inside it. Purge the CDN first while the server cache still holds the old page, and the CDN can fetch that old page straight back. Clear the inner layers first and the outer ones refill with the new version.
Wait a few minutes after the last purge, then test again in a private window.
Step 6: When it is not a cache at all (block themes)
If you or a developer edited a template file inside the theme's folder and the site did not change, caching is often not the cause. The WordPress.org Template Editor documentation (updated for 7.0, last updated August 10, 2026, read September 23, 2026) says changes made to a template in the editor "take precedence over your theme's bundled template files." Once someone saves that template in the Site Editor, the saved version wins and the file is ignored.
To check and fix it:
- Go to Appearance > Editor > Templates.
- Open the three-dot menu next to the template and look for Reset. The documentation says this option only appears on templates that were customized. If it is missing, the template is already in its default state.
- Choose Reset, then confirm "Reset to default and clear all customizations." The template goes back to the theme file.
Reset deletes the saved customization, so anything built in the editor on that template goes with it. Take a quick backup before the edit, and if you want a copy of the customized version, use Export under Tools in the Site Editor's three-dot menu, which downloads your theme with its templates and styles. Styles follow the same pattern: the three-dot menu in Styles offers style revisions and a full reset.
When to stop clearing caches
If you have worked through all six steps and a private window still shows the old page, stop purging. Repeating the same clear rarely changes the result, and it buries the real signal. The cause is now more likely a plugin that rewrites the page or an error that stops the new version from rendering. Run the 15-minute WordPress diagnosis to narrow it down, and if a plugin is the suspect, the WordPress plugin conflict test isolates it without guesswork.
One honest limit. WordPress core does not include a page cache, which is why Site Health looks for signs of one added by a plugin or your server. That also means WordPress has no built-in purge button for your host's server cache or your CDN. Those services sit outside WordPress, their wording differs, and their own documentation is the authority on where the button is.
FAQ
Why do I see my WordPress changes but visitors don't?
Most often a page cache that skips logged-in users. You get a freshly built page while visitors get the stored copy. Open the page in a private window to confirm, then purge the page cache and any server or CDN cache, inner layers first.
How long does it take for WordPress changes to show up?
A saved change is in WordPress right away. Any delay comes from a cache holding the old copy until it expires or is purged, and that expiry is set by the plugin, host or CDN, not by WordPress.
Will clearing the cache delete my content or changes?
No. Purging a cache throws away stored copies of pages, and the site rebuilds them from what WordPress has saved. Resetting a Site Editor template is different: that does delete the customization, so back up first.
Why did my CSS change not show up in WordPress?
Browsers cache stylesheets separately from the page, so a hard refresh is the first fix. If you used the Customizer on a classic theme, confirm you clicked Publish. In a block theme, confirm the Styles change was included when you saved in the Site Editor.
Does WordPress have its own page cache I need to clear?
Not in core. The page cache on a WordPress site comes from a plugin, your host or a CDN, which is why the Site Health check under Tools > Site Health looks for their signs rather than a WordPress setting.
