Site Audit
Point Kitbase at a website and it answers one question: what is wrong with it, and what should you fix first?
An audit crawls the pages, checks each one, and returns a single report — a score, a ranked issue list, and the table of every page it reached. The crawl and its rule checks are ours, so that part costs nothing per run beyond time and you can run it as often as you like.
Three of the checks are not ours to give away, and you can turn each of them off before a run:
| Check | What it spends |
|---|---|
| AI page reads | AI credits — a model reads your pages |
| Duplicate detection | AI credits — an embeddings model reads your pages |
| Page speed (Lighthouse) | The same data credits as your other paid SEO data |
If your organization is out of credits, the audit still runs and the parts it could not buy come back empty, rather than the whole audit failing.
What makes this different from a generic SEO crawler
Broken links and missing meta descriptions are a solved commodity. The part worth your attention is the AI-readiness score — whether an AI platform can reach, parse and cite your pages. That is the headline of the report; the issue list is what makes it trustworthy.
Running an audit
Press Run audit on the Site Audit page. The dialog asks two things: which website, and which checks to spend on it. One audit runs at a time per project.
A run starts from the homepage and the sitemap, then follows internal links outward until it reaches its page limit. It respects robots.txt for our user agent, skips assets that are not pages, and holds itself to a polite request rate.
| Option | Default | What it does |
|---|---|---|
| Website | Your project's website | Any address to audit. See Auditing any website. |
| Page limit | 100 | How many pages the crawl may fetch. Higher means longer, not more expensive. |
| Follow links | On | Off crawls only what the sitemap lists — faster, and blind to anything unlisted. |
While it runs you see the phase, the page counts, and the URLs it is crawling right now. Cancel stops it; everything already crawled keeps its results.
Auditing any website
The Website field is prefilled with your project's own site, and leaving it alone is the normal case. Type any other address and the run audits that instead — a competitor, a client's site, a site you are about to acquire. The address is reduced to its domain, so a path or a query is discarded; IP literals, ports and credentials are rejected.
Audits of other websites have a daily allowance
Ten a day per project. The eleventh is refused with a message saying so, and the counter resets at midnight. Audits of your project's own site are unlimited and never touch the allowance.
Two checks are about your project rather than about a website, so they cannot run against somebody else's:
- Traffic & AI visibility grades AI-crawler visits, crawl freshness and share of voice from your own analytics.
- Plan compliance checks a site against your project's approved plan — the addresses, figures and terms you signed off on.
They are skipped on an external run, and the report says they were skipped rather than reporting them as failures.
The rest of Kitbase only ever reads audits of your project's own site. A run pointed at a competitor cannot answer for you — it does not feed recommendations, the assistant, or a workflow.
Choosing which checks run
The dialog lists every check this server can run, each pre-ticked. Untick the ones you do not want and the run does less work; the list is served by the API, so a check added in a later release shows up on its own.
| Check | What it does | Can you turn it off? |
|---|---|---|
| Robots & AI crawler access | Reads robots.txt and grades whether search and AI crawlers are allowed in | No |
| llms.txt | Looks for an llms.txt file describing the site to AI assistants | No |
| Sitemap discovery | Finds and walks the sitemap to discover the site's pages | No |
| Homepage & HTTPS health | Loads the homepage and follows its redirect chain | No |
| Page crawl | Fetches the site's pages, following links up to the page limit | No |
| Edge blocking probe | Sends requests with real AI-bot signatures to detect firewall or CDN blocking | Yes |
| Traffic & AI visibility | Grades AI-crawler visits, crawl freshness and share of voice from your analytics | Yes — own site only |
| Page quality checks | Grades every crawled page: titles, headings, structure, AI-readability signals | Yes |
| Facts & consistency | Cross-checks stated facts, figures and taxonomy for contradictions across pages — this is what fills the Checklist tab | Yes |
| Plan compliance | Checks the site against your approved plan's addresses, figures and terms | Yes — own site only |
| AI page reads | An AI reads key pages and reports how each one positions itself — spends AI credits | Yes |
| Duplicate detection | Embeds page content and clusters near-duplicate pages — spends AI credits | Yes |
| Page speed (Lighthouse) | Measures performance, SEO and accessibility on a sample of pages — spends data credits | Yes |
The five core crawl steps always run — without them there is no audit to report on.
A check you untick appears in the report as not applicable rather than vanishing, and it is left out of the score's numerator and its denominator. A narrower audit is not a worse-scoring one.
A check this server cannot run at all — no measurement provider configured, no AI model available — is shown disabled with the reason next to it, rather than offered and then quietly skipped.
The report
Six tabs: Issues, Pages, Performance, Duplication, Checklist and Scorecard.
Score
The AI-readiness score (0–100) and its three category scores: Crawler access, Machine readability and Analytics. This is the weighted verdict of the 16-item scorecard — a check that passes still counts, which is why the Scorecard keeps its own tab.
Tiles
Pages crawled, issues found by severity, average response time, and how many pages came back blocked, broken or erroring.
When a Performance measurement ran, four more tiles join them: Lighthouse tests, average performance, average SEO and average accessibility. If nothing was measured the four are hidden rather than shown empty — no measurement and a bad measurement must not look the same.
Issues
Every problem the audit found, grouped by severity and then by rule. Expanding a rule explains why it matters, what to do about it, and which pages it affects.
| Severity | Means |
|---|---|
| Critical | Costs traffic or indexing outright — unreachable, unreadable, or blocked. |
| Warning | Real damage, but the page still works. |
| Info | Worth knowing, not worth interrupting anything for. |
Rules come from several places, and each row is chipped with which:
- Crawl — what only a crawl can answer: blocked pages, server errors, broken pages, redirect chains and loops, duplicate meta descriptions, canonical conflicts, slow pages, buried pages.
- Scorecard — a scorecard item that did not hold up. A failure on a heavily-weighted check (AI crawlers blocked at the root) is critical; a light one (no
llms.txt) is not. - Page checks — the per-page content checklist: what one page's title, headings, structure and copy get wrong.
- Consistency — relational findings computed over the whole crawl: links pointing at pages that turned out to be broken, pages nothing links to, pages publishing identical copy, and figures that contradict each other between pages.
- Content — where a page departs from your project's approved plan.
A source you have no permission to see contributes nothing, and the counts are computed after that filter — so a hidden producer cannot be inferred from a total that does not add up.
Orphan pages need a complete crawl
"Nothing links here" is a claim about everything, so it is only reported when the run followed links, read your whole sitemap, and did not stop at its page limit. A partial crawl says nothing about orphans rather than guessing.
Pages
Every page the crawl reached, with its status, title, H1 count, word count, images missing alt text, response time, crawl depth and issue count. Filter by status, search by URL, and sort by slowest, thinnest or deepest.
This is one run's snapshot. Every page number in Kitbase — here, in the assistant's answers, in a workflow that walks your pages — comes from the latest completed audit of your own site, so two figures read at the same moment were measured by the same crawl.
Page detail
Click a row to open one page in full:
- What the crawl measured — status, response time, words, headings, H1 count, images and how many lack alt text, internal and external links, crawl depth, whether it is in the sitemap, whether it is indexable, its canonical and its meta description.
- Page checks — which rules this page failed, what each one found, and how to fix it.
- How a model read this page — present when the run included AI page reads: the question the page answers, what it says it is, how it sits against the rest of the site, and what to change.
- Nearest pages by meaning — the pages closest to this one, best first, from the same embeddings that build the Duplication tab.
First seen and Last changed are carried forward between audits of your own site, so they predate this run: a page first crawled in March still says March. A page with no earlier snapshot to carry from shows neither.
The markup the crawl retained is deliberately not shown. It is an input to the checks, not a report.
Performance
What your pages cost to load, measured with Lighthouse: performance, accessibility, SEO and best-practices scores, plus LCP, CLS, TBT and TTFB. Filter by device or score band, show only the runs that failed, and sort by worst score or slowest metric. View issues opens what Lighthouse actually objected to on that page.
Four things are worth knowing about this tab.
It measures a sample, not the whole crawl. Each measurement is a paid call to a measurement provider, so a run measures your most important pages — the homepage first, then the pages closest to it — rather than every page it crawled. The tab says how many it measured.
It runs after the crawl, not during it. The measurement is a separate job that starts once the crawl finishes, so the rest of your report is readable while this tab is still filling in. The report header says Page speed still measuring and the tab shows Measuring the sampled pages while it runs — results land here on their own within a few minutes, so an empty table right after the crawl means "still measuring", never "nothing was measured".
It spends. Measurements draw on the same data credits as your other paid SEO data. If your organisation is already at its monthly limit, the audit still runs and this tab stays empty rather than the whole audit failing.
It can be absent entirely. The measurement provider is DataForSEO. Self-hosters must set DATAFORSEO_LOGIN and DATAFORSEO_PASSWORD — the same account that powers AI Visibility's Google surfaces, Backlinks and keyword research. Without them the Performance tab stays empty and every other part of the audit works as normal; the tab says so instead of showing a blank table.
Why there is no INP column
INP is a field metric — it needs real visitors interacting with the page. A Lighthouse run is a lab test on one synthetic load, so it cannot produce one. TBT (Total Blocking Time) is the lab stand-in and is what the tab reports. Labelling TBT as INP would be claiming a measurement nobody made.
A page that could not be measured keeps its row and is marked Could not be measured, so a page your server refused to serve is visible rather than silently missing.
Duplication
Which of your pages say the same thing. The run embeds each page's copy and groups the pages that land near each other — grouped, not paired: three pages that each duplicate the next are one problem with three pages in it, and reporting them as pairs would triple the apparent count.
Each group carries its tightest link as a percentage and one of two verdicts:
| Verdict | Means |
|---|---|
| Near-duplicate | Two pages that are nearly the same page. Worth merging, redirecting, or differentiating. |
| Related | Normal for a site that covers one subject. Reported so you can see what the grouping is made of rather than only being shown the alarming half. |
Like page speed, the comparison runs after the crawl — the tab says Comparing pages now and fills in on its own a few minutes later, rather than showing an empty list that reads as "no duplicates".
Reading this tab costs nothing — the vectors were bought once, when the run embedded the pages, and grouping them is free from then on. The tab says so plainly when the run had no embeddings model available or could not afford the pass.
Checklist
Every site-wide check the run graded, including the ones that hold up — the facts and figures your pages state, and whether they agree with each other. The issue list can only ever tell you what is wrong; this is the only place that can say "seventeen checks ran and fifteen hold up", which is what turns an accusation into a measurement.
Filter by All, Problems or Holding up. Each row explains what the check is, what this run measured, how to fix it, and which pages it names — empty when the finding is a count or a comparison rather than a set of pages.
Scorecard
The 16-item AI-readiness checklist behind the score, including the items that passed. Any single check can be re-run on its own with Re-check without starting a new audit.
Checks you left out of the run appear here as not applicable, so a shorter run is legible as a shorter run.
Export
Export hands you the Issues, Pages or Performance tab as CSV or JSON, filtered exactly as the screen is.
Report (PDF) is the whole report as one document: the score and its three category scores, the run's stats, any notice about what the crawl did not cover, and the full issue list — every rule with its description and its fix, whichever tab you happened to be on. It opens your browser's print dialog, where Save as PDF is the destination, so the file carries selectable text and live links rather than a picture of the screen. The affected URLs stay in the app: one bad template can put thousands of them under a single rule, so the PDF prints how many pages each rule hit and leaves the list where you can filter it.
Sharing a report
Share on a finished audit mints one public link. Anyone holding it can open the report without a Kitbase account.
The token in the URL is the credential — there is no second check behind it. Treat the link the way you would treat the report itself.
| What the reader sees | The domain, the dates, the AI-readiness score and its three category scores, the graded scorecard with the sentence explaining each verdict, the ranked issue list, and the page table cut down to URL, status, title, word count and response time. |
| What never travels with it | Your organization and project, who shared it, the AI page reads, the retained page content, and the evidence behind the analytics checks — that evidence is your own traffic and AI-visibility data. Analytics checks keep their verdict and its sentence, and lose their workings. |
The redaction happens on the server, so there is nothing sensitive in the response for a reader to dig out.
Pressing Share twice hands out the same link — two people sharing one report cannot end up distributing two different URLs. Only a completed audit can be shared; a run still crawling has no report to hand anybody.
Turn off this link revokes it. The link stops working immediately and answers "not available", indistinguishable from a token that never existed. Sharing again mints a new link rather than reviving the old one, so a link you have revoked stays revoked.
Reviewing an article before it is published
An audit reads a crawl, so the earliest it can see a new article is after it is live. Review a draft, the second tab of Website Scan, takes the file instead: drop a markdown or HTML file on the panel or paste the text, and the same checks that grade a published page grade the draft — plus the one only a pre-publish review can make, whether it contradicts something the site already says.
That last part is why the timing matters. A wrong figure is quotable the moment it publishes, and the next crawl finds it only after an answer engine has already lifted it.
Front matter is read for the title and description, so an ordinary blog file needs nothing else filled in. Where it will publish is optional and worth giving when you know it: it lets the review check the draft against the page already at that address.
The verdict answers one question. This contradicts what your site already says is reserved for exactly that — a figure, a structure count or a title the site has already committed to differently. A thin description or a missing opening answer comes back as something to fix, not as a contradiction. Under it, every check is listed with what it measured and what to do about it, passes included, because "two of fourteen" and "two of two" are different pieces.
What it grades depends on what you send. A markdown file is the prose you own — opening answer, question headings, statistics, heading order, lists, length, title, description, image alt text. Structured data, social tags and the byline belong to the template that renders it, so they are only asked of an HTML draft, which is the whole page.
Nothing is stored. The draft is graded and forgotten: no audit row, no findings, no copy of the text, which is why there is no history of past reviews to open. Everything a live URL is needed for — status, canonical, sitemap membership, AI-crawler access, citations — still waits for an audit, and the review names what it left out rather than passing a draft as fully checked.
The comparison needs a completed audit of your own website. Without one the prose checks still run and the page says so.
Your coding agent can run the same review on a file without opening the dashboard — see audit_draft on the MCP server.
Audit history
The Site Audit page lists every audit the project has run, newest first, with the site it audited, its status, its score, when it started and how long it took. Open any one of them to read that run's full report, or delete it from the row menu — deleting one audit takes its checks, pages, findings and measurements with it and leaves the others alone.
An audit that is still running cannot be deleted. Cancel it first, so that stopping a run and discarding it stay two decisions rather than one button that quietly does both.
When something is blocked
If bot protection turns our crawler away, the report says so plainly rather than reporting hundreds of phantom broken pages. Allowlist the user agent to fix it:
Mozilla/5.0 (compatible; KitbaseAuditBot/1.0; +https://kitbase.dev/audit-bot)Every AI crawler meets the same wall you put in front of ours, so this is worth fixing for its own sake. See Bot & Crawler Detection for what our crawler does and how to recognise it.
Older audits
Audits run before this release keep their score and scorecard but have no issue list or page table — they were sampled, not crawled. Audits older than the tab that reads them have nothing in it either: no measurements before Performance existed, no groups before Duplication, no graded checklist before Checklist. The report names that rather than showing an empty list. Run a new audit for the full report.