Technical SEO Audit Checklist: A Practitioner’s Workflow

A technical SEO audit answers one question: can search engines fetch, understand and choose the right version of the pages that matter? This checklist follows the order in which problems block each other. A redirect loop makes canonical analysis pointless, and a robots.txt block makes on-page checks irrelevant, so start at the top and work down.

1. Scope the crawl before you run it

Most bad audit conclusions come from a crawl that didn’t look at what the auditor thought it did.

Start URL and host variants. Decide which host is canonical (https://www.example.com/ vs https://example.com/) and confirm that the other variants redirect there with a single 301.
Page limit. Record it. If the crawl hits the limit, every count that depends on coverage (inlinks, orphan candidates, hreflang return links) is a lower bound.
Rendering. Know whether your crawler executes JavaScript. If it doesn’t, client-side titles, links and structured data will look “missing”. Check a few templates with View source versus the rendered DOM before trusting those findings.
User agent and robots.txt. Crawl as an identifiable bot that respects robots.txt, and note which paths it couldn’t fetch. Blocked URLs are a finding of their own, not an absence of problems.
Rate. Leave a delay between requests on small or shared-hosting sites. An audit that triggers 503s or a firewall block measures your crawler, not the site.

Write these settings down. You need them to compare this audit with the next one (why this matters).

2. HTTP status codes and redirects

Every important URL returns 200. List 4xx and 5xx URLs together with the pages linking to them.
Record each URL’s own status. A URL that 301s to a 200 page is a 301 in your data, not a 200. Tools that only report the final status hide redirect problems.
Redirect chains (A → B → C) waste crawl requests and slow users down. Point the first URL straight at the final one.
Redirect loops (A → B → A) are a hard failure: nothing gets indexed.
Temporary vs permanent. Use 301 or 308 for permanent moves. Google treats permanent redirects as a strong signal that the target should be canonical (Google: redirects).
Timeouts and connection errors are not 404s. Report them as unconfirmed, re-test them, and check server logs before calling a page broken.

3. robots.txt

Fetch /robots.txt on every host and protocol you crawl. Each origin has its own file.
Check that important sections, CSS and JavaScript aren’t disallowed.
Remember precedence: under RFC 9309, a crawler follows the group that names its user agent, ignoring the * group, and the longest matching rule wins.
robots.txt controls crawling, not indexing. A disallowed URL can still be indexed from links, without its content. To keep a page out of the index, allow crawling and use noindex.

4. Indexability

For each HTML page, work out whether anything technically prevents indexing:

noindex in a meta robots tag or an X-Robots-Tag HTTP header (Google: robots meta tag)
a non-200 status
a canonical pointing to another URL
a robots.txt block (the page can’t be fetched, so its directives can’t be read)

Label the result as technically indexable rather than “indexed”. Only Search Console’s Page indexing report shows what Google actually indexed. A page can be technically indexable and still excluded as a duplicate or for quality reasons.

5. Canonical tags

Read canonicals from both the HTML <link rel="canonical"> and the HTTP Link header. Some CMSs and CDNs set one and forget the other.
Flag conflicting canonicals (two different targets). Google may ignore both.
Check every canonical target: does it return 200, avoid redirects, stay indexable and point to itself? A canonical to a redirect or to a noindex page sends contradictory signals.
Canonicals to other domains, or to pages your crawl didn’t reach, are not verified. Say so rather than guessing.

The detail is in canonical tag issues and how to fix them.

6. XML sitemaps

Locate sitemaps via robots.txt Sitemap: lines and common locations; parse sitemap indexes.
Every listed URL should return 200, be indexable and be its own canonical. Sitemaps are a list of URLs you want indexed; redirects, 404s and noindex pages in them weaken that signal (sitemaps.org protocol).
URLs that appear in the sitemap but were never reached through links are worth investigating. Only call them “orphans” if your crawl covered the whole site.

7. Internal links

Broken internal links: group them by destination and sort by the number of linking pages. One broken link in a header menu is one fix that clears hundreds of occurrences. See how to find broken internal links.
Links through redirects: update them to the final URL, usually once in a template.
Click depth: important pages buried more than a few clicks from the homepage are harder to discover. Use your own threshold, applied consistently.
Inlinks and anchor text: pages with almost no internal links, and links with no accessible text (an image with no alt, an empty <a>), are both discovery and accessibility problems.

8. Structured data

Treat structured data as three separate rulebooks, and say which one a finding comes from:

JSON syntax. One stray comma invalidates the whole JSON-LD block. This is a genuine error.
Schema.org vocabulary. Missing @context or @type, malformed URLs or ISO 8601 dates, the same @id described inconsistently.
Google’s rich-result requirements for the specific feature you want. Meeting them makes a page eligible; it never guarantees the rich result (Google: structured data intro).

Don’t flag a site for not using a schema type. Confirm important markup in the Rich Results Test.

9. International SEO (hreflang)

Only relevant if the site has alternate language or region versions. When it does:

Collect annotations from the HTML, HTTP headers and XML sitemaps, then merge them.
Validate codes: ISO 639-1 language, optional ISO 15924 script, optional ISO 3166-1 region, or x-default. Common mistakes are en_US (underscore), en-UK (should be en-GB) and three-letter language codes.
Every page in a set should reference itself and every alternate, and each alternate must link back. Missing return links are the most common hreflang failure (Google: localized versions).
Targets must be 200, indexable and self-canonical.

10. On-page fundamentals

Missing or duplicated titles, meta descriptions and H1s across indexable pages.
Title and description length ranges are rules of thumb. Search engines truncate by pixel width, and length isn’t a ranking factor. Treat them as opportunities, not errors.
Skipped heading levels and empty headings (an accessibility issue as much as an SEO one).
Possibly thin and near-duplicate pages, measured on main content only (excluding navigation, header and footer). Word count is a prompt to look, not a quality verdict.

11. Images

alt missing is a problem; alt="" is correct for decorative images.
Missing width/height attributes can cause layout shift.
Broken and very large images, verified with real requests and not assumed.

12. What a crawler can’t tell you

Be explicit about the limits in your deliverable:

Actual indexing, impressions and rankings: Google Search Console and Bing Webmaster Tools.
Core Web Vitals: field data from the Chrome UX Report (shown in PageSpeed Insights and Search Console), not a crawl.
Rendering differences: compare rendered HTML for key templates if the site relies on JavaScript.
Server-side behaviour for real bots: log files.

13. Prioritise and report

Group findings by root cause. Most technical issues live in templates, so one fix clears many URLs.
Rank confirmed errors on many URLs or on the homepage first, then other errors, then widespread warnings.
Give each root cause its evidence, the affected URLs and a fix a developer can act on.
Record your crawl settings, then re-run the audit after fixes with the same settings, so the comparison shows real change.

Checklist summary: scope → status & redirects → robots.txt → indexability → canonicals → sitemaps → internal links → structured data → hreflang → on-page → images → limits → prioritise.