Jetpack Has Forty Modules and You Need Six of Them

A site I looked at in the spring had forty-one Jetpack modules active. Nobody had chosen forty-one. An agency that no longer exists built it, a form broke in its second year, and someone clicked through the settings screen until the form worked again. Every update since has added a module or two to a list nobody reads.

The invoice arrived as a support request that could not be answered. The contact form was delivering roughly one message in three. The host asked, correctly, for plugins to be disabled one at a time, which is impossible on a site where mail runs through Jetpack, the page cache runs through a second plugin, and the login flow depends on a third. Disabling Jetpack long enough to test would have taken the email with it.

That is the case against Jetpack in one paragraph, and not a case against the software. Most of the plugin is good. The module list is what gets judged; the active list is what costs money and weekends. Forty-one modules switched on is a plugin used badly, and the settings screen makes that the path of least resistance.

Disclosure: some links on this page are affiliate links, and WPSifero may earn a commission if you buy through them. That does not change the price you pay, and it does not change what this piece recommends: the modules worth paying for are named below, and so are the ones to leave off.

What the plugin is now, and why the reputation is worse than the software

Jetpack began as a way to get WordPress.com features onto a self-hosted install. One activation turned on sharing buttons, likes, a carousel, infinite scroll, Gravatar hovercards, a mobile theme, image hosting and stats. On the shared hosting of the time that was a visible load, and the reputation dates from there.

The bundle has since been taken apart. The largest pieces are separate plugins now, installed on their own terms: backup, scan, the performance plugin, social scheduling, search, video. That made each piece sensible to run alone, and it left the main plugin's settings screen listing everything a site could turn on rather than what it does. The forty-module figure is an inventory, not a workload and not a bill.

Reputations are slow summaries of early experience. People burned by an install a decade ago have not repeated the test, and a screen that still looks threatening reads as confirmation. The plugin is judged at the level of the bundle while it is used at the level of the module.

There is a real cost underneath that, and naming it keeps this from becoming defence of a vendor. Each active module is a thing that can conflict, a line in the support matrix when a page breaks, and a thing whose update can change behaviour on a Tuesday. The cost is the number of moving parts on a site one person maintains, paid in hours rather than milliseconds.

The architecture has not changed. Several modules still send and receive data through WordPress.com's servers, which is a design decision rather than a defect, and it is the honest reason to decline the plugin. That objection is settled by not installing. The weight objection is settled one module at a time, which is what the rest of this piece is about.

The six modules that usually earn their place

The test, applied six times: does the module replace a plugin that would otherwise be installed, and can the failure it prevents be named without an adjective? Passing both makes a module cheap at almost any price; failing either makes it a liability however little it appears to do.

Backups. The failure is a broken update, a dropped table or a host that goes dark, and the useful part is the restore: one file, one table, one plugin directory, back to the state before the change. The free alternative is a backup plugin aimed at remote storage, or the host's snapshots if they restore to a staging copy. Both suffice for a small site that changes rarely and has tested a restore. The paid version adds the audit trail saying which change caused the break, which is worth it once more than one person edits.

Downtime monitoring. The failure is specific and common: fine pages to logged-out visitors while PHP fails for logged-in ones, or a database that drops when only the checkout notices. Its whole job is to report something you cannot see, which makes it cheap insurance. A free uptime tier pinging one URL is enough for a brochure site, as is monitoring bundled with managed hosting. The paid argument is breadth of checks and an alert on the same timeline as the backups.

The image CDN. The failure is page weight: a theme asking for full-size hero images from a shared host with no edge cache. Rewriting image URLs in the markup has one real advantage over a conventional CDN: no DNS change, so it works where nameservers are not yours. A large edge network's free tier plus a compression step covers similar ground. What this module will not do is shrink an image the theme requested at full size; a resizing pass before upload will.

Brute force protection. The failure is a distributed login attack, which a per-IP limit cannot see, because each address tries once and there are thousands. Blocking at the network level also means nothing has to be undone on removal. A login-attempt limiter or an edge firewall is free and defensible for a site with one administrator. The paid reason is that the blocking decision happens somewhere other than the box under attack, and the module will lock the owner out if the recovery path is not set up first.

Secure sign-on. The failure is a password reused from a breach elsewhere, which complexity rules will not prevent. Two-factor authentication is the fix, and a reputable TOTP plugin does it for nothing. The paid case is narrower than the marketing implies: it matters when several sites and several people share one identity, because then the strongest password on any of them is stored on none of them. It needs a fallback route in before it is switched on.

