Most WordPress performance plugins are in the business of making a slow site look faster. They cache pages, they defer scripts, they squeeze images. That work is real and worth doing, but it has a ceiling, and past that ceiling you need something different: a tool that tells you what is actually wrong.
WP Multitool is that second kind of tool. It caches nothing and minifies nothing. It is a set of 19 modules that answer one question, which is why this site is slow, and then point you at the thing to fix.
I installed it on a client site earlier this year, and I have since spent rather more time reading its source code than clicking around in it, which is a habit of mine. I build a backup and rollback plugin, so I have had to solve some of the same problems this one solves, and I know which parts are hard to get right. That is the angle I am reviewing it from.
What is in the box
19 modules, 11 of which come in the cheap Lite edition and all 19 in Pro. Each one is a separate tool that you switch on or off, and a module you have not enabled does not load at all. Two of the heaviest ones ship switched off by default, which is a small decision that tells you something. The site most likely to install a diagnostic plugin is a site already struggling, and that is exactly the site you should not quietly start logging every database query on.
The list covers most of what you end up needing: a database cleaner, an autoload optimiser, a slow query log, a wp-config editor, an image size manager, a shortcode finder, a debug log viewer, a performance column on your plugins page, a front end cleanup panel, and an Action Scheduler cleaner for WooCommerce stores.
Two of them are the reason to buy it. I will spend most of this review on those.
Find Slow Callbacks: the number that is usually wrong
Say a profiler tells you your theme is responsible for 200 milliseconds of a page load. You open the theme file, and there is nothing in it that could possibly take 200 milliseconds.
Here is why. Almost every WordPress profiler measures a function by starting a timer when it begins and stopping it when it ends. The problem is that the function did not spend all that time working. It called other things, which called other things, and every one of those is inside the timer. Your theme's header function fires an event, six plugins are listening to that event, and all six get billed to your theme.
It is like blaming the person who opened a meeting for how long the meeting ran.
WP Multitool separates the two numbers. It shows you what each function spent on its own work, and separately what it cost including everything it set in motion. Those are very different lists. Sorted by its own work, the culprit is usually a function you had never looked at, sitting quietly somewhere in the middle of the old list.
Both numbers stay visible, which matters more than it sounds. A function that does almost nothing itself but triggers something enormous is still a real problem, just a different one. If a function shows 4 milliseconds of its own work and 200 including everything downstream, you know not to bother reading that function, and to go and look at what is hanging off the event it fires instead.
The developer's own release notes give a case from testing where a function reported at 126 milliseconds turned out to be doing 33 milliseconds of work and calling something else that did the remaining 93. On the usual kind of measurement, three quarters of the blame lands on the wrong file.
I have lost afternoons to exactly this problem, using tools that cost more than this plugin does, so I went and read how it does the accounting. It is done properly, including the awkward cases. When a function crashes halfway through being measured the books still balance, and where the arithmetic could produce a nonsensical result it produces a conservative one instead. That is the sort of thing you only write after it has bitten you.
One practical note. This module is genuinely expensive to run, because it has to wrap every single function on the page in order to time it. So it does not run on your live traffic. You give it a URL, it loads that one page with the profiler attached, and it tells you what happened. The module stays off until you turn it on, and it cleans up after itself when you switch it off, which I checked, because plugins that leave files behind irritate me.
Site Doctor: 21 honest questions about Redis
The second module is a whole site scan called Site Doctor. You press one button, it looks at everything, and it hands you a list sorted worst first, with a link to the tool that fixes each item. It is read only and it runs only when you ask it to.
The most interesting part of it is what it does with Redis.
If your site uses Redis as an object cache, almost every tool you can install will check it the same way. Connect, get a reply, show a green tick, done. Including WordPress's own Site Health screen.
The trouble is that Redis does not usually fail by refusing to connect. It fails while looking perfectly healthy. It can be full, throwing away everything your site saves to it as fast as your site saves it. It can be shared with another website whose data you are now serving. It can be a copy that accepts reads but silently rejects writes. It can be far enough away on the network that fetching from it costs more than the database query it was supposed to replace.
Every one of those is worse than having no Redis at all, because you pay for the round trip and then run the query anyway. And every one of them shows a green tick.
Site Doctor asks 21 separate questions instead of one. Is it full. Is it throwing things away, and how fast. What proportion of lookups actually find anything. Are its keys properly separated from other sites. Is this the main server or a copy. How long does a round trip take. And so on down the list.
Two things about how it does this impressed me more than the list itself.
First, it refuses to guess. Several managed hosts, Kinsta and WP Engine and Cloudways among them, block the command that reads the server's configuration. When that happens, the affected checks say they could not verify this here, and tell you how to find out for yourself. They never say everything is fine. That sounds like a small distinction. It is the entire difference between a tool you can act on and a tool that quietly reassures you on managed hosting, which is where an awful lot of WordPress lives.
Second, it never asks Redis to list all of its keys. That is the obvious way to check whether two sites are sharing a cache, and on a busy store it would freeze the server for as long as it takes to walk through everything in it. In other words, the obvious implementation of this check can take your site down. This one takes a small sample instead.
Neither of those decisions is visible in the interface. Both are the difference between a diagnostic you can trust and one you cannot.
The wider scan covers the rest of the usual suspects too. How much data your site loads on every single request before it does anything else, database bloat, slow queries it has caught, whether OPcache is on, whether page caching is genuinely working, and whether somebody left a WooCommerce payment gateway in test mode. There is a command line version of the same scan if you look after a lot of sites.
The rest, briefly
The autoload optimiser deals with a problem most site owners have never heard of. WordPress loads a set of settings on every single request, before it does anything else, and plugins add to that set and rarely clean up after themselves. On a site that has been running for years this can be a megabyte or more of data loaded on every page view, much of it belonging to plugins that were deleted long ago. This module watches which of those settings are genuinely read over a period of real traffic, and lets you switch off the ones nothing has touched. It backs up before it changes anything.
The slow query log records database queries that take too long, along with which plugin or theme fired them, then analyses each one and tells you which database index would fix it. There is no AI involved and nothing is sent anywhere, despite a folder name inside the plugin that suggests otherwise. It is all done locally.
The wp-config editor lets you change the settings in your site's main configuration file through a normal interface instead of an FTP client. This is the file that takes your whole site down if you get it wrong, so I was more interested in the safety work than in the feature. It backs up before every change, it checks the result is valid before saving, and it writes to a temporary file and swaps it into place rather than editing the live file. It also shows you exactly what a restore would change before you commit to it, with passwords hidden.
Then there is a small thing I did not expect and rather admire. If your configuration file is broken in the particular way that stops WordPress starting at all, you lose the admin area, which means you also lose the tool that would have put a backup back. WP Multitool ships a separate rescue command that runs before WordPress does, so you can restore a working configuration with the database completely unreachable. That is the difference between a ten minute problem and an afternoon of restoring from backups. Write the command down somewhere that is not the website.
There is also a nice touch for anyone running several optimisation plugins at once. It reads the settings of WP Rocket, Perfmatters, Autoptimize and a few others, and tells you where you have the same switch turned on in two places, which is a classic source of bugs nobody can explain. It never changes their settings, only offers to turn off its own.
What I would change
The privacy section of the documentation is out of date, and in a way that matters. It says plainly that no data is sent to external servers and that no tracking is included. That stopped being true in version 1.8.0, which added two counters that travel along with the licence check the plugin already makes twice a day. The feature itself is about as respectful as this sort of thing gets. Two numbers, no site content and no addresses, no extra connection, and a switch to turn it off. Which is precisely why the documentation should just say so.
Uninstalling leaves its data behind. Switching the plugin off cleans up properly. Deleting it keeps its settings and its database tables, deliberately, and there is no option anywhere that says remove everything. For a plugin sold to agencies who install things on client sites they later hand over, that option should exist.
The pricing ladder is strange. Lite is $9 once, for 11 modules on as many sites as you like. Pro is $79 a year for all 19 on exactly one site, with a 14 day refund window instead of 30. Pro for unlimited sites is $199 a year. The middle option is the only one limited to a single site and the only one with a shorter guarantee, which makes it read like the tier you are meant to skip.
There is no free version. It is not in the WordPress plugin directory, so there is no way to try it on your own site before paying. $9 is not a real obstacle, but for a tool whose whole pitch is that it tells you the truth about your site, not being able to check that first is the wrong kind of friction.
Verdict
This is a plugin for people who fix WordPress sites, not for people who want a better score out of a speed test. If that is not you, you will not get your money's worth, and to its credit the plugin does not pretend otherwise.
If it is you, and particularly if you look after sites for other people, the two modules I have spent most of this review on are worth the price on their own. Being able to see what a function actually costs, rather than what it costs plus everything it set off, will save you an afternoon the first time it matters. Being told that your Redis cache is quietly throwing away everything you put into it, instead of being shown a green tick, will save you rather more than that.
What convinced me is not the number of modules. It is that the code reads like it was written by somebody who has been burned. The check that refuses to say everything is fine when the host would not let it look. The measurement that stays sane when the arithmetic goes wrong. The rescue command that works when the database does not. You can tell where each of those came from, and that is rarer than any feature list.
Lite is $9 once. Pro is $199 a year for unlimited sites, or $499 as a one off. Current pricing is on the plugin's own site.
