Website Crawl Audit Triage Worksheet: From Export to Repair Queue
How do I turn a crawl export into a repair queue that someone can act on and verify?
Convert a crawl export into a URL-level worksheet with separate columns for the requested URL, observed response, classification, business impact and repair control. Read each row without treating a successful status as proof of indexing or page quality. Group rows only when they share the same symptom and likely cause, prioritise patterns affecting important journeys, and assign each repair an owner, expected outcome and rerun test. Retest the defined URLs after the change and preserve unresolved exceptions.
Read each crawl record without over-interpreting it
A page must be crawled and then indexed before it can be retrieved for a Google ranking. Read the requested URL, final URL, response status and response type as separate observations because none of them alone establishes indexing or page quality.
Sources: The Complete Technical SEO Guide for Small Businesses (2026) - eSEOspace.
A redirect may be intentional, a successful HTML response may still carry an unwanted noindex instruction, and a successful machine-readable response may not require HTML metadata. Preserve the original export and crawl date so later triage does not erase the evidence that prompted the repair.
- Keep the requested URL distinct from its final destination.
- Read status and response type as observations, not conclusions.
- Retain the crawl date with the source export.
Complete the URL-level crawl triage worksheet
A Hallermann Consulting post-repair crawl on 2026-10-03 retained 177 requested URL variants, comprising 170 HTML responses and 7 machine-readable responses, with status, response type and URL recorded for each crawl entry. Use one worksheet row per requested URL and preserve response type so HTML pages and machine-readable endpoints are not silently combined.
Sources: One-site release crawl and metadata verification.
In the observed-response column, enter the final URL, status and response type together; in classification, choose the primary access, redirect, discovery, indexing-control or response-type question. Use business impact to name the affected page or journey, then use repair control to capture the owner, expected outcome and rerun test.
- Use one row for one requested URL.
- Choose one primary classification for triage.
- Write concise impact and repair controls.
Prioritise patterns rather than scanner noise
A useful website audit asks whether the site works effectively for users and the business behind it, not merely whether it looks good. Prioritise crawl patterns by the affected journey, the importance of the pages and the breadth of the likely shared cause.
Sources: The Complete Website Audit Guide: How to Audit a Website from Top to Bottom.
Group rows only when the symptom and likely cause match, and retain representative URLs so the assignee can confirm the pattern before changing templates, redirects or controls. Escalate blocked or broken priority paths before low-impact housekeeping, while retaining lower-priority exceptions for later review.
- Group only matching symptoms with a plausible shared cause.
- Retain representative URLs in every grouped ticket.
- Prioritise important journeys before cosmetic tidiness.
Define the rerun before the repair begins
Technical SEO covers several infrastructure concerns, including crawlability and indexing as distinct areas. A rerun should therefore test the repaired crawl observation without claiming that the result proves every other technical or search outcome.
Sources: The Complete Technical SEO Guide for Small Businesses (2026) - eSEOspace.
Name the exact URLs or defined set to repeat, the expected destination, status and response type, and any indexing-control observation that must be reviewed separately. Keep the earlier and later records together, and report unresolved exceptions instead of deleting them from the worksheet. The Hallermann Consulting example covered one website and one release window; its URL variants were not independent websites, and successful responses did not prove accessibility, functional correctness or enquiry delivery.
- Name the exact URL set to repeat.
- State the expected destination, status and response type.
- Preserve unresolved exceptions and audit limits.
URL-level crawl triage worksheet
Use one row per requested URL. The observed response combines final URL, status and response type; the repair control combines owner, expected outcome and rerun test.
| Requested URL | Observed response | Classification | Business impact | Repair control |
|---|---|---|---|---|
| https://example.com/old-service | Final: /service; Status: redirect; Type: HTML | Redirect question | Priority service journey | Owner: developer; Outcome: intended destination confirmed; Rerun: request old URL and verify final URL |
| https://example.com/contact | Final: /contact; Status: successful; Type: HTML | Indexing-control review | Contact journey | Owner: website manager; Outcome: controls reviewed; Rerun: inspect the same URL and retain the result |
The example rows are hypothetical and demonstrate the worksheet structure. Replace them with retained observations from your own crawl.
Related guidance
What follow-up questions matter most?
- What should I record for each crawled URL?
- Keep the requested URL and final URL separate. Add the response status and response type, then classify the observation without assuming that a successful response means the page is indexed or healthy.
- When should crawl findings be grouped together?
- Group URLs only when they exhibit the same symptom and likely cause. Keep representative examples and the affected priority pages in the repair ticket so the owner can validate the pattern before making a broad change.
- How do I make a crawl repair verifiable?
- Write the rerun test when the ticket is created. Name the URLs or defined set to test, the expected destination or response, and the signal that will count as a pass.
What steps does this workflow follow?
Turn a crawl export into a repair queue
- Read the retained fields: Review the requested URL, final URL, status and response type without inferring indexing or quality from one field.
- Classify the observation: Label the issue as an access, redirect, discovery, indexing-control or response-type question.
- Connect it to impact: Identify the important page or customer journey affected and note whether the pattern appears elsewhere.
- Assign the repair: Give the pattern an owner, expected outcome and representative examples rather than forwarding an unfiltered export.
- Define the rerun: State which URLs will be retested, what result is expected and which remaining exceptions must still be reported.