Redis Object Cache: When to Turn It On, and When Not To
Last updated September 6, 2026
Turn Redis on if your site has a cart, a checkout, memberships, or visitors who log in. On a blog or a brochure site the page cache is already doing that work for you, and this switch is built for the pages a page cache cannot serve. Knowing which is which is the whole of this page.
- Turn it on for
- WooCommerce, memberships, logins
- Leave it off for
- Blogs, brochures, portfolios
- Costs
- Nothing. Included
- Where
- Panel → Redis Cache
Why It Does Nothing for a Blog
There are two caches, and they work at different moments.
| Page cache | Object cache (Redis) | |
|---|---|---|
| What it stores | The finished HTML page | The answers to individual database queries |
| When it helps | Before WordPress starts | After WordPress has started |
| Who it helps | Anyone not logged in | Anyone the page cache cannot serve |
| Typical gain | Hundreds of times faster | Noticeable on complex, uncacheable pages |
On a blog, almost every visitor is anonymous and gets a page the web server already has on disk. WordPress is never started, so there are no database queries for Redis to have saved. Adding it changes a number that was not the problem.
On a shop, the pages that matter most are exactly the ones a page cache must never serve: a cart with somebody’s items in it, a checkout, an account page. Those run WordPress every time, and that is where an object cache is felt.
Turning It On
Open your hosting account in the client area and choose Redis Cache. Every WordPress site we manage is listed with its own switch.

Flip the switch for the site that needs it. The panel installs the object-cache drop-in, connects it, and the site keeps serving throughout. There is nothing to configure and no plugin to install.
Each website’s object cache is private to that website. Nothing else reads it, on your account or anyone else’s.
Flushing It
A Flush button appears beside any site that has the object cache on. It empties that site’s cached query results and nothing else. Reach for it when you have changed something directly in the database, or when a value on the site is stale in a way a page-cache clear did not fix.
“On, but WordPress Cannot Reach Redis”
If the panel says this, the drop-in is installed but Redis is not answering. Your site is not broken. WordPress falls back to querying the database directly, exactly as it does with the cache off. What you have lost is the speed-up, not the site.
Turn the switch off and on again. If it comes back, open a ticket; we can see the node’s own logs and you cannot.
Turning It Off
Flip the switch back. The drop-in is removed and WordPress goes back to the database. Nothing is lost, because an object cache holds only copies of answers it can work out again.
Questions
Does Redis cost extra?
No. It is included, and it is off by default because on most sites it changes nothing worth the moving parts.
Do I need to install a Redis plugin?
No, and please do not. The switch installs and configures the drop-in itself. A plugin like Redis Object Cache added on top will fight with it over the same file.
Will Redis make my WooCommerce store faster?
Usually yes, and specifically on the pages that were always slow: cart, checkout, my-account, and admin. Product listings that anonymous visitors see were already coming from the page cache.
Can another customer see my cached data?
No. Every website’s object cache is private to that website.
Should I turn it on for a staging copy?
There is no need. A staging copy has one visitor: you.