Guardian view of your routes & SEO
CavCore Console is the dashboard behind CavBot — an event-first map of pageviews, 404 recoveries, SEO structure, referrers, and runtime feel. Every card on this screen is backed by append-only events and derived tables ready for a future AI layer.
Choose which project, window, and signal CavBot should show here. These knobs drive every card on the console — from 404 density and SEO to referrers and deploy markers.
Sessions, events, and 404 density
A clean roll-up of CavBot’s event stream for this project — every number on this row comes directly from events, sessions, and daily_page_aggregates.
CavBot never stores PII — trends are built from anonymousId, sessionKey, route, and component, not from user accounts.
Route-level SEO snapshots
CavBot takes periodic seo_snapshots per page — title, description, canonical, indexable flags, headings, word count, and social tags.
- Duplicate titles detected on 3 blog posts.
- Missing or thin meta descriptions on 6 marketing pages.
- Canonical mismatch on
/404variant — points to outdated route. - 2 high-traffic pages marked
noindexunintentionally.
These rows feed insight types like seo_missing_meta, duplicate_title, and non_indexable_critical_page.
Performance snapshots per route
From performance_samples, CavBot tracks LCP, TTFB, CLS, and FID per page and device, so slow-but-important pages float to the top.
Canonical map & weak routes
CavBot uses the pages table, internal referrers, and sitemap data to detect orphan and under-linked pages.
This is where CavBot earns its “guardian angel” role: flagging pages that should carry more structural weight.
Who sends traffic into broken routes
CavBot’s referrer_aggregates table rolls up traffic by domain and UTM campaign — highlighting sources that over-index on 404s or thin pages.
Campaign health is computed the same way — aggregating UTM source / medium / campaign with error rates and top landing pages for each.
Bars show relative traffic volume per campaign. Color intensity and badges reuse the same referrer_aggregates and insights schema as the table above, so CavBot can talk about which campaigns are healthiest — or sending visitors into dead ends.
Issues CavBot is watching
The insights table stores typed, severity-ranked findings that future AI layers can “read” and talk about — each with structured context.
Alerts for these insights (webhook, email, dashboard banners) are stored in the alerts table, keeping a clean history of when teams were notified.
Align incidents with releases
CavBot’s deploy_markers table helps you line up 404 spikes, SEO regressions, and perf changes against your own deploy timeline.
Event-first, privacy-respectful
CavBot’s analytics layer is designed to be safe for real production websites: no emails, no names, no long-term IP storage — only coarse, anonymous signal.
- Anonymous visitors only: CavBot uses project-scoped anonymousId, never raw user IDs.
- No PII in payloads: Events avoid emails, names, or custom identifiers by default.
- IP handling: Optional, truncated, and used only for aggregated geography if enabled.
- Append-only events: Raw
eventscan be archived after N days, while daily aggregates and insights are retained longer.
daily_page_aggregates and referrer_aggregates, not raw events.
This project view is intentionally structured so a future CavBot assistant can sit on top of events, seo_snapshots, performance_samples, and insights — without ever needing to see personal identities.