Crawling & technical audit
How this is scored
Site crawling at real scale: what the crawler finds, how deeply it checks, whether Core Web Vitals and indexation problems are diagnosed rather than merely listed.
0 — No site crawler; the product is keyword data only.
3 — A crawler with a low page cap that reports broken links and missing tags, with no prioritisation and no rendering of JavaScript.
5 — Scheduled crawls at a stated page limit, JavaScript rendering, issue categories with severity, and Core Web Vitals pulled per template.
8 — Log-file or Search Console integration to compare what the crawler sees against what Google fetched, indexation and canonical diagnosis, structured-data validation, and issues prioritised by traffic impact rather than count.
10 — The audit is diagnostic rather than a list: crawl budget analysed, rendering differences surfaced, regressions detected between crawls with the deploy that caused them inferrable, and remediation guidance specific enough for a developer ticket.
The In-House SEO Lead
Crawling runs at real scale — up to 450 URLs per second non-rendered and 350 rendered, millions of pages — with JavaScript rendering via Google's own engine, and findings arrive traffic-weighted: log-file crawl budget breakdowns of which page types receive bot hits, Source Gap and Search Console reports comparing what the crawl found against what Google fetched and clicked, indexation and structured-data categories, and error pages joined to actual visits. Core Web Vitals are measured both in a lab environment through their own rendering service and Lighthouse runs and as origin-level CrUX field data, with per-metric sourcing documented. The AI dev ticket writer turns issues into developer-ready tasks, which is exactly what I need for our board; we found no public information on surfacing rendering differences between crawls. 1 2 3 9