WordPress edits not showing? Blame the layers
You update a service page in WordPress. The editor preview looks right. The public page still shows the old CTA. In Dubai, Liverpool or anywhere else, this is the sort of small website problem that wastes an afternoon because everyone starts editing the page again instead of proving where the old version is coming from.
When WordPress changes are not showing, the saved edit may be correct while an older version is being served from another layer. Common causes include browser cache, page cache, CDN cache, object cache, generated CSS files, unpublished revisions or the wrong template. The sensible fix is to test one changed element across controlled views before rebuilding content or blaming the page builder.
Not ideal, obviously. But also very common.
The field note: the page is not always the guilty party
The usual scene is simple enough. A service page has been updated in WordPress. The business wants a new CTA, maybe from an old phone number to a WhatsApp enquiry button. The editor preview shows the new version. Logged-out visitors still see the old CTA.
The false assumption is that the page builder failed to save it. Elementor, Divi, WPBakery or the block editor might be involved, but they might also just be standing closest to the scene of the crime.
In WordPress website development, especially on sites using performance plugins, Cloudflare, server cache and generated builder assets, there may be several versions of the same page in circulation. If you keep changing the content before testing the layers, you create a new problem. Now nobody knows which edit worked, which cache was stale, or whether the current live page is even the version you meant to publish.
Use one changed element and test properly
Do not change the headline, CTA, layout, image and form all at once. Pick one visible element. Something boring and obvious works best.
For example, change one CTA button label from Book a consultation to Request a callback. Save it. Publish it. Then stop touching the page.
That single changed element becomes your evidence. If it appears in the editor but not publicly, the diagnosis moves away from content editing and towards delivery layers.
The cache-layer diagnosis checklist
| Layer to check | What to test | What it usually tells you |
|---|---|---|
| Publishing state | Confirm the edit is published, not saved as a draft, revision or scheduled change. | If preview is correct but public is wrong, publication still needs ruling out first. |
| Logged-in view | Open the page while logged into WordPress, then as a logged-out visitor. | Many cache setups bypass cache for logged-in users, which can hide the real issue. |
| Incognito browser | Check the URL in a private window and on mobile data, not the same browser tab. | If incognito shows the update, your normal browser cache may be the stale layer. |
| Page cache | Check whether the caching plugin or host cache has stored the old page HTML. | The page may be saved correctly while the visitor receives old cached markup. |
| CDN cache | Check Cloudflare or another CDN if traffic is routed through it. | A CDN can keep serving the old version after WordPress has already changed. |
| Generated CSS | Check builder-generated files, such as Elementor CSS in uploads folders. | The text may be current, but styling, layout or hidden elements may be coming from old generated assets. |
| Object cache | Check persistent object caching such as Redis if menus, widgets or options look stale. | The page may load but use old stored data from a backend cache. |
Do not start with a big dramatic purge
Clearing cache can be part of the fix. It is not a diagnosis by itself.
If you purge everything blindly, the page may start working and you still will not know why it failed. That sounds like a win until the same issue returns next week and everyone is back to pressing random buttons with slightly more confidence.
A better process is:
- Confirm the correct page, template and language version were edited.
- Check the public URL while logged out.
- Test in incognito and on a different network, such as mobile data.
- Look for host-level page cache and plugin cache.
- Check CDN cache if the domain runs through Cloudflare or similar.
- Regenerate generated CSS only when that layer matches the symptom.
- Record which action made the new CTA appear.
That last point matters. Proper maintenance is boring until it is the only thing that saves the site from guesswork.
A practical example from a service page
Say a Dubai clinic updates a service page CTA because the old phone number is being retired. In the WordPress editor, the button is correct. In the public browser, the old number remains. Someone edits the button again. Then the mobile version gets changed as well. Then the page builder cache is regenerated. Then the whole layout shifts slightly because a global style was touched.
The original issue may have been one cached HTML file. Now the page has three content revisions, a mobile-only layout change, and a team asking why the button spacing looks odd.
Stop changing things until you know what changed first.
Generated CSS is a common little nuisance
Page builders often save styling into generated files rather than loading every design choice directly from the database on every page view. This is normal. It can also be irritating.
With Elementor, for example, a page might use a generated stylesheet in a folder under wp-content/uploads. If that file is stale, a button colour, spacing rule or responsive section can look old even when the content edit has saved. Regenerating those files may help, but only after you have confirmed the symptom is visual styling rather than old page text.
A form that says thanks but sends nothing is not working. It is just being polite about failing. Same principle here: a preview that looks right does not prove the public delivery layer is current.
When it becomes a repair issue
If the problem keeps returning, it may not be a one-off cache annoyance. It may be a messy stack: overlapping cache plugins, server cache, CDN rules, page builder asset settings, old staging workflows or a host setup nobody has documented.
That is where structured diagnosis beats another round of plugin roulette. For more serious stale-page, broken-layout or post-update issues, our WordPress website repair in Dubai work usually starts by finding the failing layer before changing more content.
For ongoing sites, this sort of check also belongs inside practical WordPress website maintenance in Dubai, especially where service pages, landing pages and lead generation forms are being edited regularly by different people.
The smallest sensible next action
Pick one visible change. Publish it. Test it logged in, logged out, incognito and on another network. Then check cache layers in order. Browser, page cache, CDN, generated CSS, object cache. Do not rebuild the page because one visitor view is stale.
The opinion here is simple: prove the source of the old version before touching the content again. It is quicker, cleaner and less likely to create a second problem while trying to solve the first.
FAQs
Why are my WordPress changes not showing on the live website?
Your edit may be saved correctly, but visitors may still be receiving an older cached version. Check whether the change is published, then test logged out, in incognito and on another network. If the editor preview is correct but the public page is old, page cache, CDN cache or generated CSS are likely suspects.
Is this a WordPress development problem or a cache problem?
It can be either, which is why diagnosis matters. A development issue may involve the wrong template, conditional display rules or a page builder problem. A cache issue means the right version exists but is not being served publicly. Test one changed element before deciding which route you are dealing with.
Should I clear all cache when WordPress edits are not visible?
Clearing cache may fix the immediate symptom, but doing it blindly does not tell you which layer failed. First prove whether the stale version is in the browser, caching plugin, server cache, CDN or generated assets. Then clear the specific layer where possible and record what worked.
Can a CDN in the UAE or Dubai cause old WordPress pages to show?
Yes. If your website traffic runs through a CDN, it may serve a cached version of a page even after WordPress has saved the new one. This is common on business websites using Cloudflare or host-level performance tools. Test both the public URL and the origin/cache settings before editing the page again.
If your editor and live website disagree, message Standish Services on WhatsApp and we can help trace the stale layer. Identify which layer is serving the stale version before changing the page again.