Documentation
SEO Dashboard & Site Health
Every project has a dashboard that answers one question at a glance: how healthy is this site right now? It combines a single health score, a prioritized fix list, and quick snapshots of your keywords, backlinks, and Core Web Vitals, all built from your most recent crawl.
Nothing on the dashboard is guessed: the score and every issue come from actually fetching your pages and measuring them against a fixed set of checks. Before any of this can run, your domain has to be verified so we know you actually own the site we're about to crawl.
Crawl your site
Score every page
Raise issues
Prioritized fix list
The SEO dashboard & site health score
The top of the dashboard shows four numbers at a glance: your health score (0–100), how many keywords you're tracking, how many backlinks point at your site, and how many critical issues are currently open (with warnings noted alongside). Each of these links through to its full page (keywords, backlinks, or the issues list), so the dashboard is a starting point, not a dead end.
The health score is a weighted average across nine signals measured on every crawled page: title length and page speed each count for 18% of the score, AI/crawler readability (whether your content is visible without JavaScript) counts for 15%, meta description quality and content depth each count for 14%, and single H1 usage, image alt text coverage, mobile-friendliness, and structured data (schema) each count for 8–10%. An info icon next to the score breaks down these weights so you can see exactly what's pulling the number down.
Below the stat cards you'll find a prioritized fix list: the ten highest-priority issues found across your site, ranked by how much impact fixing them would have, how many pages they affect, and how much effort they'd take. Underneath that sits a Core Web Vitals card for your homepage, and if your domain isn't verified yet, a banner walks you through verifying it via a DNS TXT record or a meta tag before any crawling can start.
How crawling works
Clicking Run crawl starts a BullMQ job that walks your site breadth-first from the homepage, following internal links up to three levels deep and up to 100 pages by default. It respects your site's robots.txt: pages disallowed there are skipped and listed separately, and it waits between requests to the same domain so it doesn't hammer your server. It also looks for an XML sitemap, either from a `Sitemap:` line in robots.txt or at the default `/sitemap.xml` location, and uses it to check whether your indexable pages are actually listed there.
If a page comes back blocked (a 403, a 429, a Cloudflare challenge, a captcha, or a generic "bot wall"), the crawler first retries once with a more browser-like identity before giving up on that page or, if configured, falling back to a rendering proxy that can get past JavaScript-based defenses. Pages that look almost empty when fetched directly are also re-rendered once through that same proxy, which is how the dashboard can tell you when your content only appears after JavaScript runs, invisible not just to some search crawlers but to the AI answer engines this product tracks.
A crawl can only run once your domain is verified, and only one crawl runs per project at a time: clicking Run crawl again while one is already queued or running just points you at that same job rather than starting a duplicate. The dashboard's crawl panel shows live status while it's in progress and keeps a short history of your last five runs, noting how many pages were crawled and whether the fallback proxy had to be used. Running a crawl does not refresh your keyword rankings or backlink data; those come from separate processes.
How scoring and checks work
Every crawled page gets its own score from the same nine weighted signals described above, each scored against a specific target: titles are scored best between 50–60 characters, meta descriptions between 140–160, content depth ramps up to a full score around 1,500 words (with anything under 300 words flagged as thin), and server response time scores best under 600ms and drops to zero past 5 seconds. Your project's overall health score is simply the average of every page's score.
Separately from the score, the same crawl surfaces individual issues: things like a missing title or `<h1>`, images without alt text, broken internal links, mixed HTTP/HTTPS content, pages set to `noindex`, missing HSTS headers, or render-blocking scripts in `<head>`. Each issue carries a severity (critical, warning, or notice) and an impact/effort estimate; these combine into the priority score that decides its position in the fix list, so a critical issue affecting many pages with a small fix ranks above a minor issue on one page that's expensive to fix.
Beyond individual pages, the crawl also runs site-wide checks: whether a sitemap exists at all, whether indexable pages are missing from it, whether any noindexed pages are contradictorily still listed in it, and whether robots.txt declares a sitemap location. It also compares pages against each other to catch duplicate titles, duplicate meta descriptions, and canonical tags that collapse multiple distinct pages onto the same target, problems that no single page's score could reveal on its own.