SEO Technical Audit Service: What Gets Checked and What You Should Get Back

An SEO technical audit service answers one narrow question: can search engines find, render and index the pages that matter on your site, and if not, why? It is not a review of your copy or your link profile. Keeping the scope narrow is what makes the findings precise enough for a developer to fix.

I have worked in SEO and digital marketing for more than 16 years, and technical audits are a large part of what I do, working remotely from Bucharest and charging by the hour. This article lists what a technical audit should check and, just as important, what the deliverable should look like when it lands in your inbox.

If you are still deciding whether to buy an audit at all, our guide to what a paid SEO audit agency should deliver covers that, and how I audit a site step by step walks through a full audit including content and links. Here I stay with the technical layer only.

What an SEO technical audit service covers

A technical audit follows the path a search engine takes: it requests a URL, decides whether it may crawl it, renders the page, decides which version is canonical, and decides whether to index it. Each step can fail quietly. The audit’s job is to find where.

Not every site needs every row. A small brochure site in one language does not need a hreflang review or a log analysis. A proposal that lists all of them for every site is padding the scope.

Crawling, robots.txt and indexing

This is where I start, because nothing else matters if the important pages are not reachable or not indexed.

robots.txt: a traffic rule, not a privacy tool

Google’s introduction to robots.txt says the file “is used primarily to manage crawler traffic to your site” and that “it is not a mechanism for keeping a web page out of Google.” If a blocked page is linked from elsewhere, “its URL can still appear in search results, but the search result won’t have a description.” To keep a page out of results, Google points to noindex or password protection instead.

In audits I often find the opposite problem: a robots.txt rule that blocks CSS, scripts or a whole directory of product pages, left over from a staging site. The audit should list each rule, what it blocks and whether that was intended.

Indexing: start from Search Console

The Page indexing report and the URL Inspection tool in Search Console show what Google has actually done with your URLs. The audit should not try to fix every “not indexed” line. It should find the important pages that are missing, and give the reason Google reports for each one, grouped by template.

Canonicals, redirects and duplicate URLs

In my audits, duplicate URLs are among the most common findings on business sites: the same page reachable with and without a trailing slash, with tracking parameters, or on both HTTP and HTTPS.

Google’s page on consolidating duplicate URLs ranks the methods. A redirect is “A strong signal that the target of the redirect should become canonical.” A rel=”canonical” annotation is “A strong signal that the specified URL should become canonical.” Sitemap inclusion is “A weak signal”. It also lists mistakes to avoid: “Don’t use the robots.txt file for canonicalization purposes”, don’t use noindex to choose a canonical, and don’t give different canonical URLs for the same page across methods.

So the audit should compare all three signals for each template and flag where they disagree. A canonical tag pointing to one URL while the sitemap lists another is a typical finding, and an easy fix once someone sees it.

Redirects get their own check: chains of several hops, redirects to pages that then return an error, and old URLs from a previous site version that now return a 404 while still receiving links.

Rendering, Core Web Vitals and structured data

JavaScript rendering

Google’s JavaScript SEO basics explains that Google processes JavaScript apps in three phases: crawling, rendering and indexing. It also says “Google can only discover your links if they are <a> HTML elements with an href attribute”, and that “server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers.”

The audit should compare the raw HTML with the rendered HTML for each main template, using the URL Inspection tool or a rendering crawl. If the main content, internal links or canonical tag appear only after rendering, that is a finding. Our article on rendering problems on JavaScript sites goes deeper.

Core Web Vitals

Google’s Core Web Vitals page sets the targets: Largest Contentful Paint “within the first 2.5 seconds”, “an INP of less than 200 milliseconds” and “a CLS score of less than 0.1”. It says good Core Web Vitals align “with what our core ranking systems seek to reward” and points to the Core Web Vitals report in Search Console.

I would expect the audit to use field data from that report first, grouped by template, rather than one lab test of the home page. A slow product template affects hundreds of pages; a slow home page affects one.

Structured data

The check here is simple: is the markup valid, is it the right type, and does it match what the visitor sees? Markup that describes reviews, prices or opening hours not shown on the page is a finding, not a feature.

A finding that does not name the URLs or the template it affects is an opinion, not an audit result.

XML sitemaps, hreflang and log files

Google’s sitemaps overview is honest about their limits: a sitemap helps search engines find URLs, but “it doesn’t guarantee that all the items in your sitemap will be crawled and indexed.” It also says a site may not need one if it is small, “about 500 pages or fewer”, and “comprehensively linked internally”. For larger or newer sites, the audit should check that sitemaps list only canonical, indexable URLs that return a 200 status.

For hreflang, the audit checks that each language version lists the others and itself, that the codes are valid, and that the targets are canonical pages. Errors here usually come from one template, so one fix often solves hundreds of URLs.

Log files are the only direct record of what Googlebot requested. On large sites they show crawl time spent on parameter URLs, old redirects or filtered pages instead of the pages you care about. I offer log file analysis as a separate piece of work, because it needs access to server data and is not worth the cost on small sites.

What you should get back: issue, evidence, fix, priority, owner

This is the part buyers should look at first in a sample report. A long list of warnings from a crawler is not a technical audit. Every finding should follow the same format:

On top of the findings, I would expect a short summary that names the few issues to fix first, with a rough estimate of the work each one involves, and a call to walk your developer through them.

For more on reading a technical consultant’s first findings, see what I look at in the first hour.

FAQ

What do SEO technical audit services include?

Crawling and robots.txt, indexing, canonicals and redirects, JavaScript rendering, Core Web Vitals, structured data, hreflang where relevant, XML sitemaps and, for larger sites, server log analysis. Content and link reviews are usually separate.

How is a technical audit different from a full SEO audit?

A technical audit checks whether search engines can crawl, render and index your pages. A full audit adds content quality, search intent, internal linking strategy and external links.

What access does a technical auditor need?

Usually read access to Search Console and analytics, plus a crawl of the public site. Log analysis needs an export of server logs, and staging sites need a login agreed in writing.

How often should a technical audit be done?

A full audit before and after a redesign or migration, and when traffic changes without a clear reason. Between audits, the Page indexing and Core Web Vitals reports in Search Console catch most new problems.