Trakis

Guide

What is a technical SEO audit, and how do you do one?

A technical SEO audit checks how a site is built for search engines, not what its pages say: whether a crawler may fetch each address, what the server answers, what the headers and the HTML say about indexing, whether the content needs JavaScript to be seen, how fast the pages load, and whether the structured data is valid. You do one by following a single address the way Googlebot does, then doing the same for every page with a crawler.

Technical audit or SEO audit?

A technical audit is the part of an SEO audit about the machinery: crawling, indexing, redirects, speed, structured data. The rest of an SEO audit is about what the pages say: titles, descriptions, headings, text (what is an SEO audit). The technical part comes first, because a page Google cannot fetch or may not index has no words worth checking. On our demo shop, 10 of the 22 problems the audit found were technical.

What Google needs at the technical level

Google names three things a page needs before it can be indexed: Googlebot isn’t blocked, the page works, meaning it answers with a successful status code, and it has indexable content (technical requirements). And it reads the mobile version: Google indexes and ranks the mobile version of a site’s content, fetched with its smartphone crawler (mobile-first indexing). So the mobile pages need the same content, the same structured data and the same robots meta tags as the desktop ones.

Step 1: robots.txt, the first file a crawler asks for

curl -s https://example.com/robots.txt

What the server answers for this file decides what Google does with the whole site (how Google reads robots.txt):

  • A 4xx answer, other than 429, is read as no robots.txt at all: everything may be crawled.
  • A 5xx answer stops crawling of the site for the first 12 hours; then Google uses the last good copy for up to 30 days.
  • Only the first 500 KiB are read, and Google follows at least five redirects to the file.
  • Google generally caches the file for up to 24 hours. A page you allow today may still be blocked for Google tomorrow.

We met the last one on this site. Our robots.txt lists the pages crawlers may fetch, so every new guide is blocked for Google until it reads the file again. On 4 November 2026, Search Console refused to index two of the guides we published that day, as “blocked by robots.txt”: Google was still reading the old copy, and its live test went on saying so for a while after the robots.txt report already showed the new one.

The checks: Sitemap URLs blocked by robots.txt, Internal links to pages blocked by robots.txt and robots.txt keeps AI search out. Paste the file into the robots.txt validator to see who may fetch what.

Step 2: the status code, and every redirect on the way

curl -sIL https://example.com/some-page

This prints the headers of every hop until the final answer. What Google does with them (HTTP status codes):

  • Its crawlers follow up to 10 redirect hops. Each hop is a wasted request, and a chain is usually an old redirect pointing at another.
  • Every 4xx except 429 is treated the same: a page that was indexed is removed from the index.
  • 5xx and 429 make Google slow its crawling; a server error that persists takes the pages out of the index.
  • A page that answers 200 but looks like an error, empty or saying “not found”, shows in Search Console as a soft 404.

Then the site’s other addresses: http:// and https://, with and without www. Each should redirect, in one hop, to the one you chose. The checks: Response other than 200, Redirect chain, Pages that could not be downloaded at all, The site is published on two addresses, http:// serves the site instead of redirecting to https:// and The domain is a mirror of another domain.

Step 3: the headers

The same command shows the final answer’s headers. Two matter here. An X-Robots-Tag: noindex keeps the page out of search while nothing in the HTML says so, which is why it goes unnoticed: X-Robots-Tag noindex header. On our demo shop, a header rule meant for PDFs took the guide pages out of search this way. And on an https site, the HSTS header: HSTS header missing.

Step 4: the HTML before JavaScript

curl -s https://example.com/some-page | grep -i -E 'rel="canonical"|name="robots"|<title'

Google handles JavaScript pages in three phases, crawling, rendering and indexing, and rendering waits in a queue that “can take longer” than a few seconds (JavaScript SEO basics). Three things follow from that page:

  • A noindex in the original HTML may stop Google before it runs your JavaScript, so a script can’t be counted on to take it away. Put the robots meta tag you want in the HTML the server sends: meta robots noindex.
  • Google only finds links that are <a> elements with an href: Internal links without a valid href.
  • A page that answers something other than 200 may not be rendered at all.

The canonical belongs in that first HTML too: Canonical missing, Canonical to another page and Relative canonical. And AI assistants that search the web mostly read that HTML without running it (AI crawlers), so content that only appears through JavaScript is missing for them: Content only appears through JavaScript. For the mobile version, meta viewport missing; for the page’s language, lang attribute missing.

Step 5: what Google itself sees

Search Console’s URL Inspection tool, with “Test live URL”, fetches the page in real time and shows a screenshot of the rendered page, the raw HTML returned, the HTTP headers, the JavaScript console output and the page’s resources: the page as Google renders it, which no command above shows. Google adds that a positive result is not a guarantee the page will appear in search (URL Inspection tool).

Step 6: the sitemap, speed and structured data

Then: every page, counted by template

One address by hand shows how the checks work; a site is hundreds of them. A crawler does steps 1 to 6 on every page and finds what no single page shows: two addresses for the same site, pages no link reaches, internal links written to another address of the site (Orphan pages and Internal links written to another address of the site). Most pages are made from a few templates, so most technical problems repeat on every page of one template: count each once, with the pages it covers, and fix it once, in the template.

The technical SEO audit checklist

Every technical check the Trakis audit runs, 38 in all, each linked to what it looks at and how to fix it:

Common questions

Do I need to code to do a technical SEO audit? No, to find the problems: the commands above only read. Fixing them usually means a change to a template, a server rule or a setting, which is a developer’s job.

How long does it take? One address by hand, a few minutes. A whole site is a crawler’s job; the time then goes into deciding what to fix first.

Do I need Search Console? Not to find the problems: a crawler sees what any crawler sees. Search Console adds what Google itself did with the pages, and the live test above.

How often should I run one? After every change to templates, the server or the CDN, and on a schedule in between: how often to audit a site.

Run it on every page

The Trakis audit runs all 65 checks, the 38 technical ones among them, on every page it reads, free for up to 200 pages: create an account and add your site, or see what the report looks like.

Sources

Google’s pages, read on 4 November 2026.

Last changed 4 November 2026.