---
title: "SEO audit"
url: "/docs/seo-audit"
canonical_url: "https://crunchjunkie.io/docs/seo-audit"
markdown_url: "https://crunchjunkie.io/docs/seo-audit.md"
language: "en"
type: "doc"
summary: "Crawl a client's website with our own crawler, see first whether AI crawlers can reach and read it, and fix the issues in order of what the affected pages are worth."
site: "CrunchJunkie"
llms_txt: "https://crunchjunkie.io/llms.txt"
---

# SEO audit
Source: https://crunchjunkie.io/docs/seo-audit

Crawl a client's website with our own crawler, see first whether AI crawlers can reach and read it, and fix the issues in order of what the affected pages are worth.

## What the SEO audit does
The SEO audit crawls a client's own website and checks every page it reaches against 189 checks. Open a client and choose SEO audit under Website & crawlers. AI search comes first: whether AI crawlers may fetch the pages under robots.txt, whether a firewall refuses them although robots.txt allows them (we send one test request to the home page with each AI crawler's published user agent), whether the server logs show them being refused, and whether the pages AI answers already cite still work. The classic checks follow: crawlability and indexability, redirects, canonicals, titles and meta, content, internal links, sitemaps, HTTPS, international settings, structured data, performance and HTML.

Every issue is ranked by what the affected pages are worth to the client, not by how many pages it touches. Each check names the evidence it rests on (a standard or a platform's documentation, an emerging convention, or a heuristic) and a source you can open, and only documented behaviour can make an Error. Correct configuration is never a finding, and a page we could not measure is not evaluated rather than failed.

The GEO Audit stays a separate tool: it scores a small sample of pages for AI-search readiness in seconds. The SEO audit is a full crawl.

## Running an audit
Click Run audit. The first time, you confirm that you are authorised to audit the website on its owner's behalf; the confirmation is stored with who gave it, when and for which host, and it is asked again when the client's website changes. Only the client's own website is crawled, with and without www. The start URL can be any https page on it; a start page that redirects to another site stops the crawl.

Under Settings, Parameters to ignore lists up to 100 query parameter names, one per line, the same idea as a URL parameter rule in other crawlers. A URL the crawler finds with one of them, in a link, a sitemap, Search Console or anywhere else, is crawled without it: with topic on the list, /contact/?topic=a and /contact/?topic=b are one page, /contact/, requested once and counted once. Names are compared without regard to case, and the value never matters, so page removes page=1, page=2 and every other value. The URL is never dropped, only the parameter, and the start URL is crawled as you entered it. Add common tracking parameters fills in the UTM parameters and the Google, Meta and Microsoft click ids. The list is empty by default, so nothing is ignored unless you add it; it costs nothing, applies from the next crawl, and each crawl keeps the list it ran with.

Our crawler identifies itself as CrunchJunkieSiteAudit, reads robots.txt before any page, obeys it (there is no override), asks for at most one page a second and follows a Crawl-delay of up to 10 seconds. It keeps what the audit needs, such as status codes, titles and links, and never the text of the pages. After the pages it checks the scripts, styles and images they use and the external pages they link to, one light request each, and on another website only what that site's robots.txt allows. crunchjunkie.io/bot describes the crawler for site owners and how to allow or block it. When a site's firewall answers 429 or 503, the crawler slows down and waits as the site asks, up to 10 minutes at a time, and the running crawl says so: if it stays slow, ask the hoster to exempt the user agent CrunchJunkieSiteAudit from the rate limit, using the section on allowing our crawler on that page. A crawl that cannot measure the site stops and says why: robots.txt answering with a server error (under RFC 9309 the whole site then counts as closed), a hosting placeholder instead of the site, or more than 20 % of recent requests refused. Stop ends a running crawl and keeps and analyses what it fetched.

Pages are included in your plan and nothing is charged. Each workspace has a page allowance per billing period (the calendar month in UTC without a subscription): Solo 5,000, Starter 25,000, Pro 100,000, Agency 250,000, Scale 1,000,000 pages. A trial gets 1,000 pages, at most 500 per crawl. Every internal page we request counts, whatever it answers; URLs closed by robots.txt, scripts, styles, images, external links and the AI-crawler test do not. A crawl reserves its page limit when it starts and gives back what it did not use when it ends, so a crawl that does not fit what is left cannot start. One crawl requests at most 5,000 pages and a client can be audited 5 times a day (UTC); the Run audit dialog shows the page limit, the allowance left and when the period ends.

## Reading Site Health and AI Search Health
Site Health is the share of pages without an Error: pages with no Error divided by the pages evaluated, counted once over the whole crawl, and always shown with both numbers and the crawl's date ("1,018 of 1,240 pages without errors"). A page is evaluated when we requested it and it answered, with any status. URLs closed to us by robots.txt or refusing our crawler are left out and counted beside the score, because a page we could not see has not failed. Warnings and notices never move it.

AI Search Health is the same share over the AI-search errors only. The two are never averaged into one number, and neither is the GEO score. Site-wide errors, such as an expired certificate, robots.txt answering with a server error or a firewall refusing AI crawlers, are named beside the scores rather than counted as pages; they always come first in the fix list.

## Priorities and what the pages are worth
Each page gets a value tier. A key page (V1) is the home page, a page an AI answer cited in the last 30 days, one of the smallest set of pages that earns 80 % of the client's Google clicks over 28 days, or a page in the top 10 for a tracked keyword in the latest Rank Tracker run. V2 is any page with Search Console impressions, a top-20 position, AI-crawler visits in the server logs or a place in a sitemap; V3 is the rest. Without Search Console or AI-visibility data the tiers come from the site's structure alone, and the page says so.

P1 is an Error on a key page or a site-wide Error, P2 an Error on another page or a Warning on a key page, P3 everything else. An issue takes the best priority of its pages, and issues are sorted by priority, then by Google clicks on the affected pages, then by AI answers citing them, then by the pages affected. Each issue says in one line why it is where it is.

The value columns are on the affected pages, never what a fix would recover: Google clicks and impressions from Search Console over 28 days (Pacific days, with the properties read), AI answers citing the pages over the last 30 whole UTC days (each answer counted once even when it cites two affected pages; only engines that name pages count, so Gemini, which names sites, is left out), and tracked keywords in the top 20 in the latest Rank Tracker run. Each figure is labelled with its window and base. A source that is not connected shows "not connected", never zero. The data is joined without the query, so a page's figures are counted once, on one URL: the URL without the query, or, when only query variants were crawled, one of them. Every other query variant (for example /check?domain=x), whether it was fetched or blocked by robots.txt, and a page canonicalised to another URL of the same page show no figures of their own; the page names the URL they are counted on. Such a variant is never a key page and raises no issue that rests on its value, such as "Blocked by robots.txt, yet it has search or AI traffic"; a plain robots.txt block is still reported.

## Issues, Pages and Compare
Overview shows both scores, the site-wide errors, what changed since the previous crawl, the clicks on pages with errors, the issues to fix first and a card per category. Issues lists every issue with filters for category, severity and priority; open one for what it is, why it matters, how to fix it, its evidence basis and source, and the affected pages with their value figures and the detail of each finding, such as the target and anchor of a broken link or the hops of a redirect chain. Notices are information and never count in a score.

Pages lists every URL of the crawl with its status, indexability, depth, links pointing to it, issues, value tier and value figures, with filters and a page view that shows the robots.txt rule each AI crawler meets on it. Both lists export to CSV, with the windows of the value figures in the file. The reported issues export too, all of them from the Issues tab or one issue from its own panel, as CSV, Excel or PDF. The CSV and Excel files list every affected page with what the crawl found on it, and keep muted and ignored issues, labelled with their reason. The PDF is a readable report in your language: the first 20 pages of each issue (up to 500 for a single issue), each value with its window, and a note where the full list is in the CSV or Excel file.

Compare sets a crawl against the previous crawl of the same scope, meaning the same start URL, device and parameters to ignore. That previous crawl is the last one that ran to the end; a crawl that was stopped counts only when no complete one exists. Overview, reports and the assistant also lead with the last complete crawl, and Overview says so when a later crawl was stopped. An issue is fixed only when its page was checked in both crawls and passes now; a page the new crawl did not check is not re-checked, never fixed, and an issue on a page the earlier crawl never reached is on newly checked pages, never new. Crawls of another scope are not comparable, and the page shows the reason instead of numbers. Page details are kept for the latest crawls; older crawls keep their summary.

## Google's view and the monitor
Core Web Vitals come from the Chrome UX Report: the 75th percentile of real Chrome users over 28 days, for the URL or, when the URL has too little traffic, the whole origin, and every figure says which level and which dates it is. Show the trend reads the history live and does not store it; PageSpeed Insights runs on a click (20 a day per client) and only its score is kept. Without a configured key the audit says so and shows no value.

URL Inspection reads Google's verdict and canonical through the client's own Search Console, up to 100 of the most valuable pages per crawl and more on a click. It uses that property's 2000 inspections a day, shared with the client's other tools. Bing's current crawl issues are read from Bing Webmaster Tools when it is connected. All these checks rest on a sample or another service, so they are listed and ranked but never count in Site Health or AI Search Health; one that did not run is not checked, never fixed.

The key-page monitor, off by default, checks chosen pages daily (hourly on Pro and higher) against their last answer, under the same robots.txt and pace, outside the page allowance. A lost status, a new noindex, a changed canonical or a page newly closed by robots.txt raises a Signal, a changed title or H1 a quieter one; a check that got no answer changes nothing, and a server error counts only when the next check repeats it. Checks are kept 90 days.

## If the site slows the audit down or refuses it
A site can push back on a crawler. When it answers our requests with 429 (too many requests) or 503 and asks the crawler to wait, the audit slows down and pauses as asked, so it takes longer, and the crawl lists "The site rate-limited our crawler" (site_rate_limited) for information. Nothing on the pages is counted against the site, and the audit cannot see which limit AI crawlers meet when they read the same site. A request that is refused or met with a challenge is shown as refused, never as a broken page, and a crawl stops when more than 20 % of its recent requests are refused.

To let our crawler through, allow requests whose user agent contains CrunchJunkieSiteAudit in the firewall, CDN or security plugin that applies the limit (for example Imunify360, Cloudflare or a WordPress security plugin). Our requests come from changing cloud addresses, so allow by user agent, not by IP address. [How to allow or block our crawler](https://crunchjunkie.io/bot#allow) shows the user agent, how it treats robots.txt and the rule to add.

## Acting on what the audit found
Mute or ignore an issue, for the whole site or one page, with a reason a teammate can read. A muted issue leaves the lists, the fix list and its Signals; Site Health and AI Search Health still count it. Create task turns an issue into a task in the Approvals queue, with an owner, a due date and the pages it names; nothing is sent anywhere.

Draft the fix with Crunch writes the exact fix for one issue on one page (a tag, a JSON-LD block, robots.txt lines, a redirect rule) from what the crawl stored, only when you click. It never claims the fix will raise rankings or citations, and it marks every value it cannot know with a placeholder. Each draft uses one Ask Crunch message from your plan's monthly allowance and never counts against your checks. A safety ceiling of 60 drafts per workspace a day applies; on your own AI key there is no meter.

A schedule is off until someone switches it on. You choose weekly or monthly, a day and an hour in UTC, and accept the per-crawl cap and the most a month of it can use, which the settings show before you save. A scheduled crawl runs within that cap and never beyond the page allowance; a turn the allowance left cannot cover in full is skipped, not shortened, and a notice says so.

After each crawl the audit raises Signals with both crawl dates and the pages evaluated as their base: new Errors on key pages, a fall in Site Health of 5 points or more between two complete crawls of the same scope with at least 50 pages evaluated in each, an AI crawler blocked on key pages, a cited page that is broken, a crawl the site refused, a certificate about to expire, and a scheduled crawl skipped for want of pages. A standing condition the next complete crawl no longer finds is resolved. Automations can act on all of them.

## In reports
SEO Audit is a report source in the builder and in Draft with AI, rendered the same in the app, on a shared link and in the PDF, in the report's language and without our brand on a white-label report. Its KPIs are Site Health and AI Search Health with their n, the pages evaluated, the issues at Error and at Warning, the issues fixed and new since the previous crawl, and the Google clicks on pages with errors with their window. The chart plots Site Health per crawl with AI Search Health beside it. The tables are the top issues, what was fixed since the previous crawl, AI crawler access (robots.txt and our test request per crawler) and cited pages with problems.

A report never starts a crawl. It reads the last finished crawl on or before the end of the report's period and says "As of" that crawl's date; a change is shown only against a crawl of the same scope. SEO Audit is not a channel, so it is never part of the All channels blend.

## With an assistant (MCP) or the REST API
The connector gives an assistant seven read tools: get_site_audit, list_site_audit_issues, get_site_audit_issue, list_site_audit_pages, get_site_audit_page, compare_site_audits and get_site_audit_history. get_site_audit_issue also returns the facts and rules the in-app fix draft uses, so your assistant can draft the fix itself without a second AI call. Five tools change something and show a preview before anything happens: run_site_audit, stop_site_audit, update_site_audit_settings, set_site_audit_issue_status and create_site_audit_task. run_site_audit also needs the switch "Allow actions that spend AI" under Settings → Connect AI assistants (MCP), because it starts a crawl that uses your page allowance: its preview states the pages, the allowance left and the period's end. The guided prompt site_audit_triage turns the latest crawl into an ordered fix list.

The REST API (v1, read scope) has the same reads under /api/v1/clients/{id}/seo-audit: the audit, issues, one issue, pages, one page (pages/detail?url=), compare and history.