The sustainability issue with AI, and what we can change as marketers

When I first gave this talk at BrightonSEO in April 2026, my second slide said that generating one AI image uses as much energy as fully charging your phone. It’s the number everyone quotes. When I went back to the source for the extended version at the Belgrade SEO Conference in September, I found it’s only true of the least efficient model in the study it comes from, measured against an old figure for phone charging. A typical model uses a fraction of that.

That’s this whole topic in miniature. The per-prompt numbers are slippery, they keep getting smaller, and the total keeps going up anyway. So this write-up is about the gap between the two, and the part I care most about: what an SEO or marketing team can actually do about it on a Tuesday afternoon.

Here’s what I’ll cover:

• why the famous “one ChatGPT query = ten Google searches” figure is out of date, and what the labs have actually published since
• why per-prompt efficiency is improving fast while total data-centre consumption still climbs
• why which AI you use matters more than whether you use it, with the research to back that up
• where marketing and SEO specifically make the problem worse
• ten practical changes, from planning before you prompt to replacing LLM calls with purpose-built models
• one real workflow, end to end, where nine of the ten steps cost nothing

A note on the numbers: every energy, water and carbon figure below links to its source. Where a figure is contested, I say so. Where my own slides got something wrong, I say that too.

The number everyone quotes is from 2023

You’ve probably seen it: a ChatGPT query uses 2.9 watt-hours, a Google search uses 0.3 Wh, so asking a chatbot costs ten times as much. I put it on a slide in Brighton too. It traces back to Alex de Vries in Joule (October 2023), who gave 2.9 Wh as an upper estimate built from analyst figures on early-2023 server costs, and it was then repeated by the IEA in Electricity 2024. The 0.3 Wh Google figure is even older: it comes from a Google blog post from January 2009.

So the comparison is a 2023 estimate set against a 2009 one. Since then, two of the big labs have published their own numbers.

	Google Gemini	OpenAI ChatGPT	Mistral Le Chat	Anthropic Claude
Energy per prompt	0.24 Wh (median text prompt)	0.34 Wh (“average query”)	not given as energy	nothing published
Water per prompt	0.26 ml (on-site cooling only)	~0.32 ml	45 ml (full lifecycle, 400-token reply)	nothing published
Carbon per prompt	0.03 gCO2e	not given	1.14 gCO2e	nothing published
Where	Technical paper, Aug 2025	Blog post, Jun 2025	Lifecycle analysis, Jul 2025	none I could find, as of Oct 2026
Method shown?	Yes	No	Yes (with Carbone 4 and ADEME)	n/a
Training included?	No	No	Reported separately	n/a

The numbers look tiny, and the companies would like you to stop there. But read the small print. Google’s figure is a median text prompt, not a mean, and excludes training. Its water figure counts only on-site cooling, not the water used to generate the electricity, which is why researchers including Shaolei Ren and Alex de Vries-Gao called it the tip of the iceberg. Altman’s figure came in a blog post with no method, model or query length attached. Mistral’s 45 ml looks alarming next to Google’s 0.26 ml, but that’s because Mistral did a full lifecycle analysis, including manufacturing and the water behind the electricity. The honest reading is that the most transparent lab looks the worst.

The gap that matters isn’t between the numbers. It’s that only some of them showed their working, and none of them counted training in the per-prompt figure.

Lazarina Stoy, Belgrade SEO 2026

There is no such thing as “one query”

The other problem with a single figure is that queries vary enormously. Microsoft researchers Oviedo et al. (Joule, 2026) estimate a median of about 0.31 Wh for a typical query to a frontier model, but about 3.91 Wh, roughly 13 times more, once reasoning is switched on and the model writes around 5,000 output tokens. Epoch AI estimates that stuffing 100,000 tokens of context into a prompt pushes a single query to around 40 Wh. That’s more than a hundred times the short prompt.

The same goes for water. The widely shared Washington Post and UC Riverside estimate that a 100-word GPT-4 email uses 519 ml is an upper-end 2024 figure: it counts power-plant water as well as cooling, and assumes 2023-era energy use. Asking “what does a query cost?” is like asking what a journey costs. Nobody says how far.

