Why Your Website Gets Traffic but No Enquiries: Technical Problems to Fix

Most advice on this problem goes straight to copy, offers and calls to action. Those matter, but they are guesses until you have ruled out the technical faults that stop a ready buyer from reaching you, or stop you from seeing that they tried. This guide is a diagnosis, not a redesign brief. It follows the journey an enquiry takes through your lead generation setup, and for each step you get the symptom, a test you can run yourself and what to fix.

In this guide:

• Is it a traffic problem or a technical problem?
• The diagnosis table: symptom, test, fix
• Step 1: Are slow pages losing visitors?
• Step 2: Can a visitor on a phone find a way to ask?
• Step 3: Does your contact form actually submit?
• Step 4: Is the enquiry reaching a person?
• Step 5: Does the lead land in your CRM?
• Step 6: Are you counting enquiries correctly?
• What if every technical check passes?
• A short self-audit checklist
• Frequently asked questions

Is it a traffic problem or a technical problem?

Start by asking whether people try to enquire and fail, or never try at all. If enquiries stopped on a particular date, after a new plugin, theme or migration, suspect something technical first. If they were never there, check both. A few quick comparisons tell you which story you are in.

• Enquiries fell on a date while traffic held steady. Look at what changed on the website that week.
• A customer says they filled in your form and you have no record of it. That is a delivery fault, not a demand problem.
• Analytics and the inbox disagree. Zero form events in Google Analytics 4 (GA4) but real emails in the inbox (or the reverse) points to tracking.
• Plenty of mobile visits, almost no mobile enquiries. A high bounce rate on mobile landing pages, while desktop converts, points to the phone version.
• The visits come from research questions, not buying questions. That is a fit problem, covered near the end of this guide.

A word on website conversion rate: here it simply means enquiries divided by visits, for the same pages over the same period. We have not found a neutral, current benchmark worth quoting, so compare the site with itself: by page, by device, and before and after each change.

The diagnosis table: symptom, test, fix

Use this table as a map. Each row is one place an enquiry can leak, in the order a visitor meets them. Run the test in the middle column; if it fails, the right-hand column is your fix. The sections below explain each row in more detail, with the official benchmarks behind it.

Step 1: Are slow pages losing visitors before they see your offer?

If a slow website takes too long to load on a phone, visitors can leave before they reach the part that asks for an enquiry. Google's Core Web Vitals set three targets to check: the main content should appear within 2.5 seconds, the page should respond to a tap in under 200 milliseconds, and the layout should stay stable.

How to test it

• Open the Core Web Vitals report in Search Console. It is built from real visits (field data), groups similar pages together and labels them Good, Need improvement or Poor. Only indexed pages appear.
• For a single page, run a live test in PageSpeed Insights or Lighthouse, the two tools Search Console Help points to. Start with the pages that bring the most visitors.
• Read mobile and desktop separately. web.dev suggests judging at the 75th percentile of page loads, split by device, so a fast office connection does not hide a slow experience on a phone. It also notes that lab tests are not a substitute for data from real visitors.

What to fix

• Heavy images and background videos. Serve them at the size they are shown, compress them, and load images further down the page only when needed.
• Third-party scripts. Chat widgets, heatmaps and extra tracking pixels all add work for the phone. Remove what nobody uses.
• Layout shift near the form. A cookie bar or late banner that pushes the Send button down just as someone taps is exactly what cumulative layout shift (CLS) measures. Reserve space for anything that loads late.
• Slow server responses. An overloaded host slows every page, so check response time as well as page weight.

Planning a rebuild anyway? Our website redesign guide covers why that project is the best time to deal with speed at the root.

Step 2: Can a visitor on a phone find a way to ask?

It is easy to judge a website on the laptop it was built on, but Google indexes and ranks what phones see (mobile-first indexing), so the mobile page is the real page. If the contact form, phone number or WhatsApp button is hidden, cramped or covered on a phone, the interest you worked to attract stops there.

How to test it

