Practice ·
A website audit begins with what a person needs to accomplish
A technical website audit should produce more than a long defect report. It should decide what to fix first by connecting search accessibility, interface performance and form behaviour to the visitor’s real task.
Establish the goal and baseline
The same defect has a different weight on a portfolio, store or client portal. Define critical pages, conversions, traffic sources, technology, recent changes and known failures before testing.
Record the baseline as well: indexable URLs, server errors, performance, analytics events and actual enquiries. Without it, a later change cannot prove improvement.
Indexing needs deliberate control
Review server responses, robots.txt, sitemap.xml, canonical links, redirects, languages, metadata and whether content is available without a fragile client-side sequence. Search engines should find useful canonical pages rather than parameters, duplicates and technical routes.
Look for orphan pages, repeated titles and URLs that change content without changing address. These faults obscure the site’s structure.
Test performance in the context of the screen
One average score does not identify a cause. Find which resource builds the first view, what blocks rendering, why layout shifts and how the page responds to interaction.
Test a mobile device and slower connection, then compare laboratory results with field data. Images, fonts and third-party scripts should be fixed according to measured impact.
Run scenarios manually and automatically
Navigation, search, forms, payments, uploads, messages and network failures need separate checks. The failure path matters: empty fields, repeated submission, back navigation and unavailable integrations often expose the main defects.
Automated tests protect repeated rules but cannot replace viewing a real screen. Text may technically fit and remain unreadable.
Security and ownership belong in the audit
Check HTTPS, dependencies, security headers, input handling, administrator permissions, backups and access to domain, hosting, analytics and repository. Sensitive information must not leak into client code or logs.
The audit should also reveal whether the owner can continue without the previous contractor. Missing access and documentation are technical risks too.
The outcome is a prioritised plan
Every finding needs evidence, an affected scenario, risk, repair method and verification step. Separate critical faults, revenue or indexing issues, planned improvements and observations.
Within the Method, I finish an audit with a sequence of actions rather than a defect count. Restore operation and observability first, correct structure next, and only then add new capability.
Start with the website's purpose
If you are planning a website or rethinking one, we can begin with its role in your business, its structure and the visitor's path to an enquiry.