Better at the unit, worse at the total

Here’s the good news. Google says the energy per median Gemini prompt fell 33-fold, and the carbon 44-fold, in the twelve months to mid-2025 (Elsworth et al., 2025). So the problem is solved, surely?

Well, no. According to the IEA (April 2026), data-centre electricity demand grew 17% in 2025 to about 485 TWh, and demand from AI-focused data centres grew 50%. The IEA expects total consumption to roughly double to about 950 TWh by 2030, around 3% of global electricity. Its 2025 report put that 2030 figure at 945 TWh, which it described as slightly more than Japan’s entire electricity consumption today.

Since I gave this talk in Brighton: my April slide said data centres could use 1,050 TWh by 2026. That was the top of a range in the IEA’s 2024 report, and it included crypto mining. Actual use came in far lower (415 TWh in 2024, 485 TWh in 2025), so I’ve replaced it. The trend is the same; the scary number was wrong.

The company reports tell the same story. Google’s 2026 Environmental Report puts its emissions at about 14.5 million tCO2e, up 81% on its 2019 baseline, with data-centre water consumption up 37% in a year to about 10.5 billion gallons. Microsoft’s 2026 environmental data fact sheet shows total emissions rising from 12.9 to 20.3 million tCO2e between 2020 and 2025, which by my reading of its tables is an increase of nearly 60%.

Efficiency per prompt is winning. Volume is winning faster.

OpenAI said in July 2025 that ChatGPT handled 2.5 billion prompts a day. That’s the last daily figure it has confirmed. Since then weekly users went from 700 million to 900 million by February 2026, and by July 2026 OpenAI said its models reach more than a billion users. When its image model went viral in March 2025, Sam Altman posted that “our GPUs are melting”. Nobody decided we needed millions of Ghibli portraits and action-figure versions of ourselves. It just compounded.

That gap is the whole talk. We’re getting better at the unit and worse at the total, which means how you work matters more than which model you pick.

The corporate response: scale at all costs

• Stargate: OpenAI, SoftBank, Oracle and MGX announced $500 billion of US AI infrastructure in January 2025.
• Google: planned $75 billion of capital spending for 2025, raised it to $91–93 billion by October 2025 (Alphabet Q3 2025 results), and in July 2026 guided to roughly $195–205 billion for 2026, as reported from its earnings call.
• Apple: more than $500 billion of US investment over four years, including an AI server factory in Houston.
• Nuclear: Google signed for small modular reactors with Kairos Power and Amazon invested in X-energy, both in October 2024.

And the costs don’t stay inside the data centre. In April 2026 the NAACP, represented by the Southern Environmental Law Center, sued xAI over 27 unpermitted gas turbines powering its Colossus 2 data centre near Memphis. When the groups first announced their intent to sue in February, SELC’s Patrick Anderson said xAI was “breaking the law while leaving local communities to deal with the consequences”. On 20 October 2026 the court refused a US Department of Justice attempt to stop the case. Researchers at Caltech and UC Riverside estimate the public-health cost of US data-centre air pollution at more than $20 billion a year by 2028.

Two YouTube videos shaped this part of the talk. Hank Green’s Why is everyone so wrong about AI water use? is a good corrective on how misleading per-use water figures can be, in both directions. Benn Jordan’s Datacenters behaving like acoustic weapons raises concerns about low-frequency noise near data centres. I showed his symptom figures in Belgrade, but they come from his own informal experiment, which isn’t published yet, so I’ve left them out here. What isn’t in question is that companies measure CO2, water and money, and the people living next door don’t appear in any of those numbers.

Meanwhile, Altman’s answer to the energy question in February 2026 was that it also takes a lot of energy to train a human: “like 20 years of life and all of the food you eat”. Noted.

It isn’t AI versus no AI. It’s which AI, for which job

This is the bit that changes how I think about my own work. In Power Hungry Processing (FAccT 2024), Sasha Luccioni, Yacine Jernite and Emma Strubell measured 88 models on 30 datasets. On average, per 1,000 inferences, text classification used about 2 Wh, text generation about 47 Wh, and image generation about 2,900 Wh. Generating an image cost over 1,450 times what classifying a piece of text did.

