Begin with what is actually broken.
A technical review should start with the paths that matter to the business. Can a customer load a service page, understand the offer and make contact? Can a search engine access the content that explains it? A site-wide score is less useful than evidence about a specific problem.
Existing pages, links and customer data need protection during changes. Capture the current state, identify important URLs and plan deliberate redirects before moving or replacing content.
The checks that support a useful website.
Discovery & indexing
Review crawl access, robots directives, sitemaps, internal links and the evidence available in Search Console.
URL consistency
Check HTTPS, canonical URLs, redirects, status codes and duplicate versions of important pages.
Page delivery
Look at image size, scripts, rendering and the experience on representative mobile and desktop pages.
Conversion reliability
Test forms, errors and confirmations so a polished page also provides a dependable next step.
Ask for an actionable issue record.
Each material finding should identify the affected URL or template, the evidence, the likely impact and the work needed. It should also name who can implement the change and how the result will be checked.
| Illustrative finding | Action | Verification |
|---|---|---|
| An important service URL returns an error. | Repair the intended page or map a relevant permanent replacement. | Confirm its status, content, links and destination. |
| Multiple URL versions describe the same page. | Review redirects, canonical signals and internal links together. | Check consistency and monitor the search engine’s selected version. |
| A request form reports success without a saved record. | Connect confirmation to actual durable storage. | Find the submitted request in the authorised operator view. |
These are examples of useful scoping, not findings about your website or claims about completed client work.
Agree who does the work.
An audit and an implementation engagement are different. Confirm whether the scope includes development, content changes, coordination with an existing developer and post-release checks. Access and responsibility should be agreed before work starts.
Lab performance tests can help diagnose problems. They do not establish the experience of every real visitor. Where field data is available, interpret it alongside the affected page types and customer journeys.
Fix, verify, then measure. A successful build proves that code compiled. It does not prove that the production contact form works or that a page has been indexed.
Further reading
Reference guidance reviewed October 21, 2026. Check the source for current requirements.