Summary: Test your website on a phone using five customer tasks: identify the service, check the area, assess the evidence, make contact and understand what happens next. Fix a failed task before adding more decoration.
A tradie website checklist should end with an enquiry arriving on your phone, not a tick beside “looks good”. Your customer is trying to solve a problem. If they cannot tell whether you do the work, serve their suburb or will respond, an expensive design can still leave them stuck.
You do not need a developer’s vocabulary to start. Pick one service, open the website on a phone and ask someone unfamiliar with the business to work through the test below. Watch where they hesitate. Resist the temptation to explain what the page was supposed to mean.
Test a specific customer journey
Use a realistic scenario: “I need someone to replace a leaking kitchen tap at my home. Can this business help, and how do I ask?” For another trade, substitute a job you genuinely want.
Start on the page that customer would reasonably reach. That might be a service page, not the homepage. A visitor arriving from search should not need to return to the homepage to discover your phone number or coverage.
Record what the tester did, where they paused and whether they completed the task. You are finding obstacles, not marking their computer skills.
The five-task website test
| Customer task | What a useful page provides | What to record |
|---|---|---|
| Find the service | A plain explanation of the work and relevant scope | Could the tester identify a match? |
| Check the area | Clear, truthful service coverage | Were they certain their suburb was covered? |
| Assess trust | Relevant work, genuine feedback and accurate business details | What evidence reassured them? |
| Make contact | Working call and enquiry options | Did the request actually arrive? |
| Understand the next step | A realistic explanation of response or booking | What did they expect to happen? |
Use “completed”, “unclear” and “failed” as your results. Do not give yourself a pass because the information exists somewhere. A customer has to find and understand it.
Make the first screen answer the obvious questions
Your opening section should help visitors identify the business, the service and the area. A slogan such as “Quality you can trust” does little work on its own.
A fictional electrician’s opening could say: “Residential electrical repairs and installations across our Brisbane service area.” The next sentence can explain the enquiry process. Actual coverage and service claims must match the business.
Avoid squeezing every suburb and every service into the headline. Give the main promise room, then use navigation and dedicated sections for detail.
On mobile, check that the title is readable, the main button is visible and an oversized video or animation does not delay access to the page. Keep the language direct: “Request a quote” should lead to a quote enquiry, not an unrelated download.
Put relevant proof near the decision
Choose evidence that answers a customer’s doubt. A gallery of luxury renovations may not reassure someone seeking a small repair. A relevant job example can be more useful if it explains the problem, work completed and any limits to the result.
Use genuine photographs with permission. Identify business credentials accurately and check that links or displayed details remain current. Present customer feedback honestly, without rewriting it into claims the customer never made.
Prepare a simple proof list:
- One relevant completed job you can explain.
- A genuine customer comment that relates to the service.
- Accurate business identification and contact information.
- A clear description of what happens before and after the visit.
If you lack proof, collect it. A generated image can illustrate an article, but it should not be presented as a photograph of your completed work.
Check the form from the customer’s side
Only require information you need at this stage. A name, contact method, service, suburb and short description may be a sensible starting point. Larger projects may need extra detail; avoid asking every visitor to complete a project tender.
Label fields clearly. Explain errors beside the affected field and keep the customer’s other entries when something needs correcting. The W3C’s forms guidance explains why labels, instructions and useful feedback matter for accessibility.
Make image uploads optional unless they are essential. Some customers cannot safely obtain a photo or may be enquiring from a different device. A form should not encourage someone to investigate a hazardous situation themselves.
Then submit a harmless test using contact details you control. Check the confirmation on screen, the notification to the business and any acknowledgement to the customer. A success message alone does not prove delivery.
Test the website after the click
The business side of the test is often overlooked. Who receives the enquiry? Who is responsible for replying? Can they see the service and suburb without opening several systems?
Use this small test log:
Submitted: time and page. Received: inbox and time. Assigned: person responsible. Replied: method and time. Result: working or action required.
A fictional example: the website says “Thanks, we’ll be in touch”, but the message goes to an employee who has left. The visible design works; the business process fails. Correct the destination before rewriting the button.
Test the call link as well. Confirm it opens the correct number and that the advertised response hours match what the business can deliver.
Fix the biggest obstacle first
Use this order: broken contact, unclear service or coverage, missing reassurance, then visual refinement. Keep changes small enough to test again.
For speed problems, ask your developer to review loading, responsiveness and layout movement. Google’s Core Web Vitals are useful diagnostics, but a strong performance score does not prove that customers understand the offer.
Repeat the five tasks after meaningful changes and periodically as part of maintenance. Plugins, notifications, staffing and service areas can change even when the homepage looks identical.
For a website built around the enquiry journey, see Tradie Local’s smart functional websites.
Sources & further reading
- W3C Web Accessibility Initiative: forms tutorial—labels, instructions and form feedback.
- Google web.dev: Web Vitals—loading, interaction and visual stability.
Frequently asked questions
How many pages does a tradie website need?
Enough to explain the business and its important services clearly. Start with actual customer needs. There is no useful universal page count, and many thin pages can make navigation harder.
Should the phone number be visible on every page?
It should be easy to find wherever a customer is ready to enquire. Check the header, mobile layout and relevant service sections rather than relying only on the footer.
Is a shorter quote form always better?
No. Too little information can create unnecessary follow-up. Ask for details that help route or assess the enquiry, and defer details that are not needed yet.
Do I need a booking calendar?
Only if customers can genuinely reserve the displayed time or understand that it is a request. Many jobs need qualification before a visit can be confirmed.
What should I check first on an existing website?
Submit a test enquiry and follow it through to the person replying. It is a quick way to discover failures that are invisible when you only browse the page.