That’s also where the phone-charging line comes from. The least efficient image model in the study used 11.49 kWh per 1,000 images. Using an old figure for a phone charge, MIT Technology Review framed that as one image per full charge. The final paper uses an updated figure and gets about half a charge per image, and the median image model used about 1.35 Wh per image. Still not nothing, but not a full phone charge per picture.

The more useful finding is that it’s the architecture, not just the size: multi-purpose generative models cost orders of magnitude more than task-specific ones for the same task. A 2026 study made this painfully concrete for marketers. Zschache and Hartwig (Scientific Reports, 2026), at the German Environment Agency, ran one text classification task through everything from a linear model to a 70-billion-parameter reasoning model.

The linear model on sentence embeddings used 0.12 Wh and was the most accurate, at 57%. The reasoning model used 702 Wh, 5,850 times as much, and got 46%. One caveat, which the authors make themselves: the LLMs were used zero-shot, while the classic models were trained on the data. But that’s exactly the trade most of us are making when we paste a keyword list into a chatbot.

DeepSeek is the other example people raise. Its V3 model’s final training run took 2.79 million GPU-hours, against 30.8 million for Meta’s Llama 3.1 405B, so roughly 90% less compute (not the 95% less energy I’d seen quoted, and DeepSeek published no energy figure). But efficiency in training can be wiped out at inference: early tests reported by MIT Technology Review found DeepSeek’s reasoning model R1 used more energy per prompt than a comparable model, because it writes such long answers.

Where marketing and SEO make it worse

This is where our industry comes in, because a lot of the volume isn’t coming from people chatting to a bot. It’s coming from search, agents, crawlers and the things we build.

AI Overviews on everything

In March 2025, Pew Research found AI summaries on about 18% of the real Google searches made by its US panel. By May 2026, Similarweb put AI Overviews on about 43% of Google searches. Trackers that use fixed keyword sets report higher shares again, so the figure depends on whose queries you count, but the direction isn’t in doubt. And, as everyone who remembers the glue-on-pizza and eat-a-rock answers knows, they’re not always right.

In Brighton I multiplied “10× the energy” by “8.5 billion daily searches”. I’ve retired that maths. The 10× no longer holds for a short prompt, and Google now says it handles more than 5 trillion searches a year, about 14 billion a day. The multiplier was never the model. It’s what happens around it: the re-prompting in AI Mode, the follow-ups, and the fan-out.

Query fan-out and agents

When a person looks something up, they open maybe five pages, read, and stop. When an AI system answers the same question, it can fan the question out into sub-queries, run a retrieval and an inference step for each, and keep going. Cloudflare’s CEO Matthew Prince illustrated this at SXSW in March 2026: a human shopping for a camera might visit five sites, while an agent might visit 5,000. The Microsoft study I cited above is candid that tool calling and orchestration are out of scope for current per-query estimates, and that agentic energy use could be dominated by them (Oviedo et al., 2026). The prompt got cheaper. The thing a prompt sets off got much bigger.

The traffic data agrees. HUMAN Security reports that traffic from AI agents and agentic browsers grew 7,851% year over year (from a small base, on its own customer network), and Cloudflare says daily requests from AI agents on its network grew by more than 1,700% over the past year. In June 2026, Cloudflare Radar showed automated requests overtaking human ones for HTML pages, at about 57.5% to 42.5%.

Crawlers that take and don’t send back

Cloudflare was already seeing more than 50 billion AI crawler requests a day in March 2025. In August 2025 it published crawl-to-refer ratios: Anthropic’s crawlers fetched nearly 50,000 pages for every visitor Claude sent back, OpenAI 887 and Perplexity 118. Nearly 80% of AI crawling was for training, and less than 5% was a crawler fetching a page because a person asked (or undeclared). Those ratios have since dropped sharply as assistants started linking out more, and they swing a lot by time window, so check the live Radar data before you quote one. But by June 2026, 52% of crawler requests were for AI training, up from 22% in spring 2025. The crawl happens whether or not a single person ever reads the answer. You pay the bandwidth. Everyone pays the compute.

