Your developer says the website update is live.

They may even send you a screenshot showing that the new text, image, button, or design change is clearly there.

Then you open the website on your computer and still see the old version.

Or you can see the change, but a customer tells you they cannot.

Sometimes one employee sees the updated page while another sees something completely different.

This is a surprisingly common website problem, especially on WordPress sites.

It can also be confusing because there may be several systems between the version of the website your developer updated and the version that eventually appears in a customer’s browser.

The good news is that this usually does not mean the website update was lost. The first step is figuring out where the old version of the website is coming from.

Why can two people see different versions of the same website?

Most modern websites use some form of caching.

Caching allows a website, hosting provider, browser, or another service to temporarily save a copy of a page so that it can load faster the next time someone requests it.

That is generally a good thing.

The problem is that there can be several different cached copies involved.

A typical WordPress website might have:

• A copy saved by the visitor’s browser
• A WordPress caching plugin
• Server-level caching provided by the web host
• A CDN such as Cloudflare
• Cached CSS or JavaScript files
• Additional caching added by a theme, page builder, or optimization plugin

Your developer may be seeing the newest version while your computer is receiving an older copy from one of those layers.

That is why simply saying “clear your cache” does not always solve the problem.

You first need to know which cache is serving the old version.

Start by checking whether everyone sees the problem

Before changing anything on the website, try to establish how widespread the issue actually is.

Open the affected page:

• In a private or incognito browser window
• On another device
• On a phone using cellular data instead of Wi-Fi
• In a different browser

If the change appears everywhere except your normal browser, the issue is probably local to that browser or device.

If the old version appears across multiple devices and networks, the problem is much more likely to be somewhere on the website, hosting environment, or CDN.

This is also useful information to give whoever manages your website.

“Customers can’t see the update” is difficult to troubleshoot.

“The old page appears when I open it in Chrome, Safari, and on my phone over cellular data” gives us somewhere to start.

Your browser may still have the old version

Browsers save website files locally so they do not have to download everything again every time you visit a page.

That can include:

• Images
• Stylesheets
• JavaScript
• Fonts
• Sometimes parts of the page itself

This is why a developer can update something and immediately see the correct version while your browser continues displaying something that was downloaded hours or days earlier.

A hard refresh or clearing the browser cache can often resolve this.

But if several customers are experiencing the same issue, browser caching becomes a much less likely explanation.

It is unlikely that all of them independently have the exact same stale files stored on their devices.

At that point, I would start looking farther upstream.

WordPress caching plugins are a common cause

WordPress sites frequently use caching plugins to improve performance.

Depending on the site, that might be something like WP Rocket, LiteSpeed Cache, W3 Total Cache, or another performance tool.

These plugins can save a completed version of a page rather than having WordPress rebuild it every time someone visits.

If that cached page is not cleared after an update, visitors may continue receiving the old version.

This can create an especially confusing situation where:

• The WordPress editor shows the new content
• The developer sees the new content while logged in
• Regular visitors still see the old page

That last distinction is important.

Many caching systems intentionally behave differently for logged-in WordPress administrators. An administrator may bypass a cache entirely while normal website visitors continue receiving the cached version.

So a developer saying “I can see the change” does not necessarily prove customers can see it.

Logged-in users and customers may be seeing different versions

This deserves its own mention because it causes a lot of unnecessary confusion.

WordPress frequently treats logged-in administrators differently from normal visitors.

Caching plugins may skip the cache for administrators.

Page builders may load newer files while someone is logged in.

A development tool may add additional scripts or styles that regular visitors do not receive.

That means the most useful test is usually the public version of the page while logged out.

If a change looks correct inside WordPress but disappears when you open an incognito window, that is a strong clue that some form of caching or generated file is involved.

Your hosting company may also be caching the website

Even after clearing WordPress’s cache, there may be another cache at the hosting level.

Many managed WordPress hosts use server-side caching because it can dramatically improve performance.

That cache exists independently of WordPress.

So you can have a situation where:

1. WordPress contains the correct page.
2. The WordPress cache has been cleared.
3. The hosting platform is still serving an older version.

This is why websites with multiple caching systems can sometimes become frustrating to troubleshoot.

