isolate-what-you-dont-trust.md

Isolate what you don't trust: the architecture behind Pulse and Aura

Isolate what you don't trust: the architecture behind Pulse and Aura

Date
Jul 7, 2026
Reading time
6 min
Tags

The default stack leaks and looks backwards

The average WordPress site measures and optimizes on autopilot: Google Analytics on top, an SEO plugin from the last decade next to it, done. Two habits, two problems.

Google Analytics calls for a cookie banner and sends visitor data to an advertising company before you've seen your first chart; legally that's been shaky in the EU for years. And the classic SEO plugin still optimizes for a web with one search engine, while more and more people get their answer from an AI system that wants structure and context, not keyword density.

I built two plugins to straighten that out: Pulse for cookieless analytics and Aura for AI-assisted SEO and GEO. Different domains, but under the hood they share one principle that I bring back in almost every project: isolate the part you don't trust.

Pulse: everything stays on your own server

With analytics, the untrustworthy part is the visitor data itself. As soon as you hold or forward personal data, you have a problem; with the law, with your visitor, or with both. So Pulse's design choice is simple: nothing leaves the server, and nothing is stored that can be traced back to a person.

No cookies, so no cookie banner. Instead of tagging a visitor, Pulse builds a short-lived, hashed identifier from request signals, with a salt that rotates. You can tell sessions apart with it, but you can't trace anyone with it, not even me, and that's the point.

And no, this is emphatically not fingerprinting. A browser fingerprint is meant to recognize you everywhere and for a long time; here the salt rotates, so the same visitor can't be matched tomorrow with today. The opposite of a silent fingerprint.

The plugin is tightly layered (PHP 8.4, PSR-4, more than forty test classes):

  • A light ingestion endpoint validates and normalizes every event before it goes into the database. User-agent classification and origin detection happen server-side, not in the browser.
  • The privacy layer (salt store, visitor hasher, exclusion policy) is deliberately a separate, isolated component. Anonymization isn't a side issue you handle somewhere between the lines; it's a module of its own, with its own tests.
  • A set of presenters turns the raw events into the numbers behind every chart: visitors over time, busiest hours, traffic sources, bounce, session duration and page journeys.
  • Maintenance runs on WP-cron: an aggregate roller condenses old events into summaries and a retention policy cleans up the rest, so the tables don't grow forever.
Page journeys as a Sankey diagram in Pulse
Page journeys as a Sankey diagram in Pulse

The nice effect: because the raw data is short-lived and aggregated right away, "privacy by design" here isn't a sticker but a consequence of the architecture. You can't leak what you don't keep.

Aura: SEO for a web where AI reads along too

With Aura, the untrustworthy part is something quite different: a language model. Handy for generating meta texts, but you never want to trust the output blindly. The whole plugin is built around taming that output.

Aura picks up three things you'd normally spread over three plugins and a manual process:

  • Generation of meta titles, descriptions and other SEO fields via Claude or OpenAI, in two modes: fill only empty fields, or overwrite existing ones. The human stays in charge; the AI does the typing.
  • Structured data: a coherent JSON-LD entity graph instead of loose snippets. From a service page, for example, Aura derives a Service with its Offer entities (name, price, currency) and writes that to the <head>, so both Google and an AI system understand what you offer and who's behind it.
  • Scoring on two axes, SEO and GEO, updated live in the Gutenberg editor as you type, with a checklist per topic and historical snapshots.
Aura's SEO and GEO content analysis in the editor
Aura's SEO and GEO content analysis in the editor

That scoring isn't a vague traffic light. Per page you see, per topic, whether something is present, partial or absent: from canonical URL and readability to citable facts, opening answer and rich page entities. That last bunch is exactly what generative engine optimization is about; not "do I score on this keyword", but "can an AI understand, cite and trust my page".

The derived schema.org entities in Aura
The derived schema.org entities in Aura

Under the hood, Aura is the biggest of my plugins (PHP 8.4, PSR-4, some seventy-five test classes), and the layer that shields the model is the core:

  • A provider abstraction with swappable clients for Claude and OpenAI. Request builders, response mappers and a JSON fence stripper absorb the quirks of each API, behind a single interface.
  • A generation pipeline (prompt builder, post reader, field writer) that reads content, builds a prompt and writes the result back to the right fields in a controlled way; never directly, always through a review step.
  • An output layer that builds the entity graph from its own schema.org vocabulary, with a page type resolver and breadcrumb trail.
  • A scoring engine with axis scorers, a topic catalog and an aggregator that adds page scores up into a site analysis.

The shared principle: isolate what you don't trust

Put the two side by side and you see the same move. Pulse pushes the untrustworthy (personal data) into an isolated privacy layer and makes sure it's gone again as fast as possible. Aura pushes the untrustworthy (an LLM) behind a provider interface and a review UI, and never lets the output flow through unfiltered.

That's no coincidence. It's a design rule: the unpredictable part of a system, whether that's sensitive data or a generative model, belongs behind a narrow, explicit boundary you can test completely. Everything outside it, the bulk of the plugin, becomes boring and predictable as a result; and boring is exactly what you want in code that has to last for years.

It's also why both plugins are so easy to test. You swap the salt store for a fake, or the LLM client for a stub that returns a fixed answer, and the rest of the logic just runs around it. The untrustworthy part is thin enough to replace, and the rest is none the wiser.

What it gets you

For the owner of the site the result is prosaic, and that's a compliment. Statistics you switch on and forget, without a banner and without the legal hangover. SEO that moves with how people search in 2026, including the AI that reads along. And in both cases: your data and your logic stay on your own server, without vendor lock-in.

For me as the builder the gain is the architecture underneath. Two plugins with completely different goals, built on the same principle. Once you've shielded the unpredictable, the rest becomes a matter of calm, testable, maintainable work. And that's ultimately what good software is about; not the clever tricks, but the boring edges that keep holding up.