For context, Imperva found that automated traffic passed human traffic in 2024 at 51% of the web, and 37% of all traffic was bad bots, up from 32% in 2023.

And my favourite: vibe coding

“Everyone is a programmer now.” I love that people who couldn’t code can now build things. I don’t love what a vague prompt does at scale. “Build me a tool that…”, with no spec, no constraints and no output format, is a guess. “Not quite, try again” re-sends the whole context and regenerates the whole answer. Then the output gets shipped, indexed, crawled and quietly abandoned. Products, tools and websites that serve no one are being built every day, because they can be built, not because they should exist.

Now run the thought experiment from my slides. One SEO trains a custom model for keyword classification. Then 10% of the industry does the same thing, separately. Then all of SEO. Then every marketer, designer and hobbyist. Each one is a separate training run for a job someone has already done. Nobody has published a number for this, and that’s the point: the total isn’t counted anywhere.

What this leads to: trust, thinking and the dead internet

Trust erosion. The KPMG and University of Melbourne global study (48,000 people in 47 countries, 2025) found 66% use AI regularly, but only 46% are willing to trust it, and 70% are unsure whether online content can be trusted because they don’t know if it’s real or AI-generated. In the US, 81% of consumers said they’d trust AI more if laws and policies were in place. Adoption isn’t endorsement. That’s the environment your brand is publishing into.

The dead internet. Ahrefs analysed 900,000 pages published in April 2025: 74.2% contained AI-generated content, but only 2.5% were purely AI and 71.7% were a mix. Graphite estimates AI now writes about half of new online articles, a share that has plateaued since 2025. The question stopped being “did a machine write this?” It’s “did anyone check?”

Cognitive decline (maybe). I’m more careful here than I was on stage. MIT Media Lab’s Your Brain on ChatGPT study found weaker brain connectivity and worse recall among people who wrote essays with an LLM, which the authors call “cognitive debt”. But it’s a preprint with 54 participants and one task. A Microsoft Research and Carnegie Mellon survey of 319 knowledge workers found that the more people trusted generative AI, the less critical thinking they reported doing. And Harvard’s Christopher Dede has warned that if AI does your thinking for you, it undercuts your own critical thinking and creativity. This is early, suggestive evidence rather than a settled finding. It’s enough for me to change how I work, though: the struggle is the learning.

What we can change as marketers

This is the part of the talk I actually wanted to give. None of it requires you to stop using AI. It asks you to be AI-assisted, not AI-driven, and it happens to save money and produce better work as well.

1. Do the thinking yourself, then delegate the execution

What usually happens: you hand the whole task to the model and hope. The model decides the approach, invisibly and differently each run. When it comes back wrong, you can’t see which part failed, so you re-prompt everything and pay for the full context on every retry.

What to do instead: decide the goal, the constraints, the output format and the steps yourself, before a single token is spent. Then let the model run one step at a time, where each step is checkable on its own. When one breaks, you fix that step and re-run only that.

The plan is the part that compounds. The execution is the part you can hand over. Do it the other way round and you pay full price for the full context on every retry, and keep nothing.

2. Don’t re-prompt. Build the template once

Hand-drawn is fine for your personal brand. I showed Mark Williams-Cook’s hand-drawn LinkedIn cartoons in Belgrade: authentic, memorable, zero compute. Nobody screenshots a perfect stock illustration. They screenshot the one someone clearly drew themselves.

But an enterprise social team ships the same branded card forty times a month, and nobody is drawing those. That’s a templating problem, not a generation problem. So instead of prompting an image model for every post (a wait, a look, fonts that drift, and no way to regenerate last month’s post), build two things once: a brand file with your hex codes and fonts, and an HTML layout per image type (quote card, stat card, carousel, blog hero). An AI coding assistant can write both. After that, the only thing that changes is the content, as data, and a headless browser screenshots it.

For one campaign I built this way, that came to 59 layout templates, one shared brand file, two canvas sizes, 113 finished images and zero image-model calls. Swap a colour in the brand file and every image re-renders on brand, in one command. On my rough maths (about four hours to build, about three minutes saved per image), it pays for itself around image eighty. Your numbers will differ; the direction won’t.

