DEV Community: Veilvex

We checked 178 small business websites on Google's first page: half hide prices, 8% block AI

Veilvex — Fri, 30 Oct 2026 13:28:19 +0000

In October 2026 we opened 178 websites of small businesses that rank on the first page of Google for local queries: dentists in Dubai, plumbers in London, hair salons in Berlin, family lawyers in Sydney, vets in Vienna, accountants in Miami and more. 24 cities, 15 niches. 157 sites could be opened and checked.

We looked at the home page the way a phone browser loads it, and at what a search engine or an AI assistant can read.

The basics are solved

Check	Share of sites
HTTPS	99%
Mobile layout (viewport)	98%
Page title	100%
Meta description	95%
Tap-to-call `tel:` link	85%
Contact or booking form	65%

On page one, an unsafe or non-mobile site is now rare. The gaps are elsewhere.

Gap 1: prices

48% of the sites show no price on the home page and have no visible link to a price page.

0 of 7 vet clinics showed prices
1 of 7 family law firms did
beauty salons and cleaning companies were the most open: 80%+ showed prices

Gap 2: no messenger

52% have no link to WhatsApp or Telegram (45% link WhatsApp, 8% Telegram). 11% have neither a tel: link nor a messenger link, so on a phone the visitor copies the number by hand.

Dental clinics lead: 22 of 23 have a messenger link. Law firms and vet clinics: 0 of 7 each.

Gap 3: AI crawlers blocked

12 of 157 sites (8%) disallow AI crawlers such as GPTBot, ClaudeBot or Google-Extended in robots.txt, often through a default setting of a site builder or security plugin. Another 14 sites returned 401/403/429 to an automated request.

The most striking niche: 6 of 10 accounting firms blocked AI crawlers. If someone asks an assistant to recommend an accountant in Miami, those firms give it very little to work with.

Caveats

This is a snapshot of first-page results, not a random sample. Sites that already rank well are usually in better shape than average. Messenger links injected by JavaScript widgets may be undercounted.

What to check on your own site

Show a price "from" or a range, or link a price page.
Put a WhatsApp or Telegram button on the first screen on mobile.
Make the phone number a tel: link.
Open your robots.txt and make sure you are not blocking the AI assistants your clients use.

Full study with the method and niche breakdown: We checked 178 small business websites.

The anonymized data (CSV, one row per site), summaries by niche and city, and the checker script are open on GitHub: Veilvex/small-business-websites-study (data CC BY 4.0, code MIT).

Before you build an app: the 4 questions we ask small businesses first

Veilvex — Fri, 30 Oct 2026 10:53:57 +0000

When a small business asks us for "an app", the first thing we do is not a quote. It is a question: what is the one thing your user needs to do? Surprisingly often the answer does not need an App Store listing at all.

Here is the short decision path we walk clients through before anyone draws a screen.

1. Is it a repeat action or a one-off?

Apps earn their place on a home screen when people come back weekly or daily: ordering from the same café, tracking a loyalty balance, booking the same trainer. If a customer uses the product twice a year, they will not install anything. A fast mobile website that ranks in search does the job better.

2. Can it live inside a messenger?

Bookings, orders, reminders, simple personal accounts: a Telegram or WhatsApp bot covers a surprising share of "we need an app" requests. No store review, no install friction, notifications work out of the box, and the launch takes days, not months.

3. If it must be an app, does it need to be native?

For typical business apps (catalogs, bookings, loyalty, service requests) one cross-platform codebase for iOS and Android is usually enough. Native development makes sense for heavy graphics, deep device features or very large audiences. Two native apps roughly mean two codebases to build and maintain.

4. What is the smallest version that proves demand?

We write down the single main action, keep only the screens it needs, add sign-in only if it is truly required, launch, and watch real usage for a few weeks. Everything else goes to a "next stage" list with its own estimate.

The costs people forget

Store accounts: Apple Developer is about $99 a year, Google Play a one-time $25.
Backend: hosting, a database, push notifications, maps. Small for a small app, but monthly.
Updates: every new iOS and Android release can break something. Many teams budget around 15–20% of the build cost per year for maintenance.

None of this is exotic, but it changes the conversation from "how much is an app" to "how much is the first useful version".

We put the full breakdown, with a comparison table and the questions to answer before asking for a quote, here: How much does a mobile app cost in 2026.

Landing page or multi-page website? The 5-minute question we ask every small-business client

Veilvex — Thu, 29 Oct 2026 14:12:29 +0000

Every small-business website project we take starts with the same question from the client: "Do I need a full website, or is one page enough?" It sounds like a budget question. It is really a question about where clients will come from.

Here is the short framework we use to answer it in about five minutes, before anyone talks about design.

One page, one offer

A landing page is one page built around one action: call, message, book, buy. It works best when:

the business sells one product or one service;
traffic is paid or already yours: ads, social media, a newsletter, a QR code on a flyer;
the goal is to test demand before investing more;
it is an event, launch or promotion with a short life.

A good landing page is not "everything on one long page". It answers the visitor's questions in order: what is offered, why it is worth it, what it costs, what others say, how to get in touch.

A page per service

A multi-page site gives every service its own page, plus about, cases, contacts and articles. It makes sense when:

there are three or more services and people search for each one separately;
the client wants customers from search without paying per click;
the business works in several cities or languages;
trust matters: cases, team and articles in one place look more solid than a single page.

Why this decides search visibility

Search engines and AI assistants match a query to a page. Someone searching "teeth whitening in Dubai" lands on a page about teeth whitening, not on a dental clinic's one-page site where whitening is one line in a list. A landing page can rank for a narrow topic and a handful of queries. A site with a page per service has a chance for each of those services.

