Technical Site Audit: A Working 20-Point Checklist

A technical audit is the most underrated part of working on a site. It produces no pretty presentations, but this is exactly where you find the problems that make the rest of the budget pointless. Below is the checklist we run every project through. On a site of up to 500 pages it is 1–2 days of work.

Indexing and availability

• Robots.txt is not blocking sections you need — check it line by line, not by eye
• Sitemap.xml exists, returns 200 and contains only canonical URLs that return 200
• The number of indexed pages is comparable to the number of real pages (a gap over 20% is a red flag)
• No accidental noindex in the head — after a move from a staging server this happens regularly
• The server returns correct codes: 404 for pages that do not exist, 301 for moved ones, no soft 404s

Duplicates and canonicalization

• One version of the site: https, one variant with or without www, everything else 301
• The trailing slash in URLs is unified
• Canonical is present on every page and points to itself, except on pagination and filters
• Sorting parameters and UTM tags do not spawn indexable copies
• No two pages target the same query — the most common cause of stuck positions

Speed and Core Web Vitals

We check LCP, INP and CLS on field data, separately for mobile. The same section covers image sizes, server-side compression, static caching and the number of third-party scripts. The order of analysis and the typical fixes are described in the articles on Core Web Vitals and load speed. The measurement tool is PageSpeed Insights.

Mobile version and layout

• No horizontal scrolling at 360 px width
• Tappable elements are at least 44 px and not stuck to each other
• Body text is 16 px or larger and contrast passes WCAG AA
• The mobile content matches the desktop content in full — Yandex simply will not see hidden blocks

Markup and metadata

• Title is unique on every page and contains the main query at the beginning
• Description is written by hand for the top 30 pages rather than generated
• One H1 per page, a heading hierarchy with no skipped levels
• Organization and BreadcrumbList microdata, and for a store, Product with price and availability

Security and infrastructure

A valid certificate, no mixed content, service sections closed off, up-to-date CMS and plugin versions. More than once we have found backdoors left behind by previous contractors on client sites, and admin panels on default addresses with no IP restrictions. The basic list of threats is worth checking against the OWASP Top Ten, and if the site processes personal data, a full security audit is worth considering.

How to present the result so that it gets used

Nobody reads an 80-page report full of Screaming Frog screenshots. The working format is a table: the problem, where exactly it is, the impact (critical / important / cosmetic), an estimate in hours, and the owner. We hand it over together with priorities for the first sprint so a developer can pick up tasks the same day — usually this happens as part of technical support.

How often to repeat it

A full audit once a year, or after any major change: a redesign, a migration, a CMS switch. A short check of indexing and speed monthly, 30–40 minutes. Before a redesign an audit is mandatory, otherwise you carry the old mistakes into the new site: we described the plan for such a transition in the article on redesign without losing positions.

If there is nobody to run the checklist for you, we do the audit in 5–7 working days and deliver the tasks in a convenient format. Details are in the web development section.