Site Audit
Point the crawler at a domain and get a severity-ranked list of technical problems across up to 25 pages. Built for a fast first look before a migration, a pitch or a deeper audit.
Type a bare domain and the request is passed to app.search.co, where search.co's own crawler starts at your homepage, follows internal links, and fetches up to 25 live pages. Each fetched page is checked for technical problems, and the findings come back grouped by severity rather than as one undifferentiated list. Nothing is installed on your site and no login to your CMS or Search Console is needed. Your first audit runs without an account; to run more, you create a free search.co account.
A 25-page crawl is deliberately small. It is long enough to reach the homepage, the main navigation targets and a sample of deeper templates, and short enough to finish while you wait. That makes it useful for triage: checking a prospect before a sales call, confirming a staging-to-live launch did not ship with obvious breakage, or deciding whether a site needs the full treatment at all.
This page explains what a sampled crawl can and cannot prove, how to read severity, and how to turn a short issue list into work that gets done. If you want a single on-page grade for the homepage instead of a crawl, the SEO score checker answers that narrower question.
What a 25-page crawl reports.
The output is a list of issues found on the pages the crawler reached, each tagged with a severity level and tied to the URLs where it appeared. Because the crawler requests live pages the way a bot would, it sees status codes, redirects, and the HTML your server actually returns, not what your CMS preview shows.
The exact checks evolve, but they sit in the families any technical auditor starts with:
- Response problems: pages returning 4xx or 5xx codes, and internal links that pass through redirects before reaching their target.
- Indexability signals: pages carrying a
noindexdirective, canonical tags that point elsewhere, and similar settings that decide whether a URL can rank. - On-page basics at scale: missing or duplicated titles and descriptions, missing H1s, and other tag-level gaps repeated across templates.
- Link hygiene: broken internal links and outbound links that fail, found on the pages in the sample.
- Severity grouping: issues ordered so the ones most likely to block crawling or indexing sit above cosmetic warnings.
What a sample can prove, and what it cannot.
A crawl capped at 25 pages proves that an issue exists. It cannot prove that an issue is absent. If the sample contains no broken links, the site may still have hundreds of them in a blog archive the crawler never reached. Read a clean result as "nothing found in the pages sampled," never as a clean bill of health.
Which pages get sampled matters too. The crawler follows links from the homepage, so it favors pages that are prominent in navigation. Orphaned pages, deep pagination, faceted URLs and anything only reachable through a sitemap are unlikely to appear. That bias is useful, because the most-linked pages are usually the most important ones, but it means the audit says little about crawl waste or index bloat, which tend to live in exactly the places a short crawl skips.
If you need the whole site, every template, log files and Search Console data cross-referenced, that is a different job. SEO.co's full technical audit covers the complete crawl with a strategist interpreting the findings. The quick audit tells you whether that investment is warranted, and where to point it.
| Question | 25-page quick audit | Full audit |
|---|---|---|
| Are there broken pages on key templates? | Yes, for templates reached in the sample | Yes, across every URL |
| Is the site free of broken links? | Cannot confirm | Yes, with the full link graph |
| Is there index bloat or crawl waste? | Rarely visible | Core focus |
| Did a launch ship obvious errors? | Good fit | More than you need |
| What should a 90-day roadmap contain? | A starting list | Prioritized plan with context |
Reading severity without overreacting.
Severity labels describe the potential impact of an issue type, not the impact on your site. A 404 is high severity in principle, but a 404 on a page nobody links to and nobody searches for costs you nothing. A noindex on the category page that drives most of your organic revenue is a fire. The label starts the conversation; the URL list decides it.
For each high-severity item, ask two questions. First, how many affected URLs are in the sample, and do they share a template? Second, does any affected URL matter, meaning it earns traffic, links or conversions? Cross-check the second question with your analytics or with the top pages checker, which estimates which URLs carry a domain's organic visibility.
Lower-severity warnings are worth a batch pass, not a sprint. Long titles, thin descriptions and similar items usually get fixed in bulk during a template update. Treat them as a backlog, not as reasons to delay the real fixes.
From issue list to tickets.
Developers fix tickets, not audit exports. Convert each issue group into one ticket per root cause, with the affected sample URLs, the expected behavior, and how to verify the fix. A ticket that says "all blog posts return a canonical pointing at the blog index" will be fixed. A ticket that says "canonical issues: 14" will sit in the queue.
Then rerun the audit after deployment. Because the crawl starts from the same homepage, the sample is usually similar between runs, which makes before-and-after comparison practical for confirming a release resolved what it was supposed to. For individual URLs a developer is fixing, the broken link checker and the title tag checker give page-level confirmation without waiting for a crawl.
Ways a quick audit gets misused.
Most problems come from asking a 25-page sample to answer a whole-site question.
- Calling a site clean: zero issues in the sample is not zero issues on the domain. Say what was crawled when you report it.
- Auditing the wrong host: if the site redirects
example.comtowww.example.com, or HTTP to HTTPS, note which host the crawl landed on before comparing runs. - Sending raw output to a client: an unfiltered issue list without context reads as alarming. Annotate which items matter and why.
- Fixing instances, not templates: patching ten pages by hand when one template change would fix all of them, and every future page too.
- Skipping the rerun: a fix that was deployed is not a fix that was verified. Crawl again after release.
Triage a site in one pass.
A workflow for pre-sales checks, launch QA or the first day of an engagement.
Confirm the canonical host
Load the domain in a browser and note whether it settles on www or non-www, HTTP or HTTPS, then audit that host.
Run the quick audit
Enter the domain and let the crawler fetch its sample of up to 25 pages.
Group by root cause
Collapse repeated issues into template-level causes and note which affected URLs actually earn traffic.
Write tickets
Create one ticket per root cause with sample URLs, expected behavior and a verification step.
Rerun after release
Audit again once fixes ship and compare the severity counts against the first run.
Get an expert read on your results
Tools give you the raw numbers. Tell us your site and an SEO.co strategist will email you what they'd prioritise and the next steps they'd recommend.
Site audit questions.
Why only 25 pages?
Which pages does the crawler pick?
Does the audit use Google data?
How is this different from the SEO score checker?
Can I audit a staging site?
How many audits can I run?
Pair it with these checks.
Need every page, not a sample?
SEO.co's technical audit crawls the full site, cross-references the findings with your search data, and hands you a prioritized plan written by a strategist rather than a generic export.