So the honest rule we give clients: if most traffic will be paid, start with a landing page. If you want clients from Google, Yandex or ChatGPT-style answers, you need pages.

The five-minute checklist

Count the services. One or two: a landing page may be enough. Three or more: multi-page.
Name the traffic source. Mostly ads: landing page. Search and AI answers: multi-page.
Look one year ahead. New services, cities or languages planned? Multi-page saves a rebuild.
Compare the price gap with the average order. Often one or two extra clients cover it.
Build the landing page so it can grow. Many projects start as one page for ads and become a full site once it is clear which services sell.

Numbers, if you need them

For reference, at Veilvex a landing page starts at $500 and a multi-page business site at $900. We wrote longer, client-facing versions of this topic with tables and FAQs:

They are also available in Russian, Azerbaijani and German, linked from the articles page.

How do you answer this question for your clients? Curious whether other teams use a different rule of thumb.

We are Veilvex, a remote team working on websites, SEO, visibility in AI answers and AI automation.

llms.txt on a 4-language static site: how we generate it, validate it and keep it honest

Veilvex — Thu, 29 Oct 2026 11:11:13 +0000

AI assistants now answer "who does X in Y" questions directly, and they build those answers from what they can read about you. For a small team, the cheapest thing you control is your own site: what crawlers are allowed to read, and how clearly your facts are stated.

On veilvex.com (an Astro static site in English, Russian, Azerbaijani and German) we treat this as part of the build, not a one-off file. Here is the setup and the rules we ended up with.

1. robots.txt: say yes explicitly

Many sites block AI crawlers by accident: a template, a CDN toggle, a security plugin. We generate robots.txt at build time and list the crawlers by name, even though User-agent: * already allows everything:

User-agent: *
Allow: /
Content-Signal: search=yes, ai-input=yes, ai-train=yes

User-agent: GPTBot
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Allow: /

Why list them? Because the next person who adds a "block bots" rule will see the intent, and because a test can assert that every agent in the list stays allowed. The Content-Signal line follows contentsignals.org and states how the content may be used.

Also check your CDN: on Cloudflare, "Block AI bots" and bot-fight settings can override a perfectly good robots.txt. We verified with real requests that GPTBot, ClaudeBot and PerplexityBot get a 200 and the full HTML.

2. llms.txt: a fact sheet, generated from the same source as the pages

llms.txt is a proposed convention: a short Markdown file at the site root that tells language models what the site is and where the important pages are. It is not a ranking factor and no engine promises to use it. We still ship it because it costs nothing and removes ambiguity.

The important decision: never write it by hand. Ours is built by a script from the same i18n content files that render the pages. So the price on the services page and the price in llms.txt cannot drift apart.

What goes in (English, compact):

one-sentence brand line (the same sentence is used in the footer, the Organization.description in JSON-LD and external profiles);
an About block: name spelled out letter by letter (search engines like to "correct" unusual brand names), legal status stated plainly, official contacts only;
every service with its "from" price and a link to its own page;
service names in the other languages, linked to the localized pages;
a "what we do not promise" section;
a page list per language.

Next to it there is llms-full.txt with the full text of every page in all four languages (about 400 KB for us), for tools that want everything in one fetch.

3. The generator fails the build

This is the part that keeps it honest. The script throws, and the deploy stops, when:

llms.txt grows over 15 KB (a fact sheet nobody reads in full is not a fact sheet);
a price in the file does not match the single price source (prices.ts);
the text contains words we decided never to publish: guarantees, "official", leftover template markup like [[...]] or {{...}}.

A simplified version of the price check:

for (const s of services) {
  const expected = formatFrom(PRICES[s.id]);
  if (!s.line.includes(expected)) {
    throw new Error(`llms.txt: ${s.id} shows a price that is not ${expected}`);
  }
}

Models repeat what they read. If your site says "guaranteed first place" in one corner, that is what an assistant may quote back to a customer. A build-time check is cheaper than finding it later.

4. Structured data that agrees with the text

Each service page carries Service + Offer and FAQPage JSON-LD built from the same content object as the visible text, with stable @ids across languages. The organization node uses the same brand line as llms.txt. One source, three outputs (HTML, JSON-LD, llms.txt), so a crawler sees the same facts whichever it reads.

5. Sitemaps with honest dates and IndexNow

<lastmod> is the date of the last git commit that touched the page's source files, not the build time. A build date on every URL tells crawlers nothing. After a deploy, a script compares the new sitemap with the live one and sends only new or changed URLs to IndexNow (Bing, Yandex and others).

What this does not do

None of this makes an assistant recommend you. It removes the reasons not to: blocked crawlers, conflicting prices, vague descriptions. Being named still depends on being mentioned in places models trust: directories, reviews, articles, discussions. We check monthly by asking ChatGPT, Perplexity and Gemini the same set of queries and logging who they name.

Checklist

[ ] AI crawlers allowed in robots.txt and not blocked by your CDN
[ ] One page per service with price range, area and FAQ in plain text
[ ] llms.txt generated from your content, not typed by hand
[ ] Build fails on price mismatch or forbidden claims
[ ] JSON-LD built from the same source as the visible text
[ ] Real lastmod dates, IndexNow after deploy
[ ] A fixed list of 10–20 queries you re-check every month

You can see the live files at veilvex.com/llms.txt and veilvex.com/robots.txt. Questions about the setup are welcome in the comments.

For business owners rather than developers, we explain the same topic in plain language here: How to get ChatGPT to recommend your business.

We are Veilvex, a remote team working on GEO (visibility in AI answers), SEO, websites and AI automation.