AI Site Audit on a 500-Page Site: How Many Chat Sessions It Takes

Under the model in this article, auditing a 500-page website through AI chat takes about 21 sessions and roughly 15 hours of your own time for a single pass. The bigger cost is that the 21 results do not add up to one audit: each session starts without the evidence the others saw, looks at different things on different pages and words its verdicts its own way, so there is no single method to merge and none to repeat next month. AI sessions are excellent at explaining and fixing problems; they do their best work when they start from a complete findings inventory.

Whether you audit a website with ChatGPT, Claude or another assistant, the arithmetic below is the same, because it comes from how chat sessions work rather than from any one product. Our first piece in this series, why one AI session cannot audit a whole website, covered what a single session can reach and modeled sessions per site at 25 and 100 pages each. This one adds up what happens when you keep opening new ones: your hours, and the drift between sessions.

A 500-page site is in the top quarter, and still common

Site size decides everything in this model, so it starts with real sizes. Among 29 external websites SEOReport audited between May and October 2026 whose XML sitemap listed at least one URL, the median sitemap listed about 90 URLs; a quarter listed 20 or fewer, a quarter listed more than 440, and the largest tenth listed more than 3,000.

These are sites submitted for an SEOReport audit, not a random sample of the web. A 500-page site sits just inside the top quarter of them, typically an established business with a blog, service or product pages, and perhaps a few languages. A sitemap lists the pages a site asks search engines to find; tag, filter and archive URLs can sit outside it, so the sitemap count is a floor for what an audit has to consider.

The model: pages per session, then sessions per site

This is a model, not a measurement. Every number in it follows from 4 stated assumptions, and you can change any of them.

1. 25 pages per session. This is the lower of the two capacities used in the first piece of this series. A careful page review reads far more than the visible text: the status code, the response headers, the head tags, the structured data, and how the page relates to the sitemap and to other pages. Across 45 external websites SEOReport audited between May and October 2026, 94% of the 506 issues flagged were somewhere a reader of the page never sees, and the median site had flagged issues in 5 different evidence locations. Holding that much evidence per page and still answering carefully puts a session at the lower capacity, not the higher one. Simple pages allow more; heavy templates allow fewer.
2. 1 extra session for site-wide files. robots.txt, the XML sitemap, and the redirects between HTTP and HTTPS and between the www and bare hostnames.
3. 20 minutes of your time per session. About 10 minutes to restate the method and hand over the page list, and 10 to save the output and merge it into a master list.
4. 1 minute of your time per page. Fetching or pasting the page with its headers, and confirming the session actually read it. Assistant fetch tools often return the page converted to text without its headers, which is why this step exists; what an AI agent sees when it checks your page shows the difference.

The formulas: sessions = pages ÷ 25, rounded up, plus 1. Your minutes = 20 × sessions + pages.

The hours are less sensitive to the per-session assumption than the session count, because the page-handling minutes do not shrink when a session gets bigger. At 10 pages per session, the 500-page site needs 51 sessions and about 25 hours. At 100 pages per session, the generous capacity from the first piece, it needs 6 sessions and still about 10 hours.

The hours also leave out 3 things: the time the assistant spends working, the fixes themselves, and any second pass to check the first.

Why 21 sessions do not add up to one audit

The hours are visible and you can budget for them. The drift is harder to see, and it is what makes the combined result unreliable.

Each session starts without the others' findings. Session 14 does not know that session 3 found the same missing canonical tag on the blog template. It reports it again as if new, or treats a template problem on 180 pages as a one-page note. Project files and memory features carry earlier notes forward, which helps, but notes are conclusions. They do not make session 14 apply session 3's criteria.

Each session decides what to look at. Asked to review a batch of pages, an assistant chooses which signals to check on each one. One session reads the structured data; another skips it because the page looked fine. At the end you know which pages were opened, but not which checks ran on which page.

Each session words its verdicts differently. "Missing canonical", "no rel=canonical link" and "canonical tag absent" are one finding written 3 ways. Severity drifts too: the same issue is "critical" in one session and "minor" in the next. The number that decides priority, how many pages share an issue, only exists after you normalize every line by hand.

Problems between pages fall between sessions. Of the same 45 external websites SEOReport audited between May and October 2026, 32 (71%) had at least one issue that cannot be seen on any single URL: it only appears when the sitemap is compared with the pages it lists, when pages are compared with each other, or when the article library is read as a whole. Splitting a site into batches of 25 splits exactly those comparisons. Two near-duplicate articles reviewed in sessions 4 and 19 never meet, which is one way the duplicate pages behind Duplicate without user-selected canonical survive a page-by-page review.

Next month cannot be repeated. The same question asked twice can come back worded differently and, now and then, judged differently. If you repeat the 21 sessions in December and find fewer issues, you cannot tell whether the site improved or the sessions changed their minds. Without a fixed method there is no baseline to compare against.

