Prioritise website repairs using evidence

Describe the issue before proposing a solution

Write a reproducible statement: which page, device or account is involved, what action fails and what result was expected? ‘The website looks outdated’ is not actionable. ‘On a phone, the quote button stays hidden after opening the menu’ gives you a concrete acceptance check. Keep a screenshot or error message without unnecessary personal data.

Separate your observation from your hypothesis. An enquiry without a reply may involve validation, sending or receipt; changing the form’s appearance may leave the cause untouched. If the issue was reported only once, record the conditions and try to reproduce it in a test environment without real external effects.

Order work by consequences and dependencies

Our starting method gives priority to essential page availability, the contact journey and restoration capability. Access to content on mobile and with a keyboard, followed by information accuracy, comes next. Discovery, speed and measurement then need attention according to actual needs and evidence. A specific constraint may change this order.

One task can unlock several others. Recovering administration access or fixing a shared template may be more useful immediately than rewriting an individual page. Identify those dependencies and keep the first batch small enough to deliver and check together. An important issue without evidence remains a planned verification, not a confirmed failure.

• Critical failure: an essential function cannot complete.
• Barrier: the function exists, but some visitors cannot use it properly.
• Improvement: the answer or journey works and can become more useful.
• Unknown: there is not enough evidence to conclude.

Turn a priority into a verifiable delivery

For each batch, record the page or function, owner, dependency, expected change and acceptance criterion. A fictional example: make the contact menu keyboard accessible; acceptance means opening, navigating, closing and returning focus without a mouse on both affected templates. Another person can then check the delivery independently.

Arrange a proportionate rollback before changing a shared function. Copying files does not back up a database. Keeping the previous version may suffice for an editorial repair; an import or migration also needs preserved identifiers, relationships and persistent data.

Measure under comparable conditions

A loading measurement on a slow connection cannot be compared directly with one on a fast network. Repeat the same URL with a comparable device, tool, consent state and conditions. Core Web Vitals cover different aspects of experience; one laboratory score does not describe every visitor.

Check whether the failure follows one page, the whole website or several unrelated websites on the same connection. That distinction helps decide whether to examine the page, hosting or local network. Keep the diagnostic conditions alongside the result rather than treating every slow observation as a server fault.

For search, separate the delivered repair from its observed outcome. Google’s Search Essentials do not guarantee crawling, indexing or serving. Record what changed, then observe performance separately when actual data is available.

Keep a short record and continue with the next batch

A useful record contains the observation, evidence, priority, owner, delivered version, performed check and remaining point. Avoid claiming increased conversions merely because a new button exists. A smaller result can be fully observable: the journey completes, accurate information is visible or a page no longer returns an error.

Use the website priorities tool for an initial work order and the acceptance log for checks. After accepting a batch, revisit unknowns and remaining improvements. Keep reasons and evidence for satisfactory areas instead of rewriting them simply to fill a plan.