Site Audit With GPT-6 Astra: Crawl, Triage, Verify

Most site audits fail at the same place, and it is not the crawl. A tool returns 400 issues, you fix the twelve that were easy to fix, and the list is still 388 long a month later. The crawling was never the hard part. Deciding what to ignore was.

That is why GPT-6 Astra is more interesting for audits than for most SEO jobs. Not because it can crawl, because it cannot. Because it can hold the entire result set in working memory while it decides what actually matters for your site, instead of triaging one page at a time and forgetting the first page by the twentieth.

There is a catch, and it flips the usual constraint. With a window this large, context stops being what limits you. What limits you is what the crawl costs.

What Astra brings, and what it does not

It does not crawl. A language model cannot fetch fifty of your pages and parse the HTML. It needs a tool for that, and if you ask it to audit your site with nothing connected, you will get a plausible-sounding audit of a page it half remembers. Astra’s knowledge cutoff is April 30, 2026 on the official model page, so for anything you have shipped since, it is guessing.

It does triage, and that is the expensive half. Given a real crawl, the useful questions are which of these issues actually costs traffic, which pages are worth the effort at all, and what is the smallest set of changes that moves the most. Those are judgment calls over a large pile of evidence. That is the job the big window is for.

It is strong at browser and computer-use work, which matters at the end of the loop rather than the start. Details and benchmarks are in the full GPT-6 Astra breakdown.

Why triage across the whole crawl is different

Here is the thing a smaller window forces you into.

You audit 25 pages. The findings do not all fit, so you work through them in batches. By batch three, the model no longer has batch one in context. It cannot tell you that the same missing canonical appears on nine pages, or that four of your thin pages are thin in the same way because they came from the same template. So you get 400 individual findings instead of six underlying causes.

With a million-token window, the whole result set stays in front of it. Ask for causes instead of issues and you get a genuinely different answer.

Copy this prompt

Here is the full audit output for my site.
Do not list the issues back to me.
Group them into underlying causes, ordered by how many pages each affects.
For each cause, tell me the single change that fixes all of its pages at once,
and name any that are not worth fixing on a site my size.

That last clause is the important one. A tool that reports everything has no opinion about your site. A model that can see your whole crawl at once can have one, and telling you what to ignore is more valuable than another sorted list.

The constraint flipped, and it is worth saying plainly

For two years the limit on agent SEO work was how much you could fit in the conversation. Astra largely removes that. So the honest thing to point out is that the limit is now what the data costs.

Audits are metered per page, near enough everywhere, and ours is no exception. With ContextBolt SEO a site audit costs one credit per page checked. A 25-page run is 25 credits, and the monthly plan includes 1,000, so a weekly audit of your important pages is a rounding error.

The guardrail matters more than the price here, because you are not the one issuing the calls. Our audit is capped at 50 pages in a single run and defaults to 25, so an agent cannot decide on your behalf to crawl five thousand. Re-running “audit my site” re-checks the pages already covered rather than expanding into new ones, and reaching further takes an explicit instruction. And you do not have to check your balance first. If you run out mid-audit, the tool itself returns a plain failure with the top-up link rather than failing silently.

That design exists because the failure mode is specific to agents. A human running an audit chooses the scope. A model running one will take whatever ceiling you leave it.

Why 25 pages is usually the right number

Auditing everything feels thorough and is mostly waste.

Search traffic on almost every site is concentrated in a small number of pages. Fixing a title on the page that earns 1,200 clicks a month is worth more than fixing forty pages that earn nothing between them. A run scoped to your top pages by impressions is not a compromise, it is the correct scope.

So take the page list from your own Search Console rather than from a sitemap. Audit what earns, fix what earns, and let the long tail wait until it is doing something.

What the audit actually checks

Worth knowing before you read a report, because the findings split into two kinds and only one of them needs a site-wide run.