You clear one cache and nothing changes because the stale page is actually coming from another one.

The exact troubleshooting process varies significantly between hosts, so I don’t want to turn this article into a guide for every hosting platform. I’m considering putting together a more technical article specifically about tracing caching problems through WordPress, hosting, and CDN layers later.

For a business owner, the important thing to know is simply that your WordPress dashboard is not necessarily the last system involved before a customer receives the page.

A CDN can continue serving an older copy

Some websites use a Content Delivery Network, commonly called a CDN.

Cloudflare is probably the name business owners encounter most often, although there are many others.

A CDN stores copies of website files on servers in different locations so visitors can receive them quickly.

This can occasionally mean that one location receives a newer version while another location still receives an older cached file.

That is one reason a change may appear correctly for your developer while someone in another city still sees the previous version.

CDNs can cache different things depending on how they are configured. Some only cache static assets such as images, CSS, and JavaScript. Others may cache entire HTML pages.

The distinction becomes important when troubleshooting, but it gets technical fairly quickly. That’s another area I may break into a separate technical article rather than trying to cover every CDN configuration here.

Sometimes the page updated, but the design did not

There is another variation of this problem that can be especially confusing.

Imagine your developer changes:

• A font size
• A button color
• Spacing
• A mobile layout
• A navigation style

The text on the page may update correctly, but the visual change does not appear.

That often points toward cached CSS or JavaScript files rather than the page itself.

CSS controls much of how a website looks. JavaScript controls many interactive features.

Browsers and CDNs tend to cache these files aggressively because they may be used across hundreds of pages.

If a website continues referencing an older version of one of those files, the page content can be completely current while the design remains outdated.

This is also why sometimes a website looks correct on one device and broken on another.

WordPress page builders can add another layer

WordPress page builders and themes sometimes generate their own CSS files.

Elementor is a common example.

You can make a change inside the editor, save it successfully, and still have an older generated stylesheet being served publicly.

Other themes and builders have similar systems.

Optimization plugins may then combine or minify those generated files, creating yet another version that can potentially become stale.

None of this means WordPress is inherently unreliable. It does mean a WordPress website can accumulate several systems that all need to agree about what the current version of a page is.

The more performance plugins, optimization systems, CDNs, and customizations a site has accumulated over the years, the more complicated that chain can become.

Make sure the change was actually made on the live website

Caching gets blamed for a lot, but sometimes the explanation is simpler.

The developer may have made the change on a staging website.

Most professionally managed websites have some type of staging or development environment where updates can be tested before being pushed to the live website.

That is a good practice.

Problems happen when someone believes the changes were deployed but they were never actually moved to production.

This is particularly common when several developers or vendors are involved.

You might have:

• staging.example.com
• A hosting provider’s temporary domain
• A development server
• The actual production website

They can look nearly identical.

If someone accidentally updates the wrong environment, clearing every cache on the live website will accomplish nothing.

One of the first things I check in situations like this is extremely simple:

What exact URL are we looking at?

You would be surprised how often that answers the question.

The deployment itself may have failed

On more customized websites, updates may go through a deployment process rather than being edited directly on the live website.

A developer changes the code, tests it, and then deploys that code to production.

Sometimes that deployment only partially succeeds.

For example:

• A template updates but its CSS does not
• New code reaches one server but not another
• A build process fails
• An old file remains in production
• A deployment is rolled back
• A file permission prevents something from being replaced

This is less common on a relatively simple WordPress site where someone edits a page directly, but it becomes much more relevant on custom websites and complicated WordPress builds.

A proper writeup of deployment failures would get far more technical than this article needs to be. I’m considering covering that separately because it becomes especially useful when multiple developers or hosting environments are involved.

DNS can occasionally make the situation even stranger

DNS tells browsers where a domain should send visitors.

Most content updates have nothing to do with DNS.

But DNS can become relevant after:

• A website migration
• A hosting change
• A major launch
• Moving from a staging environment to production
• Changing a CDN or proxy

If some visitors are being sent to an old server while others are reaching the new one, two people can genuinely be looking at different websites under the same domain name.

That is less common than a normal caching issue, but it is something I would consider when the problem starts immediately after a migration or hosting change.

How can you tell whether the problem is caching or something else?

