A service-business website can fail in two very different places, and only one of them is loud.

It can fail at the front, where a suitable visitor lands, can't tell what you do or whether you're for them, and leaves. That failure is at least visible in the aggregate: traffic arrives, nobody contacts you, and eventually you go looking for why.

It can also fail at the back, after the visitor has decided to reach out. The form submits, the "Thanks, we'll be in touch" message appears, and nothing reaches you — or it reaches an inbox nobody watches, or it reaches the wrong person who assumes someone else has it. The visitor did everything right and believes the ball is in your court. You never learn the inquiry existed. That failure is silent, and it is the expensive one, because you lose the customer and the information that anything went wrong.

A lead-generation website is one built to prevent both failures and to prove it prevented them. It helps the right visitor understand the offer, decide whether it fits, complete a contact action — and then it preserves what they submitted, notifies the responsible person, and leaves enough evidence to confirm the hand-off actually worked. That last clause is what separates a lead-generation website from a nicely designed page with a form on it.

So rather than argue about the label, here is the test I would run on any site before agreeing it earns the name. Seven questions, roughly front-to-back:

  1. Can the right visitor recognize the service and whether it fits?
  2. Is there proof where the doubt is, so making contact is a rational act?
  3. Can the visitor take the correct next step without guessing?
  4. Is the inquiry saved somewhere a person can later inspect?
  5. Is the responsible person notified?
  6. Can the business tell website activity apart from an actual inquiry?
  7. Does the business control the accounts and data the whole thing depends on?

Fail an early question and fewer suitable people act — the loud failure. Fail a later one and people act while the business stays unaware — the silent one. Most of the attention in website sales goes to the first three. The last four are where lead generation is actually won or lost.

Small-Business Website Acceptance Standard

Use: Buyer inspection standard and launch-acceptance companion. Print it or save it as a PDF with the button above and mark it up during the acceptance walkthrough.

A website is not accepted because it is attractive, published, or capable of displaying a thank-you message. It is accepted when the buyer can inspect the agreed customer path, prove that a valid inquiry created a durable record, see what notification evidence exists, and leave with control of the assets and accounts the agreement says they own.

This standard is deliberately stricter than a design approval. It asks what the website does, what evidence proves it, where responsibility changes hands, and what remains outside the website provider's control.

How to score the site

Mark every row:

  • Pass — the condition was tested and the named evidence exists.
  • Clarify — the condition may be acceptable, but the owner, method, evidence, or boundary is not explicit.
  • Fail — the condition does not work, the agreed evidence is missing, or the result contradicts the agreement.
  • Not applicable — the signed scope explicitly excludes the condition and the exclusion does not make another promised outcome impossible.

A site is ready for ordinary launch approval only when every critical row passes and every noncritical Clarify or Fail has a named owner, disposition, and date. A score does not override a critical failure.

Critical gates

Do not accept the site when any of these are unresolved:

  1. a suitable visitor cannot identify the service, fit, and next step;
  2. the primary contact action cannot be completed on a current mobile browser;
  3. a valid test inquiry does not create the agreed durable source record;
  4. the responsible person receives no notification evidence and no visible failure record exists;
  5. the business lacks the access or written exit path promised for its domain, content, data, or accounts;
  6. intended public pages are blocked from indexing or canonicalized to the wrong URL; or
  7. a material public claim conflicts with the visible service, price, responsibility, or evidence.

The acceptance checklist

Area Acceptance condition Evidence to retain Critical?
Service and fit A stranger can state the service, likely customer, area or delivery mode, material constraint, and next step from the entry page. Plain-language five-part readback. Yes
Query ownership Each important public page has one distinct reader job and does not duplicate another page's purpose. Page inventory with owner query and intent. No
Claims and proof Material claims have visible support at the point of doubt and do not travel further than the evidence. Claim-to-evidence list with owner and source. Yes
Contact choice The primary action matches how the service is actually bought: call, quote, booking, fit form, email, or another agreed path. Signed scope and mobile path recording. Yes
Form clarity Required fields, help, errors, privacy context, and success feedback are understandable without inside knowledge. One invalid and one valid mobile test. Yes
Keyboard and labels Interactive controls have visible labels, accessible names, focus states, and a logical keyboard path. Keyboard test and accessibility-tree spot check. Yes
Zoom and reflow The page remains usable when text is enlarged and at a narrow mobile viewport. Reflow/zoom screenshots or test notes. No
Source record Every valid test inquiry creates the agreed durable record before notification work begins. Timestamped synthetic test record. Yes
Record reconciliation The business can match a visible form submission to its source record without relying on the notification email. Unique test marker and timestamps. Yes
Notification attempt The system records whether notification work was queued and attempted. Event or delivery timeline. Yes
Delivery language “Delivered” is defined as the available technical receipt, not proof of inbox placement, reading, response, qualification, or sale. Visible definition and sample receipt. Yes
Failure visibility A failed notification becomes visible and has a documented retry or recovery path. Synthetic failure test or bounded implementation evidence. Yes
Analytics boundary Page activity, contact actions, saved inquiries, qualified leads, and won work are counted as different events. Measurement map with system owner. No
Consent and privacy Analytics and form collection match the published privacy explanation and avoid unnecessary personal data. Data inventory and privacy-page review. Yes
Canonical and indexability Intended public URLs return the expected status, self-canonicalize, allow intended search crawlers, and appear in the sitemap. URL inventory and live response check. Yes
Structured data Applicable structured data matches visible facts and does not add unsupported claims. Validator output and visible-copy comparison. No
Internal path Every important page is reachable through a useful internal path and is not an orphan. Crawl/link map and manual spot check. No
Search versus training policy Search crawlers, training crawlers, and user-triggered agents have separate documented decisions. Crawler-policy matrix. No
Business identity Business name, operator, offer, area, contact path, and profile facts agree across the site and approved external profiles. Entity consistency sheet. Yes
Domain and DNS The agreement names the owner, administrator, billing party, and recovery path. Access schedule; do not store credentials in the acceptance packet. Yes
Website and content The agreement states who owns the site files, copy, images, licensed assets, and reusable provider components. Ownership schedule and license list. Yes
Data and exports The business knows what lead and analytics data can be exported, in what format, and under whose authority. Redacted sample export and responsibility statement. Yes
Ongoing operation Hosting, monitoring, updates, small changes, incident response, and excluded work each have a named owner. Responsibility matrix and current fee schedule. No
Exit The agreement describes notice, billing stop, exports, transfers, operated components that stop, and any transition assistance. Exit checklist and sample handoff inventory. Yes
Launch record The final acceptance packet lists artifact/version, test date, tester, results, holds, approved exceptions, and next review. Signed or approved acceptance record. Yes

The acceptance record

Use one record per release:

Field Entry
Website and release
Public URL
Test date and timezone
Tested by
Scope/version tested
Critical gates Pass / Clarify / Fail
Noncritical totals Pass: / Clarify: / Fail: / N/A:
Synthetic inquiry marker
Source-record timestamp
Notification evidence
Index/canonical/sitemap verdict
Ownership/access packet Complete / Incomplete
Approved exceptions
Next owner and action
Next review date

Never put real customer contact information, credentials, private access details, or raw production submissions in this public or shareable record.

What a passing standard proves

A passing result proves that the tested version met the listed conditions at the recorded time with the recorded evidence. It creates a useful launch receipt and exposes responsibility gaps before they become operating surprises.

It does not prove future uptime, inbox placement, human response, lead quality, sales performance, search ranking, AI citation, legal compliance in every jurisdiction, or security against every threat. Those require their own owners, controls, monitoring, and qualified review.

Primary references