B2B Website Audit Workbook: reproducible checks instead of guesswork

1. Scope the review around important visitor tasks

Choose three tasks a suitable visitor should actually complete: understand a service, find relevant evidence and initiate a next step. Record the starting page and end state. Avoid random page inspections while the central enquiry journey remains undefined. A full inventory can follow later; the first round needs a testable focus.

The fictional Wartungsblick sells B2B maintenance-planning software. Its first test path starts on a service page and ends with a successfully confirmed demo request. A second path leads to implementation information and a third to a guide download. The team describes each end state without promising an improved conversion rate: visitors must be able to finish the task reliably.

2. Specify starting conditions and evidence format

Record browser, viewport width, login state, language and consent state. A session with saved form entries is not equivalent to a first visit. Use clearly identifiable test data and coordinate test enquiries with the receiving team. Avoid unnecessary personal information in screenshots or openly shared issue lists.

A useful finding contains the exact URL, numbered steps, expected and observed behaviour, and supporting evidence. Add whether the issue is repeatable or occurred only once. If something could not be checked, mark it “not tested” rather than “passed”. Implementation partners can then reproduce the issue without first reconstructing your entire session.

3. Test the service promise through a concrete task

Ask someone uninvolved to explain, after reading the introduction, who the offer is for, which problem it addresses and what happens next. Record their answers verbatim. Do not correct them during the task. Someone already familiar with your terminology finds different problems from a suitable first-time visitor.

In the fictional example, Wartungsblick initially displays only broad efficiency claims. The task requires understanding the difference between software, consulting and ongoing support. A revised promise passes only when those distinctions are apparent from the content. Your own satisfaction with new wording cannot replace repeating the test.

4. Check navigation and orientation on smaller screens

Start on a detail page rather than only the homepage. Find primary navigation, the current topic, the contact route and the way back to an overview. Repeat at a narrow viewport and with enlarged text. Record clipped wording, obscured controls and links whose destinations remain unclear before activation.

In the fictional case, mobile navigation requires two unclear symbols before the demo page becomes reachable. That is an observable journey, not proof of lost revenue. Set a precise acceptance condition: a test person finds the next step through understandable labels and can close the menu without losing their place.

5. Run a repeatable keyboard and form check

Put the mouse aside and start with the keyboard after reloading. Move through navigation, submenus, the form and dialogs. Record the sequence and whether your current position remains visible. Open and close relevant controls and check that work can continue afterwards. The W3C reference covers keyboard operation, focus and understandable form guidance among other topics; use it for deeper assessment, not an automatically earned approval badge.

Then submit an empty form, an invalid email address and finally a valid test entry. Check whether errors explain the affected input and preserve existing information. For Wartungsblick, an unexplained disabled button is a specific finding: record the starting state and inputs, then repeat the same conditions after the repair.

6. Check images, contrast and media deliberately

Review the page without its images and note which substantive information disappears. Important diagrams need an understandable explanation; decorative shapes do not need artificial keyword narratives. Use an appropriate contrast tool to inspect the colours actually rendered rather than only the original design. Consult the linked W3C reference for formal criteria.

For videos, test playback, available captions, understandable controls and a useful textual alternative for central information. In the fictional Wartungsblick case, one video contains the only implementation explanation. The finding is therefore not “more text would be nice” but “the process cannot be understood without the video”. Acceptance requires an alternative that covers the substantive information.

7. Test the complete enquiry rather than the click

A conversion task does not end when someone presses a button. Follow a labelled test entry to its actual destination: confirmation view, email, CRM record or agreed callback. Record duplicates, missing ownership and contradictory confirmations. A positive analytics event alone does not prove that an actionable contact reached the receiving team.

In the fictional example, Wartungsblick also checks whether a download request is incorrectly categorised as a demo request. The visitor’s expectation remains central. If a conversation is promised, the next step and responsible team must be clear. A technical failure needs an understandable response and a sensible retry or contact route.

8. Assess technical access separately

Check public destination pages while logged out and record redirects, errors and accidental sign-in barriers. Ask the technical owner to inspect response status, relevant indexing instructions and the rules applicable to each crawler. Google describes robots.txt as a way to manage crawl access; having such a file does not guarantee indexing. Assess actual access conditions together.

Also compare central statements in delivered content with what visitors see. Hidden wording or text embedded only in images makes independent inspection harder. For search and answer systems, technical availability, understandable content and actual selection are different questions. Record “technically inspectable” when supported rather than turning that observation into “will be cited by every language model”.

9. Investigate loading problems under comparable conditions

Repeat important tasks with an empty cache and documented conditions. Observe shifting content, blocked first actions or a form changing position while loading. One measurement from a fast office connection does not explain every visitor’s experience. Combine technical measurements with the actual task walkthrough.

In the fictional Wartungsblick case, an image loaded late shifts the demo button. The team records device, viewport and loading sequence, then repeats the check after the change. It makes no specific revenue claim. The first defensible improvement is that the control no longer moves unexpectedly during the same task and can be activated reliably.

10. Prioritise by task blockage and strength of evidence

Distinguish a blocked core task from friction and an unproven optimisation idea. Record the finding’s scope: does it affect a central journey, a specific viewport or an unusual edge case? Estimate effort after understanding the cause sufficiently. A visually small change can be technically demanding, and taste alone cannot establish a large impact.

The fictional team repairs a missing demo submission before rewriting the page title. Both may matter, but a demonstrated task blockage takes priority. Every action names an owner and uses the same test for acceptance. Unproven impact hypotheses enter a later comparison with their uncertainty preserved.

11. Run an audit workshop with a clear handoff

Prepare a working session with marketing, the technical owner and the person handling enquiries. One possible agenda allocates ten minutes to task selection, twenty to a shared walkthrough, twenty to sorting findings, fifteen to prioritisation and fifteen to acceptance planning. These timings are an adaptable facilitation suggestion.

Bring documented evidence rather than debating every design preference live. A finding enters implementation only when the expected and observed behaviour are distinguishable. If nobody can access the actual destination of an enquiry, assign a verification task instead of inventing a successful outcome. Finish the meeting with a small set of reproducible repairs.

12. Release with retesting and known limitations

After a change, repeat the original test and at least the immediately adjacent step. A repaired button may lead to the wrong destination; a working delivery process may now create duplicate records. Record date, version and retest outcome. Confirm only what was actually checked.

The first audit round is complete when core journeys are documented, significant blockages are repaired or explicitly accepted as unresolved, and actions have clear ownership. Give remaining questions a review date. Technical release is neither a complete accessibility determination nor evidence of better rankings or leads. It establishes a more reliable foundation for subsequently observing impact.

YOUR WORKSHEET

Editable finding and acceptance record

These completed starting points are explicitly fictional. Add your URL, starting conditions, actual evidence and owner for each row. “Not tested” is valid and must not be reinterpreted as “passed”.