Technical website audit: what to check and how
A technical website audit covers indexing, speed, security, forms and analytics. A 20-point checklist and how to rank the findings by what matters most.
In short
A technical website audit checks whether search engines can find and understand your site, whether it is fast on a phone, secure and up to date, and whether forms, analytics and backups actually work. The result is a list of findings ranked by impact: what's critical, what's important and what's merely an improvement. It's worth doing before taking over maintenance, before SEO work, before a rebuild and after a drop in traffic.
Key takeaways
- An audit covers four areas: indexing, mobile speed, security and the system, and data and compliance.
- robots.txt doesn't keep a page out of Google – that takes noindex or a password.
- Only 48% of mobile websites had good Core Web Vitals in 2025.
- 91% of new WordPress vulnerabilities in 2025 were in plugins – their versions are part of the audit.
- A good audit ends not with a list but with priorities: fix first what costs enquiries or security.
What a technical audit is and when you need one
- Technical website audit
- A systematic check of a website: indexing, speed, security, the state of the system, forms and analytics. The result is a list of findings with priorities and recommendations for what to fix first.
An audit isn't a design review or an opinion on whether the site is “nice”. It answers practical questions: does Google see your key pages, does the enquiry form actually send emails, is the system still getting security patches, and can the site be restored from a backup?
- Before taking over a website's maintenance from another developer
- Before starting SEO work – so content isn't built on a broken foundation
- Before deciding whether to rebuild the website
- When search traffic or enquiries suddenly drop
- After a major update or a move to another server
Crawling and indexing
Whether search engines can find, crawl and correctly understand the site's pages.
robots.txt and noindex
noindex
Google states that robots.txt is not a mechanism for keeping a page out of Google: a blocked page can still appear in results if other pages link to it. That takes noindex or password protection.
Source: Google Search Central, 20261
What to change
- Check that robots.txt doesn't block key pages, styles or scripts
- Find pages with noindex and make sure they're marked that way on purpose
- Review the Pages report in Search Console to see why some pages aren't indexed
Sitemap and canonical URLs
The sitemap should list only the pages you want in search: no redirects, errors or noindex pages. The canonical URL tells search engines which of several similar pages is the main version. If it points to another domain, a staging site or a page that doesn't exist, search may index the wrong version.
What to change
- Compare the sitemap with the pages actually being indexed
- Check that each page's canonical points to itself or to a deliberately chosen version
- Submit the sitemap in Search Console
Redirects and errors
Broken internal links, redirect chains (A → B → C) and temporary redirects where permanent ones belong waste both visitors' patience and search crawlers' time. After a rebuild, a common problem is old URLs with no redirects that links from other sites still point to.
What to change
- Crawl the site and find 404 errors and redirect chains
- Replace temporary redirects that should be permanent with 301s
- Check in Search Console which broken URLs visitors are landing on
Structure and internal links
Your most important pages should be a few clicks from the home page. Orphan pages – pages no internal link points to – often stay unindexed, and visitors can't find them. A crawler shows how many clicks each page is from the home page and which pages have been left without links.
Speed and mobile
How fast and stable the site is for real visitors – on a phone first of all.
Core Web Vitals
48%
Share of mobile websites with good Core Web Vitals in July 2025 (56% on desktop). 62% of sites had a good largest contentful paint (LCP) on mobile.
Source: HTTP Archive, 20264
2.5 s · 200 ms · 0.1
The “good” Core Web Vitals thresholds: LCP up to 2.5 s, INP up to 200 ms, CLS up to 0.1, measured at the 75th percentile of page loads, separately for mobile and desktop.
Source: web.dev (Google), 20263
The audit relies on real-visitor data (the Core Web Vitals report in Search Console, field data in PageSpeed Insights), while lab measurements help find the causes: oversized images, render-blocking scripts, fonts and third-party tags.
The mobile version
Google indexes and ranks based on the mobile version of a site, so the audit checks whether the phone shows the same content, headings, links and structured data as the desktop, whether text is readable without zooming, and whether buttons are too close together.
Security and the system
Whether the system is up to date, the connection is secure, and access and backups are in order.
HTTPS and certificates
Every page should load over HTTPS, and the HTTP version should permanently redirect to the secure one. The audit also checks for images or scripts loaded insecurely (over HTTP) and whether the certificate renews automatically.
398 → 47 days
The CA/Browser Forum approved reducing the maximum validity of TLS (SSL) certificates in stages from 398 to 47 days, between March 2026 and March 2029.
Source: CA/Browser Forum, 20265
System, plugin and server versions
The audit lists the versions of the system, theme, plugins and PHP and compares them with those still supported. The more parts are out of date, the greater the risk and the harder it becomes to update everything at once later.
91%
Share of new WordPress ecosystem vulnerabilities in 2025 found in plugins (9% in themes); 11,334 in total, 42% more than in 2024.
Source: Patchstack, 20266
31 Dec 2026
Access and backups
What to change
- Review admin accounts: are they all still needed, and does each belong to a specific person?
- Check whose name the domain, hosting and analytics are registered in
- Find out where backups are stored, how often they're made and whether a restore has ever been tested
Data and compliance
Whether the things the site exists for actually work: forms, analytics, structured data and accessibility.
Forms and email
The audit submits every form and checks that the email arrives, that it doesn't land in spam, that the data reaches the CRM and that the visitor sees a clear confirmation.
Analytics and cookie consent
Is analytics installed on every page, and only once? Are the key actions (enquiries, calls, sign-ups) measured, and does tracking start only after the visitor consents, where consent is needed? A duplicated tracking code or broken events mean decisions are made on the wrong numbers.
Structured data and meta information
Titles and descriptions should be unique for every page, and each page should have one H1. Structured data (schema.org) helps search understand what a company, article or product is; the audit checks it with the Rich Results test and schema validation tools.
Accessibility
28 June 2025
From this date, the European Accessibility Act applies to services provided to consumers, including e-commerce. Microenterprises providing services are exempt.
Source: EUR-Lex, 20268
A technical audit checks the basics: whether the site can be used with a keyboard alone, whether images have alt text, whether form fields have labels and whether the text has enough contrast. A full accessibility assessment is a separate job.
The audit report: where to start fixing
An audit's value isn't the number of findings but whether it's clear what to do first. A hundred minor notes without priorities only distract from the two that are actually costing you enquiries.
| Priority | What it means | Examples |
|---|---|---|
| Critical | Enquiries or sales are being lost, or there's a security risk | A broken form, noindex across the whole site, an unsupported system, no backups |
| Important | Reduces visibility or experience, but the site works | Slow LCP on mobile, 404 errors on key pages, a duplicated analytics code |
| Improvement | Worth fixing alongside other work | Duplicate descriptions, redirect chains, missing alt text |
Checklist: 20 points
Technical audit checklist
- robots.txt doesn't block key pages, styles or scripts
- noindex is used only where it's needed
- The sitemap lists only indexable pages and is submitted in Search Console
- Each page's canonical points to the right version
- No 404 errors in internal links
- No redirect chains; old URLs redirect with a 301
- Key pages are a few clicks away, with no orphan pages
- Core Web Vitals on mobile are good (LCP, INP, CLS)
- The phone shows the same content as the desktop
- The whole site runs on HTTPS, with HTTP redirected
- The certificate renews automatically
- The system, theme and plugins are up to date
- The PHP version is supported
- Only necessary admin accounts exist
- Domain, hosting and analytics are in the owner's name
- Backups are made, stored separately and a restore has been tested
- Every form sends an email and the data reaches the CRM
- Analytics is installed once, key actions are measured, tracking follows consent
- Unique titles and descriptions and one H1 on every page
- The site works with a keyboard alone, and images have alt text
How we carry out an audit
We take data from Google Search Console and GA4, check the technical state with Screaming Frog, PageSpeed Insights and Lighthouse, and validate structured data with the Rich Results test and schema validators. The audit doesn't fix the findings – fixes are estimated and agreed in advance as separate work, or handled under a maintenance plan.
Methodology
- Date
- Criteria
- The areas and checkpoints were chosen by their impact on search, enquiries and security
- Technical thresholds and recommendations – from Google Search Central, web.dev, php.net, Patchstack and the CA/Browser Forum
- The accessibility fact – from the text of Directive (EU) 2019/882 on EUR-Lex
- Limitations
- The list doesn't apply equally to every system: online stores and web platforms need extra checks (payments, integrations, permissions). It is not a legal or full accessibility assessment.
If you'd like us to take over your website's maintenance, tell us about it – we'll start with an audit. If the goal is more traffic from Google, see our SEO service. And if the audit shows the foundation no longer fits, read when to rebuild your website. We reply within 1 business day.
Frequently asked questions
How long does a technical audit take?
It depends on the site's size, system and integrations. We agree the scope and timeline before we start, so you know what you'll get and when.
Can we audit the site ourselves?
Partly: Search Console, PageSpeed Insights and the checklist in this article will reveal the most obvious problems. Checking system versions, backups, access and integrations usually takes technical knowledge and server access.
How is a technical audit different from an SEO audit?
An SEO audit looks mainly at search visibility: keywords, content, competitors. A technical audit also covers what search can't see: security, system versions, backups, forms and analytics. The technical check is the foundation of SEO work.
How often should a site be audited?
A full audit before big decisions: taking over maintenance, starting SEO, rebuilding or after a major change. Day-to-day things – updates, backups, uptime – are better monitored continuously than once a year.
Does the audit fix the problems it finds?
No. The audit shows what's wrong and what to fix first. Fixes are estimated and agreed in advance as separate work, or handled under a maintenance plan.
Sources and methodology
- Google Search CentralIntroduction to robots.txtaccessed
- Google Search CentralMobile site and mobile-first indexing best practicesaccessed
- web.dev (Google)Web Vitalsaccessed
- HTTP ArchivePerformance – The 2025 Web Almanacaccessed
- CA/Browser ForumBallot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periodsaccessed
- PatchstackState of WordPress Security in 2026accessed
- PHPSupported Versionsaccessed
- EUR-LexDirective (EU) 2019/882 on the accessibility requirements for products and servicesaccessed