More fixes

WordPress changes not showing on the live site

You changed your opening hours, a price or a photo, pressed Update, and it looks right to you. But a customer, or your own phone, still shows the old version, hours or even days later. Nothing is broken: a copy of the old page is being kept somewhere between WordPress and the visitor, or the change went into a different copy of the site. Below is a rebuilt example (not a real client), a two-minute test that tells you which, and how to clear each one.

The same page, two visitors

What the checks found


  





First: the two-minute test


    
  
  1. Open the page in a private (incognito) window, where you are logged out. Logged-in WordPress users usually skip the cache, so you see the new page and visitors do not. If the private window shows the old version, a cache is holding it; if it shows the new one, the old copy is only in your normal browser (see the first cause).
    2. 
  
  2. Add a made-up query to the address, such as yoursite.com/contact/?test=123. Most caches treat that as a new page. New version with it, old without it: a server or CDN cache, not WordPress.
    3. 
  
  3. Look at who answered. In Chrome, press F12, open the Network tab, reload, click the first row and read the Response Headers. cf-cache-status: HIT means Cloudflare served its stored copy; x-cache: HIT, x-proxy-cache or a large age value means the host's cache did. A caching plugin often leaves a comment at the very bottom of the page source (Ctrl+U) naming itself and when the copy was made.
    4. 
  
  4. Still the old version everywhere, even with the query? Then the cache is not the problem: the change was saved somewhere visitors never see. Go to the last causes.
    5. 




The causes, most common first


    
  
  1. Your own browser kept the old page. Press Ctrl+F5 (Cmd+Shift+R on a Mac) on the page. On a phone, close the tab and open it again, or try another browser. This only fixes what you see; if customers also see the old page, keep going.
    2. 
  
  2. A caching plugin kept the old copy. WP Rocket, W3 Total Cache, WP Super Cache, LiteSpeed Cache and others store finished pages. Most clear the page you edit, but not always the home page, menus, footers or other pages that show the same text (opening hours in the footer appear on every page). Use the plugin's "clear all" or "purge all" button, usually in the black admin bar at the top of the dashboard.
    3. 
  
  3. The host's own cache. Many hosts cache pages on the server whether or not you have a plugin: SiteGround, WP Engine, Kinsta, GoDaddy Managed WordPress and others add a purge button to the admin bar or their control panel. Clear it after the plugin's cache, not before, or the plugin can refill it from the old copy.
    4. 
  
  4. Cloudflare or another CDN. If the headers showed cf-cache-status: HIT, log in to Cloudflare, open the site, then Caching > Configuration > Purge Everything. If it keeps coming back, look for a "Cache Everything" page rule or cache rule with a long edge time; that is the rule doing it. Turn on Development Mode while you work if you change things often.
    5. 
  
  5. A page builder or optimisation plugin kept old CSS. If text changed but a colour, font or layout did not, the styles are stored in separate files. Elementor has a button under Elementor > Tools that regenerates or clears its CSS files; Divi and others have similar settings. Plugins that combine and shrink CSS (Autoptimize, the "minify" options in caching plugins) also need their cache cleared.
    6. 
  
  6. You edited a different copy. A staging or test copy (the address often has "staging" or "dev" in it), a second page with the same title (the real one may end in -2), a draft or a revision that was never published, or a post scheduled for later. Check the address bar in the editor against the page visitors open, and check the page's status reads Published.
    7. 
  
  7. The text is not on the page at all. Opening hours, phone numbers and addresses often live in a widget, the footer, the theme's Customizer, a header plugin or a Google Business Profile embed rather than in the page you edited. Find where it really lives: Appearance > Widgets, Appearance > Customize, or the page builder's header and footer templates.
    8. 
  
  8. You edited the theme's files and an update put them back. Changes made directly in a theme (Appearance > Theme File Editor) are lost when the theme updates. Put them in a child theme or the Customizer's Additional CSS instead.
    9. 




What you see, what it means, what it needs





  
What you seeUsual causeUsual fix

  
New version for you, old for customersYou are logged in and skip the cacheTest in a private window; clear the plugin, host and CDN caches

  
Old version only on your own computer or phoneYour browser's copyCtrl+F5 / Cmd+Shift+R, or reopen the tab

  
New with ?test=123, old withoutServer or CDN cachePurge the host cache, then Cloudflare's

  
Headers show cf-cache-status: HITCloudflare stored the pagePurge Everything; check for a "Cache Everything" rule

  
Text changed, colours or layout did notOld CSS files from a builder or minify pluginRegenerate the builder's CSS; clear the optimisation cache

  
Footer or header still shows old hours on every pageThe text lives in a widget, the Customizer or a templateEdit it there, then clear caches

  
Old everywhere, even in a private window with a queryWrong copy edited, draft not published, or scheduledCheck the editor's address and the page status

  
A change worked, then disappeared after an updateEdited theme files directlyMove it to a child theme or Additional CSS







What not to do



Once you know which layer is holding the old copy, the fix takes minutes. If you would rather hand it over, or the change still will not show, that is what the box below is for. Related: a site that is slow to load, a WooCommerce checkout that fails (often a cache too) and a footer still showing an old year.