flowchart TD
    subgraph many["Many chat sessions"]
        A["Pick the next 25 pages"] --> B["New session: explain the method again"]
        B --> C["Session checks what it chooses, in its own words"]
        C --> D["Copy its findings into your notes"]
        D --> E{"Pages left?"}
        E -->|yes| A
        E -->|no| F["Merge 21 sets of notes by hand"]
        F --> G["No record to repeat next month"]
    end
    subgraph one["One audit, then AI per finding"]
        H["One audit: same method every run"] --> I["Findings inventory with evidence"]
        I --> J["One AI session per finding"]
        J --> K["Later audit, same method"]
        K -->|"finding still open"| J
    end

What one audit changes, and what it does not

An audit samples too. A full SEOReport diagnosis examines the homepage, the pages your sitemap lists and pages your internal links point to. It does not read every page, and each finding drawn from a sample states how many pages it examined, so the scope of every result is on the record.

What it changes is the method. Every diagnosis runs the same defined set of checks in the same way and records the evidence for each, so two reports of the same site are comparable finding by finding. The comparisons that fall between chat sessions happen inside one run: sitemap entries that contradict the pages they list, internal links to missing pages, near-duplicate articles, contradictory article dates and pages nothing links to. The output is one inventory: findings with evidence and affected URLs, a ranked fix plan with verification steps, and exports in PDF, Markdown and JSON. What a scored SEO report contains walks through that structure.

It also changes the size of the AI's job. In 249 external websites SEOReport audited between August 23 and October 4, 2026, the median report flagged 14 distinct issues (failing or warning findings), and a quarter of sites had 17 or more. One issue can affect many pages, but it is still one well-defined task. A work list of about 14 tasks with evidence attached is a very different assignment from 21 open-ended discovery sessions.

What the audit does not do is replace judgement or write the fixes. That is where AI sessions earn their place, which is the point an earlier piece on AI spot-checks made from the other direction.

How to use AI sessions well on a large site

Give the session the findings, not the site. Start each session with one finding, its evidence and its affected URLs. An agent can also create the report and read every finding itself through the REST API or the MCP server, as described on our page for AI agents, so its work starts from the diagnosis instead of rediscovering the site.

Assign one fix per session. A narrow task keeps the session's attention on one cause and makes its answer easy to review. A prompt shaped like this works well:

Finding: XML sitemap lists URLs that redirect.
Evidence: https://www.example.com/old-pricing -> 301 -> https://www.example.com/pricing
          https://www.example.com/team -> 301 -> https://www.example.com/about
Platform: [your CMS, sitemap generator and hosting]
Task: Explain the most likely reason the sitemap still lists these URLs on this
platform, and give the smallest change that makes it list only final URLs.
Address this finding only.

If you must use chat for discovery, write the method down first. Paste the same checklist at the start of every session, assign each session a fixed page list, and require one output format: a table of URL, check, observed value and verdict. Merging then becomes mechanical. This reduces the wording and coverage drift; it does not recover the problems that only appear between pages.

Verify with a later audit and with Google. For anything Search Console reports, fix every affected URL first, then run URL Inspection's "Test live URL" on one of them to confirm Google can fetch the changed page. The live test does not check duplicate or canonical decisions, so for those issues it confirms access only. Then click "Validate fix" on the issue. Google's Page Indexing report documentation (checked October 2026) says validation typically takes up to about two weeks and in some cases much longer. A later report, or weekly monitoring through the API described in continuous SEO monitoring, shows whether the finding has cleared under the same method that found it.

For small sites the picture is gentler: in the model, a 20-page site is 2 sessions and about an hour, and a single-page question needs no audit at all. The cost grows with the site, and so does the value of a repeatable method.

Common questions

Can an assistant with web browsing audit the whole site on its own?

Browsing removes the pasting, so the 1 minute per page in the model shrinks. The assistant still opens pages one at a time, chooses which ones to open, and often receives converted page text rather than the full response with its headers. Tool behavior varies between assistants, and none of it adds a fixed method that runs the same way next month.

Does a larger context window remove the problem?

It raises the number of pages per session, which lowers the session count. In the model, 100 pages per session still means 6 sessions and about 10 hours for a 500-page site, because handling each page takes the same time. It also leaves the drift between runs untouched.

Is 25 pages per session a realistic number?

It is an assumption, chosen for a session that reads headers, head tags and structured data as well as text. Change it to suit your pages and use the formula: sessions = pages ÷ pages per session, rounded up, plus 1. The conclusions about drift do not depend on it.

Should I keep the chat transcripts as my audit record?

Keep them as working notes. A transcript records what a session concluded, usually without the raw evidence it saw, such as the status code and header values at that moment. A record that stores evidence with each finding lets someone check the verdict later and compare it with the next audit.