Yes. A website can remain on Cloudflare Pages while server-side logic runs through Pages Functions or Workers, and AI responses can come from Cloudflare Workers AI or supported external AI providers. You do not need a traditional always-on web server just because the site has a chatbot.

This is a useful example of why "static website" and "dynamic website" are not opposites in the way people often imagine.

The public pages can be simple, fast static files.

Then specific actions can use server-side code.

Forms.

Authentication.

APIs.

AI chat.

That gives you complexity only where it is needed.

Cloudflare Pages can serve the website

Cloudflare Pages can host the public frontend.

HTML.

CSS.

JavaScript.

Images.

The ordinary website can remain static and inexpensive to serve.

That is the same architecture I discuss in Cloudflare for small-business websites.

Nothing about adding an AI feature requires abandoning that.

Pages Functions add server-side behaviour

Cloudflare's current Pages documentation says Pages Functions can execute server-side code on Cloudflare's network without a dedicated server.

That means a function can sit behind a route such as:

/api/chat

The browser sends the visitor's message there.

The function handles the private logic.

That is where you keep:

API credentials;

business rules;

model calls;

rate limits;

validation.

The secret parts stay off the public frontend.

Workers are the broader serverless layer

Pages Functions run on the Workers runtime.

Cloudflare Workers can also be used directly.

Conceptually, Workers are small pieces of server-side code that run on Cloudflare's network without you managing a traditional server.

For an AI chatbot, a Worker can:

receive the chat request;

check it;

add business context;

call an AI model;

stream or return the answer.

That is enough to create a surprisingly capable system.

Workers AI can run models

Cloudflare Workers AI is Cloudflare's serverless AI inference platform.

Cloudflare says it can run models on GPUs across its network.

A Worker can access Workers AI through a binding and call a model from server-side code.

Pages Functions can also use Workers AI bindings.

So one possible architecture is:

Cloudflare Pages for the site;

Pages Function/Worker for the chat endpoint;

Workers AI for the model.

That keeps the whole stack inside the Cloudflare platform.

You are not limited to Cloudflare models

This is important.

Cloudflare AI Gateway can also route requests to supported external providers.

So the architecture does not force the business to use one model forever.

Cloudflare currently documents support for external providers alongside Workers AI.

That creates options.

The right model can be chosen based on:

quality;

latency;

cost;

features;

business requirements.

I would not pick a model just because all the infrastructure has the same logo.

AI Gateway adds useful controls

Cloudflare's AI Gateway currently provides features such as:

analytics;

logging;

caching;

rate limiting;

request retries;

model fallback;

cost visibility.

Those are useful operational tools.

For a public chatbot, rate limiting and usage visibility are particularly valuable because they help reduce abuse and surprise bills.

This is infrastructure doing a real job.

What about business knowledge?

The model still needs context.

You can pass selected website information directly for a small use case.

For larger knowledge bases, Cloudflare also offers products such as Vectorize and AI Search for retrieval-oriented applications.

That can support a chatbot answering from business documents rather than relying only on the model's general knowledge.

But do not jump to vector databases because the site has six FAQs.

Use the simplest information architecture that works.

What would a simple Built by Gavin chatbot look like?

Imagine somebody asks:

How much does a website cost?

The frontend sends that message to a server-side endpoint.

The endpoint includes approved Built by Gavin pricing/context.

The AI model answers using that information.

Then the chatbot can link the visitor to:

Services;

the website-cost guide;

Contact.

That is useful because the conversational layer connects into the public knowledge base.

It does not replace it.

Could the chatbot read the entire Guides library?

Yes, technically.

The Guides provide a large body of structured source material.

A retrieval system could search the relevant guide sections and pass them into the model as context.

That would make the chatbot more grounded in Built by Gavin's actual published positions.

The important design principle would be:

cite or link back to the underlying Guides where useful;

do not make the bot the only way to access the information.

The public pages remain the canonical source.

Does this make the website expensive?

Not necessarily.

Cloudflare's current Workers AI model is usage-based, with a free daily allocation and paid usage beyond it.

Pages Functions also have free-plan allowances and Workers-based billing when usage grows.

Exact pricing can and does change.

So I would not sell a chatbot on the basis of:

AI costs almost nothing forever.

I would put:

rate limits;

usage monitoring;

budget controls;

and sensible model choice

into the design.

A small low-traffic chatbot may remain inexpensive.

A heavily used AI application can cost real money.

Cloudflare does not remove model costs

This is worth stating clearly.

Cloudflare can simplify deployment and provide useful infrastructure.

It does not make inference computationally free.

If you use external providers, their model costs still matter through the relevant billing setup.

If you use Workers AI beyond included usage, usage is chargeable according to current pricing.

Free hosting and free AI are not the same thing.

Gavin's take

What appeals to me here is not “AI for the sake of AI”. It is that a simple site can stay simple while a small server-side function handles the genuinely dynamic part. That is a better fit than rebuilding an otherwise straightforward business website around a heavyweight application stack just to add one feature.

Why this architecture appeals to me

I like separating the ordinary website from the expensive/dynamic part.

A visitor loading the homepage should not trigger AI infrastructure.

They are reading a page.

Only the chat endpoint should invoke the AI function.

That keeps the basic site lean.

Cloudflare's routing can be configured so static assets remain static while only selected routes invoke Functions.

That is exactly the kind of architecture I prefer.

Complexity where it earns its keep.

Is Cloudflare the only way to do this?

No.

There are many valid serverless/backend platforms.

The reason Cloudflare is interesting here is that it can combine:

static delivery;

serverless functions;

AI inference;

gateway controls;

other data services

inside one ecosystem.

That can be convenient.

But the business requirement comes first.

What I'd do

I would prove the customer need before adding the infrastructure. If visitors repeatedly ask questions the site cannot answer efficiently, then a focused assistant may be worthwhile. If the business receives three straightforward enquiries a week, a good page and contact form may be the better system.

Would I recommend this for every small business?

No.

A café does not need a RAG chatbot simply because it has a website.

A consultant with a substantial knowledge library might get more value.

A software company may have stronger use cases again.

The customer problem decides whether AI belongs.

The platform comes afterwards.

Gavin’s perspective

Built by Gavin's approach

For a small-business AI feature, I would aim for something like:

static site by default;

one controlled server-side endpoint;

no exposed API keys;

limited business context;

clear fallback to Contact;

rate limits;

usage visibility;

expand only if people actually use it.

That can provide a useful modern feature without turning a straightforward website into an expensive application stack.

The bottom line

Yes, Cloudflare can support an AI-powered website or chatbot.

Pages can serve the public site.

Pages Functions or Workers can provide secure server-side logic.

Workers AI can run models.

AI Gateway can provide control and visibility across AI traffic.

Other Cloudflare data products can support more sophisticated retrieval later.

You do not need all of them on day one.

Start with the smallest architecture that solves the problem.

Want an AI feature without turning your website into an infrastructure project?

Tell me what you want the chatbot to do.

I can help work out whether the sensible answer is a small Cloudflare function, a deeper AI implementation — or simply a better page on the website.

---