# 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. - Category: Cache - Canonical: https://xspeedcache.com/docs/what-to-cache/ --- [Page Cache](https://xspeedcache.com/docs/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** > > 1. In your WordPress admin, click **xSpeed Cache** in the left menu. > 2. In the xSpeed Cache sidebar, open the **Cache** group. > 3. Click the **Advanced Cache** card, then the **What to cache** tab. > > *Shortcut: open `wp-admin/admin.php?page=xspeed#/cache/cache-coverage` directly.* > > ⭐ The features on this tab are part of **xSpeed Pro**. ![The 404 caching settings](https://xspeedcache.com/_astro/404-caching-settings.CuWNhosT.png) 1. **Cache 404 pages** — the master switch for 404 caching. 2. **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](https://xspeedcache.com/docs/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 ![The search caching settings](https://xspeedcache.com/_astro/search-caching-settings.j2V0jPKX.png) 1. **Cache search results** — the master switch for search caching. 2. **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](https://xspeedcache.com/docs/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. --- ## Related - [How to cache 404s, search and feeds](https://xspeedcache.com/docs/advanced-cache/) - [How to cache feeds and the REST API](https://xspeedcache.com/docs/feeds-and-api/) - [How to add cache rules and bypasses](https://xspeedcache.com/docs/rules-and-bypass/) - [How to enable Page Cache](https://xspeedcache.com/docs/page-cache/)