How to Create a Trade Business Website That Wins Jobs (UK)

A useful trade website answers three questions before the customer gets in touch: can you do this job, do you cover the address and what evidence can they check? Build around those questions.

1. Keep control of your domain and the accounts used to manage the site.
2. State actual services, coverage, current credentials and how you assess a price.
3. Show permissioned real work and genuine feedback with its source.
4. Make calls and messages easy from a phone.
5. Check search access and indexing, then measure suitable enquiries, quotes and booked jobs.

Use the task check below before commissioning a replacement. Improve the existing page that answers the question, rather than creating more pages for their own sake.

Your own domain gives customers a consistent place to check services, real work and contact details. Keep access to the domain account, website content and enquiry destination, including when a provider builds it for you.

A directory profile can be another source of work. Its current fees and enquiry terms may differ from other platforms, so judge each using suitable enquiries and actual booked work. Point your public profiles, van and business documents at a website page that tells the customer what happens next.

Choose a domain customers can recognise and you can read aloud. Use your trading name where possible. Record who controls renewal, the account access and the current cost before paying.

An email address on that domain can make the contact route consistent, but it also needs a working inbox. Test delivery and replies. Keep your actual business name and phone number accurate across the site and documents.

Include the company information that applies to your business. GOV.UK specifies the registered name, number, registered office and registration jurisdiction for a limited company's website. A registered office is distinct from a customer-facing premises or service area.

A replacement website and a working email address are separate checks. Google Workspace's instructions describe mail routing through the domain's MX records; use your actual email provider's current instructions for your service.

• Account and renewal: domain ___; registrar ___; authorised account owner ___; renewal date/cost ___; website provider ___; email provider ___.
• Before a change: current public website address ___; working mailboxes/aliases ___; provider's saved configuration reference ___; person responsible for the change ___.
• After a change: public address shows the intended site/date ___; call/form reaches the intended recipient ___; test email sent, received and replied to/reference ___; unresolved item and owner ___.

Keep the existing contact route until the new route has been checked. An editor preview or a provider's launch date is separate from a public site that receives enquiries and an inbox that receives replies. Nominet's renewal guidance covers .uk registration; your registrar supplies your actual renewal terms.

Give the customer enough information to decide whether to enquire.

• Services and quote basis: explain inclusions, exclusions and what information or visit is needed to assess the work. If publishing prices, use your actual basis, check date and VAT treatment.
• Coverage: list the areas you genuinely attend and any attendance limits. Use the travel coverage worksheet to decide which work is retained, conditional or excluded.
• Real job evidence: permissioned photographs with an accurate account of what you did, rather than stock images presented as your work.
• Genuine feedback: identify its source and date, and use only words you have permission to reproduce. Use the neutral review-request ledger to organise future requests.
• Current credentials: name only registrations actually held and link to the relevant register. Do not use a logo as a substitute for verifiable details.
• Contact route: a tappable working phone number or short form, with the information needed to assess the job.

Copy these real-job proof fields

Job type ___; date ___; general area ___; agreed scope ___; problem found ___; work completed ___; limitations or exclusions ___; photograph permission/source ___; relevant credential checked/date ___; customer feedback source/permission, if used ___.

Keep the address, contact details and private documents out of the public example. Explain what the evidence shows; do not infer a safety outcome or energy saving you did not measure.

Fictional example of structure, not completed work: “[Business] fitted [agreed equipment] in [general area] on [date]. The agreed scope included [items] and excluded [items]. Photo [reference] shows [specific completed work].” Replace the fields with evidence from your own work before publishing. The real-job case-study brief takes this evidence through a complete page outline.

Use a distinct service page where it answers a distinct job question: scope, price basis, real examples and information needed to enquire. There is no required number of pages. A useful existing page is a better starting point than several copies.

• What the job involves and what the customer is concerned about.
• What changes the price and what the stated range includes.
• How you assess the job, attendance and access requirements.
• Permissioned evidence of relevant work and current credentials.
• The enquiry details needed for the next step.

Add a local page only when it has useful evidence specific to that area, such as actual work, genuine attendance limits or local access knowledge. Do not replace a town name in otherwise identical copy. Google's spam policies cover doorway and scaled-content abuse.

Use customers' own words alongside accurate trade terms, such as “fuse box” and “consumer unit”. If the existing page is not appearing at all, use the indexing checklist before adding more content.

Check the actual phone experience, not just the desktop preview. Text should be readable, buttons easy to tap and the enquiry route usable without a screen-covering interruption.

Google's Core Web Vitals guidance covers loading, responsiveness and visual stability. Record a measurement and its date rather than describing every site as fast. Large images, layout shifts and unnecessary scripts are useful faults for a provider to investigate.

Copy this mobile enquiry task check

Test only contact routes you own or with the business's agreement. Tell whoever receives the test that it is a test; do not create a real booking.

Put important business facts in visible text beside photographs and downloads. A customer should be able to understand the service, coverage and next step without interpreting a logo or opening a separate document.

Google says its normal Search guidance applies to AI Overviews and AI Mode, with no special AI markup or text file. Any structured data should match the visible page. Search and model-training access are separate choices for OpenAI and Anthropic; ask the site provider to check the relevant controls.

Use the Google audit for profile and indexing faults, and the ChatGPT and Claude observation sheet to record answers, cited sources and factual corrections. There is no reason to claim a fixed page format guarantees an AI recommendation.

Compare proposals on what you own, who supplies evidence and who maintains the site. Get actual dated prices and terms rather than using a generic cost or launch-time estimate.

For each proposal record: checked date ___; provider ___; setup ___; recurring ___; domain/email ___; VAT ___; extras ___; owner of accounts/content ___; agreed launch dependencies ___; maintenance responsibility ___. An estimated delivery date is separate from a site that is public and receiving enquiries.

1. Read the site on an actual phone and complete the agreed contact-route test above.
2. Check every service, price basis, coverage claim and registration against current facts.
3. Check permission for public job photos and review quotations.
4. Point your real Business Profile and other public listings at the correct site.
5. Ask the provider to check search access, the site's indexing settings and its sitemap.
6. Record the actual indexing result in Search Console; submission is separate from indexing.
7. Record who receives enquiries and who keeps the content current.

Check the public pages after a change rather than treating an editor preview as proof. Keep the domain renewal and account access with someone the business authorises.

Choose a date window and keep these counts separate: site visits, real enquiries, suitable enquiries, quotes, bookings, completed jobs and payment. Record the service, actual source, source fees and time spent. Keep a decision pending when the customer has not decided.

Search Console shows website search performance and indexing; it does not prove a click became a customer. A form confirmation does not prove the enquiry arrived. Check the actual receiving record, then use the lead ledger to follow the job stages.

Choose the next task from the evidence: repair a failed contact route, answer a repeated suitable-customer question or clarify the scope before quoting. Tradehand keeps the enquiry, quote and job together; check the public offer before choosing how to run them.

• A service page that never explains the scope or what is needed to quote.
• A published number, price or credential that no longer matches the business.
• A form success screen with no check of the actual receiving inbox.
• Stock or illustrative images presented as your completed work.
• Private customer information copied into a job example.
• Near-identical town pages with no useful local evidence.
• Claims of search or AI results measured only by a single test answer.