How to cache 404s and searches
Two request types that cost a full page render and usually aren't cached — unknown URLs and search queries. Cache both, with lifetimes short enough to stay accurate.
Page Cache covers pages that exist. This tab covers two request types it doesn’t: someone hitting a URL that isn’t there, and someone using your search box. Both run WordPress from scratch every time, and both repeat far more than you’d expect — bots probe missing URLs relentlessly, and real visitors converge on the same search terms.
Where to find it
- In your WordPress admin, click xSpeed Cache in the left menu.
- In the xSpeed Cache sidebar, open the Cache group.
- Click the Advanced Cache card, then the What to cache tab.
Shortcut: open
wp-admin/admin.php?page=xspeed#/cache/cache-coveragedirectly.⭐ The features on this tab are part of xSpeed Pro.
- Cache 404 pages — the master switch for 404 caching.
- 404 cache lifetime — how long a cached 404 lives before regenerating.
Settings at a glance
| Setting | Default | What it does |
|---|---|---|
| Cache 404 pages | Off | Serve unknown URLs a cached 404. |
| 404 cache lifetime | 5 minutes | How long before a cached 404 regenerates. Range 1–1440. |
| Cache search results | Off | Serve repeated searches from cache. |
| Search cache lifetime | 10 minutes | How long a cached result set lives. Range 1–1440. |
How it works
Both features work the same way: the first request renders normally and the result is saved; matching later requests get the saved copy. Both store into the Page Cache, so it must be on for either to do anything.
What they share, and what makes them safe, is that both lifetimes are deliberately short and both purge immediately when content changes. That combination is what lets you cache request types that would otherwise be risky to cache at all.
Cache 404 pages
A missing page costs exactly as much to produce as a real one. WordPress runs its full bootstrap, fails to find the post, then renders your 404 template — every time, for every bad URL. On a site with old broken links or steady bot traffic that’s thousands of full page builds a day for pages nobody wanted.
The HTTP status stays correct. This is the part that matters for SEO: visitors and crawlers still receive a real 404 Not Found, not a 200 OK containing 404-looking content. Search engines treat the page exactly as they should — nothing about your indexing changes. Your server just stops doing the work twice.
Why the 404 lifetime is short
The default is 5 minutes, which looks stingy next to Page Cache’s 7 days. There’s a reason.
Consider a URL that 404s today because you haven’t published that post yet — then you publish at that exact address. With a long lifetime, visitors would keep getting “not found” for a page that now exists, with no obvious clue why. A short lifetime bounds that window.
Two protections combine: the short default caps how long a stale 404 survives, and publishing or updating content purges cached 404s immediately, so the common case resolves instantly. Range is 1 to 1440 minutes; raise it only if your URL structure is genuinely static and you’re being hammered by bots.
⚠️ A long 404 lifetime can mask new content. If you publish to a URL that previously 404’d — a scheduled post, a restored page, a fixed slug — a stale cached 404 can hide it. The 5-minute default exists for exactly this reason.
Cache search results
- Cache search results — the master switch for search caching.
- Search cache lifetime — how long a cached result set lives.
A WordPress search runs a LIKE query across your posts table — no index helps much, and cost grows with your content. It’s among the most expensive things WordPress does, and searches repeat: on most sites a small set of terms accounts for the majority of queries.
Each distinct search term is cached separately. A search for “pricing” and one for “support” are different entries; one doesn’t serve the other. So the benefit scales with repetition.
Two things are never cached, both deliberately:
- Empty searches — not a meaningful result set, nothing worth storing.
- Logged-in users — results can vary by user (private posts, drafts, restricted content), so they always get a fresh query. Same principle as Page Cache: never serve one person’s view to another.
Choosing a search lifetime
Default 10 minutes, range 1 to 1440. Short is right, because search results shift as content changes far more visibly than an ordinary page does — publish a post that should match a popular term, and a long-lived cached result set would keep hiding it.
As with 404s, publishing purges cached searches immediately, so new content becomes findable straight away rather than waiting out the lifetime.
- Content-heavy site with steady publishing — keep it short; 10 minutes is well judged.
- Reference site or documentation — a longer lifetime is safe, since content rarely changes.
💡 The win depends on repetition. If every visitor searches something different, you’ll cache many entries and hit few. Check your search logs: if a top-ten list of terms covers most searches, this pays off well.