• Use a real phone, not only a narrow browser window. Chrome's own documentation calls its device mode "a first-order approximation", because the code is not actually running on a mobile device.
• From the page people land on most (often not the homepage), try to enquire with one thumb: find a contact option without scrolling back to the top, tap the phone number, start a WhatsApp chat and fill in the form. Then open the menu: is the contact page easy to find, or buried in confusing navigation?
• A page can look fine on desktop and still fail on a phone. Session recordings and heatmaps from a tool such as Microsoft Clarity or Hotjar show where phone visitors stop scrolling or tap on things that do nothing.
• Compare the mobile and desktop versions of your key pages. Google asks for the same content on both, and a contact block dropped from the mobile template is an easy leak to miss.
• Note anything that covers the page when it opens: a newsletter popup, an app prompt or an offer box.

What to fix

• Make every phone number a tap-to-call link. Links can use tel: URLs for telephone numbers, so a tap opens the dialler instead of asking someone to copy digits.
• Keep a visible call-to-action (call, WhatsApp or enquiry button) on long mobile pages, so the way to ask is never more than a thumb away.
• Swap full-screen popups for small banners. Google says intrusive interstitials block the content and can frustrate visitors and erode their trust, and recommends banners that take up a small part of the screen.
• Give form fields room to tap, and make sure the keyboard matches the field: numbers for a phone number, the email keyboard for an email address.

Step 3: Does your contact form actually submit?

A form can look perfect and still fail. A script error, an over-strict spam filter or a rule that rejects real phone numbers will stop an enquiry without warning anyone. The only reliable test is to fill it in yourself, the way a customer would, on more than one device and browser.

How the form is built matters too. A 2014 study reported in NN/g's form usability article (2016) compared two kinds of form: on forms built to usability guidelines, 78% of submissions were error-free on the first attempt; on forms that ignored them, the figure was 42%.

How to test it

• Submit the form on a desktop and on a phone, in at least two browsers.
• Enter a UAE mobile number with the +971 code and spaces, the way people actually type it, and check it is accepted.
• Leave a required field empty on purpose. The form should say which field is wrong, in words, and keep everything else you typed.
• Paste a long message and attach a file if the form allows it.
• Open the browser console (F12 on most desktop browsers) while you submit, and note any red errors.
• If you use a spam check, make sure people pass it easily. Puzzles are not the only option: Cloudflare documents Turnstile as a check that runs with no CAPTCHA for visitors to solve.

What to fix

• Fix any script error that appears on submit, then test again after every plugin or theme update.
• Loosen validation that rejects real input, such as phone numbers with spaces or a plus sign, and remove fields you do not need for a first reply. Every extra step is friction.
• Show a clear confirmation message after a successful send, so the visitor knows it worked and does not try again.
• Review what your spam filter blocks. If blocked messages are not logged anywhere, you cannot know what you are losing.

This guide keeps forms to one step. For the design side (labels, number of fields, keyboards and error messages), see our contact form design checklist.

On the websites we develop, form submissions are verified before launch sign-off, along with payment flows and API endpoints. A form nobody has tested end to end is only an assumption.

Step 4: Is the enquiry reaching a person?

A successful submission only means the website accepted the message. Someone still has to receive it. Notification emails go missing for ordinary reasons: an old address, a colleague who has left, a full mailbox or a spam folder. Until you test the whole trip to a real inbox, you cannot be sure your enquiries are being read.

How to test it

• Send a test enquiry with a subject you will recognise, then check the receiving inbox and its spam or junk folder.
• Open the form settings and read the recipient list. Is every address one that someone checks daily?
• If your form tool stores entries on the website, count last month's stored entries and compare them with the notification emails received. Any difference is enquiries nobody saw.

What to fix

• Route notifications through a transactional email provider configured for your domain instead of the server's built-in mail. Google's email sender guidelines ask every sending domain to set up SPF, DKIM and DMARC, and warn that mail failing authentication can land in spam or be refused outright.
• Send each notification to a shared address or to two people, so one holiday or one full mailbox does not stall replies.
• Keep a stored copy of every entry, so a lost email is never a lost lead.

Step 5: Does the lead land in your CRM?

If your sales team works from a CRM, a lead that never arrives there may never get a call. A form-to-CRM link can stop working when a password or access key changes, a field is renamed or a connector is switched off. The test is simple: send a lead and look for it where sales will look.

How to test it

• Submit a test lead with a name you will recognise, such as "Test Lead October", and search for it in the CRM.
• Check every field arrived in the right place: name, phone, email, message and the page it came from. A phone number buried in the notes field slows the first call.
• Compare a month of stored form entries with the CRM records for the same month. The gap is the size of your leak.
• Open the integration's activity or error log, if it has one, and look for failed syncs.

