Key takeaways
- AI search behavior changes without warning, so a quarterly audit is a snapshot of a site that no longer exists. Weekly runs catch regressions while they are cheap.
- The 21 checks below fall into five groups: crawler access, rendering and indexing, content, linking, and entity signals. Access problems come first because nothing else matters if bots cannot read the page.
- The change log matters more than the score. A health score of 82 tells you little. Three new broken links on your pricing page tell you what to do on Monday.
- Pair the audit with crawler logs and citation data. The audit says what could be wrong. The logs say whether AI systems actually hit it.
Why weekly, and why now
Classic SEO audits were quarterly or annual because search engines changed slowly and so did most sites. Neither is true anymore. On August 8, 2026, ChatGPT Search started using the site: operator at scale. Promptwatch Data shows site:-scoped fan-outs jumping from 0.37% to 16.8% of all fan-out queries in a single day, with searches per response rising from about 1.08 to about 1.83. Nobody got a changelog from OpenAI. Sites with thin category pages, broken internal search, or unindexed content started losing answers that week.
That is the argument for a weekly cadence. Platform-controlled retrieval can shift overnight, and the only defense is to look often and compare against last week.
The other reason is that sites rot on their own. Someone edits a robots.txt, a developer ships a template change that moves content into client-side JavaScript, a CDN rule blocks a bot that was fine yesterday. None of these are dramatic. All of them quietly cost citations.
What a weekly audit is (and is not)
A weekly audit is a fast, automated crawl of your own site that checks a fixed list of conditions and reports what changed since the previous run. It is not a strategy document. It does not tell you which prompts to target or what to write. Think of it as a smoke detector, not an architect.
If you want the longer, manual version, several agencies publish good AI readiness checklists that walk through crawler access, rendering, extractability, schema, and measurement. The weekly audit is the part of that you automate so it keeps running after the consultant leaves.
Tools that can do this job include general crawlers like Screaming Frog, Sitebulb, and ContentKing, and platforms that bundle audits with AI visibility data. Promptwatch runs a weekly audit with 21 checks, a health score, a what-changed-since-last-run view, and a weekly email, so I will refer to how that works where it helps. The checks below are a practical framework you can run in any tool.
The 21 checks, grouped
Not all checks carry equal weight. I have ordered the groups by how much damage a failure does. A blocked crawler is worse than a missing meta description, every time.
Group 1: crawler access (checks 1 to 5)
- robots.txt allows the AI crawlers you want. Check the answer-time fetchers (OAI-SearchBot, ChatGPT-User, Claude-SearchBot, PerplexityBot, Perplexity-User) separately from training crawlers. You may want to block one set and allow the other.
- No CDN or WAF rules turning bots away. A robots.txt that says yes means nothing if Cloudflare or your firewall returns a 403.
- Key pages return 200. Pricing, product, docs, and top landing pages should not redirect in chains or return soft errors.
- XML sitemap is reachable and current. Pages missing from the sitemap are slower to be discovered and more likely to be skipped.
- No accidental noindex or X-Robots-Tag headers. This one shows up after staging-to-production deploys more often than anyone admits.
The AI crawler traffic report gives you a benchmark for sanity-checking this group. OpenAI made up 79.8% of verified AI crawler requests in the week of Aug 31 to Sep 6, 2026, down from 94.8% in the week of Jun 8 to 14. The report's advice is simple: compare your own logs with the overall mix. If a provider is a big share of the mix and nearly zero in your logs, you are probably blocked or unreachable for that provider.
Group 2: rendering and indexing (checks 6 to 9)
- Main content exists in server-rendered HTML. Many AI fetchers do not execute JavaScript. If your answer lives in a client-side widget, it does not exist for them.
- Canonical tags point where you think they do. Self-referencing on clean URLs, no canonical chains.
- Pages are indexed. After the site: operator change, this matters more. ChatGPT's site: queries only surface what search engines have indexed.
- Internal search and category pages return real content. Thin or empty category pages are now a retrieval liability, since your domain has become a search surface.
Group 3: content (checks 10 to 14)
- Titles present, unique, and descriptive.
- Heading structure makes sense. One H1, logical H2s, headings that match the questions people actually ask.
- Content length is not suspiciously thin. Short pages are not always bad, but a sudden pile of 80-word pages usually means a template broke.
- No duplicate content across URLs. Duplicates split signals and confuse which version gets cited.
- Freshness: key pages updated recently. More on this below.
Freshness deserves a number. Promptwatch's content half-life study tracked every page ChatGPT cited on July 6, 2026 for 90 days. News pages decayed fastest: half were gone after 36 days. Product pages, reviews, and how-to guides reached their half-life after 74 to 77 days. Landing pages and docs lasted longest, with 78% and 76% still cited after 30 days. So a freshness check should not be one global rule. Flag product and listicle pages sooner, and docs and landing pages mostly for accuracy rather than age.
Group 4: linking (checks 15 to 17)
- No broken internal links.
- No orphaned pages. A page with no inbound internal links is easy for crawlers to miss and easy for you to forget.
- Pages missing from the sitemap. Same issue from the other direction. Compare the crawl against the sitemap.
Linking checks look boring and they are, until you realize that a rebuilt navigation can orphan 200 pages in one deploy.
Group 5: entity and extractability signals (checks 18 to 21)
- Structured data validates and uses the most specific type available. Generic Organization markup on a dental clinic leaves detail on the table.
- Organization details are consistent. Name, description, and contact info should match across the site.
- Authors and dates are visible on guides and articles.
- Answers appear early. Definitions and direct answers near the top, supported by steps, lists, or tables.
A note on markdown and llms.txt: Promptwatch Data found markdown files make up just 0.05% of AI search citations. They serve AI agents, not AI search. I would not put a markdown version of every page on a weekly checklist. Check it quarterly at most.
Summary table
| Group | Checks | What failure costs you | Typical fix owner |
|---|---|---|---|
| Crawler access | 1 to 5 | Bots cannot read anything | DevOps, SEO |
| Rendering and indexing | 6 to 9 | Content invisible or unretrievable | Engineering |
| Content | 10 to 14 | Weak or stale answers | Content team |
| Linking | 15 to 17 | Pages orphaned or undiscovered | SEO, engineering |
| Entity and extractability | 18 to 21 | Brand resolved poorly, passages not quoted | Content, SEO |
How to read the change log
This is where most teams go wrong. They open the audit, see a health score, feel vaguely good or bad, and close the tab. The score is the least useful number on the page.
Start with what changed, not what is wrong
Every site has a backlog of old issues. Reading them weekly is demoralizing and pointless. The change log answers a different question: what broke or got fixed since last Monday? A new issue is nearly always tied to a specific event, like a deploy, a content migration, or a plugin update. That makes it fast to trace.
When you open a run, sort in this order:
- New access or rendering failures (Groups 1 and 2). Stop and fix these now.
- New issues on pages that earn revenue or get cited. Fix this week.
- New issues on everything else. Batch them.
- Resolved issues. Confirm the fix stuck, then move on.
Read the direction of the score, not the level
A score that drifts from 91 to 84 over three weeks is a signal. A score that sits at 78 for six months might just mean you have a lot of old blog posts. Watch the slope and ignore the absolute number unless you are comparing similar sites.
Distinguish noise from signal
Some swings are harmless. A crawl that hit a rate limit can report phantom timeouts. A one-off CDN hiccup can show up as a handful of 5xx errors. If a failure appears once and vanishes the next week, note it and keep going. If the same URL fails twice in a row, treat it as real.
The opposite problem is a check that stays red for months because nobody owns it. Put a name next to every recurring failure or delete the check from your attention.
Weekly email, then a ten-minute review
The weekly audit email is the right format for this. Skim it Monday morning, open the full change view only if something in Groups 1 or 2 changed, and forward the rest to whoever owns it. Ten minutes is the target. If the review takes an hour, the checks are too noisy and you should trim them.
Connect the audit to crawler logs and citations
An audit tells you a page could be a problem. It does not tell you whether any AI system noticed. That takes logs.
IP-verified crawler logs show which bots visited, which pages they read, and which requests ended in errors. If the audit says your pricing page started returning 403s, the logs tell you whether GPTBot or OAI-SearchBot actually tried it that week. Platforms like Promptwatch tie crawl data to citations per page, which closes the loop. If you only have raw server logs, DarkVisitors is a lighter option for seeing which agents show up.
Then look at citations. A page that passes every check but never gets cited has a content problem, not a technical one. A page that gets cited often and fails a check is where to spend your Monday. That prioritization, audit issues weighted by citation value, is more useful than any raw issue count. For a broader look at software that combines these views, the GEO software directory at bestgeosoftware.com lists the main options.
A sample Monday workflow
Here is how this plays out in practice.
- The audit email arrives. Score dipped from 88 to 85.
- The change log shows 14 new items. Twelve are meta description length warnings on blog posts from last week. Ignore them for now.
- Two are different: your /pricing page now has a canonical pointing to /pricing-old, and three product pages dropped out of the sitemap.
- You trace both to a Thursday deploy. The canonical goes to engineering as urgent. The sitemap generator gets a ticket.
- Midweek, you check crawler logs to confirm answer-time bots are still reaching pricing. They are, but crawl errors on the product pages are up.
- Next Monday, both items show as resolved. The log confirms.
That is the whole thing. It is dull. It also catches the exact class of problem that silently erodes AI visibility.
Common mistakes
Treating all 21 checks as equal is the biggest one. A missing alt attribute and a blocked crawler are not the same kind of problem.
The second is running the audit but never re-running the same prompts afterward. If you fixed a rendering issue, check whether your tracked prompts now show the page cited. Without that, you are polishing the site and guessing at results.
The third is trusting one-off audits after a big platform change. When behavior shifts, as with the site: operator rollout, keyword and fan-out mappings built before the change are stale. Re-run those analyses too, not just the crawl.
The fourth is auditing only the pages you remember. Orphaned pages and untracked sections are exactly where problems hide. Crawl from the sitemap and from the homepage, and compare the two.
Picking a tool for the job
| Need | Option | Notes |
|---|---|---|
| Deep one-off technical crawl | Screaming Frog, Sitebulb | Desktop crawlers, strong on detail, manual cadence |
| Continuous monitoring of technical changes | ContentKing, Lumar | Good at change alerts on large sites |
| Weekly audit joined to AI crawler logs and citations | Promptwatch | 21 checks, health score, change view, weekly email, tied to AI visibility data |
| Basic AI bot visibility from logs | DarkVisitors | Lightweight view of agents hitting your site |
The right pick depends on whether you want a pure technical monitor or one connected to AI citation data. For most teams chasing AI visibility, the connection is the point, because it tells you which failures actually cost you something.
What to do this week
Run a baseline audit now, even a rough one. Fix anything in Groups 1 and 2 first. Then set the weekly cadence, assign an owner to each group, and decide what a ten-minute Monday review looks like. After four weeks you will have a change history, and that history is worth more than any single report. You will see which deploys break things, which teams introduce regressions, and which fixes hold.
Platform behavior will keep moving. A weekly audit will not predict the next shift, but it will tell you within seven days whether your site is still readable when it happens.