Businesses Without a Website: Build a Lead List Without Inventing Details or Bypassing Restrictions

An empty website field on a lead record almost always means the information is missing from the source, not that the business has no site. Before treating an absence as a fact you have to verify it separately, and record the difference between "checked and not found" and "never checked at all".

This is a technical description of data quality and a verification method, not legal advice.

Why a blank field is not evidence

A blank field records what your pipeline managed to populate, not the reality of the business. Three separate causes produce exactly the same empty cell, and each one means something entirely different.

• The column was never in the source at all. A licensing register publishing business name, company number, licence number, street, phone and email simply does not collect websites.
• The column exists in the source but was not filled for this record, because whoever completed the form skipped it.
• The record itself is stale. Licence status in the Beer Sheva file splits into 2,820 rows marked as renewing, 176 marked temporary and 50 marked as under permit, and a status is no guarantee that the contact details were refreshed alongside it.

Your pipeline sees an empty cell and manufactures a claim from it. That claim enters the list, and later somebody dials on the strength of it. The point of failure is not the call. It is the moment an empty cell became a fact with nobody marking the transition.

What does "empty" actually look like in the data?

This is an operational question rather than a philosophical one, because each shape of emptiness behaves differently in a query. The table covers the shapes present in that one register.

The fourth row is the dangerous one, because it does not look empty at all. An expiry date in 2099 is an internal convention meaning "no limit", and it flows into every validity calculation as though it were a genuine date. There is no way to discover it except by looking at the distribution of values before building logic on top of them, and that is precisely the step people skip when they are in a hurry.

How do you prove a business has no website?

You do not. You lower confidence through a defined check and record exactly what was checked, so somebody else can repeat the same check and reach the same result.

1. Search the exact business name as it appears in the record, together with the locality.
2. Search again on a cleaned name: corporate suffix removed, punctuation stripped, repeated spaces collapsed.
3. Check for a domain containing the brand name in transliteration, on both .co.il and .com.
4. Check whether a public platform profile exists that is functioning in practice as the business site.
5. Search the phone number from the record as a literal string, which sometimes surfaces a page the name did not.
6. Write the outcome as a status with a date and the list of queries that were run.

The status has three values, not two: found, not found after search, and not checked. Separating the last two is the whole point. A record that was never checked does not belong in a segment called "businesses with no website", and no batch job should ever overwrite it with "none".

What one false positive costs on the call

Outreach that opens with "I noticed you don't have a website" against a business that has one ends in that second, and the loss is far larger than the single call.

• Credibility: the person understands the approach was built on an unverified data point, and draws the obvious conclusion about everything else you are about to say.
• List contamination: the record is marked contacted and leaves the queue, so the business is never approached again even after the data is corrected.
• Opportunity cost: that call slot could have reached a verified record instead.
• Broken measurement: the segment's answer rate drops, and somebody concludes the segment does not work when in fact the data was wrong.
• Referral damage: the business mentions the call, and the bad impression attaches to your name rather than to your list.

What stays off the list

Some sources look tempting and are not usable, and that decision belongs to the design stage rather than to collection time.

• A source that requires signing in to see the records. A personal account is not a key for a data pipeline.
• A source that blocks automated access. A block is an answer, not an obstacle to solve.
• Content behind a paywall sold to a human subscriber.
• A closed group, or a forum that requires approval to join.
• Guessing an email pattern from the domain and marking it verified. An address born from a formula is not a collected data point.

What remains is usually enough: open government registers such as the Registrar of Companies file, municipal business licensing files, and the businesses' own websites. If a gap survives all of that, the gap is recorded as a gap. Directory-shaped sources are covered further in scraping business leads from directories, and the list as a maintained product in building a lead list with scraping. The verification method itself is close to the one in automated supplier verification in Israel.

Which fields make a record checkable

A good record carries its own story, so any claim it makes can be reconstructed without opening an investigation.

• The source identifier, and the file or endpoint the row arrived from.
• The date and time of the pull, which is not the source's own update date.
• The raw value alongside the normalised value, in two separate columns.
• A check status for every field derived from an external check rather than supplied by the source.
• The name of the checker, or the identifier of the process that ran the check.
• A last-verified date, from which today's confidence level is derived.

Sources

• Business licensing, Beer Sheva municipality - data.gov.il
• Registrar of Companies database - data.gov.il