Templates
Technical SEO Audit Template
The technical half of an audit, separated out — the checks a tool can settle, with the evidence each one needs to be actionable.
Run a fresh DomainLens audit and use the report as your priority list.
Scope
This covers what stops a page being eligible: whether it can be crawled, rendered, indexed and delivered. It deliberately excludes content quality and intent, which no tool settles and which belong in a separate pass.
Run it per template. Technical faults are systemic almost by definition — a canonical bug affects every page a template produces, not one.
Crawling
| Check | Evidence to record |
|---|---|
| robots.txt reachable | Status code and content type |
| Path not disallowed | The matching rule, if any |
| Sitemap declared and valid | URL, parse result, URL count |
| Crawlable links present | Count of anchors with href |
| Redirect chains | Hop count and final destination |
| Server response time | TTFB, from more than one location |
| Crawl errors | Counts by response code |
Indexing
The declared-versus-selected canonical comparison is the highest-value row here. A mismatch names a duplication problem you would otherwise spend hours inferring.
| Check | Evidence to record |
|---|---|
| Status code | The code, from outside your network |
| Meta robots | The exact directive string |
| X-Robots-Tag | The header value, if present |
| Declared canonical | The URL, and its status code |
| Google-selected canonical | From URL Inspection |
| Coverage state | The Search Console state string |
| Soft 404s | Status returned for a nonexistent path |
Rendering
| Check | Evidence to record |
|---|---|
| Content in served HTML | Whether main content appears before JS |
| Title and canonical in served HTML | Present or absent |
| Rendered HTML | From URL Inspection |
| Blocked resources | The list from the inspection panel |
| Console errors during render | Messages Google reported |
| Hydration warnings | From the browser console |
Recording values, not verdicts
Write down what you observed rather than whether it passed. "TTFB 1.4s from Frankfurt, 0.3s from London" is a finding somebody can act on months later; "slow server" is a note that has to be re-investigated the moment anyone questions it.
This matters more for technical findings than for anything else, because they are the ones that get disputed. A developer who does not believe a canonical is wrong will believe a recorded value with the URL and timestamp it came from, and the argument ends there.
It also makes the next audit cheaper. A previous report with values lets you compare rather than re-measure, and a metric that moved is the first place to look when something changes.
Delivery
Record values rather than pass or fail. A finding saying "TTFB 1.4s" survives re-reading; one saying "slow" does not. See the full audit checklist for the content half.
| Check | Evidence to record |
|---|---|
| HTTPS | Certificate issuer and expiry |
| Mixed content | Any http:// resources |
| Compression | Content-Encoding header |
| Cache-Control | The directive per resource type |
| HTTP version | Negotiated protocol |
| Security headers | Which are present |
| Core Web Vitals | Field values, and lab if no field data |
- Why separate technical from content?
- Because the technical checks can be settled mechanically and the content ones cannot. Mixing them produces a report where objective findings and opinions look alike.
- How many URLs should I check?
- One per template, plus any page with unusual behaviour. Technical faults are systemic, so more URLs of the same type add little.
- What if field data is unavailable?
- Record the lab values and label them as lab. Do not present a simulated score as though it were user data.