Technical SEO audit checklist: the order to check things in

A useful audit is ordered by consequence: first anything that stops pages being crawled or indexed, then what confuses which URL ranks, then structure and speed, then enhancements. This checklist follows that order and ends with a prioritised list, not a 200-row spreadsheet.

DeskSEO editorial team · Nov 8, 2026 · 6 min read

An engineer walks around a small white propeller plane in a bright hangar

Technical audits often fail in a predictable way. A crawler produces a report with hundreds of issues, a consultant pastes them into a spreadsheet, and the development team receives 180 rows of equal-looking warnings. The three items that actually suppress the site's visibility sit next to forty missing alt attributes on decorative icons, and nothing much changes.

A better audit is ordered by consequence. First anything that prevents crawling or indexing, because nothing else matters if pages cannot be found. Then anything that confuses search engines about which URL should rank. Then structure, speed and enhancements. This checklist follows that order.

Before you start

Access: Search Console (a Domain property if possible), analytics, server logs, CMS and the ability to see the robots.txt and templates.
Context: recent releases, migrations, known problems, business priorities (which sections bring revenue).
A full crawl with a desktop or cloud crawler, configured to render JavaScript if the site depends on it, plus a list of URLs from sitemaps and analytics to compare.
Templates: list the main page types (home, category, product, article, location, search) and pick a few representative URLs of each. Most technical issues are template issues.

1. Can search engines reach and read the site?

Check	Healthy result
Home page and key templates return 200 over HTTPS	Yes, quickly, without redirect chains
robots.txt	Returns 200 or 404, does not block important sections or resources, lists the sitemap
noindex	None on pages meant to rank, in meta tags or X-Robots-Tag headers
Bot protection and firewalls	Search engine crawlers are not challenged or blocked
Rendering	Main content and links present in raw HTML or rendered without errors
Server errors	No pattern of 5xx or timeouts in logs or Crawl Stats

The noindex and robots.txt guide and the JavaScript guide cover the details. The free SEO checker covers these basics for any URL in under a minute and is a good first step before a full crawl.

2. Is the right URL indexed for each page?

Host and protocol: one version (https, www or not) returns 200; the others redirect in one hop. See redirects, HTTPS and www.
Canonicals: self-referencing on indexable pages, absolute URLs, consistent with internal links and sitemaps. See canonical tags.
Duplicates: trailing slashes, case, parameters, print views, staging copies. See duplicate content causes.
Page indexing report: reasons that are rising, especially "Duplicate, Google chose different canonical" and "Crawled – currently not indexed" on important templates. See the Page indexing report.
Status codes: soft 404s, 404s that are still linked, redirect chains and loops.

A home inspector checks the corner of a sunny attic beneath timber beams

3. Is crawling spent well?

Mainly for larger sites:

Parameter and filter URLs being crawled at scale; see faceted navigation.
Internal links pointing to redirects or errors.
Infinite spaces: calendars, internal search, session IDs.
Share of crawler requests going to valuable templates, from logs; see log file analysis.

4. Is the structure sound?

Click depth of important pages from the home page.
Orphan pages: in sitemaps or analytics but not linked internally.
Internal anchors: descriptive, consistent, not pointing the same anchor at different pages.
Pagination: crawlable links, self canonicals; see pagination.
XML sitemaps: only canonical, indexable, 200-status URLs; honest lastmod; see XML sitemaps.

5. On-page basics, by template

Unique titles and meta descriptions; one H1; no template defaults left in place.
Main content substantial and distinct per page; no near-empty templates.
Images with alt text where they carry content, and dimensions set.
lang attribute and meta viewport present.

Look at these per template, not per URL. One template fix resolves thousands of rows in the crawl report.

6. Performance and page experience

Field Core Web Vitals per template group from Search Console, then lab diagnosis of the worst groups.
Server response time for HTML; see TTFB.
LCP, INP and CLS causes per template; see LCP, INP and CLS.
Mobile parity: content, links and markup present on the mobile version; see mobile-first indexing.
Intrusive interstitials on mobile.