Stats. Strictly, this prevents nothing. It is decision support: which posts are read, what people searched to find them, whether the newsletter or the search result did the work. Access logs are free, a self-hosted analytics package is free and needs maintenance, and a hosted product carries a consent problem as well as a bill. If nobody opens a report, the module is decoration.

Assembling those six from separate plugins is the wrong trade for a small team, and they are the six the paid tiers exist to sell. Jetpack's plan and module comparison is where to check a plan before buying, because the free one already carries several utility modules and the split changes more often than the names do.

The modules to leave off because something else already does it

Sharing buttons, related posts, likes, hovercards, the carousel and infinite scroll are front-end features from an era when a theme could not be trusted to have them. Now they are a second set of requests, a second set of styles and a second thing to test after a theme update. Sitemaps and lazy loading are worse, because WordPress core produces both, so the module duplicates a default.

Custom CSS belongs to the child theme if there is one; otherwise it is a third place to look when a style is wrong. Markdown, shortcodes and widget visibility are small and mostly harmless, which is why they should go: they will never be remembered during a debugging session. Search duplicates either core search or the search plugin, and the module list is not where to discover which one is answering.

The test is arithmetic. A module that does nothing for a reader still costs a line in the plugin list and one more suspect when a page breaks.

The failure mode of switching everything on

Two plugins fighting over the same hook is what this piece is about, and it looks like nothing until it looks like everything. A contact form module and an SMTP plugin both filter the mailer, so one rewrites the envelope after the other has set it and messages are accepted and never delivered. Two image optimisers rewrite the content filter at different priorities, so the second rewrites the first one's URLs and a subset of images 404s after a cache purge. Two backup processes wake on the same schedule, and the archive that reports success is sixty percent of the database because both were writing when the memory limit hit.

Two login limiters are worse, because they count separately: the attacker gets double the attempts and the owner gets locked out by the one nobody remembered installing. None of this is exotic; it is what an overlapping plugin looks like.

The support request that follows cannot be debugged. The host asks whether the problem persists with plugins off, which changes email, cache and login at once, so the answer is uninterpretable. The vendor asks for a reproduction on a default install, which this site cannot be. Whoever owns it spends a weekend bisecting forty modules and leaves the list at forty, because removing them one at a time is a project. That is how a good plugin becomes a bad reputation: not the code, but the debugging surface it accumulates.

How to audit which modules are actually loading

Start with the active list, not the available one, and write it down with a date. Compare it against what would be installed from scratch today, and the difference is the work.

Then check what the database believes. The module list is stored in an option, and that option is what code reads, so it can disagree with the screen after a partial activation. Where the command line is available, that option can be read and modules switched one at a time, the only sane way to bisect on a live site.

Front-end evidence settles arguments. Load a post, a page, an archive and the login screen with the network panel open. Outbound calls to WordPress.com identify the module that made them, and so do enqueued assets: a handle carrying the plugin's name belongs to a specific module. A module that enqueues nothing and makes no call is either doing background work or nothing, and two weeks of error log after switching it off tells you which.

One trap: hiding a module from the settings screen is not deactivation. Modules can be activated by code, by a host's onboarding, or by another plugin that expects them, and the stored option is the authority rather than the screen.

The decision rule, and when the paid tier is the wrong answer

Some sites should not buy anything here. Managed hosting that provides tested daily backups with one-click restore, an edge firewall and a global cache has duplicated most of the six, and a second backup from elsewhere is not redundancy, it is another thing to keep working. A five-page brochure site with no logins, whose downtime is noticed at lunch, does not need a monitoring contract. An owner who never opens a report should not pay for stats.

Buying a bundle to get one module is the other mistake. If the only need is an image CDN, a free edge tier does that; if it is uptime alerts, a free ping does. The bundle is defensible when the value is the chain: a change recorded, a break detected, a restore that puts it back, all on one timeline. That chain is the product, and the plan breakdown on Jetpack's own site is where to check whether the tier you are considering contains it.

So the rule is one sentence. Switch a module on when both the failure it prevents and the thing it replaced can be named; if only one of the two can be named, leave it off. Re-read the active list whenever the host changes, because the host is usually what made three modules redundant, and nobody sends a notification when it does.