Plausible integration
Plausible is on the map, not in the product yet.
We read historical and realtime traffic per published page through Plausible's Stats API.
How it works
Plausible connects with a Bearer API key scoped to read-only stats access. We query the Stats API, using the v2 query endpoint for both historical and realtime figures per published page, and stay inside the default limit of 600 requests per hour by batching and scheduling pulls. The connection is as simple as the analytics tool itself: one key, one site, read-only.
In the loop, Plausible is the measure step for teams who picked lightweight, cookieless analytics on purpose. Published pages get judged on the visitors and sources Plausible records, and those numbers feed back into the opportunity engine. Plausible reports aggregates rather than raw events, which covers per-page measurement fully; it just means visitor-level journeys are out of scope by design.
Best forTeams on Plausible who want published content measured with the same lightweight, privacy-respecting tool they chose for their site.
Setup, step by step
- In Plausible, create an API key with the read-only stats scope under your account settings.
- Paste the key into SearchHandled's Plausible connector.
- Confirm the site the key can read and select yours.
- Review the first pull, which backfills historical per-page traffic into your dashboard.
Best practices
Use a stats-scoped key
Plausible lets you scope API keys, and the stats scope is all this integration needs. A key that can only read statistics is a credential with nothing to abuse.
Know the sync rhythm
The default rate limit is 600 requests per hour, so we schedule pulls in batches sized inside it. Dashboards stay current on a steady rhythm rather than refreshing on every page load.
Read aggregates as aggregates
Plausible reports totals and breakdowns, not individual visitor events. Per-page traffic and sources are fully covered; questions about a specific visitor's path are not answerable from this data, by design.
Keep goals defined in Plausible
If you define goals in Plausible, conversion data joins the per-page picture we pull. Defining the goals that matter makes content reports measure outcomes, not just visits.
Known issues
What practitioners actually report, from official docs, issue trackers, and community forums.
Aggregate stats only, no raw events
The Stats API serves aggregated metrics and breakdowns, so visitor-level event streams and individual journeys are not available through the connection.
How we handle itPer-page measurement is built entirely on aggregates, which is what content evaluation needs. We present the data as what it is and never imply visitor-level tracking that the platform deliberately does not do.
plausible.io
The 600 requests per hour rate limit
Pulling many pages across long date ranges can approach the default hourly limit, and requests past it are rejected.
How we handle itWe batch queries and spread scheduled pulls across the hour, sized to stay comfortably inside the limit, so refreshes complete without ever hitting the ceiling.
plausible.io
Questions teams ask
- Does this work with self-hosted Plausible Community Edition?
The integration targets the Stats API, which self-hosted instances also expose. You point the connector at your instance URL with your key, and reachability from the internet is the main requirement.
- Can SearchHandled see individual visitors?
No, and neither can anyone else using Plausible. The platform stores aggregates, not visitor profiles, and the Stats API reflects that. We read totals and breakdowns per page.
- How fresh is the realtime data?
The v2 query endpoint serves realtime figures, and we surface them for recently published pages. Historical reporting runs on a scheduled batch rhythm sized to the rate limit.
Not connectable yet
Start with the plan, not the connector.
Build a Growth Map from your site to see the work itself. Approved pages can leave through the export or the webhook today, and telling us Plausible matters moves it up the rollout.