Comprehensive website audit: every dimension, one work plan

A comprehensive website audit puts SEO, speed, security, accessibility, mobile, privacy and email in one picture. Here is how to plan the work it produces.

SEO · Published: 6 October 2026 · 6 min read · Ольга Мирошник

Most sites get checked in slices. Marketing looks at SEO, a developer looks at speed, and once a year someone remembers the certificate. Each check is honest, but the result is a mosaic, and the most expensive problems live exactly where the slices meet: a redirect that hurts both indexing and load time, an analytics script that slows the page down and also fires before cookie consent. A comprehensive website audit exists to see every layer at once and decide what to fix first — instead of fixing whatever happened to catch someone's eye.

Seven dimensions, checked together

A proper comprehensive audit does not cover "everything". It covers a defined set of dimensions:

• SEO and indexing. Title and description, headings, canonical, hreflang, structured data, robots.txt and the sitemap.
• Speed. Core Web Vitals, with Google's "good" thresholds: LCP ≤ 2.5 s, CLS ≤ 0.1, INP ≤ 200 ms.
• Security. HTTPS and the certificate, HSTS, Content-Security-Policy and the other headers, service files left exposed.
• Accessibility. WCAG 2.1: labelled fields, contrast, visible focus, keyboard operation.
• Mobile. The viewport, elements wider than the screen, menus and dialogs on a phone.
• Privacy and legal pages. Trackers, the consent banner, links to the privacy policy and terms.
• Email and domain. SPF, DKIM, DMARC, and the expiry dates of the domain and the certificate.

Each of these has its own article on our blog, from Core Web Vitals to email authentication. The point of a comprehensive approach is to put them on one scale of priority.

Why checking in slices fails

Three common situations where a partial audit misses the real problem:

1. Third-party scripts. The SEO specialist does not see them, the developer considers them "someone else's", and legal does not know the chat widget sets cookies. One script ends up hurting INP, breaking the CSP and violating GDPR at the same time.
2. Moving to HTTPS or a new domain. Redirect chains cost speed and crawl budget, mixed content costs security, and a forgotten SPF record on the new domain sends contact-form mail to spam.
3. A redesign. The new layout passes visual sign-off but quietly loses form labels — and the product markup along with them.

When different people look at different dimensions at different times, nobody notices that it is one cause.

Turning the audit into a work plan

The output of a comprehensive audit easily becomes a list of a hundred items that nobody finishes. A simple order helps.

First, whatever breaks the whole site. An expiring certificate, a domain without auto-renewal, a robots.txt that blocks indexing, 5xx errors on key pages. These are domain-level problems: one change, effect everywhere.

Then critical and high findings, weighted by the number of pages. A bug in the product template that shows up on 400 pages beats a perfect fix to a single article.

Then the quick wins. Security headers, width and height on images, caching for static files: half an hour of work, visible results.

Only then the long projects. Rewriting the front end for INP or rebuilding navigation for accessibility are sprint-sized tasks, not evening ones.

Give every task an owner: server and DNS to the admin, templates to the front-end developer, copy and meta tags to content, the consent banner and policies to whoever owns the legal side.

How many pages to check

You do not need every URL. Most sites have only a handful of templates, so the sample has to include the home page, category pages, product or service pages, articles, forms and the cart. If the site has 20 page types and the audit read 10 addresses, some templates were never seen — that is a reason to run a deeper audit type, not to draw conclusions from half a picture.

The re-check is part of the audit

An audit without a second run is an opinion, not a result. After the fixes are deployed, scan the site again and compare: what was fixed, what is still there, and what is new. The last group matters most — tightening the CSP easily breaks a payment widget, and font optimisation can break the mobile layout. The process side is covered in our piece on the website audit as a process, the server side in the technical audit guide.

Running a comprehensive audit with SiteScan

1. Start a free scan. The scanner loads pages in a real headless browser and returns an overall score out of 100 plus category scores: SEO, performance, security, accessibility, mobile, privacy, forms, links, console, HTML validity, images and infrastructure.
2. Read "In short, for the site owner" first: the three most dangerous problems and how many pages each one touches.
3. Go through the site-level checks — certificate, domain registration, mail, headers. Every row links to an explanation, for example on DMARC or certificate expiry.
4. Click "Copy fix brief" to turn the critical, high and medium findings into a task list for your developer.
5. After the fixes, scan again: the report shows what changed since the previous scan.

What each analyzer covers is described on the product page; deeper audits for larger sites are on the pricing page.