3. Plan before you prompt

Four principles I follow before I touch any AI tool:

• Research prompting techniques first. In my experience, ten minutes learning how a technique such as chain-of-thought or few-shot prompting works turns ten to fifty back-and-forth interactions into one to three. That’s my rule of thumb, not a study, but try it.
• Use system prompts for repeatable tasks. A system prompt sets the persona, rules, tone and guardrails once, so you’re not re-explaining them in every message. Structure it in clear sections (personality, goal, tools, guardrails), one action per line, with explicit error handling.
• Plan the task, not just the prompt. Write down the goal, the constraints and the output format before you open the tool.
• Ask whether you need AI at all. More on that below.

4. Architect LLMs into repeatable systems, with roles

A content brief isn’t one task. It’s at least four, and only one of them needs a big model. The default is one giant prompt (“Write me a content brief for X”): everything in one context window you pay for every turn, no way to tell which part went wrong, one model tier for every subtask including the trivial ones, and nothing reusable for the next brief.

The alternative is an orchestrator that holds only the goal, constraints and output format, handing work to specialists: a SERP analyst (rules and an API, no LLM needed), an entity extractor (an ML API, deterministic and free), a brief writer (the one big model, for judgement only) and a QA checker (a small model checking against a schema). What that buys you: every task belongs to someone, specialists carry tiny contexts, you can fix one step instead of the prompt, you can score each agent, and each interaction has less latency.

5. Ask: do I actually need AI for this?

The test I use is whether the task has one right answer. Classification, extraction, entity typing, salience scoring, matching, counting and deduplication all do: run them twice and you should get the same answer twice. That’s the whole requirement, and it’s a job for classic ML or plain rules.

“What does this mean?”, “Why is this page weak?”, “Write the brief”, “Summarise a conflict”, “Explain the gap”: ask two people and you get two answers. That’s where a language model earns its price.

If the answer should be the same every time, it’s not a job for an LLM. Ask it what something means. Never ask it to count.

Lazarina Stoy

I wrote more about this split in rule-based vs AI-powered automation.

6. Choose the right model for the task

Here are five jobs an LLM is routinely handed, and what I’d use instead. On these jobs, the purpose-built model isn’t the compromise. It’s simply the better tool: smaller, faster, cheaper, greener and usually more accurate.

The job	Instead of	Use	What changes
Keyword classification	a general-purpose LLM	BERT / DistilBERT, or sentence embeddings plus a linear classifier	Same output every run, at a fraction of the energy
Content categorisation	LLM prompting	fastText, spaCy, or Google’s Natural Language API	Purpose-built for text, runs locally or on a free tier
Sentiment analysis	a chatbot	VADER or a RoBERTa sentiment model	Numeric scores, thousands of rows in one batch
Entity extraction	LLM parsing	spaCy NER or Google’s Natural Language API	Structured output, no invented entities
URL pattern matching	an LLM, honestly	Regex and lightweight ML	Deterministic, zero API calls

There’s a free notebook or template for most of these in the MLforSEO resources library: no sign-up, open it in Colab. If you want the method behind them, the Introduction to Machine Learning for SEO course in the MLforSEO Academy walks through classification, entities and sentiment step by step, and the Semantic AI-powered Keyword Research course applies them to keyword work. There’s also a free guide to structuring keyword data for semantic analysis and a deep dive on sentiment analysis methods.

Then combine them properly. Each layer does what it’s actually good at: an ML API extracts and scores the entities, an LLM interprets what the extractor found once, and plain rules decide using a rubric and thresholds. Put them in the wrong order and you’re paying a language model to count, badly, and differently every run.

7. Pull the four levers that don’t change your output

When you do use a generative model, four settings cut the bill, and very likely the footprint, without changing the answer. Each one is a single parameter in the request.

• Structured outputs. Give the model a schema and it returns data, not prose. Same shape every run, so you can diff two runs and trust the difference, and you stop re-prompting to fix formatting.
• Batch, don’t stream. If nobody is waiting for the answer, submit it as a batch job. Both OpenAI and Anthropic charge 50% less for batches. Most audits aren’t urgent, and nobody is watching the cursor blink.
• Cache the context. Send the long instructions once and reuse them. Your rubric doesn’t change between pages, so stop re-sending it. Cached input is billed at around a tenth of the normal price on current Anthropic and OpenAI models.
• Tier the models. The cheapest model that can do a step is the right model for that step. Small for extraction, large only where reasoning genuinely changes the answer. Choose per step, not per project.

