A website audit looks at a site as a set of pages rather than one page at a time. Most of the problems that cost a site traffic are only visible that way: two pages with the same title, a category page that quietly carries noindex, a navigation link that goes through a redirect on every page, a cluster of near-empty tag pages. This site audit tool crawls from the URL you give it, follows internal links, and reports those patterns across the pages it reaches.
What is the difference between a website audit and a page audit?
A page audit measures one URL in depth: its performance, security headers, structured data, AI crawler access and on-page tags. A website audit measures many URLs at shallow depth and compares them, which is the only way to find duplicates, missing elements across templates, internal redirects and broken links. You need both. The full audit on our homepage is the page audit; this tool is the crawl.
How to run a website audit
- Start from the homepage, or from the section you care about. The crawl follows links breadth-first, so the start page decides which ten pages are reached. Starting from
/blog/audits the blog; starting from the root audits the top navigation. - Watch the live table. Pages appear as they are fetched with status, redirect, title and description lengths, H1 count, canonical, index status, word count and response time.
- Read the issues list once the crawl finishes. Each issue groups the affected pages and explains why it matters. Errors come first.
- Open the full audit for any flagged page with the link next to it. That report adds fix steps, copy-paste snippets and an owner for each item.
- Export the CSV and keep it. Re-run after the fixes ship and compare the two files.
What each column means
| Column | What it shows | Why it matters |
|---|---|---|
| Status | Final HTTP status, with the redirect status when one occurred | 4xx and 5xx pages waste crawl budget and break user journeys |
| Title / Desc. | Character counts of the title tag and meta description | Google says titles may be rewritten when they are missing, too long or repeated (title links) |
| H1 | Number of H1 headings | One H1 states the topic; zero or several blur it |
| Canonical | Self, other or none | "Other" means the page asks to be indexed under a different URL (Google says how canonicals are used) |
| Index | Whether a robots meta tag or X-Robots-Tag header says noindex | Linked but non-indexable pages are often accidents |
| Words | Visible words in the HTML, before JavaScript | Under 200 is thin for search engines and for AI crawlers, which rarely run scripts |
| Time | Milliseconds to the last byte of HTML from our servers | Over two seconds is slow server-side regardless of front-end optimisation |
Which issues should you fix first?
Fix in this order: server errors and broken pages, because nothing else on those URLs matters until they load; internal links to redirecting URLs, because every hop is wasted crawl budget and Google says to update links to point at the final URL (redirects documentation); unintended noindex and canonicals pointing elsewhere, because they remove pages from search silently; then duplicate and missing titles, descriptions and H1s, which are template fixes that often cover dozens of pages at once. Thin pages come last and are a judgement call: a contact page with 60 words is fine, a product category with 60 words is not.
Our view: do not chase a perfect issues list. Ten duplicate descriptions on paginated archive pages are not worth an afternoon. A redirect in the main navigation is.
Limits of a 10-page crawl
Ten pages is enough to find template-level problems, because templates repeat. It is not enough to find every broken link or every orphaned page on a 2,000-page site. The unlocked crawl reaches 50 pages, which covers most small business sites completely and the top layer of larger ones. The crawl also runs from our servers without JavaScript, the way search engine and AI crawlers first see a page, so a site that only renders content client-side will show low word counts here; that is a finding, not a bug. For a whole-site crawl with log analysis, ask for an expert review from any unlocked report.
What to do next
Run the crawl, fix the errors and redirects, and then work through the technical SEO checklist, which links each item back to a tool. If internal redirects turned up, the redirect chains post shows how to find and remove them at the source. Then check the pages you fixed with the AI visibility checker, since the same crawlers that see your HTML feed AI answers too.
Frequently asked questions
- How many pages does the website audit crawl?
- Ten pages free, starting from the URL you enter and following internal links breadth-first. Entering your email raises the limit to 50 pages. Either way the crawl stops after 45 seconds and tells you how many pages it discovered but did not reach.
- Which pages get crawled first?
- The start page, then the pages it links to, then their links, in the order found. Clean URLs are crawled before URLs with query strings so filter and sort variants do not use up the limit.
- Why is a page listed with a redirect?
- An internal link points to a URL that redirects. We follow the redirect and audit the final page, and we flag the link so you can point it at the final URL directly.
- Does it check Core Web Vitals or backlinks?
- No. This tool is about page-level structure across many pages. The full audit on the homepage covers performance, security and AI visibility for one page in depth, and the backlink checker covers links.
- Can I export the results?
- Yes. Every crawl has a copy-to-clipboard and a CSV download with one row per page: status, redirect target, title and description lengths, H1 count, canonical, noindex, word count, response time and depth.