A technical audit is useful when it helps you choose work, define a task and verify its outcome. Take your report and highlight its five most serious findings. In an hour, you can turn them into a short decision list: fix, request evidence, monitor or defer. You do not need to read the site’s entire codebase yourself.
Prepare the report, a list of important pages and someone who knows how the site receives enquiries or orders. If the report’s author is available, ask them to explain those five findings using specific URLs. “350 errors found” tells you neither the number of causes nor the workload: one template fault can recur on hundreds of pages.
Establish exactly what was checked
Find the date, website address and investigation conditions. Check whether the report covers the live site, a test copy or a version preceding the latest update. List changes since the review: a new domain, template release, catalogue migration or new widget.
Ask the author to distinguish discovered pages from tested pages. Crawling one sitemap will not find every old URL or page without incoming links. Testing the home page does not cover the basket, search, filters or forms. Inspecting source HTML does not always reveal the result after JavaScript executes.
- Which sections and page types were sampled?
- Where did the URLs come from: links, a sitemap, a search console or server logs?
- Were forms and ordering tested through user actions?
- Which devices and browsers were used?
- Which checks could not be completed, and why?
“Eight page types checked” may be sufficient for an initial template investigation. Just do not describe that sample as a check of every URL. If the reviewer had no search-console access, conclusions about actual indexing need additional evidence.
Turn a finding into an issue record
Choose a line such as “Broken links found”. Request the source page, link location, destination URL, test time and response received. Then follow the link yourself. If the fault does not recur, do not immediately discard it: conditions may have changed, or the failure may be intermittent.
A complete record contains an observation, consequences, suspected cause, proposed solution and acceptance criteria. The cause may remain a hypothesis. For example, a product disappeared after an exchange, but it is not yet clear whether source data, catalogue selection or caching caused it. Recording uncertainty is more useful than commissioning an integration rebuild in advance.
| Weak finding | What is missing | What to request |
|---|---|---|
| Poor SEO | A verifiable fact | URL and observation |
| Slow website | Measurement conditions | Page, device and test |
| Duplicate pages | Content comparison | URL pair and differences |
| Fix the form | Expected outcome | Scenario and acceptance test |
Evidence should be accessible and understandable to the person accepting the work. A screenshot showing the URL, a saved server response, a short scenario recording or an exported page status can all help. A link to a contractor’s private dashboard is inconvenient if access disappears when the contract ends.
Separate facts from explanations
Fact: the required page returned 404 during the check. Explanation: a URL rule generated an incorrect link. Possible consequence: some visitors may not have reached a product. These statements need different evidence. An error does not automatically tell you how much revenue was lost.
Label each of the five findings “observed”, “suspected” or “not checked”. Then decide which test would change your decision. If opening two URLs and comparing their products is enough, do not buy another large investigation. An intermittent failure may need error-log monitoring over an agreed period.
Ask separately where each rule comes from. A search-engine recommendation, a particular system limitation and the report author’s personal preference carry different weight. Request current documentation and an explanation of why it applies to your page. The same tool may flag a useful exception as a warning.
Review four commonly disputed conclusions
“There are 404s, so the site is broken”
A 404 response means no content was found at that URL. This is expected for a page that never existed. It becomes a problem when a live link points there or a useful page should be there. Ask for the source of the visit and the URL’s intended purpose. Google documents response-code behaviour in its HTTP status guidance.
“It is in the sitemap, so it is in search”
A sitemap helps communicate URLs for discovery. It does not prove inclusion in the index. Google’s sitemap overview distinguishes submission from subsequent processing. Request the selected URL’s actual status in the search engine’s console, including the data date.
“The speed score is low; you need a new platform”
First establish the page, device, network, tool and number of tests. A laboratory run helps investigate causes under controlled conditions; real-user data describes a different set of observations. Google defines Core Web Vitals in terms of loading, responsiveness and visual stability. One score cannot choose your site architecture.
Ask how the delay affects an action: someone waits too long for products, a button fails to respond or a field moves during typing. Then assess specific causes and fixes. A large image, an external script and a slow database query require different work.
“All short titles must be made longer”
Check whether the page’s subject and distinctions are clear, whether a repeated template obscures them and whether meaning is cut off. Character count alone does not prove a ranking problem. If the recommendation adds empty words just for length, ask for a substantive improvement and what it explains to the customer.
Prioritise by consequences
Start with issues that prevent important actions: orders are not saved, a material price is wrong, a section is unavailable or required pages have accidentally been excluded from search. Then review navigation, duplicates and content. Within that queue, consider reach, confidence in the diagnosis and difficulty of the fix.
Do not assign urgency solely from the report’s colours. One incorrect payment URL may matter more than a thousand identical utility-page descriptions. Conversely, an apparently harmless shared-template fault may affect the entire catalogue. Record who is affected and which action is disrupted.
It helps to separate immediate recovery from investigating the cause. You may restore access to a form before completing the investigation into its instability. After a temporary fix, keep a task open to explain recurrence and determine a lasting correction.
A completed training example
Observation: the second-page link in the “Cabinets” category opens an empty list; direct access gives the same result. The catalogue contains products that should appear there. Cause not yet established. Priority: investigate the list template. Task: restore access to the next product group through its own URL. Acceptance: the URL opens in a new session, contains the expected items, product links work and the neighbouring category has also been checked.
Before work starts, define the boundary: is the fix for this section or the shared template, are caching changes needed, and what will be checked after the catalogue refreshes? “Two hours per error” without this boundary may conceal different scopes from two contractors.
Prepare a small developer brief
- Specify the page, scenario and observed behaviour.
- Attach the original evidence and date.
- Describe the expected result through simple actions.
- Name related pages that must keep working.
- Agree a test copy, release time and method of restoring the previous version.
- Decide who repeats the check and where its result is saved.
For a template, test different content: short and long names, a product with variants and an empty optional field. If an exchange changed, repeat the check after the next agreed data update. A fix that disappears after an exchange has not passed acceptance.
Keep four separate states in the worksheet: change prepared, published, retested successfully, and processed by the search engine. The last applies only to search-related tasks and may happen later. A screenshot of published code cannot confirm that Google or Yandex has processed it.
When you do not need another audit
If the current report is recent, describes reproducible problems and has not yet been acted on, start with priorities and fixes. Another automated crawl may repeat the same list. A focused recheck is useful if the template changed, the author cannot show evidence or contractors disagree about a significant fault.
Do not commission a complete rebuild solely because a report is long. First group repeated findings by cause and estimate fixes to shared components. A platform change makes sense after checking the current system’s limitations and the cost of alternatives.
Glossary
- Crawling: visiting URLs with software to collect information.
- Coverage: the parts of the site and scenarios that were checked.
- Hypothesis: a possible explanation still awaiting verification.
- Regression: a previously working scenario breaking after a change.
- Acceptance: a repeatable check of the agreed result.
For outside help, five disputed findings, their URLs and available evidence are enough to begin. You can request a priority review while retaining control of decisions about further work.
Apply this to your own project
Turn five report findings into decisions: fix, clarify, monitor or defer, with a check for each outcome.
From an audit finding to a testable task: open the worksheet · Download the CSV to complete. Free access, no registration. Use it independently or pass it to your contractor.