1. Check that inquiries are received
Open the website on a phone and follow the same path as a new visitor. If it uses a form, submit an agreed test inquiry and find it in the working system. Check the fields, arrival time and recipient. If the data does not appear, record the page, actions and result.
‘Thank you, your inquiry has been sent’ does not prove delivery. A form may show that message before the server responds or send data to an old email address. The check ends at the destination, not at the button.
If contact is through a personal messenger, check the link address and the chat it opens. Click tracking shows interest in opening it, but the person may not have written. When testing a form on a live website, tell the recipient it is a test and do not use someone else's personal data.
2. See who visits the page
Look beyond the total number of visits to the entry page, source and visitor's task. An article for people learning to build a website themselves may attract an audience that does not intend to commission development. A high visit count then does not mean high demand for your service.
For search traffic, examine queries and pages in Search Console or Webmaster. If a new page has not been discovered or indexed, that is a separate technical task. Search Console's URL Inspection tool helps establish the state of a particular address. Being indexed does not guarantee impressions for the desired query.
When visits are scarce, conclusions about button text will be unreliable. Do not label a website ineffective after a few visits. First establish whether the offer has had enough exposure to a relevant audience; there is no universal number for every business.
3. Compare expectations with content
Open the page alongside whatever brought the person there: a search query, post, recommendation or ad. The page should make clear that it addresses that particular need. If someone is looking to repair specific equipment, a general company overview may not help them choose a provider.
Check the opening screen: are the service, audience and next step visible? Then find answers to common customer questions: what is included, what is required from them, how cost is estimated and what the limitations are. Explain unknown terms instead of hiding them behind a generic ‘personalized approach’.
Show the page to someone who was not involved in development and ask them to describe the offer without prompting. If they cannot explain who the service is for and what to do next, that is a specific reason to clarify the copy.
4. Check the reasons to trust you
You do not have to add a long reviews section if you have no verified reviews yet. You can show a real workflow, a personal example or a feature demonstration and honestly describe what it illustrates. A precise example is more useful to readers than an unsupported promise of results.
- It is clear who provides the service and how to contact them.
- Examples relate to a similar task, rather than simply looking attractive.
- Demonstrations are labeled; client results are neither invented nor borrowed from other projects.
- The scope and limitations are stated, and uncertain points can be discussed.
- Prices and terms are current; if pricing is individual, the factors behind it are explained.
5. Complete the action on a phone
Test imperfect situations too: a required field is missing, text is longer than usual or the connection slows down. One successful desktop submission on the developer's machine does not cover the whole journey. For a complex form, prepare acceptance scenarios in advance.
- Text is readable without zooming, and the important button is visible and clearly labeled.
- The form asks only for information you need to begin handling the request.
- The keyboard does not cover the action, and field errors explain what to correct.
- After submission, it is clear whether the request was accepted and what happens next.
- A failure leaves a way to retry or make contact through another channel.
- The contact leads to the correct recipient; extra windows do not get in the way of writing.
How to choose the first change
Record the initial observation, suspected cause, change and verification method. Do not change the whole website at once: it will be difficult to tell what helped. At the same time, an obvious technical failure should be fixed immediately, without waiting to collect statistics.
After a change, compare equivalent periods, pages and sources. Inquiry counts can change with seasonality, visitor mix or business terms. An increase after an edit does not itself prove that the new button caused it.
| Observation | What to check first |
|---|---|
| A test inquiry did not arrive | Data storage and the delivery route |
| Almost no visitors | Availability, indexing and traffic sources |
| Visitors have a different task | Queries, the source's promise and page content |
| People read, but it is unclear why they should write | The offer, terms and a specific next step |
| Messages arrive, but there are no orders | Whether requests fit the service and how they are handled afterward |
Sources and notes
- Google Search Console: URL Inspection ↗
Checking a specific page's indexing status and the limits of that result.
- Yandex Metrica: JavaScript event ↗
A goal counts a configured action. Saving and receiving an inquiry require additional checks.
Next step
Let’s discuss your task
If you have found a specific failure or awkward step, send the link and steps to reproduce it. We can discuss what can be improved and how to check the result.
A message to get you started
Hi Vladislav! I read ‘Why a website brings no inquiries’. Website: [link]. I checked [step] and got [result]. I would like to discuss improving [task].
Adjust it to your task. Opening a chat does not send a message.