Technical SEO Audit Checklist: 7 Areas to Check

4 views 5 min read

A technical SEO audit checks whether search engines can crawl, understand and trust your site. Use this checklist as a repeatable routine. It is grouped by area, and each area starts with the checks that matter most.

1. Crawling

  • robots.txt is reachable, returns 200 and does not block important sections, CSS or JavaScript files that the pages need to render.
  • The sitemap location is listed in robots.txt.
  • Server errors (5xx) are rare. Frequent errors make crawlers visit less.
  • Important pages are reachable through internal links within a few clicks of the home page.

2. Indexing

  • Pages you want in search do not carry noindex, in the meta tag or in the X-Robots-Tag header.
  • Each indexable page has a self-referencing canonical, and canonicals do not point to redirected or error pages.
  • The XML sitemap lists only final, indexable URLs with a 200 status.
  • Soft 404 pages, which look empty but return 200, are fixed to return a real 404 or redirected.
  • Search Console's Pages report is reviewed for reasons such as "Crawled, currently not indexed" and "Duplicate without user-selected canonical".

3. Site structure and redirects

  • One canonical host: HTTP redirects to HTTPS and the non-preferred www or non-www host redirects to the other, each in a single 301.
  • No redirect chains or loops. Update internal links to point straight to the final URL.
  • URLs are readable and stable, with parameters handled so that duplicates are not created.
  • Broken internal links (404) are found and fixed.

4. Speed and rendering

  • Time to first byte is low. Slow responses point at hosting, caching or heavy backend work.
  • Core Web Vitals are in the good range: Largest Contentful Paint of 2.5 seconds or less, Interaction to Next Paint of 200 milliseconds or less, Cumulative Layout Shift of 0.1 or less.
  • Text compression such as Brotli or gzip is on, static files have caching headers and images are compressed.
  • Render-blocking scripts and stylesheets are deferred or inlined where possible.
  • Content that matters is present in the rendered HTML, not only after a long client-side script runs.

5. Security and trust

  • A valid TLS certificate with a safe expiry date and a modern protocol version.
  • No mixed content: every image, script and stylesheet loads over HTTPS.
  • Security headers: Strict-Transport-Security, a Content-Security-Policy, X-Content-Type-Options, a clickjacking rule (X-Frame-Options or frame-ancestors) and a Referrer-Policy.
  • Cookies carry the Secure and HttpOnly flags, with a suitable SameSite value.
  • No exposed backup, configuration or directory listings.

6. Structured data and metadata

  • JSON-LD is valid for the types you use, such as Organization, Article, Product or FAQPage.
  • Titles and meta descriptions are unique and complete.
  • Open Graph tags are present for shared links.

7. International and AI-search setup

  • hreflang codes are valid, include a self-reference and each language version links back to the others.
  • The language of each page matches its hreflang and the visible content.
  • robots.txt rules for AI crawlers are a deliberate decision. Some site owners also publish an llms.txt file; treat it as an optional signal, not a ranking factor.

How to prioritize what you find

  1. Fix problems that stop pages being crawled or indexed.
  2. Fix site-wide issues that repeat on every page.
  3. Fix speed and security items with a clear user impact.
  4. Do the remaining polish when the above is done.

Record the date and the main findings of each audit so you can see whether the site is improving. Repeating the audit after releases catches regressions early.

Mistakes that make audits less useful

  • Delivering a list without priorities. A report with three hundred items and no order is rarely acted on. Group findings and mark the few that matter most.
  • Auditing only the pages you like. Sample every template: home, category, product or service, article, search and pagination pages.
  • Treating every warning as an error. Some warnings are intentional, for example a noindex on internal search results. Note the decision so the next audit does not raise it again.
  • Not retesting. A fix that was deployed but never verified may have failed or broken something else. Re-run the affected checks after each release.

Automate the repeatable part

Most of this list can be tested by a script. SEOCheck-AI runs more than 60 checks in six areas and returns a score for each, with a fix in plain language. It reads public pages only, does not log in and does not change anything. If you only want a quick first pass, see how to check website SEO for free.

FAQ

How often should I run a technical SEO audit?

Run a full audit once or twice a year and a quick check after every major release or migration.

Which area should I start with if I only have an hour?

Indexing and crawling. Confirm that robots.txt, noindex, canonicals and the sitemap are correct, because mistakes there can hide the whole site.

Is technical SEO more important than content?

They work together. Technical problems can stop good content from being found, and good technical setup cannot rescue content nobody wants.

Do small sites need a technical audit?

Yes, though it is shorter. A small site has fewer pages to crawl, but the same mistakes can hide it: a leftover noindex, a wrong canonical or a blocked robots.txt. A quick scan takes minutes and prevents long periods of invisible problems.

Check your own website

Reading a checklist is useful, but a scan shows what is actually wrong on your site. Run a free SEO check, enter your domain and get a score for each area with a ranked list of fixes. The baseline report needs no account. You can also read what the SEO checker analyzes or open the free SEO check page for an example report.

Back to blog