Website traffic but no leads? Check these five handoffs before a redesign

Few enquiries despite steady website traffic are a reason to check how visitors become customers. Start by confirming that a visitor can contact you and that the enquiry reaches the right person. Then check your measurement, the audience reaching the page, the service information on that page and any remaining difficulty using it.

Use the five checks below. When you find a clear failure, fix it and repeat the same test. Continue through the remaining checks if that fault does not explain the gap.

This guide is for a service-business owner who can see visits in an analytics or search report but receives few useful contacts. An enquiry is a contact attempt your business actually receives. A qualified lead is an enquiry from someone whose need, location, timing and other requirements make them a plausible customer. A form count, an enquiry and a qualified lead are three different things.

The five-check route

The sequence matters. If messages are disappearing after submission, changing a headline will not restore them. If most visitors want a different service, shortening the form will not turn them into qualified leads.

1. Prove that an enquiry can reach a person

Start outside your analytics dashboard. Use a real phone on mobile data and an email address that is not already recognized by the business. Follow the route a new visitor would use:

1. Open the landing page you expect a prospective customer to see.
2. Find the relevant phone number, email address or form.
3. Send a clearly labelled test with a time and reply address.
4. For a form, confirm the page gives an unmistakable success message.
5. Confirm the message reaches the correct inbox, customer-management system or phone.
6. Confirm who notices it and owns the reply.

Test each advertised route separately. A working phone link does not prove the form works; a form success screen does not prove its email arrived. Keep the test out of sales reports by labelling it clearly.

Forms also need to be usable. The W3C says labels should describe their controls and be associated with the corresponding fields. Its forms guidance also calls for clear error and success notifications, including instructions that help someone recover from an error (W3C: labelling form controls; W3C: form notifications).

If a test fails, record the exact step and stop here. Repair the delivery path, repeat the test, and only then interpret enquiry numbers.

2. Define what your report is counting

"Traffic" can refer to clicks, users, page views or sessions. Choose one measure, one date range and one page or group of pages. Then separate the stages that matter:

• Sessions: visits under the rules of your analytics tool.
• Contact attempts: form submissions, phone-link clicks or other tracked actions.
• Received enquiries: messages or calls the business can actually inspect.
• Qualified leads: received enquiries that meet your stated fit criteria.
• Won work: qualified leads that become customers.

A useful rate always names its numerator and denominator. For example:

received-enquiry rate = received enquiries ÷ sessions on the relevant pages

You may also need qualified leads ÷ received enquiries to see whether the problem is traffic quality rather than the contact route. There is no universal percentage that can diagnose every service business; urgency, price, location, buying cycle and traffic source all change what a useful baseline looks like.

Google Analytics 4 uses key event for an event that matters to the business. Google's own example creates an event when a visitor reaches a confirmation page after sharing contact details, then marks it as a key event (Google Analytics: create or modify key events). That can count a confirmation-page visit. It still does not prove the message reached your team or that the sender was a suitable buyer, which is why the real receipt belongs beside the event.

Copy this test record; the filled row is a hypothetical example:

For real enquiries, add only the fit facts you legitimately collect. Do not put private customer details into a public article or shared diagnostic screenshot.

3. Ask whether the visitors could become customers

A person can be real and engaged yet still be the wrong visitor. They may want a service you do not provide, live outside your area, be looking for a job, or be researching rather than choosing a provider.

Use source evidence to test the fit:

Google Search Console's Performance report can group Google Search data by query, page, country, device and date. It reports clicks, impressions, click-through rate and average position (Google Search Console: Performance report). Start with the pages that receive clicks, then inspect the queries behind those pages. Search Console also notes that results vary by time, place, device and recent search history, so repeating one search yourself is not a substitute for the report.

For a broader source view, Google Analytics 4's Traffic acquisition report uses session channel, source and medium to show where new and returning visitors came from. It can also show key events and the percentage of sessions in which a key event happened (Google Analytics: Traffic acquisition report). Compare those source groups with received and qualified enquiries from your own record. A dashboard cannot decide qualification for you.

If the wrong audience dominates, the next fix may be campaign targeting, page intent or search content, not the contact form or the site design.

4. Check the promise on the page they entered

Now read the landing page as a prospective customer, not as its author. A suitable visitor should be able to answer these questions from the page:

• What service is offered here?
• Who is it for, and what problem does it address?
• Is it available in my location or situation?
• What happens if I take the next step?
• What information should I have ready?

Write those answers down, then point to the exact words on the page that supply them. A logo, stock photograph or general claim such as "quality solutions" does not carry the same information as a named service, service area and next action.

Match the action to the decision. Someone comparing a substantial project may need to know what a first conversation covers. Someone seeking urgent local help may need a prominent call route and opening-hours context. Ask only for information needed to begin; explain why a less obvious field is required.

If one high-traffic service page is vague, revise and retest that page before commissioning a whole-site redesign.

5. Look for friction on the real route

If receipt, measurement, traffic fit and page clarity do not explain the gap, examine the remaining interface friction. A usability fault may already appear during the first contact test; fix and retest it when it appears. Repeat the journey on a small phone, with a keyboard, and on an ordinary connection. Check for:

• a contact option that is hard to find or operate;
• a phone or email link that opens the wrong destination;
• field labels that disappear when typing begins;
• an error that does not say what to correct;
• a submit button that appears to do nothing;
• a success screen that leaves delivery uncertain;
• unnecessary required fields;
• a page that shifts, stalls or becomes unusable while loading.

Record a reproducible observation: device, browser, page, action, expected result and actual result. Fix one clear fault, then perform the same test again. Several simultaneous changes make it harder to learn which handoff improved.

A hypothetical diagnosis

Imagine a local heating-repair business whose analytics shows steady visits to a boiler-pressure article but whose service inbox has few enquiries.

First, the owner sends labelled tests. The desktop form arrives. On a phone, the submit button produces a spinner but no success message, and nothing reaches the inbox. That is a real delivery defect. It should be repaired and retested before the owner trusts form-event counts.

After the repair, the owner reads Search Console queries for the article. Many visits come from people looking for do-it-yourself pressure checks, while the business sells local repair. The traffic is genuine, but much of it is informational and some searchers may be outside the service area. The owner keeps the useful safety information, states the service boundary and area clearly, and gives people who need a professional a route to the relevant service page.

This is a hypothetical example, not a WPShip customer story or a predicted improvement. It illustrates two different failures: a broken mobile handoff and a traffic-to-service mismatch that a single "conversion rate" would hide.

Decide what to fix and whether a redesign is justified

If your record points to repeated page-structure or WordPress implementation problems, bring the existing URL and the completed test record to a WPShip scope discussion. That gives the conversation a useful starting point: which handoff fails, what evidence you have, and whether a targeted repair or broader website build is the better fit.

Keep the diagnosis repeatable

After any change, repeat the same route on the same device types. Compare equivalent periods using the same metric definitions and source groups. Record concurrent changes such as a new campaign, a seasonal spike or a changed service area. With little data, describe what you observed without claiming a general trend.

Judge the result by whether a suitable visit becomes a received, qualified enquiry. When it does not, the record should point to the smallest next change.