7. Structured data and enhancements

Valid markup for the page types that matter (Organization, Product, Article, Breadcrumb, LocalBusiness), matching visible content.
Enhancement reports in Search Console for errors and warnings.
Open Graph tags for sharing.

8. International and multi-site setup

If the site has language or country versions: hreflang complete and reciprocal with valid codes, self canonicals per version, no forced IP redirects, consistent structure. See hreflang implementation.

9. AI crawler access

Check robots.txt and CDN settings against the business's intentions for AI search and training crawlers. Many sites block AI search agents by accident through copied lists. The AI bot checker shows the effective rules per crawler.

10. Security and hygiene

HTTPS everywhere, valid certificate chain, no mixed content.
No exposed staging sites, backup files or debug pages.
Manual actions and security issues reports clear.
CMS, plugins and themes up to date.

Checking templates efficiently

For each template, pick three URLs: a typical one, a heavy one (many products, long article, lots of images) and an odd one (empty category, out-of-stock product, very old post). For each, compare the raw HTML with the rendered HTML, note title, canonical, robots directives, H1, structured data, internal links and main content, and run a lab performance test on mobile. Twenty minutes per template finds most issues a full crawl would report, and it explains them, which a crawl report does not. Use the crawl afterwards to measure how many URLs each template issue affects.

Writing a finding that gets fixed

Compare two ways of reporting the same problem.

Weak: "Canonical issues found on 3,412 pages."

Strong: "Product pages reached through a category path (/boots/trail-x/) declare a canonical to that path instead of the main product URL (/products/trail-x/). Affects about 3,400 URLs. Search Console shows 1,100 of them as 'Duplicate, Google chose different canonical', and product pages have lost impressions since the theme update on 2 October. Fix: change the canonical in the product template to always output the main product URL. Effort: small, one template change. Impact: high, affects the revenue template."

The strong version names the template, shows evidence, connects it to performance, and says exactly what to change. Developers can act on it, and managers can prioritise it.

Audit pitfalls

Auditing only the home page. The home page is usually the best-maintained page on a site.
Trusting tool severity labels. A crawler's "high priority" warning about meta description length is not high priority.
Ignoring what Google already says. Search Console's reports often confirm or rule out a suspected issue in minutes.
Recommending what cannot be done. Check platform limits before recommending changes; the Shopify guide is a good example of how much a platform fixes for you.

Turning findings into a plan

For each finding, write: what is wrong, which templates or how many URLs, evidence (screenshots, example URLs, data), likely impact, recommended fix, and effort. Then rank them. Indexing blockers and canonical confusion on revenue-driving templates go to the top; cosmetic items go to a backlog. The prioritising fixes guide describes a simple scoring method.

Agree the top items with whoever will implement them before the report is final. A fix the development team understands and has scheduled is worth more than a perfect recommendation that sits in a backlog. A good audit report fits the important findings on one page, with appendices for detail. If the summary is longer than the list of things that will actually be fixed in the next quarter, it is too long.

Between audits

Most technical damage happens between audits, in releases nobody checked. Scheduled monitoring catches the expensive regressions early: a noindex added by a release, a robots.txt change, a broken redirect, a slower server. DeskSEO re-checks domains on a schedule and emails when the score drops or a new critical issue appears; see scheduled monitoring.

Questions

How long does a technical SEO audit take?

For a small site, a focused audit takes a few hours. Mid-size sites with tens of thousands of URLs take a few days, mostly spent crawling, sampling templates and reading logs. Large sites need longer and benefit from ongoing monitoring instead of one-off audits.

What tools do I need?

A crawler, Search Console, a way to view raw and rendered HTML, PageSpeed Insights or Lighthouse, and ideally server logs. Most problems are found with these alone.

How often should I audit?

A full audit once or twice a year, plus a quick check after every major release, migration or redesign. Scheduled automated checks between audits catch regressions early.

Should the audit list every issue the crawler reports?

No. Crawlers report hundreds of minor items. A useful audit groups findings by template and cause, estimates impact, and recommends a short prioritised list of fixes.