What public-page-only scanning can and cannot tell you about a website revenue leak
A founder-honest read on the limits and the value of scanning only what is publicly visible.
By Bruce Tyndall · Principal Consultant, Revvye
The question we are actually answering
Revvye does not crawl your CRM. It does not read your booking software. It does not pull your GA4 sessions or your Stripe ledger. It only looks at what a stranger could see if they typed your URL into a browser, opened your service pages, glanced at your reviews, and asked an AI assistant about your business.
That sounds like a limitation, and it is. It is also the right starting question for the businesses Revvye is built for. If your public surface is leaking trust, clarity, or conversion before a buyer ever signs in or fills out a form, the rest of your funnel is patching pressure on a pipe that has already burst upstream.
What public-page-only scanning does well
There is a real list of revenue leaks that live entirely in the public layer. These are the ones a public-page scan can find with reasonable confidence: missing or weak service pages, ambiguous offer language, broken booking links, schema and metadata gaps, slow mobile rendering on the first contact page, missing trust elements that buyers expect for the category, sparse local presence on Google or Apple Maps, AI crawler access blocks that prevent your business from being summarized accurately, and follow-up handles like contact forms that fail silently.
These leaks are visible because they are public. That is exactly why they matter. The buyer, the search engine, and the AI assistant are looking at the same thing the scanner is looking at. If the scanner cannot understand the offer, the next click probably could not either.
What public-page-only scanning cannot tell you
There is an equally honest list of things a public scan will never know. It will not know your conversion rate. It will not know your true bounce. It will not know which keyword cohorts buy. It will not know how often your front-desk pickups close. It will not know whether your follow-up SMS sequence runs at all, or whether it converts when it does. It will not know the nuance of your pricing or whether your leads are coming from a single ad spend that is masking a deeper problem.
If a tool tells you it can see all of that from the outside, it is either fabricating, or it is quietly stitching together vendor data you have not actually connected. Revvye refuses to do either.
Why this still pays off
Most of the revenue leaks that hurt small and midsize businesses are public layer leaks. The booking flow that breaks on iPhone. The service page with no schema. The location entity that does not match Google. The trust block that has not been updated in two years. The crawl block that hides the business from AI assistants. These are the leaks that bleed demand before any analytics tool gets a chance to count it.
A public scan is the cheapest way to find them. It does not require a pixel install. It does not require auth. It does not require trust. It just runs, scores, and tells you what a buyer would have seen.
How Revvye handles the edges
Revvye does three specific things to keep the diagnosis honest. First, it scopes every finding to a public surface and shows you which surface it came from. Second, it reports a leak count and severity, not a recovered revenue number, because no public scan can know revenue. Third, it offers a paid report that adds context, evidence, and a recommended fix order without pretending it has data it does not have.
If the next layer of work needs private data, Revvye says so out loud. The free scan is not the whole product. It is the entry point. Anything beyond it should be opt-in, scoped, and grounded in real evidence.
What to do with the output
Treat a Revvye scan the way you would treat a vehicle inspection at a fair shop. The technician walks around the car, lifts the hood, checks the obvious failure points, and gives you a list ranked by severity. They do not pretend to know how you drive. They tell you what is leaking, what is at risk, and what would cost the most if you ignored it.
From there, you can fix it yourself, hand the list to your developer, or use the paid report and roadmap to plan a single focused sprint. The point is to stop guessing at your demand problem and start fixing the visible ones first.