Technical SEO audit service.
A fixed-scope teardown of how your site crawls, renders, indexes, and performs — delivered as findings your developers can ship.
SEO audit services that end in shipped fixes
Most sites don't have a content problem. They have a plumbing problem — pages Google can't reach, templates that render blank to a crawler, canonical tags pointing three directions at once, a sitemap listing forty thousand URLs on a site with six thousand real pages.
Our technical SEO audit service finds those faults, proves each one with evidence, and writes every fix as a spec your developers can implement without a follow-up call.
The audit is a one-time, fixed-scope engagement. You get a findings register ranked by impact against effort, the raw crawl and export data behind it, and a walkthrough of what to fix first. No retainer required. If you want us to implement, we can — but the report is written so you don’t need us to.
What a technical audit actually catches
The failures that flatten organic traffic are rarely visible in the browser. Your homepage looks fine. Meanwhile faceted navigation is minting hundreds of thousands of crawlable parameter URLs, Googlebot is spending its budget on filter combinations nobody searches for, and the category pages that actually earn revenue sit five clicks deep with three internal links each. Or the reverse: the site renders everything client-side, the raw HTML response contains a spinner, and half the catalog exists only after JavaScript that a crawler under budget pressure may never execute.
Symptoms look like this. Rankings that plateau no matter how much content ships. Pages stuck in Search Console’s "Crawled — currently not indexed" bucket for months. A redesign that quietly halved organic traffic and nobody can say why. New pages taking weeks to appear in the index. Core Web Vitals failing in field data while every lab test passes.
None of that gets fixed by writing more blog posts. It gets fixed by finding the specific mechanical fault and shipping the correction. That’s the job.
The Six-Gate Audit
Every audit runs the same six-gate sequence. Each gate is a pass/fail examination of one layer of the stack, run in the order the layers actually depend on each other — there's no point measuring Core Web Vitals on pages Google can't crawl.
Crawl
We crawl the site twice: once as raw HTML, once with JavaScript rendering enabled, and diff the two. The first pass maps what any crawler sees; the second maps what your site actually is. Then we hunt crawl waste — faceted navigation generating parameter URL spirals, calendar and search-results pages creating infinite spaces, redirect chains four hops deep, soft 404s returning 200. Orphan pages get triangulated three ways: present in the sitemap, known to Search Console, but linked from nowhere. Where server access allows it, we sample log files, because what Googlebot actually requests is regularly a different list from what anyone assumes it requests.
Indexation
Crawlable and indexed are different states, and the gap between them is where traffic dies. We reconcile the crawl against Search Console’s coverage report in both directions: URLs indexed that shouldn’t be — thin parameter pages, staging leaks, tag archives — and URLs that should be indexed but sit in "Discovered — currently not indexed" or "Crawled — currently not indexed." Both buckets have causes, and the causes are findable. We check every declared canonical against the one Google actually selected, because they disagree more often than most teams expect. Leftover noindex tags from a launch three years ago. robots.txt disallows fighting meta directives. Sitemaps listing redirected and dead URLs, which teaches Google to trust the sitemap less.
Rendering
For each template, we diff the server response against the rendered DOM and list everything that exists only after JavaScript runs: navigation links injected client-side, product descriptions hydrated from an API, content that appears on scroll events a crawler never fires. Hydration errors that wipe and rebuild the page get flagged, because they can discard server-rendered content Google already parsed. We build in Next.js ourselves, so we know precisely where App Router pages leak into client-side rendering and what that leak looks like from a crawler’s side of the wire — and the equivalent failure patterns in plain React SPAs and theme-injected script stacks.
Experience
Field data first, lab second. CrUX tells us what real Chrome users experienced over the trailing 28 days; lab runs only explain the why. We identify the actual LCP element per template — it's frequently not the hero image but a web font, or an image whose preload lost a priority fight — then trace INP problems to their long tasks and the scripts responsible, and CLS to its sources: unreserved media boxes, late-injected banners, font swaps. The pass bar is the one Google publishes and the one we hold our own builds to: LCP under 2.5 s, INP under 200 ms, CLS under 0.1.
Structure
Internal linking decides where authority pools, and on most sites it pools in the wrong place. We map click depth from the homepage to every money page, find revenue pages surviving on two internal links, and check whether pagination, breadcrumbs, and hub pages distribute equity or hoard it. Anchor text gets audited as a pattern, not a list — four hundred "learn more" links tell Google nothing about four hundred destinations.
Meaning
Structured data closes the audit because it’s the layer AI retrieval reads most literally. Validity is table stakes; connectedness is the finding. We map your JSON-LD as a graph and flag nodes referencing @ids that don’t exist, two competing Organization entities describing the same company, and markup asserting content the rendered page doesn’t show — which is a spam-policy exposure, not a technicality. Sites serving multiple languages get their hreflang pairs checked for the return-tag failures that silently break the whole cluster.
What's included in the audit
Every engagement delivers the same package:
- Findings register — every issue ranked by traffic impact against implementation effort, so the fix order is an engineering decision, not a debate.
- Evidence per finding — the affected URL sets, crawl exports, and Search Console data that prove the issue exists and define its blast radius.
- Ticket-ready specs — each fix written as an implementable ticket: current behavior, required behavior, affected templates, acceptance check. Your developers should never have to interpret.
- Rendered-vs-raw crawl diff — the full comparison dataset, template by template.
- Template-level Core Web Vitals breakdown — field and lab, with the responsible element or script named for every failing metric.
- Structured-data graph map — your JSON-LD as it actually connects, orphans and conflicts marked.
- Prioritized fix sequence — what to ship first and why, matched to your release cadence.
- Walkthrough call — we present the findings, your team asks questions, nothing in the report stays ambiguous.
- The raw data — crawls and exports are yours to keep.
E-commerce and platform-specific audits
E-commerce sites fail in their own characteristic ways, and we audit for them specifically. Faceted navigation is the classic: filter and sort combinations compounding into a URL space thousands of times larger than the catalog. Variant pages duplicating each other into canonical soup. Collection pagination that strands deep products. On Shopify — where we build and ship ourselves — the recurring findings are tag-page indexation bloat, collection-scoped product URLs leaning entirely on canonicals, and theme apps injecting render-blocking scripts that drag every template’s LCP. The audit names the offending apps, not just the symptom.
Enterprise sites get a different crawl strategy, not a bigger invoice for the same one. Past a certain URL count, exhaustive crawling stops being informative; we sample by template, weight by log-file frequency, and audit the systems that generate pages rather than the pages one by one.
After the audit: findings you can ship
An audit that ends at a PDF is a diagnosis without treatment. Every finding we deliver is already written for implementation, and there are three ways it gets shipped. Your own developers work the specs — the report is built for exactly that. Our web development arm implements the fixes, which is the shortest path from finding to deploy since the people who wrote the spec write the code. Or the audit becomes month one of ongoing technical SEO, where we fix, verify in Search Console and field data, and keep the site clean as it changes.
Content-layer findings — thin pages, intent mismatches, title patterns — get logged and routed to on-page SEO scope rather than padded into a technical report where they don’t belong.
Request an audit. Send the domain and we’ll come back with a fixed written scope.
- ↗Web Developmentwe implementWe implement the fixes ourselves — spec authors writing the code.
- ↗Technical SEOmonth oneThe audit becomes month one, verified and kept clean.
- ↗On-Page SEOcontent findingsContent-layer findings route here, already separated from technical.
Technical SEO audit FAQ
What does a technical SEO audit include?
A technical SEO audit includes crawl analysis, indexation review, rendering diagnostics, Core Web Vitals assessment, internal-link mapping, and structured-data validation. Ours runs those as six sequential gates, each producing evidence-backed findings with the affected URLs attached. The deliverable is a ranked findings register with a ticket-ready spec for every fix, plus the underlying crawl and export data.
How do I evaluate a technical SEO audit service?
Ask to see a sample finding before you commit. A real one names the issue, proves it with data, lists the affected URLs, and specifies the fix precisely enough that a developer can ship it without a meeting. If a provider’s sample is a tool export with a logo on it, that’s what the full report will be too. Ask whether they diff rendered against raw HTML and whether their performance findings come from field data — those two answers separate practitioners from resellers quickly.
What should I look for in an SEO site audit?
Look for evidence and prioritization, not volume. Every issue in the report should carry the URLs it affects, the data that proves it, and a rank based on traffic impact — a 300-page export of unweighted warnings is noise wearing a cover page. Performance sections should lead with field data from real users, and the fixes should read like engineering tickets, not observations.
What features define a premium technical SEO audit?
A rendered-versus-raw crawl comparison, log-file analysis where access permits, template-level Core Web Vitals diagnosis from field data, and structured-data review at the graph level rather than per-page validation. The other marker is the spec quality: premium audits hand developers implementable tickets with acceptance checks. The walkthrough matters too — findings a team can interrogate get shipped; findings in an unopened PDF don’t.
How much does a technical SEO audit cost?
Every audit is quoted in writing as a fixed scope — no hourly meters, no packages page. The quote depends on what actually drives audit effort: URL count, template count, stack and rendering approach, and how much history sits in Search Console. Send the domain and you’ll get a defined scope and a fixed number before any work starts.
Let's build somethingworth finding.
One brief. One reply within a working day. Evidence, not a pitch.
Prefer email? hello@rankingtank.com