Per-page problems. A missing title, a missing meta description, a title that runs too long to render, thin content, a page that does not return properly, a canonical tag pointing at a broken URL, a sitemap entry that redirects. Any single-page audit catches these one page at a time. You do not need a crawl for them, and you do not need Astra either.

Problems that only exist across pages. Two posts competing on the same title. Forty pages sharing one meta description because a template forgot to fill it in. A duplicate is genuinely invisible from inside a single page, because each page on its own looks fine. It is only a duplicate next to the other one.

The per-page list matters too, but it scales differently. One broken canonical is a page audit. The same broken canonical on every page built from one layout is a pattern, and you only see the pattern with the whole crawl in front of you.

That second group is the argument for a site audit at all, and it is where a large context window earns its keep. Holding every title at once is what makes a duplicate obvious.

What to fix first, and what to leave

The report will be ordered by severity. Severity is not the same as impact on you, and this is where most audit follow-through dies.

Fix anything that stops a page being indexed or understood. A canonical pointing at a broken URL, a redirect loop, a page returning the wrong status. These are not cosmetic. A page Google cannot resolve earns nothing regardless of how good it is.

Then fix the things that affect pages already earning. A too-long title on a page sitting 6th is worth more than a missing description on a page nobody finds. Cross-reference the audit against your top pages by impressions and do that intersection first. It is usually about five changes.

Then fix anything that repeats across a template. One bad pattern on forty pages is one edit and forty fixes. This is the best ratio available to you and it is the thing a site-wide view exists to find.

And leave the rest. Thin content on a page you wrote for a customer who asked, an unoptimized title on a legal page, a missing description on a tag archive. These will sit in every report you ever run. Deciding not to fix them is a decision, and it is the one that lets you close the tab.

If you are not sure whether something belongs in the last group, the question is whether the page it affects has earned a click in the last three months. If it has not, the audit finding is not the reason.

Verify against what is served, not what you edited

This is where audits quietly go wrong, and Astra’s browser ability is genuinely useful here.

The file in your repo and the HTML Google receives are two different artifacts. A template can strip a tag. A build step can rewrite a canonical. A CDN can serve a cached copy for hours after you deploy. Every one of those produces a fix that is real in your editor and absent in production.

So close the loop properly.

• Re-run the audit after the change, and compare against the previous run rather than reading the new one cold.
• Load the live URL, not the source file, and read what actually came back.
• Give the cache a moment. One bad response straight after a deploy is a sample, not a verdict. Check twice before you conclude the fix failed.

An audit you did not verify is a to-do list you have crossed things off optimistically.

Where this still falls short

It cannot tell you why traffic dropped. An audit reports the state of your pages. It does not know Google changed something in March, and it cannot see a competitor who has been building links since spring. For that you want Search Console, which is your own data and free.

A clean audit is not the same as an indexable site. Google’s Page Indexing report covers a category no on-page audit reaches: pages Google found and chose not to index. A page can pass every check here and still be excluded there, and the reasons are different every time.

A perfect audit score is not a ranking. Technical health is table stakes and clearing it does not create demand. Plenty of flawless sites rank for nothing because nobody searches for what they wrote.

And it will keep finding things. There is no state where the list is empty. At some point the correct move is to stop auditing and go write something, which no tool will ever tell you to do.

Running it with ContextBolt SEO

ContextBolt SEO is a hosted MCP server, so Astra connects with one URL and no install. Ask for an audit in plain English, get findings back in the session, fix them there, and re-audit to confirm.

It is $35 a month with 1,000 credits included. Audits are one credit per page, most research calls are one credit flat, and if a lookup comes back empty it costs you nothing. There is no dashboard to learn, and results collect on an SEO Board you never had to build, so last month’s audit is still there to compare against.

If you are setting Astra up for SEO work more broadly, keyword research is the other half, and it runs into the opposite constraint. Audits are limited by what the crawl costs. Research is limited by the model’s own pricing once your context gets large.