# Migrating from WP Rocket: Delete It First and There Is Nothing Left to Import

> WP Rocket keeps every setting in one wp_options row, and deleting the plugin destroys it. What an importer reads, and which two Advanced Rules boxes never travel.

- Published: 2026-09-10
- Updated: 2026-10-04
- Author: xSpeed Cache Team
- Tags: WP Rocket, Migration, Tutorial, Caching, WordPress, check:D2, fix:migration
- Canonical: https://xspeedcache.com/blog/migrate-from-wp-rocket/

---

Updated September 2026

WP Rocket's own uninstall guide lists eight database tables, eight folders and one `wp_options` row to remove when you take it off by hand, read on 10 September 2026. Our migration importer reads eighteen keys out of that single row, `wp_rocket_settings`, and applies seventeen of them. Delete the plugin first and there is nothing left to read.

The migration people expect is an export followed by an import. WP Rocket has no export. What actually happens is a read of one options row, in a window that closes the moment the plugin is deleted. This guide covers that window, which of WP Rocket's four Advanced Rules boxes survive the trip, and how to prove the new cache took over.

## What travels, what does not

| If you want to… | Do this | Why |
|:---|:---|:---|
| Keep your tuned setup | Import **before** deactivating, never after deleting | `wp_rocket_settings` is destroyed on delete |
| Keep Never Cache URLs and Cookies | Nothing, both are carried automatically | Read straight out of `cache_reject_uri` and `cache_reject_cookies` |
| Keep Never Cache User Agents | Retype them into Bypass User Agents | A destination field exists, no importer mapping |
| Keep Cache Query String(s) | Retype them, and **not** into Ignored Query Parameters | The two boxes look alike and mean opposite things |
| Keep Separate Mobile Cache | Turn it back on deliberately, after importing | Detected, flagged for review, never imported as on |