A caveat: a price discount isn’t a measured energy saving, and providers don’t publish the energy side. But batching lets them run work on spare capacity, caching skips recomputing the same tokens, and a smaller model does less work per token. The bill and the footprint move in the same direction.

8. If you must train, train efficiently

Before you train anything, run down this list: does an API already do this? Use it. Is there an off-the-shelf model? Use it. Could you fine-tune instead? Do that. Almost everything in this talk stops at the first question. If nothing fits and you really do need to train, these settings do most of the work, and none of them is a research project:

• Pruning: most of what a model stores never fires, so cut the dead weight. Han et al. (2015) cut two image models to between a ninth and a thirteenth of their parameters with no loss of accuracy. For language models, removing around half the weights is more realistic.
• Quantisation: store the numbers less precisely, like rounding prices to the nearest euro. Going from 32-bit to 8-bit makes the weights four times smaller. The energy saving is smaller than that and depends on the hardware.
• Distillation: a big model teaches a small one, which copies the answers, not the size. DistilBERT is 40% smaller and 60% faster than BERT while keeping 97% of its language understanding.
• LoRA: don’t retrain the model; annotate it, like notes in a textbook margin. Hu et al. (2021) cut the number of trainable parameters 10,000-fold and GPU memory three-fold compared with fully fine-tuning GPT-3.
• Carbon-aware scheduling: run jobs when the grid is cleaner. Dodge et al. (FAccT 2022) found that shifting short jobs to cleaner hours cut emissions by more than 30% in several regions and up to 80% in one. For a long training run the gain was under 1.5%, unless you were willing to pause and resume it.

Since I gave this talk: my slide said LoRA uses “100× less compute” and carbon-aware scheduling saves 34%. I couldn’t stand those up against the sources, so the figures above are what the papers actually report.

9. We don’t all need our own tools

We all do the same things for different websites. Two years ago, keyword research, technical audits, content audits, rewrites, optimisation and structured data all needed a person; now all six are automatable. The question is no longer whether, but how. And we don’t all need to build our own little tool to do them, even though we now can.

Eight teams, eight models, eight sets of mistakes. Or eight teams, one model, one thing to improve, and everyone gets the improvement. Four ways not to rebuild it:

• Use existing tools and APIs. Somebody has usually already solved the extraction, classification or matching, usually better than you will, and often for free. Search before you build.
• Share pre-trained models within your organisation and across the industry. The model your team trained last quarter is doing nothing on someone’s laptop. One good model shared by many beats a hundred bad ones built alone.
• Contribute to open source. When a library nearly does what you need, the cheap move is a pull request, not a private fork nobody else benefits from.
• Fine-tune, don’t custom-train. Take a pre-built workflow and adapt it to your case.

10. Replace wasteful workflows with processes

The wasteful workflow isn’t the complicated one. It’s the one you run again from scratch next month. A one-off prompt can’t compound: you never run the same thing twice, so you can’t tell which part worked, and if the output differs every run you have no way to detect a regression. A workflow can: keep what moved the number, drop what didn’t, and get better at the work, not just faster.

• Instead of one LLM prompt for a complex task (asking a big model for a whole content brief and hoping), build a SERP analysis step, a brief template and an NLP extraction pipeline, each sized to the job it does. You get consistent, repeatable output and you can diff two runs.
• Instead of vibe-coded one-off scripts written once, understood by one person and run twice, use maintained open-source libraries or internal team tools: something with a README and a test, tested, documented and shared, fixed once for everyone.

One process, end to end: an audit where nine of ten steps cost nothing

To finish the talk I walked through a real entity audit I ran on mlforseo.com: 647 pages, ten steps, and generative AI used exactly once. It’s the clearest way I know to show that responsible AI use is not a sacrifice.