What to fix

• Reconnect and remap the integration after any change to the form or the CRM.
• Turn on alerts for failed syncs, so a broken connection is noticed the same day.
• Pass the source page and campaign details into the CRM, so sales can see where each lead came from.

We connect landing page forms to platforms like Zoho CRM, HubSpot, Salesforce and Mailchimp, and a test lead like the one above is the quickest way to check any connection of this kind.

Step 6: Are you counting enquiries correctly?

Sometimes the enquiries exist and the reports are wrong. If the lead event fires on a button click instead of a successful submission, or the tag was lost in a redesign, analytics shows the wrong number and you end up improving the wrong pages. Check that every lead action is recorded once, and only when it really happens.

How to test it

• Turn on debug mode through Tag Assistant or Tag Manager's preview mode, open GA4 Debug View and submit a test. You should see one lead event: not zero, and not two.
• Without debug mode, watch the Realtime report, which shows events triggered in the last 30 minutes, while you submit.
• In Tag Manager Preview, Tag Assistant shows which tags fired and in what order. Check the lead tag fires on the confirmation, not on the click.
• Compare a month of lead events in GA4 with the enquiries in your inbox or CRM. They may not match to the last enquiry, but a large gap means something is miscounting.

What to fix

• Use GA4's recommended event generate_lead, which Google lists for a visitor who sends a form or asks for information, and fire it only after the form confirms success.
• Then switch on the key event setting for it. Any event can become a key event, and Google uses generate_lead as its own example. If you run Google Ads, you can create a conversion from that key event.
• Track the other ways people ask, not only the form. When we run digital marketing for a business, GA4 tracking covers every lead action: form submissions, calls and WhatsApp clicks.
• Record what happens after the enquiry. GA4's lead events also include close_convert_lead, qualify_lead and working_lead for offline steps, and together they fill the Lead acquisition report.

What if every technical check passes?

Then the leak is in the match between visitors and pages, not in the plumbing. That is useful to know: you can now work on the message with confidence that a ready buyer can reach you. Look at which searches bring people in, whether the page answers them, and whether the page gives a reason to ask now.

• Check the queries and their search intent. In Search Console, look at the searches behind your busiest pages. A guide that ranks for a research question is not a sales page, so give it a clear next step instead of expecting an enquiry on the first visit.
• Split enquiries by traffic source. Paid ads, SEO and social media visitors arrive with different expectations. If one channel brings visits but never enquiries, you may be attracting the wrong audience there rather than losing the right one.
• Read the top of the page as a stranger would. An unclear value proposition (what you do, for whom, and why you) leaves visitors with nothing to ask about.
• Put the way to ask next to the answer. A contact option at the end of the section that solves the visitor's problem works harder than one hidden in the footer.
• Show proof near the ask. Trust signals such as real testimonials and case studies beside the form give a hesitant visitor a reason to request a quote or book a call.

This is where conversion rate optimization starts: one change at a time, measured with the tracking you fixed in Step 6. If the pages themselves need rethinking, that is a website design question rather than a technical fix.

A short self-audit checklist

Run this list now and again after every change to the website: a plugin update, a new theme, a new form or a migration. Each item takes only minutes, and together they cover the whole path an enquiry travels. Tick an item only after you have tested it today, not because it worked last month.

• Core Web Vitals report checked for mobile, and the top landing pages tested in PageSpeed Insights
• On a real phone: contact option visible, phone number taps to call, WhatsApp opens, nothing covers the page
• Form submitted on desktop and phone, once with an error on purpose, and typed text kept
• Test notification arrived in the right inbox, not in spam, sent from a domain that passes SPF and DKIM checks
• Test lead found in the CRM with every field in place
• One lead event per real submission in DebugView, plus calls and WhatsApp clicks tracked
• Last month's form entries, inbox enquiries, CRM records and GA4 lead events compared

Keeping the path working

Each fault in this guide can appear the day something changes, so the fix is a habit, not a one-off project. Rerun the checklist after every update to the site, form tool, email service or CRM, and put a monthly test submission in the calendar. Treat a quiet inbox as a signal to test, not to wait.
Prefer to hand these checks to someone else? They fit naturally into routine website maintenance work.