Hotjar's WordPress plugins (the official Hotjar plugin and the common third-party connectors) all do the same job: inject the Hotjar tracking snippet keyed by a Hotjar Site ID, with optional filtering for excluded roles, specific page templates or post types, and a consent gate that decides whether the snippet fires before the visitor opts in. The recordings, heatmaps and survey results all live at Hotjar's own service and are queried there.

SleekView reads the WordPress options each plugin writes, across one site or every site in a multisite, and renders one row per site with Hotjar Site ID, excluded roles, snippet placement, consent-gate flag and the option_updated timestamp as columns. Sort by missing Site ID to find every site where Hotjar quietly stopped recording. Filter to consent-gate off for a privacy compliance pass. Search across role names to confirm internal staff is filtered out of recordings.

Because the data lives in standard WordPress options, the table works on a single site, a multisite network and an agency fleet managed from a central admin. Inline edits go through update_option, so changes are picked up by the Hotjar embed plugin on the next page load with no extra cache to clear.

Hotjar's value is at the service: session recordings, heatmaps, surveys, conversion funnels, all rendered in the Hotjar UI. The WordPress plugin's role is small but consequential: it decides whether the snippet fires, on which pages, for which roles and behind what consent gate. On a single site that's a five-minute settings job.

On a multisite or an agency portfolio, the cumulative state of those settings is what determines whether the heatmaps are honest, the recordings are compliant and the funnels are not polluted by internal staff. SleekView turns those scattered options into one table: Site IDs in a column, consent-gate flags filterable, excluded roles searchable, last-touched dates sortable. Same plugin, same options, but a query surface privacy officers and agency leads can point quarterly reviews at.