• Freeze the corpus. Crawl once (647 URLs, body text only), store the extracted text and never touch it again. That’s your before state.
• Extract the entities with Google’s Natural Language API: not an LLM, one call per page, same input, same output. The first 5,000 units a month are free.
• Filter the noise. Drop structural types (numbers, dates, prices) and site chrome, and collapse surface forms to one canonical name. Two thirds of what the extractor returned wasn’t about the page.
• Roll up to page profiles. One row per URL with the dominant entity, its salience and type, flagging every page where that isn’t what you intended.
• Score it on five dimensions (clarity, coverage, consistency, connection and corroboration), 0–3 each. A rubric, not a vibe.
• Reconcile to the Knowledge Graph with one free lookup per entity, comparing what Google returns to what your content implies.
• Compare against competitors with the same pipeline pointed at their public pages. Normalise names first, then diff the two sets.
• Now, and only now, use generative AI. Feed it the gaps, the conflicts and the canonical names, and ask for a brief, not prose. One step out of ten.
• Ship the fix. A human reads the brief and edits the page. That part hasn’t changed, and it shouldn’t.
• Re-run the identical pipeline. Same crawl, same extraction, same filters, same rubric. Only the site changed, so the movement in the score is the only proof that any of it mattered.

Nine of ten steps cost nothing, the expensive model runs once, and the second audit takes an afternoon. It’s cheaper, it’s greener, and for extraction it’s simply more accurate: same input, same output, no invented entities. You aren’t trading anything away, which makes this an easy argument to win internally.

Every step has a free, browser-based tool on the MLforSEO Academy tools page, and the full walkthrough is the MLforSEO Academy course The AI-powered Entity Audit.

Your Tuesday-afternoon checklist

1. Before you open an AI tool, write down the goal, constraints and output format.
2. Ask: does this task have one right answer? If yes, use rules or a classic ML model.
3. Look for an existing API, model, notebook or open-source library before you build anything.
4. Split complex jobs into steps, and give each step the smallest model (or no model) that can do it.
5. Use structured outputs, batch anything that isn’t urgent, and cache repeated instructions.
6. Turn repeated generation (social cards, briefs, reports) into templates and pipelines you can re-run.
7. If you must train, fine-tune with LoRA, and quantise, distil or prune what you deploy.
8. Save prompts and system prompts that work, and share them with your team.
9. Keep doing the thinking yourself. Hand over the execution.

If you want more on where ML fits in a normal week, I’ve written about incorporating machine learning into your SEO day-to-day.

Frequently asked questions

Is one ChatGPT prompt really bad for the environment?

A single short text prompt is small: current estimates and disclosures put it at around 0.2–0.4 Wh (Google, Oviedo et al.). The problem is volume and type. Reasoning modes, long context, image and video generation, agents and fan-out can cost tens to thousands of times more, and billions of prompts a day add up. That’s why total data-centre demand grew 17% in 2025 even as per-prompt efficiency improved.

Are the AI water-use figures exaggerated?

Some are, in both directions. Google’s 0.26 ml per prompt counts only on-site cooling, while the 519 ml per email estimate includes power-plant water and older energy assumptions. Water also matters most locally: the same litre means something very different in a water-stressed region. Treat any single per-prompt water figure with caution and look at the scope it covers.

Should marketers stop using generative AI?

No. My argument is to be AI-assisted, not AI-driven: use generative models where the task is genuinely ambiguous (interpreting, writing, explaining) and use rules or purpose-built models where there’s one right answer. In my own workflows that usually means one generative step out of many.

Aren’t smaller, task-specific models less accurate?

For narrow, well-defined tasks, often not. In Zschache and Hartwig (2026), a linear model on sentence embeddings was the most accurate approach on a text classification task while using a tiny fraction of the energy of large language models. For extraction tasks, a deterministic API also gives you the same answer every time, which a generative model can’t promise.

AI-assisted, not AI-driven

Better for the planet. Better for your brain. Better for your work. We’ll keep getting better at the unit; how much the total grows is partly down to how we work, and that’s something marketers can change this week.

You can download the full slides from Belgrade, with every source on the slides themselves.

Want me to give this talk at your event? Book me to speak.