Monitoring and site health

Uptime and response time are checked about every five minutes. Core Web Vitals use Google field data where it exists, and a lab measurement where it does not. Speed on the dashboard shows vitals in more detail.

A weekly crawl of your pages checks titles, meta descriptions, headings, images without alt text, broken links, redirect chains, and status codes — the things that stop ranking or rendering.

It runs weekly because these change on deploy, not overnight, and it budgets crawl so a deliberate run still has allowance left.

A 0–100 score for whether AI assistants can read and quote your site, made of four checks that each show the points they are worth. llms.txt (20): present and a real file, not your homepage served at that address. AI crawlers allowed (35): whether robots.txt lets GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot, Google-Extended and CCBot in. Structured data (25): the share of pages carrying Article, Product, Organization and similar markup, with full marks at 60% of pages. Answer-ready content (20): the share of pages that answer questions as FAQ markup or question headings, with full marks at 25% of pages.

llms.txt is a convention, not a standard any assistant is obliged to read, so the score says it helps and never promises a citation. A failed check names the points it cost and the fix.

Every audited page is a dot, sized by how many other pages link to it and coloured by its score. Lines are internal links. Hover a page to see what it connects to; click to hold it.

Pages nothing else links to are ringed and listed underneath. They are in your sitemap, so search engines can be told about them, but no visitor can reach them by clicking.

Every script, frame, image and stylesheet on each page is read. Known services (analytics, advertising, session replay, chat, payments, fonts) are named and counted in pages; every other host is listed; what the site is built on and served from is read from response headers and markup.

If your analytics is on most pages but missing from a few, the audit says which ones, because visits there are not being counted.

Time to first byte (how long the server thought before answering) is shown separately from how long the HTML then took to arrive, because they have different fixes: a slow first byte is caching, a query or the edge; a slow download is the payload. These are measured from our server, not from a visitor’s browser, so read them as a comparison between your pages, not as a lab score.

Every problem the audit finds becomes an item, ranked by how many pages share it. Tick one when you have fixed it; the next audit checks. An item that is ticked and still found is reopened, and one that is ticked and gone is marked as confirmed by the audit.

You can add your own items, and the assistant can add items too (they are labelled as added by the assistant). Each item has a copyable prompt for an AI coding assistant, written so it needs nothing else to make sense.

Every finished audit is kept. Open any row in Run history to see its pages and findings exactly as they were then; the fix list stays with the latest run. The audit exports as two CSV files, one row per page and one row per finding.

The weekly audit also raises an alert when a run is clearly worse than the one before it (see Alerts and digests).

Which AI and search crawlers hit your site, when, and which pages. Useful after a robots.txt change, and to see whether assistants that cite you have actually visited.

Crawler tracking needs a small install of its own — the tracking script cannot see bots. The AI crawlers guide (next) covers every platform, including the zero-code WordPress path.