# How can AI help my website? Six real jobs and three it cannot do

> By Lawrence Dauchy, Founder, DFYe. Published 2026-09-09. 10 min read. Guides.
> Source: https://dfye.com/blog/how-can-ai-help-website/
> Language: en

The line runs in one place: whether the job needs something only your business knows, and whether being wrong about it costs you anything.

**TL;DR.** AI does six jobs well on a website today: answering visitor questions from your own published pages, drafting product copy, writing alt text, summarising support conversations, first-pass translation, and finding content that contradicts itself. It cannot tell you why sales fell, decide anything that needs authority, or know a fact you never wrote down. The limit is not model quality. It is whether the answer exists somewhere it can reach.

There are six jobs AI does well on a website right now, and three it cannot do at
all. The difference is not model quality and will not be fixed by a better model. It
is whether the job needs something only your business knows, and whether being wrong
about it costs you anything. At least **826,000 WordPress sites** already run a chat
widget, measured against the
[plugin API](https://api.wordpress.org/plugins/info/1.2/) on 8 September 2026, so the
question is no longer whether to try. It is which jobs to hand over.

The six that work share one property: the raw material already exists on your site.

## What can AI do with your own content?

Six things, and they sort neatly by how much of the answer you already own.

| Job | What it needs from you | How good it is today |
|---|---|---|
| Answer visitor questions | Pages that contain the answers | Good, and checkable if it cites the page |
| Draft product descriptions | Specifications and your own notes | Good first draft, needs an editor |
| Write alt text | The image and its context | Good, and better than the empty attribute it replaces |
| Summarise support conversations | Your transcripts | Good, and genuinely time-saving |
| First-pass translation | The source text and a human reviewer | Good draft, never a final |
| Find contradictions across pages | Your published content | Underrated, and nobody does it |

The last row is the one almost nobody uses and the one most likely to surprise you. A
shop that has been trading for five years has a returns window stated three different
ways across a policy page, a product page and an old blog post. Nobody notices until a
customer quotes the generous one back at you. A model reading your own site and
flagging where it disagrees with itself is cheap, unglamorous and immediately useful.

Alt text deserves a note too. The bar is not perfection; it is the
[decision tree the W3C publishes](https://www.w3.org/WAI/tutorials/images/decision-tree/),
which mostly asks what the image is for. A generated description reviewed in two
seconds beats an empty attribute, and empty is what most catalogues actually have.

## What can it not do?

Three things, and none of them is a language problem, which is why a better model
does not move them.

**It cannot tell you why a number moved.** Sales fell last week because a competitor
ran a promotion, or because your checkout broke on Safari for nine hours, or because
it rained. None of that is in your data. A model asked why sales fell will produce a
fluent paragraph of plausible reasons, and the fluency is the danger: it reads exactly
like an answer.

**It cannot exercise authority.** Granting an exception, making a goodwill gesture,
deciding that this customer gets the refund even though the window closed. Those
require somebody empowered to depart from the policy and willing to own it. A system
that could do that would not be a tool.

**It cannot know what you never wrote down.** This is the one that catches people out,
because it looks like a model failure and is not. If your delivery cutoff lives in one
person's head, retrieval has nothing to retrieve, and the system will either decline
or invent. Which of those it does is the single most important thing to test.

The fix is also the cheapest thing on this page. Three pages cover most of what a shop
is actually asked: delivery, returns, and sizing or compatibility for whatever you
sell. Writing them properly is an afternoon, it improves your site for every visitor
who never opens a chat window, and it is the difference between a system that has
something to find and one that is guessing on your behalf.

## Where does it save real time?

In the repetition, not in the thinking. The tasks worth handing over are the ones you
would describe as "the same thing again".

| Task | The manual version | What changes with AI |
|---|---|---|
| The same four questions | Rewriting the same paragraph, at any hour | Answered from the page that already says it |
| Four hundred product pages | Weeks of copy, or blank descriptions | Drafts you edit, in an afternoon |
| Reading the support queue | Skimmed when there is time | Summarised, so patterns become visible |
| Catalogue alt text | Never happens | Happens |

Notice what is absent from that list: anything requiring a decision. That is the
pattern. AI is good at the work that is tedious because it repeats, and poor at the
work that is hard because it is ambiguous, and most people try it on the second kind
first because that is the work they resent.

Row four is worth pausing on. Catalogue alt text is the job most site owners have
silently written off as never going to happen, and it is the one AI changes from
impossible to a morning's review.

## What does it cost to try?

Less than the evaluation, which is the part nobody budgets.

Running the model is priced per token on both what you send and what comes back. For a
small site fielding ordinary questions this lands in the low tens of euros a month,
and less if you cache the answers to the questions everyone asks. The free, mature
option on WordPress is [AI Engine](https://wordpress.org/plugins/ai-engine/), where
you bring your own key and pay the model provider directly.

The real cost is attention. Pointing it at the right pages, excluding the ones it must
never quote, and then the part that actually decides whether this was worth doing:
asking it twenty questions you already know the answers to and reading what comes
back. That hour finds more than any dashboard, and it is the hour that gets skipped.

Speed is worth separating out, because it is the benefit most often claimed and least
often delivered. AI does not make your site faster. Your
[largest contentful paint](https://web.dev/articles/lcp) is decided by what your pages
load and in what order. Where a model genuinely helps is in the reading, pointing at
which plugin or request is costing the time. The change itself is a person editing a
template, and any tool promising otherwise is describing a different product.

## How do you tell a real capability from a demo?

Every tool in this space demos beautifully, because a demo is a controlled question
asked of prepared content. Five questions separate the two, and all of them take
minutes.

**Ask it about your own site, not theirs.** A vendor's demo runs on a site built to
answer well. Point it at yours before you form an opinion, and point it at the messy
corner rather than the tidy one.

**Ask something your site does not answer.** This is the most informative thirty
seconds available to you. A capable system says it does not know and offers you a
person. A weak one produces a confident paragraph, and you have just watched it invent
something in front of you, with nothing at stake. Next time there will be.

**Ask for the source, then open it.** An answer that cites a page is checkable; an
answer that does not is a rumour with good grammar. When it cites, read the page and
confirm it actually says that. A system that cites the right page and paraphrases it
wrongly is a specific and common failure.

**Ask the same thing twice, worded differently.** "Do you ship to Norway" and "can I
get this delivered to Oslo" should produce the same fact. If they produce different
facts, retrieval is unstable and the number you are shown in a dashboard will not tell
you.

**Try your worst-written page.** Everybody tests the polished product page. The value
of a retrieval system shows up on the eight-year-old shipping page with the
contradictory paragraph, because that is where your customers' questions actually go.

Run those five on any tool and you will know more than a feature comparison will ever
tell you. They cost about fifteen minutes, and the reason to do them before buying
rather than after is that all five are much harder to act on once the knowledge base
is built and the team has learned the interface.

## When is AI the wrong tool for your website?

Three situations, and the first is by far the most common.

If your site does not contain the answers, this is the wrong step. A retrieval system
reads what you published, and a shop whose policies live in email footers has nothing
to index. Writing those pages is the work. It improves your site whether or not you
ever automate anything, and it is the prerequisite rather than the alternative. People
skip it because installing software feels like progress and writing a returns page
does not.

If your volume is genuinely small, an email address wins. Twenty pages and six
questions a week is not a problem with a software answer, and the setup will cost you
more attention than the saving returns. That stays true for longer than most people
expect.

And if a wrong answer is expensive, whether that is medical, legal, financial or
anything regulated, the refusal behaviour is not a feature you assess at the end. It is
the first thing to test, and if it is not solid, the correct decision is not to ship.

Set against those, the ordinary case is straightforward. A shop with its policies
written down, getting the same questions at two in the morning, is handing over
repetition rather than judgement. The mechanism is on [how it works](/how-it-works/),
and the fastest way to judge any of it is to open [the demo](/demo/) and ask it
something your own site could not answer. What the category actually contains is in
[what an AI chatbot for a website actually is](/blog/ai-chatbot-website/), and the
honest limits of automation are in
[can a chatbot really replace live agents](/blog/can-a-chatbot-really-replace-live-agents/).

## Quick answers

### How can AI help my website?

Six jobs are genuinely worth handing over today: answering visitor questions from your
published pages, drafting product descriptions, writing alt text, summarising support
conversations, a first pass at translation, and finding pages that contradict each
other. What they share is that the raw material already exists on your site. Where
nothing exists to work from, AI produces something plausible instead of something true.

### What can AI not do for a website?

It cannot tell you why a number moved, because that needs context nobody wrote down. It
cannot make a decision that requires authority, such as granting an exception outside
your policy. And it cannot know a fact that exists only in somebody's head. Those three
limits are not going to be fixed by a better model, because none of them is a language
problem.

### Can AI write my product descriptions?

It can write the first draft, and that is genuinely useful when you have four hundred
products and no copywriter. What it cannot do is know the detail that actually sells
the thing: the way a fabric behaves after a wash, the reason returns on one size are
high. Feed it the specifications and your own notes and it drafts well. Ask it to
invent the interesting part and it will.

### Will AI improve my website's speed?

Not directly, and anything claiming otherwise is selling something. Speed is decided by
what your pages load and in what order, which is an engineering question with
measurable answers. Where AI genuinely helps is the reading: pointing at the plugin or
the request costing you the time. The change itself is still a person editing a
template.

### Is it worth using AI on a small website?

Often not, and that is a real answer. On a site with twenty pages and a handful of
questions a week, the setup costs more attention than the saving is worth, and an email
address does the job. It becomes worth it when the same question arrives repeatedly,
when the catalogue is too large to write by hand, or when questions arrive outside your
working hours.

### How do I check whether AI got something wrong on my site?

Ask it twenty things you already know the answers to, and read what comes back rather
than skimming it. That single hour finds more than any dashboard. After that, sample a
random handful of real conversations every week, not the escalated ones, because the
escalated ones are already visible and the quietly wrong answers are not.

## Sources

- [WordPress.org plugin API, the install figures](https://api.wordpress.org/plugins/info/1.2/)
- [OpenAI: embeddings, how a model is pointed at your own content](https://platform.openai.com/docs/guides/embeddings)
- [W3C WAI: the alt text decision tree](https://www.w3.org/WAI/tutorials/images/decision-tree/)
- [web.dev: largest contentful paint](https://web.dev/articles/lcp)
- [AI Engine on the WordPress.org plugin directory](https://wordpress.org/plugins/ai-engine/)

---
*Published by [DFYe](https://dfye.com/). Free to read, index, quote and cite with attribution and a link.*