Why split the problem into six layers?

“No inquiries” describes an outcome, not a root cause. I divide the review into data, traffic sources, demand, pages, contact paths, and inbox handling so that every suspicion has something checkable attached to it. When an earlier layer isn’t clear yet, I don’t rush to convict a later one.

This project’s social media material includes threads about inquiries and lead quality. They point to real business confusion, but they are not proof that this framework works. What follows is my review order. It promises no inquiries once the fixes are made, and it does not use anonymous posts to estimate your conversion rate.

You can start with how to diagnose traffic and inquiry changes separately, then fill your own records into each layer. Any layer you have no data for stays marked as unverified; you can’t call it a pass just because nothing looks wrong at the moment.

Layer one: what do you actually mean by traffic and inquiries?

I first get the owner and the execution team talking about the same kind of data over the same period. Search impressions, clicks, sessions, and visitors are not one metric; contact-button clicks, form success messages, and sales-confirmed demand cannot share a single “inquiry” count either.

The material to gather is search records, on-site sessions, contact events, form storage, and the messages actually received. For each one, ask which action the analytics tool counted, then check whether it really happened. Duplicate triggers, test sessions, and stale event settings should all stay on the open-questions list; don’t declare them present before you have verified them.

The judgment at this layer is narrow: is the data good enough to explain the gap the owner sees? If two reports cover different date ranges, align the dates before comparing. If clicks are high but the inbox shows no record, go verify the contact flow first. You can pin down the sources with this breakdown of what GSC and GA4 each do and this monthly report evidence checklist.

Layer two: who is visiting, and through which entry points?

I look at which pages sessions land on, whether they come from organic search, ads, direct visits, or other sources, and then break them down by device and language. Avoid equating “from a certain country” with “is a certain type of buyer”; both source and identity need other evidence behind them.

If the growth is concentrated in articles unrelated to the business, buying opportunities on the homepage and product pages may not have increased at all. Conversely, if sessions cluster on product pages, you still have to check the queries and the demand; a page’s name alone doesn’t prove the visitor is a buyer.

What I want is a source-to-landing-page comparison, not just a sitewide total. Mapping language, page, and demand together explains which group is actually growing. Don’t change the button color yet: when visitors don’t need your business, a more visible contact entry point can’t make up for demand that doesn’t match.

Layer three: does the search demand match your business?

Search volume does not mean there is business in it for you. I put real queries next to the sales scope and ask whether the searcher is buying, comparing options, learning how something works, or shopping for a personal-use product. These intents may share wording yet need different pages.

Here is an illustrative demand example, not a client case: a company supplying industrial components runs into two kinds of questions, “how does it work” and “how do I confirm a custom spec.” The first can help someone learn; the second is closer to a purchasing check. Don’t treat the first as a business opportunity for the second just because it draws more traffic, and don’t delete all educational content either — ask whether it can reasonably lead to real product demand.

This layer needs queries, landing pages, and product documentation. For unconfirmed terms, have the sales or technical staff say whether you can actually supply it. Don’t put products you don’t make or services you can’t provide on the page just to make a keyword list look complete. You can judge with this method for matching search intent to pages.

Layer four: does the page let a buyer confirm fit?

I check whether a buyer can quickly make two judgments: this company really does supply what I need, and asking my specific question directly is the easier way to get an answer. The first needs real product photos, a clear scope of business, and verifiable material; the second needs to tell them plainly what to send and what can be confirmed next.

Less text isn’t automatically better, and more text isn’t automatically more professional. Buyers are looking for whether the model, application, supply terms, or drawings match; the page should answer those practical questions first. Keep the detailed material if you like, but don’t make a customer read the whole site before finding out how to get in touch.

The page lists strengths — why still check?

Because “capable” and “high quality” may be nothing but adjectives. I look for real material behind them, whether the images show this product, and whether the claims match the product documentation. Don’t write your way around unsupported lead times, minimum order quantities, and capability claims; when a term needs confirming, invite the customer to send their details so you can check it.

Once the page matches the demand, check the technical presentation. Is the body text visible, does anything cover it on mobile, do the key images load, is the contact prompt buried under a wall of content? You can verify with this technical and content presentation checklist. These are diagnostic actions; they do not mean I have tested your site.

Layer five: can the contact entry point be seen and used?

I walk the real path on desktop and mobile rather than just reading a toggle in the admin. Whether the entry point appears, whether the text is legible, what happens when you press it, whether it can be reached by keyboard, and whether form error messages make sense all have to be checked separately.

“The button is clickable” and “the button is visible” are two different things. An entry point can sit under an overlay, or its text can blend into the background. A page can throw no errors and still leave a buyer with no way out. Look at the rendered page and the actual click result; scanning the HTML for the word “button” is not enough.

Form fields should help you reply accurately. Necessary model or requirement details shouldn’t be cut just to shorten the form; questions unrelated to a first confirmation need a stated purpose. For a WhatsApp entry point, also verify the number and the pre-filled message so it doesn’t open the wrong contact. The above are review suggestions, not a record of real submissions made to any site for this article.

Layer six: does anyone verify demand after it arrives?

After the form success message, I also verify storage, sending, and receipt. A server logging a successful submission and an inbox actually receiving the email are not the same evidence. Tests should use clearly labeled test content, with the person who checked and the result recorded, so test entries don’t end up in the business lead count.

WhatsApp is the same. A click on the entry point only proves the entry point was used; the actual message has to be confirmed on the receiving end. Once a message arrives, you still need to confirm it isn’t spam and whether the product and purchasing terms match. If the team only hands over a “number of contact events,” the owner still doesn’t know what actually happened in the business.

A sales record can be simple: source, product need, buying role, handling status, and reason it was a poor fit. Leave unknown sources as unknown; don’t force attribution based on when the visitor arrived. If sales never records why they turned someone down, the marketing team may keep attracting the same unsuitable crowd.

The goal of this layer is to feed real demand back into page and content decisions. Not every message received counts as a success, and a lack of closed deals doesn’t invalidate the earlier work; which step it stalls at should be shown by the records.

How do you decide what to fix first?

I handle the confirmed blockers first, such as a contact entry point that leads to the wrong place or body text that won’t display. When demand doesn’t match, I adjust the queries and how the page is framed. With too little evidence, better records are usually worth more than a rebuild: turn the unknowns into questions you can check back on, and next time you’ll know whether anything actually improved.

For every change, keep the original page, the reason for the change, and the conditions for re-checking. Test again on the same devices and path, then observe the real demand records. If you want the team to diagnose it, you can send the site and the target demand for review and describe the problem — don’t just send a single total traffic number.

What other questions come up during a diagnosis?

Traffic is up — why doesn’t that prove marketing works?

You have to look at whether visitor demand matches the business, and whether the follow-up contact is real, delivered, and verified by sales. Generic how-to content, consumer use, or test visits can all inflate the numbers without representing a purchasing opportunity.

Does a WhatsApp click count as an inquiry?

A click only shows the entry point was used. You still need to check whether a message actually arrived, whether it reflects real demand, and whether the product and purchasing terms match.

Does a form success message rule out a problem?

No. You should also verify storage, sending, and receipt. Test entries must be labeled separately, and a passing technical test does not replace a real purchasing inquiry.

No inquiries — should you rebuild the site right away?

First locate the gap across data, sources, demand, pages, contact paths, and receipt records. Change only the parts you have confirmed are broken, then re-check under the same conditions, so a large rebuild doesn’t leave you unable to tell what caused the change.