Technical SEO audits have a specific failure mode: scope explosion.
A client asks for a "technical audit." Your team starts crawling. They find indexation issues, which lead to architecture problems, which reveal content duplication, which surfaces a migration that was never properly redirected. Suddenly a 15-hour audit is 40 hours of analysis — and nobody scoped it that way.
The fix isn't to audit less. It's to scope what "technical" actually means for this engagement, this site, and this platform.
Who this is for
- SEO agencies selling technical audits as standalone deliverables
- Teams where junior auditors need clear boundaries for technical reviews
- Consultants scoping technical remediation projects
- Account managers pricing technical work without deep technical knowledge
Variables that drive technical audit scope
| Variable | Impact |
|---|---|
| Site size | Pages to crawl and analyse — 500 vs 50,000 is a different project |
| CMS / platform | WordPress, Shopify, headless, custom — different technical constraints |
| Number of unique templates | Each template type needs individual review |
| Internationalisation | Hreflang, multi-domain, subdirectory — adds complexity layer |
| JavaScript rendering | Client-side rendering adds crawl and indexation complexity |
| Known issues | Pre-existing problems (migration, penalty, traffic drop) change focus |
Technical audit checklist by category
Crawlability & indexation
| Check | What to look for |
|---|---|
| Crawl depth | Pages more than 3 clicks from homepage |
| Orphan pages | Pages with no internal links pointing to them |
| Redirect chains | Chains longer than 2 hops, redirect loops |
| Canonical tags | Self-referencing, cross-domain, conflicting with other signals |
| Robots.txt | Blocked resources, overly restrictive rules |
| XML sitemaps | Coverage gaps, stale URLs, incorrect status codes |
| Noindex usage | Intentional vs accidental noindex, meta robots conflicts |
| Crawl budget | Large sites: are important pages being crawled? |
Site architecture
| Check | What to look for |
|---|---|
| URL structure | Consistent patterns, unnecessary parameters, flat vs deep |
| Internal linking | Equity distribution, topic clustering, navigation structure |
| Faceted navigation | Duplicate content, crawl waste, parameter handling |
| Pagination | Rel=next/prev (deprecated but relevant), view-all pages |
| Breadcrumbs | Implementation, schema markup, navigation accuracy |
Performance
| Check | What to look for |
|---|---|
| Core Web Vitals | LCP, CLS, INP — lab and field data |
| Server response time | TTFB across templates and geographies |
| Resource loading | Render-blocking CSS/JS, unused code, image formats |
| Caching | Browser caching, CDN configuration, cache headers |
| Mobile performance | Mobile-specific speed issues, responsive vs adaptive |
Structured data
| Check | What to look for |
|---|---|
| Schema types | Organisation, breadcrumb, FAQ, product, article |
| Implementation | JSON-LD vs microdata, validation errors |
| Rich results | Eligibility, current appearance, missing opportunities |
| Consistency | Schema matches visible page content |
Scope definition
- Site URL(s) and subdomains included in audit
- Crawl limit (e.g., "up to 10,000 URLs")
- Templates in scope (e.g., "homepage, category, product, blog, landing pages")
- Excluded areas (e.g., "staging, dev environments, non-production subdomains")
Access requirements
- Google Search Console (full access)
- Google Analytics 4 (read access)
- Server access or CDN dashboard (for performance analysis)
- CMS admin access (for template and configuration review)
- Crawl tool permissions (robots.txt allowance)
Deliverables
- Crawl analysis report with issue categorisation
- Priority matrix (critical / high / medium / low)
- Implementation recommendations with estimated effort per fix
- Executive summary for non-technical stakeholders
- Walkthrough meeting (30–60 minutes)
Exclusions
- Implementation of recommendations
- Content audit or content writing
- Backlink analysis or link building
- Ongoing monitoring post-audit
- Third-party tool configuration or setup
Timeline
- Access provision: Within 3 business days of kickoff
- Audit execution: [X] business days from access confirmation
- Draft delivery: [X] business days
- Walkthrough meeting: Within 5 business days of delivery
Scoping by platform
WordPress sites Focus on: plugin conflicts, theme bloat, caching configuration, XML sitemap generation (Yoast/Rank Math), database-driven performance issues, security headers.
Shopify sites Focus on: Liquid template limitations, app-injected scripts, collection/product URL structure, canonical handling, internationalisation via Markets, theme speed scores.
Headless / custom CMS Focus on: JavaScript rendering and indexation, dynamic routing, API response times, pre-rendering/SSR configuration, structured data implementation consistency.
How RuleDox helps
Technical audits follow predictable patterns. Site size determines crawl scope. Platform determines which checks matter most. Engagement context determines deliverable depth.
With RuleDox:
- Set platform and site size — appropriate checks populate automatically
- Junior auditors scope safely — the system enforces boundaries, not memory
- Hours calculate from variables — not from optimistic guesses
- Exclusions stay consistent — "implementation not included" appears when it should
FAQ
Should a technical audit include content analysis? Not by default. Technical audits focus on crawlability, indexation, architecture, performance, and structured data. Content analysis (thin content, gaps, cannibalisation) is a separate workstream. If the client wants both, scope them as distinct sections with separate hours.
How many hours should a technical audit take? For a 500-page site: 8–16 hours. For a 5,000-page site: 16–30 hours. For 50,000+ pages: 30–50 hours. These ranges assume technical-only scope. Add 30–50% if content or backlink analysis is included.
What tools should be specified in the scope? Name the primary crawl tool (Screaming Frog, Sitebulb, Lumar) and data sources (GSC, GA4, PageSpeed Insights). This sets expectations about methodology and prevents "why didn't you use [tool]?" conversations.