Ten minutes ago the site was slow but working. Then a caching plugin went on, or a few more of its options did, and now the header is a jumble of unstyled text, the mobile menu will not open, or the contact form just spins. Perhaps customers cannot log in. You want two things, in this order: the site back to normal, and then the speed improvement without the damage.
The cause behind most “caching plugin broke my site” moments is almost never the caching itself. It is nearly always one of the optimisation features bundled with it, the options that rewrite how your CSS and JavaScript load. That is good news, because those can be switched off individually. Get the site back first and hunt for the setting second. Trying to do both at once is how a ten-minute problem turns into an afternoon.
Broken, or just showing old content?
Check this first, because the fixes are different. If the site works but shows an older version of a page you edited, that is a stale cache rather than a breakage, and our guide to clearing the right cache when changes do not show walks through each layer. This post is for the other case: something looks wrong or does not work after enabling cache or optimisation options.
Caching plugin broke my site: get it working again first
Work down this list and stop as soon as the site is back. Each step undoes a little more.
1. Turn off the last options you changed
If you can still reach the WordPress dashboard and remember what you switched on, switch exactly that off, then use the plugin’s purge all option. Check the site in a private window. Most breakages are fixed at this step.
2. Turn off all file optimisation, keep caching
If you are not sure what changed, switch off every CSS, JavaScript, HTML and font optimisation option in the plugin, leaving only page caching on. Purge and check again. If the site is fine now, you know the problem is in one of those features and caching itself is innocent.
3. Deactivate the plugin
From Plugins in the dashboard. Most caching plugins remove their server rules and their early-loading file when deactivated. Check the site again in a private window.
4. If you cannot reach the dashboard
Sometimes the admin itself is affected, for example a login page that loops, or an admin that loads without styles. Use your hosting file manager or FTP to open wp-content/plugins and rename the plugin’s folder, for instance by adding -off to its name. WordPress cannot find it, so it treats it as deactivated.
5. Clean up anything left behind
If the site still looks broken, or still serves cached pages, the plugin may have left pieces in place. Check, keeping a copy of each file before editing:
- wp-content/advanced-cache.php. This file lets a caching plugin serve pages early. If it remains after the plugin is gone, rename it.
- The WP_CACHE line in wp-config.php. Caching plugins often add a line setting WP_CACHE to true. With no caching plugin active, that line can be removed or set to false.
- The .htaccess file in the site’s root, on Apache or LiteSpeed servers. Caching plugins add blocks of rules, usually marked with BEGIN and END comments naming the plugin. Remove that block, leaving the standard WordPress rules alone.
- Cache folders inside wp-content, often named cache. Deleting the plugin’s folder inside it is safe. It only holds copies.
6. Clear the other layers
If your host runs a server cache, or you use Cloudflare or another CDN, those may still hold broken copies of pages or combined CSS files created while the plugin was active. Purge them too.
7. Restore a backup, as a last resort
If none of that helps, restore the backup from before the change. If nothing in the list above fixed it, though, the problem may not be the caching plugin at all, so note what you saw before restoring.
Match the symptom to the setting
Once the site is working, you can find the real culprit. What broke usually points straight at it.
| What you see | Most likely setting |
|---|---|
| Page looks unstyled, or styles missing on some page types | CSS combine, unused CSS removal, or loading CSS asynchronously |
| Brief flash of unstyled content before the page settles | Asynchronous CSS or critical CSS that does not cover that page |
| Mobile menu, accordion, slider or pop-up does nothing | JavaScript defer, delay or combine |
| Cookie notice or chat widget never appears | JavaScript delayed until interaction |
| Contact form will not send, or shows a security error | A cached page with an expired security token, or delayed CAPTCHA scripts |
| Icons show as squares, or fonts change | Font or CSS optimisation, or files rewritten to a CDN address that blocks fonts |
| Images missing or blank boxes | Lazy loading, WebP replacement or CDN address rewriting |
| Login page loops, or the admin bar shows to visitors | The login page or logged-in pages being cached |
| Wrong cart contents or prices on a shop | Store pages or cookies not excluded from the cache |
Layout and styling
Combining CSS files changes the order in which styles apply, and a rule that used to win can lose. Removing “unused” CSS relies on the tool spotting every style each page needs. Styles used only on certain templates, after a click, or inside a pop-up are often missed. Turn these off first. If you want them back, try each separately and test several different page types, not only the home page. If the layout stays broken even with every option off, our WordPress layout repair service covers the wider set of causes.
Menus, sliders and pop-ups
Most interactive parts of a WordPress site depend on scripts loading in a certain order, jQuery first and the code that uses it after. Deferring or delaying JavaScript changes that order. Combining scripts can do the same. The plugin will usually let you exclude individual scripts, so exclude the one that broke rather than abandoning the feature. The difference between deferring and loading scripts asynchronously, and why some scripts break, is explained in our post on defer and async JavaScript.
Forms
Two separate causes produce the same symptom. First, a form may carry a short-lived WordPress security code, and that code goes stale after some hours. Serve a cached copy older than that and the code inside it is rejected when the visitor presses send. Shortening the cache lifetime, or using a form plugin that refreshes its token, fixes it. Second, spam protection such as reCAPTCHA or Turnstile may not load if its script is delayed until interaction, so the form never gets its verification. Exclude those scripts from delay. Test by submitting the form logged out, from a page that has been cached for a while.
Logins and accounts
A caching plugin should never cache the login page or pages for logged-in users unless you have set it up to do so deliberately. If users bounce back to the login screen, or visitors see an admin bar, check the plugin’s exclusions and whether logged-in caching was switched on. If logins still loop with the plugin off, the cause lies elsewhere.
Bringing features back one at a time
With the site working and caching on, add optimisation back slowly:
- Enable one feature.
- Purge all caches, including the host and CDN if you have them.
- Check a short list of pages in a private window: the home page, a typical inner page, a page with a form, and on a shop a product page and the checkout.
- On a phone, check the menu and any slider or pop-up.
- Submit the form once.
- Open the browser’s developer tools and look at the Console for new red errors.
- If everything works, note the change and move to the next feature. If not, exclude the script or style that broke, or leave that feature off.
Minification is usually safe and gives a small gain. Combining files often gives little benefit on modern servers. Delaying JavaScript and removing unused CSS give the biggest gains and break the most things. Doing them last, and on a staging copy if you can, saves a lot of stress. If you use LiteSpeed Cache, our staged LiteSpeed Cache setup follows this same order.
When to ask the plugin’s support or your developer
If one feature breaks something and excluding obvious scripts does not help, the plugin’s support or documentation is often the fastest route. Send them:
- The exact feature that causes it, and what you see.
- Any red errors from the browser console, copied as text.
- Your theme and page builder, and the plugin that owns the broken part, such as the slider or form plugin.
- Whether it happens logged in, logged out or both.
That turns a vague “your plugin broke my site” into something they can answer.
Habits that prevent a repeat
- Take a backup before changing caching or optimisation settings.
- Change one setting at a time and test.
- Keep a short note of what is enabled and what was excluded and why.
- Retest the same pages after theme, builder or plugin updates, since an exclusion that worked last month may not cover a new script.
- Run only one plugin for each job: one page cache, one tool for CSS and JavaScript optimisation.
Speed gains are worth having only if the site still works, and our guide to improving website speed puts caching in context with the changes that carry less risk. For how page caching relates to the other caches, see our explanation of website caching.
Frequently asked questions
Will deactivating the caching plugin delete my settings?
Usually not. Most plugins keep their settings in the database when deactivated and only remove them if you delete the plugin, and some keep them even then. Export the settings first if the plugin offers it, so you can restore a working configuration later or share it with support.
Why does the site look fine to me but broken for visitors?
You are probably logged in. Many caching and optimisation plugins skip logged-in users, so you see the original, unoptimised page while visitors get the cached and rewritten version. Check in a private window or a browser where you are not signed in, and ask whoever reported it which device and browser they used.
Is minify safe to leave on after a problem?
Minification on its own rarely breaks a site, because it only removes spaces and comments. If the problem appeared after enabling several options at once, switch all of them off, then turn minify back on alone and test. If the site still works, it is safe to keep, and you can test the others one by one.
Should I switch to a different caching plugin instead?
Often not. The breakage usually comes from optimisation features such as combining or delaying files, which most caching plugins offer and which cause similar problems in all of them. Fixing the specific setting is normally quicker than switching. Change plugins if the one you have does not suit your server or keeps causing trouble.
Once the site is back, the speed gains are still worth having. Our speed optimisation work sets up caching and file optimisation one change at a time, with your approval at each step, and re-tests forms, menus and checkout along the way.
