Get Plugin xSpeed Hub
Features

By what you run

WooCommerce storesAgencies & freelancersBlogs & publishersElementor & page buildersMembership & LMSAI & agents

By your business

Home & trade services 3 Food & hospitality 4 Health & wellness 5 Professional services 5 Retail & ecommerce 5 Creative & events 4 Publishing & media 4 Learning & community 4 Tech & agencies 3 All use cases & industries
xSpeed Hub Pricing Docs Blog Scan
Free vs Pro Compare Coverage Support Community
Appearance
Get Plugin

How to cache 404s, search and feeds

Cache 5 min

Extend caching past ordinary pages — cover 404s, search results, RSS feeds and the REST API, and add your own rules and a maintenance bypass.

Page Cache covers your ordinary pages and posts. But a busy site serves plenty of other requests — someone mistyping a URL, a visitor searching, a feed reader polling, an app calling your REST API — and each of those runs full WordPress every single time. Advanced Cache extends coverage to those requests, and gives you a place to write your own caching rules.

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.

Shortcut: open wp-admin/admin.php?page=xspeed#/cache/cache-coverage directly.

⭐ The features on this panel are part of xSpeed Pro.

The three Advanced Cache tabs

Tabs on this panel

This panel is a hub — it owns no settings of its own. Six features live across its three tabs, and each tab has its own guide:

TabFeatureTierGuide
What to cacheCached 404s and search results⭐ ProHow to cache 404s and searches
Feeds & APICached feeds and REST responses⭐ ProHow to cache feeds and the REST API
Rules & bypassURL rules and maintenance bypass⭐ ProHow to add cache rules and bypasses

Each tab has its own address, so you can link straight to one:

TabURL
What to cache#/cache/cache-coverage
Feeds & API#/cache/cache-coverage/beyond
Rules & bypass#/cache/cache-coverage/rules

Which one should you use?

These features aren’t equally valuable, and turning all six on isn’t the goal. Match them to what your site actually gets:

  • A site under bot traffic or with old broken links — 404 caching is the biggest win here. Rendering a 404 template costs the same as rendering a real page, and bots probe missing URLs relentlessly.
  • A content site with a visible search box — search caching. Search queries are among the most expensive things WordPress does, and popular terms repeat far more than you’d expect.
  • A blog with feed subscribers — feed caching. Feed readers poll on a schedule whether or not anything changed.
  • A headless site or one with an app front end — REST API caching.
  • Anything with unusual URL patterns — custom cache rules for the cases the built-ins don’t cover.

💡 Everything here builds on Page Cache. If the main page cache is off, none of these have anywhere to store anything. Start there.

A note on safety

Two of these extend caching into territory where a careless setting can leak data between visitors, and both ship with guards:

  • REST API caching never caches authenticated or write requests. The panel still warns you to add rules only for public, non-personalised routes — because a route that varies per user can leak data even on an anonymous GET.
  • search caching never caches for logged-in users, and never caches empty searches.

The general principle across this panel: cache what’s identical for everyone, never what’s personal to one visitor.