**Jump to:** [Where the settings live](#where-wp-rocket-keeps-your-settings) · [The order that matters](#do-it-in-this-order-or-there-is-nothing-to-import) · [What the importer reads](#what-the-importer-actually-reads) · [What does not travel](#three-settings-that-do-not-travel) · [Whole fleets](#doing-this-on-twenty-five-client-sites-at-once) · [Proving it worked](#prove-the-new-cache-actually-took-over) · [Common mistakes](#common-mistakes-people-make-leaving-wp-rocket) · [FAQ](#frequently-asked-questions)

## Where WP Rocket keeps your settings

Every option you tuned lives in one serialised array in the options table, under the key `wp_rocket_settings`. Nothing else holds a second copy.

The rest of the footprint is generated output rather than configuration. Per its own uninstall documentation, removing WP Rocket by hand means deleting eight folders under `/wp-content/`, eight `wp_wpr_*` database tables and the `wp-content/advanced-cache.php` drop-in, stripping everything between `#BEGIN WP ROCKET` and `#END WP ROCKET` from `.htaccess`, and setting `define('WP_CACHE', true)` to false in `wp-config.php`.

That same page states the part that decides your migration: uninstalling from the WordPress admin means WP Rocket "will clean after itself automatically, removing any files/folders and modifications". That cleanup takes `wp_rocket_settings` with it.

![Order of operations for a WP Rocket migration: import while the settings row still exists, then deactivate, verify, and delete last.](https://xspeedcache.com/images/blog/migrate-wp-rocket-order.webp)

## Do it in this order, or there is nothing to import

Detection is a read of the options row, not a check that the plugin is switched on. Deactivating WP Rocket leaves the row in place. Deleting it does not. That one fact fixes the order, and it holds whichever plugin you are moving to.

1. **Write down your four Advanced Rules boxes:** Never Cache URL(s), Never Cache Cookies, Never Cache User Agent(s), Cache Query String(s). Ninety seconds now, unrecoverable later.
2. **Install your new cache plugin alongside WP Rocket**, without deactivating anything yet.
3. **Bring the settings across** while the row still exists, with an importer if your new plugin has one, or by retyping.
4. **Deactivate WP Rocket**, so one plugin owns the cache drop-in.
5. **Verify** with the checks below.
6. **Delete WP Rocket last.**

Skip to step 6 first and no importer can help you: the row it reads is gone. The only route back is a database backup.

## What the importer actually reads

xSpeed Cache is ours, built by WPDeveloper, and its migration module ships in the free plugin, not behind a licence. What follows is read from our own source on 10 September 2026: [`includes/class-migration.php`](https://plugins.svn.wordpress.org/xspeed/trunk/includes/class-migration.php), revision 3689601, function `plan_wp_rocket()`.

| WP Rocket key | Lands in | Note |
|:---|:---|:---|
| `purge_cron_interval` | Cache Expiry | Seconds to hours, clamped 1 to 720 |
| `cache_reject_uri` | Excluded URLs | Added to your rules, not over them |
| `cache_reject_cookies` | Excluded Cookies | Same union behaviour |
| `minify_html`, `minify_css`, `minify_js` | Minify | Direct booleans |
| `minify_concatenate_css`, `minify_concatenate_js` | Combine CSS, Combine JS | Direct booleans |
| `defer_all_js` | Defer JS | Direct boolean |
| `lazyload`, `lazyload_iframes`, `lazyload_youtube` | Lazy Load images, iframes, videos | Direct booleans |
| `manual_preload`, `sitemap_preload` | Preloader, daily schedule | Sitemap URLs too |
| `cdn`, `cdn_cnames` | CDN URL | **Only the first CNAME** is taken |
| `do_caching_mobile_files` | Nothing, flagged for review | Explained below |

**The import is additive.** A value that is off in the source never switches off something you already had on, and imported exclusion lists merge with yours rather than replacing them. That is what keeps the shipped safety rules for `/wp-json/`, `/xmlrpc.php`, `/feed/` and `~sitemap(_index)?\.xml` in place.

**Only your first CDN hostname survives.** If WP Rocket held several CNAMEs, the rest are dropped. Check that field afterwards.

## Three settings that do not travel

WP Rocket's Advanced Rules tab holds four boxes. Two are read, two are not, and one of them is a trap.

![WP Rocket's four Advanced Rules boxes and their xSpeed destinations: two carried automatically, one with a field but no mapping, one that means the opposite.](https://xspeedcache.com/images/blog/migrate-wp-rocket-boxes.webp)

| WP Rocket box | Closest xSpeed field | Carried? |
|:---|:---|:---:|
| Never Cache URL(s) | Excluded URLs | ✅ |
| Never Cache Cookies | Excluded Cookies | ✅ |
| Never Cache User Agent(s) | Bypass User Agents | ❌ |
| Cache Query String(s) | Nothing equivalent | ❌ |

**Never Cache User Agents.** WP Rocket stores these in `cache_reject_ua`, and per its documentation the box prevents "cached and optimized pages from being served on certain devices and in certain browsers". Our Cache module has a matching `bypass_user_agents` field, with the same substring, glob and regex matching. The importer never reads the WP Rocket key, so anything you excluded there has to be retyped.

**Cache Query String(s), the trap.** These two boxes look interchangeable and do opposite jobs. WP Rocket's lists parameters that should each get their own cache file, so `?country=italy` and `?country=france` are stored separately. Our Ignored Query Parameters field lists parameters to strip before the cache key is computed, so `?utm_source=x` and the bare URL share one entry. Paste a WP Rocket query-string list in there and you merge exactly the pages you asked WP Rocket to keep apart. Add those pages to Excluded URLs instead.

**Separate Mobile Cache.** WP Rocket switches this on by default, so almost every site has it set. Our importer detects it, records a review flag, and leaves it off. The source comment gives the reason: the static-file fast path is device-blind, and separate mobile caching disables it, dropping the site from a server-level hit to a PHP-level one. Turn it back on if your theme really does serve different HTML per device.

Critical CSS and unused-CSS removal are skipped too: the implementations differ enough that guessing would be worse than asking.

## Doing this on twenty-five client sites at once

A panel is fine for one site. For a fleet, WP-CLI takes the same actions:

```bash
wp xspeed migration status
wp xspeed migration preview --source=wp-rocket
wp xspeed migration apply --source=wp-rocket --deactivate-source
```

`--deactivate-source` is off by default, and the flag's own description says why: "running two page caches at once breaks both, but switching off another plugin is your call, not ours."

Run the preview everywhere first. The count of settings each site would import is the fastest way to spot a client whose configuration is not what you assumed.

For agencies, [xSpeed Hub](https://xspeedcache.com/xspeed-hub/) reaches every attached site from one connection and logs every AI action; [connecting an assistant to every site you own](https://xspeedcache.com/blog/connect-claude-to-every-wordpress-site/) and [our agency use case](https://xspeedcache.com/use-cases/agencies/) cover the rest. On multisite, only a network administrator can switch off a network-activated WP Rocket.

## Prove the new cache actually took over

Run the free [xSpeed Scan](https://xspeedcache.com/scan/) on the page you care about. It needs no account or API key, and check **D2, "page served from cache"**, is the one to read: it reports whether that response was a cache hit and which layer answered. An import that carried every setting and left caching off shows up as a partial, not a pass.

If you would rather check by hand, three commands settle it:

```bash
curl -sI https://example.com/ | grep -i x-xspeed-cache
ls wp-content/cache/
grep WP_CACHE wp-config.php
```

The header should report a hit on the second request. The cache directory should fill with fresh files rather than WP Rocket's old ones. And `WP_CACHE` should still read `true`, because the new cache rewrites the same constant WP Rocket used.

One limit worth stating plainly: no scan can prove your *exclusions* survived, because an exclusion is the absence of a cached response. Load your cart, checkout and account pages while logged in and confirm each is served fresh. There is a deeper walkthrough in [how to check whether WordPress caching is actually working](https://xspeedcache.com/blog/check-wordpress-caching-working/).

## Common mistakes people make leaving WP Rocket

- 🗑️ **Deleting WP Rocket before importing.** Not recoverable from inside WordPress.
- 🔁 **Leaving both plugins active for weeks.** Two page caches compete for `advanced-cache.php`.
- 🧹 **Not purging after the switch.** Old HTML outlives the plugin that made it; [purging without anything changing](https://xspeedcache.com/blog/cache-purge-does-nothing/) covers which of the four caches in front of your URL still has it.
- 📱 **Walking past the mobile review flag.** It sits in the dashboard rather than raising an error.

## Frequently Asked Questions

### I deleted WP Rocket already. Can I still import my settings?

No. Deleting removes the `wp_rocket_settings` row, and that row is the only thing an importer reads. Restore a database backup from before the deletion, or set your exclusions by hand.

### My Migration panel does not list WP Rocket, but the plugin is right there.

The plugin needs to have been configured at least once so its settings row exists. A fresh install that was never saved has nothing to read.

### I imported and got fewer settings than I expected. Is it broken?

No. Only settings with a clean match are imported; options that behave differently are skipped rather than guessed at. The preview lists what will be written before you confirm.

### My site is slower after importing than it was on WP Rocket.

Check Separate Mobile Cache first. It is deliberately not imported, so a site that serves different HTML per device caches one variant for everyone until you switch it back on.

### My cart page is being cached now and it was not before.

Your Never Cache URLs were imported and merged with the shipped ones, so this is more likely a cookie rule. Compare your old Never Cache Cookies list against Excluded Cookies.

### I already tuned my xSpeed settings. Will importing overwrite them?

No. The import writes only values the source actually had enabled, and exclusion lists are merged with yours.

### Is the migration feature free, or do I need a licence?

It is in the free plugin. `MigrationModule::TIER` is set to free in the shipped source, and [Free vs Pro](https://xspeedcache.com/free-vs-pro/) lists Migration as included in Free. Our documentation page still says Pro is required, which is wrong and is being corrected.

### Does this work for W3 Total Cache or LiteSpeed Cache too?

Yes, and WP Super Cache. Those two keep their settings in files on disk rather than the options table, at `wp-content/w3tc-config/master.php` and `wp-content/wp-cache-config.php`, so the files must be readable.

### Do I have to move to xSpeed to leave WP Rocket?

No. Every step above except the import is plugin-agnostic. On LiteSpeed hosting, LiteSpeed Cache is free and its server-level cache is genuinely faster than any PHP-level one. WP Fastest Cache sells a one-time licence rather than a subscription, which some people prefer. Neither ships an importer, so budget the retyping time.

### What happens to WP Rocket's database tables after I delete it?

Deleting from the WordPress admin removes them. Removing the plugin folder over FTP does not, and its uninstall page lists all eight `wp_wpr_*` tables to drop by hand.

## Your migration, in the right order

**What to do this week:**

1. **Write down your four Advanced Rules boxes**, especially Never Cache User Agents and Cache Query String(s).
2. **Import before you deactivate, and delete last.** Run it on staging if you have one.
3. **Read the preview**, including its notes on anything that could not be carried exactly.
4. **Re-check Separate Mobile Cache and your CDN hostname** afterwards.
5. **Run the [free xSpeed Scan](https://xspeedcache.com/scan/) and read check D2**, then load your cart, checkout and account pages while logged in.

Every source plugin's full mapping is in [our migration documentation](https://xspeedcache.com/docs/migration/), and [the 80-capability comparison](https://xspeedcache.com/comparison/) shows which plugins ship an importer at all. xSpeed Cache is one of the few, that module is free, and the Pro layer starts at $29 a year on the founding price with a 14-day money-back guarantee ([pricing](https://xspeedcache.com/pricing/)).

Migrating a caching plugin is mostly bookkeeping. The part that bites is doing the steps in the wrong order, and that part is free to get right.