How to Set Up Redis Object Cache in WordPress

WordPress executes database queries on every request. Menus, sidebar widgets, post metadata, user roles, option lookups: the same queries run repeatedly across page loads, returning the same results until something changes. Object caching intercepts those repeated queries and stores the results in Redis, an in-memory data store. Subsequent requests retrieve the cached result in microseconds rather than querying the database again. The effect on sites with database-heavy pages (WooCommerce stores, sites with complex navigation, membership sites) is measurable from the first warm request.

The theory behind object caching is covered in the WordPress caching explained article. This guide focuses on getting Redis object caching running on a VPS using the Redis Object Cache plugin, verifying that it is working correctly, and resolving the common failure modes.

This guide assumes you have a WordPress site running on a VPS with SSH access. Redis must be installed and running on the server before beginning. If you are on Arcadia WordPress hosting, Redis is pre-installed and you can skip to Step 2. For a self-managed server, complete Step 1 to verify Redis is available.

Step 1 - Verifying Redis Is Installed and Running

Before installing the plugin, confirm Redis is listening on the server. Connect via SSH and run:

redis-cli ping

Output:

PONG

If you see PONG, Redis is running and accessible. If the command is not found or the connection is refused, install Redis:

sudo apt install redis-server
sudo systemctl enable redis-server
sudo systemctl start redis-server

Re-run redis-cli ping to confirm it is now running. Redis listens on 127.0.0.1:6379 by default, which is the correct configuration for WordPress object caching on the same server.

Step 2 - Installing the Redis Object Cache Plugin

In this step, you will install the plugin that writes WordPress's object-cache.php drop-in and handles the connection to Redis.

In your WordPress admin, navigate to Plugins > Add New. Search for "Redis Object Cache" and install the plugin by Till Krüss. This is the standard choice for WordPress Redis integration; it is actively maintained and handles the object-cache.php drop-in file correctly. Activate the plugin after installation.

Step 3 - Adding Connection Constants to wp-config.php

On most setups where Redis is running on the same server as WordPress, the plugin connects to 127.0.0.1:6379 automatically without any additional configuration. If you need to specify a custom host, port, or password, add these constants to wp-config.php before the /* That's all, stop editing! */ line:

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );

If your Redis instance requires a password, add:

define( 'WP_REDIS_PASSWORD', 'your_redis_password' );

If Redis is running on the default host and port with no password, skip this step entirely. The plugin defaults are correct for a standard local Redis installation.

Step 4 - Enabling the Object Cache

With Redis running and the plugin active, this step writes the object-cache.php drop-in to wp-content/ and activates caching. WordPress loads this file automatically on every request to intercept object cache reads and writes.

In the WordPress admin, navigate to Settings > Redis. The plugin displays the current connection status. If it shows "Connected", click "Enable Object Cache" to activate caching. The plugin writes an object-cache.php drop-in file to wp-content/. WordPress loads this file automatically on every request, intercepting object cache reads and writes before they reach the database.

Step 5 - Verifying It Is Working

Before relying on the cache in production, confirm it is actually intercepting WordPress's database queries rather than just appearing enabled in the admin.

After enabling, return to Settings > Redis. The diagnostic panel shows connection status, cache hit rate, and the number of cached keys. A freshly enabled cache will show a low hit rate initially because the cache is empty; after a few page loads, the rate climbs as WordPress populates the cache.

Verify via WP-CLI from the server to confirm WordPress is using Redis rather than the default in-memory cache that does not persist between requests:

wp redis status

Output:

Status:       Connected
Host:         127.0.0.1
Port:         6379
Database:     0
Timeout:      1
Read Timeout: 1

To check the hit rate from the command line after the cache has had time to warm up:

redis-cli info stats | grep -E 'keyspace_hits|keyspace_misses'

A hit rate above 80% after normal traffic has run through indicates the cache is working effectively. A persistently low hit rate suggests the cache TTL may be set too short or the queries being cached are too variable in their parameters to benefit from caching.

What a Healthy Cache Looks Like

A well-configured Redis object cache on a typical WordPress site shows a hit rate above 80% after warm-up. Memory usage depends on the complexity of the cached objects; a typical WordPress site uses between 10MB and 50MB of Redis memory for object caching. That is a small fraction of the RAM on even the smallest VPS plan.

Redis evicts cached keys according to the configured maxmemory-policy. The default for a fresh Redis installation is noeviction, which means Redis returns an error rather than evicting keys when memory is full. For WordPress object caching, allkeys-lru (evict least recently used keys first) is more appropriate:

redis-cli config set maxmemory-policy allkeys-lru

This setting does not persist across server restarts. To make it permanent, add maxmemory-policy allkeys-lru to /etc/redis/redis.conf.

Troubleshooting

Connection refused: Redis is not running. Check its status with systemctl status redis-server. If inactive, start it with sudo systemctl start redis-server.

Wrong host or port: If the plugin cannot connect and Redis is running, confirm the constants in wp-config.php match the Redis configuration. Run redis-cli -h 127.0.0.1 -p 6379 ping to verify the default host and port are correct.

Plugin showing "Not Connected" after enabling: Confirm the object-cache.php file was written to wp-content/. The web server user needs write permission on wp-content/ for the plugin to install the drop-in. Check with ls -la /var/www/yoursite.com/public/wp-content/.

Cache hit rate stays near 0%: The object cache may be enabled but the drop-in may not be loading. Verify that WP_CACHE is set to true in wp-config.php.

Redis vs Memcached

Redis and Memcached both work as WordPress object cache backends. Redis is the standard recommendation because it supports persistent storage (the cache survives a server restart), a wider range of data structures (which some plugins use), and has better tooling for inspection and management. Unless you already have Memcached running with a specific reason to use it, Redis is the correct choice.

Your Object Cache Is Active

You have installed Redis, connected it to WordPress via the Redis Object Cache plugin, and confirmed it is intercepting and caching database queries. Monitor cache performance from the Settings > Redis panel or via redis-cli info stats. If you are running WooCommerce, Redis object caching has the most impact on product catalogue pages and checkout-adjacent queries; follow the WooCommerce front-end performance guide to see how it fits into the broader optimisation picture.