There is no single test that works for every website, but a few observations can narrow things down quickly.

The change appears in incognito mode

Your normal browser cache is a likely suspect.

The change appears while logged into WordPress but disappears when logged out

A WordPress cache, hosting cache, CDN, or generated asset is more likely.

The text changed but the design did not

Look more closely at CSS, JavaScript, optimization, or page-builder caching.

Nobody outside the development team can see the update

The developer may be bypassing caching, viewing staging, or seeing a different environment.

Different people see different versions

Consider browser caching, CDN caching, multiple servers, or DNS.

The problem started immediately after a migration

Hosting, DNS, CDN configuration, or deployment issues move much higher on the list.

Clearing one cache fixes the problem temporarily and it comes back

There is probably another caching layer or a configuration problem causing stale pages to be generated again.

What should you send your developer?

A little information can save a surprising amount of troubleshooting time.

Send them:

• The exact URL where the problem occurs
• What you expected to see
• What you actually see
• A screenshot
• Whether the problem happens in an incognito window
• Whether it happens on another device
• Whether it happens on cellular data
• Approximately when the change was supposed to go live

If the problem only happens under certain conditions, mention those too.

For example:

“The new header appears while I’m logged into WordPress, but when I open the page in an incognito window I still see the old header.”

That gives a developer a much more useful starting point than:

“The website isn’t updating.”

Be careful about randomly clearing everything

When a website has a caching problem, the instinct is often to start clicking every button labeled Clear Cache, Purge, or Regenerate.

Sometimes that works.

Sometimes it creates more confusion.

This is especially true on busy ecommerce sites, websites using multiple optimization systems, or sites with custom caching rules.

A cache can exist for a reason. Purging it may temporarily increase server load or cause another optimization process to regenerate files.

For a relatively simple brochure website, the risk is usually small. For a complicated website, I prefer knowing which system I’m testing before changing it.

That also makes the diagnosis repeatable.

If the same problem happens three weeks later, you want to know what actually fixed it.

How long should website changes take to appear?

For most normal content changes on a properly configured WordPress website, the public update should appear very quickly after the relevant caches are cleared.

You should not routinely have to wait hours or days for a basic text or image change to become visible.

There are exceptions.

DNS changes can take longer.

A CDN may behave differently depending on configuration.

Search engines obviously have their own crawling and indexing timelines if the complaint is specifically that Google still shows old information.

But if we’re talking about someone opening the actual website and seeing an old version of a page, a persistent delay usually deserves investigation.

When this becomes a bigger website problem

An occasional stale page is not necessarily alarming.

I become more concerned when:

• Updates repeatedly fail to appear
• Nobody knows which caching systems are active
• Developers routinely tell you to clear your browser without investigating further
• The site behaves differently for logged-in and logged-out users and nobody knows why
• Several optimization plugins overlap
• Nobody knows which hosting environment is production
• The website has multiple CDNs or proxies
• The same issue keeps returning
• Changes regularly break something else
• The previous developer is gone and nobody understands how the site was configured

At that point, the problem may be less about one missing website update and more about the technical state of the website itself.

That is especially common with inherited WordPress websites that have passed between multiple developers and agencies.

A website should have a predictable update process

Your website does not need to be simple.

It does need to be understandable enough that someone can answer basic questions like:

• Where is the website hosted?
• Which environment is live?
• What caching systems are being used?
• Is there a CDN?
• Which plugins control performance?
• How are changes deployed?
• How can we verify what a normal customer sees?

When nobody can answer those questions, even a tiny website change can turn into hours of troubleshooting.

And that tends to be the point where businesses start hearing some version of:

“Everything looks fine on our end.”

Meanwhile, the customer is still looking at the old page.

—

Need help figuring out why your WordPress website isn’t updating?

Kismet supports existing WordPress websites, including sites built or previously managed by other developers.

If website changes are not appearing correctly, the first step is figuring out where the old version is being served and why.

That may involve WordPress, caching plugins, hosting, a CDN, a page builder, custom code, or the way the website is being deployed.

For ongoing WordPress troubleshooting, see our WordPress Support Jacksonville service.

—

Written by Joey Zuccarini
COO at Kismet Creative Co.