WordPress may look easy, but hidden trackers in Jetpack turn a simple blog into a privacy nightmare.
WordPress has been my go‑to platform for over a decade, but recent changes to Jetpack expose a fundamental flaw: the core experience now forces site owners to run third‑party tracking code inside the admin dashboard. When I blocked those trackers, the media library vanished and image uploads stopped working. In short, WordPress has become a mediocre, extractive product that only functions when you surrender data. Below I break down why Jetpack’s hidden telemetry is a deal‑breaker, how it undermines the promise of a self‑hosted CMS, and what alternatives exist for designers and consumers who value privacy and reliability.
Does Jetpack’s hidden tracking code really break the WordPress admin?
Jetpack was marketed as an optional “all‑in‑one” toolkit—security, stats, lazy loading, you name it. The latest versions embed a tracking script directly into the admin interface, even when you only want to view site statistics. The script routes those stats through WordPress.com’s data‑collection platform, effectively turning the admin panel into a telemetry hub.
When I enabled a browser‑level blocker to stop the script, the admin UI stopped loading the media library and refused new image uploads. The failure isn’t a bug; it’s a safety net that forces you to keep the tracker active or lose core functionality. That design choice turns a paid hosting plan into a hostage situation: pay for WordPress hosting, then pay again with your personal data.
No official WordPress documentation acknowledges this behavior, and the community forums are filled with complaints that the issue disappears only when the tracker is allowed to run. The result is a platform that silently forces you to choose between privacy and basic site management.
Why does self‑hosting matter when WordPress leaks data?
Self‑hosting is often touted as a privacy safeguard because all data stays on your own server, eliminating the need to negotiate data‑processing agreements with a third party. The Matomo analytics suite illustrates this point: because the analytics run on your own hardware, compliance with GDPR, CCPA, and other regulations becomes a matter of configuration, not a legal nightmare with an external vendor—see Why Matomo 5.8 Turns Self‑Hosted Analytics Into the Only Safe Way to Attribute AI‑Assistant Traffic.
Contrast that with WordPress’s default model, where the core software lives on your server but the most useful features (stats, backups, security scans) are delivered by cloud services you cannot audit. When those services inject tracking code into the admin UI, you lose the very privacy advantage that self‑hosting should provide. In practice, the “self‑hosted” label becomes a veneer; the platform still depends on remote data collection that you cannot opt out of without crippling the site.
Can I keep WordPress secure without surrendering data?
WordPress’s ecosystem offers a plethora of security plugins, but many rely on external APIs. Jetpack itself includes a malware scanner that sends file hashes to WordPress.com for analysis. If you block that connection, the scanner stops working, leaving your site exposed.
Self‑hosted alternatives show that you don’t need third‑party clouds for security. ProjectSend’s latest release adds integrated malware scanning hooks that let you connect ClamAV or commercial scanners directly to the upload pipeline, catching malicious files before they ever touch your storage—see Why ProjectSend r2029 Revives the Case for a Simple Self‑Hosted Client Portal. By running the scanner on your own server, you retain full control over what data leaves your environment.
If you’re willing to replace Jetpack’s convenience with self‑hosted tools, you can rebuild the same feature set—stats, backups, security—without hidden telemetry. The trade‑off is a modest increase in technical overhead, but the payoff is a site that truly respects your privacy and that you can maintain without fearing that a blocked tracker will break core functionality.
What are the practical alternatives for image management and media libraries?
The media library failure I experienced is not unique to WordPress. Any platform that mixes third‑party scripts with core admin functions risks breaking essential features when those scripts are blocked. Designers looking for a reliable, privacy‑first image hub should consider self‑hosted media managers or decentralized services.
Pixelfed, a federated photo‑sharing platform, offers a WordPress‑like interface for uploading and organizing images while keeping all data on your own server or a trusted instance—read more in Discover Pixelfed: The Decentralized Alternative to Instagram. Because Pixelfed does not rely on hidden analytics scripts, you can embed its galleries in a WordPress site (or any CMS) without worrying that a blocker will silently disable the library.
Alternatively, the self‑hosted file‑delivery hub described in the ProjectSend article provides a straightforward way to store, scan, and serve images without any third‑party tracking. By decoupling media storage from the WordPress admin, you eliminate the single point of failure that Jetpack creates.
How does the “extractive economics” of WordPress affect site owners financially?
WordPress itself is free, but the ecosystem is built around a subscription model that monetizes data. Jetpack’s premium tiers promise faster stats, advanced backups, and priority support—services that are only useful if you allow the underlying telemetry to run. When you block that telemetry, you either lose the feature or have to purchase an additional plugin that replicates the same function without data collection.
This extractive economics model forces site owners into a perpetual cycle: pay for hosting, pay for plugins, and pay with personal data. The result is a platform that appears inexpensive on the surface but becomes costly in both money and privacy. For designers who build sites for clients, this model is especially problematic because you inherit the client’s data exposure without their explicit consent.
Self‑hosting flips the equation. By running open‑source analytics like Matomo and security tools like ProjectSend on your own hardware, you pay only for the server resources you actually need. The cost is transparent, and the data never leaves your control. The broader argument for self‑hosting is laid out in The Benefits of Self‑Hosting: Why You Should Consider Hosting Your Own Services—the economic incentive to stay on a data‑draining platform like WordPress diminishes.
Is the privacy myth of self‑hosting still relevant for AI‑driven tools?
Some critics argue that self‑hosting is a privacy illusion because modern AI assistants generate traffic that can be misattributed. The article The Self‑Hosted Privacy Myth in Ollama: Why Internet‑Exposed Local AI Is Becoming Its Own Attack Surface shows that even locally run AI can expose you to new attack vectors when you expose it to the internet.
That warning does not invalidate the core advantage of self‑hosting for a CMS. Instead, it highlights the need for proper network segmentation and access controls—practices that are far easier to implement on a self‑hosted stack than on a platform that already embeds remote telemetry. By keeping your WordPress (or alternative) instance behind a firewall and only exposing the necessary front‑end, you preserve the privacy benefits while mitigating the AI‑related risks described in the Ollama analysis.
If you’ve wrestled with Jetpack’s hidden trackers, found your media library mysteriously disabled, or simply want a more transparent way to run a website, I’d love to hear how you’ve navigated the trade‑offs. Share your experiences, suggest other privacy‑first tools, or debate whether WordPress can ever shed its extractive model. Let’s keep the conversation moving toward a web where control stays in the hands of creators, not data brokers.
