← All articles and guides

Technical SEO audit checklist: 14 things to check, in order

7 minute read Updated 29 October 2026

A technical SEO audit checks whether search engines can reach, read and trust each page. The order that saves most time is crawling and indexing first, then duplicate addresses and canonicals, then what each page says about itself, then speed and security. Here are fourteen checks, each with how to test it by hand.

Before you start

Technical SEO is the part of search optimisation that is pass or fail rather than a matter of judgement: a page is reachable or it is not, a canonical resolves or it does not. It is also invisible from the front of the site, which is why it needs a crawl. If you want a list of addresses to work from, run an audit first; the checklist below then tells you what each result means. Do the groups in order, because a problem in the first group makes everything after it irrelevant for the page concerned.

Reach: can search engines get to your pages?

1. robots.txt. Open yoursite.com/robots.txt and check it does not disallow folders you want found. It controls crawling, not indexing, and a page it blocks cannot be read, so a noindex tag on that page is never seen. Test an address with the robots.txt tester.
2. noindex. Look for noindex in the page source or in an X-Robots-Tag header on every page that should rank. One left on after a staging site went live is among the commonest ways a whole section disappears.
3. Status codes. Every internal link should lead to a page that answers 200. Restore or redirect pages that answer 404, and look at any 5xx errors.
4. Crawlable links. Google follows links written as an a tag with an href. A button or script that changes the page without one is not something it can follow.

Consolidate: does each page have one clear address?

5. Redirects. Use a permanent redirect when a page moves, because Google shows the new address in results for those. Avoid chains of several hops, and point your own links at the final address.
6. Canonical tags. One per page, written as a full address, pointing at a page that answers 200 rather than at a redirect. Google treats several signals as hints about the preferred address, in a stated order of strength, so contradicting them is what causes trouble.
7. One version of the site. http and https, www and non-www, and differences of capitals or a trailing slash should all lead to one address.
8. Sitemap. It should list only pages you want indexed, be declared in robots.txt, and stay within Google's limit of 50,000 addresses or 50MB uncompressed per file. Check one with the sitemap validator.

Read: can search engines read what is on each page?

9. JavaScript. Google crawls a page first and renders it in a second step. If the HTML your server sends has no heading and almost no words, you are depending on that second step. View the page source and compare it with what you see in the browser. Our audit re-renders a sample of such pages so its findings reflect what a search engine would see.
10. Titles and descriptions. Each page needs a title that describes it and is different from every other page's, and a description worth showing. Google may rewrite either, but it starts from what you wrote. Check a page with the meta tag checker.
11. Structured data. Only where it matches what the page visibly says, with the required properties present. Google retired How-to rich results in September 2023, so markup for them earns nothing and can come out.

Trust: is the site fast, secure and consistent?

12. HTTPS. A valid certificate that is not about to expire, and no page that loads images or scripts over plain http.
13. Speed. Google's guidance for Core Web Vitals is for the largest content to appear within 2.5 seconds of the page starting to load. Test your most important pages, not only the home page.
14. hreflang, if you serve more than one language. Every page should name itself and each alternative, and each alternative should link back.

Doing all fourteen at once

By hand this is an afternoon for a small site and impractical for a large one. Lala SEO runs 102 checks that cover these, free for up to 300 pages. Open the result with the guide to reading the report, and when you know what is wrong, what to actually change. The example report shows the whole thing on our own site, faults included.

How often to run it

After anything structural: a redesign, a change of platform, a URL migration, an edit to robots.txt, a move to new hosting. That is when these faults are introduced, almost always by accident. Between those moments a regular check is enough, and the paid plans re-crawl on a schedule and tell you what changed. Several of the checks come from requirements in Google's documentation, which changes, so we re-read the pages our checks cite every morning and list what changed.

The bottom line

Technical SEO comes down to three questions about every page: can a search engine reach it, can it read it, and can it tell which address is the real one. Work through the fourteen checks in that order, fix the critical findings first, and repeat the audit after anything structural. A free audit runs them for you.