Last updated: November 1, 2026.
Most of an SEO specialist’s day goes into text and data: keyword lists, Search Console exports, content briefs, page audits, technical notes. Large language models (LLMs) speed up a good part of that work. In some of it, though, they state wrong things so convincingly that the mistakes are hard to spot.
For most of this book we’ve treated AI as a channel: how your brand appears there, how it gets cited, how it gets recommended. In this chapter the direction flips, and we look at AI as a tool for doing the SEO work itself. I’ll go through keyword clustering, data analysis, writing briefs and content audits, and for each one look at where the tool helps, where it misleads, and how to check the result.
The short version: AI is strong at language work and dangerous with data it doesn’t have.
1. The model produces text, not data
In Chapter 3 we saw that the model writes by picking each word from a probability distribution. In SEO work that has a practical consequence. The model can also produce data it doesn’t have, in the form of text.
In a study published in September 2025, OpenAI defines hallucinations as “plausible but false statements generated by language models” (OpenAI). According to the study, standard training and evaluation methods reward guessing over acknowledging uncertainty, so a model tends to make up an answer instead of saying “I don’t know.” Consistent patterns like spelling and punctuation get learned correctly as scale grows, but sparse, arbitrary facts can’t be predicted from patterns.
In SEO, sparse and arbitrary facts are things like a keyword’s monthly search volume, how many backlinks a page has, where a site ranked yesterday, or what a competitor wrote on a category page. None of that can be derived from the patterns of language. Si Quan Ong of Ahrefs put it this way in an October 2025 post: ChatGPT can’t do SEO, it can only talk about SEO (Ahrefs). That comes from a company that sells an SEO tool, but the point stands.
So it helps to sort the work you give AI into two groups. Grouping, classifying, summarizing, rewriting, proposing a structure or reading a text against a checklist are language tasks, and the model is strong at them. Producing numbers, stating rankings, recalling what’s on a page or reporting what a source says are data tasks; unless the model is connected to real data, it can’t be trusted with them.
Pulling the data from the real source and having the model do the language work is the right way to use it. Asking the model for the data is the wrong way.
2. The overall picture
Before getting into details, here’s the general picture. It isn’t a definitive classification, just a map to start from.
| Task | How useful is AI? | Main risk | How to verify |
|---|---|---|---|
| Grouping keywords by intent | High | Putting different intents in the same group | Check the search results, spot-check samples |
| Providing search volume, difficulty, backlink counts | Low | Making up numbers | Don’t use it for this; get the data from a tool |
| Interpreting Search Console data | Medium | Calculation errors, wrong filters | Have the math done in code or a spreadsheet |
| Preparing a content brief | High | Assuming competitor pages say things they don’t | Give the model the competitor pages yourself |
| Auditing an existing page against a list | High | Missing details on long pages | Feed the page in sections, ask for quotes |
| Suggesting titles and meta descriptions | High | Adding a promise the page doesn’t make | Compare against the page content |
| Drafting robots.txt, regex, structured data | Medium | Syntax or logic errors | Validate in testing tools |
| “Google says…” type information | Low | Outdated or invented information, fake sources | Go to the official documentation |
Every row in that table has something in the verification column. When AI speeds up a task, the checking step doesn’t go away; it just moves. Part of the time you used to spend on the work itself now goes into checking it.
3. Keyword clustering
Keyword clustering is, in my view, one of the places where AI helps most in SEO. Grouping hundreds or thousands of queries by intent used to take either hours of manual work or tools that compared search results. A model can read what the queries mean and do the grouping quickly and, most of the time, sensibly. There are still three traps.
The model shouldn’t produce the list itself. Saying “find 200 keywords for filling machines and group them” is asking the model for data. It can produce queries that sound plausible but that nobody searches for, and then attach search volumes to them as well. Get the list from a real source: queries from Search Console, an export from a keyword tool, questions collected by the sales team. Let the model do the grouping only.
Similar meaning isn’t the same as similar intent. “Filling machine prices” and “how does a filling machine work” are about the same topic, but one is close to a purchase and the other is looking for information. The model sometimes puts them in the same group. The most reliable check is still to look at what Google shows for those queries. If the same pages rank for two queries, they can probably be answered by the same page.
And a cluster isn’t a decision to create a page. It’s tempting to build a separate page for every group, but Google warns against this explicitly in its AI guidance. Creating separate content for every variation people might search for violates the scaled content abuse policy when the main purpose is to manipulate rankings or AI answers (Google Search Central). We’ll come back to this in detail in Chapter 19.
A workflow might look roughly like this:
- Collect the query list from real sources and keep numbers like volume and clicks in the same table.
- Give the model only the query text and ask it to group by intent. Have it write a short intent description next to each group.
- Search a few queries from each group on Google and see whether the results look alike.
- Map the groups to your existing pages. You decide whether a new page is needed, not the model.
Here’s a hypothetical example. Say 300 queries come out of the filling-machine manufacturer’s Search Console. Give that list to the model and ask it to group by intent, and you might get groups like “product type and capacity” (piston filling machine, filling machine for 3,000 bottles a day), “product fit” (filling foaming liquids, filling thick products), “price and budget” (filling machine prices, used filling machine), “service and spare parts” and “information” (how does a filling machine work). That’s a starting point. Whether “used filling machine” belongs in the price group or counts as a separate intent is your call, based on the search results and your own business model.
Turkish adds one more wrinkle. Because of its suffixes, the same query can be written in many forms: “dolum makinesi,” “dolum makinası,” “dolum makineleri,” “dolum makinesinin fiyatı.” The model usually groups these correctly, but with misspelled or dialect-influenced queries it’s worth a look.
4. Leave the math to code
It’s very tempting to hand AI a Search Console export, a log file or a crawler’s output and ask “what do you see?” The model is helpful at describing trends, suggesting hypotheses and telling you which breakdown to look at. With numbers, though, there are two risks.
One is calculation errors. When a language model “reads” the numbers in a table and adds them up, averages them or works out percentages, it can get them wrong. Because the result is a plausible number, the error often goes unnoticed. The other is seeing a pattern that isn’t there. A model that knows it’s expected to say something can describe a trend the data doesn’t contain.
The fix is simple: don’t let the model calculate the number; have it write the code or formula that does. Many AI tools can now run code. Ask the model to “write and run code that calculates this breakdown”; the program does the math, and you can check the code. If your tool can’t run code, ask for a spreadsheet formula and do the calculation in the spreadsheet.
Pick a few of the model’s results at random and check them by hand against the source data. If even one doesn’t match, have the whole thing redone.
Google has started using AI on this side too. In December 2025 it added an experimental AI-powered configuration feature to the Search Console performance report that sets up the filters when you describe the analysis you want in plain language. The same announcement spells out a limitation: the AI may misinterpret some requests, so check that the suggested filters match your intent before analyzing the data (Google Search Central). That warning, written by Google about its own tool, applies to every AI-assisted analysis.
Connecting the model to data is a separate topic. Many AI tools can now connect to SEO tools, to Search Console or to your own databases. The Ahrefs post I mentioned above also introduces a connection (MCP) that gives AI assistants live data from its tool. These connections sharply reduce the risk of made-up data, because the model pulls the number from the tool instead of guessing it. But the model can still pull the wrong data with the wrong filter, or misread the right data. Even with a connected tool, look at which data the model pulled with which filter, and check the result once in the source tool.
Take a hypothetical analysis question: “Did clicks to our blog pages drop after AI Overviews launched in Turkey?” Instead of asking the model for an answer directly, go step by step. Pull page-level click and impression data from Search Console for before and after February 18, 2026, have the model write a rule that labels pages by type, have the comparison done in code, and look at the result in a table. The model designs the analysis and writes the code, the program does the math, and you do the interpreting.
5. Writing briefs
A content brief is a short document that tells a writer or content team what a page will cover, for whom, and how. AI is very good at drafting its skeleton: title suggestions, section structure, questions to answer, internal link ideas.
The risk shows up in competitor analysis. Ask the model “what do the pages ranking in the top 10 for this topic cover?” and, if it isn’t reading those pages right then, it produces a plausible list. That list may not match what competitors actually wrote. The Tow Center study in Chapter 3 showed how often AI tools get citations wrong.
So pick the competitor pages yourself and give the model their text; it’s strong at summarizing and comparing text that’s put in front of it. Ask it to back every finding with a source. If it says “Competitor A talks about foaming products,” it should quote the sentence that supports it. And put your own knowledge at the center of the brief: the sales team’s answers, product tests, constraints that come out of customer questions. The model can’t know these, and they’re what separate a brief from the average. Chapters 11 and 12 covered where that knowledge comes from.
In the filling-machine example, the model could suggest a good skeleton for a page on “Choosing a filling machine for foaming liquids”: what the foaming problem is, which nozzle types exist, how to calculate capacity, what drives the price. But “how many bottles a day our bottom-up filling model fills, which customer tested it with which product, how many days installation takes” is information only you have. AI drafts the skeleton; you add the information that makes the page worth reading.
A good brief should have these sections, and asking the model for a draft built on them speeds things up:
- The page’s purpose and reader. Who will read this page, at what stage, with what question?
- Questions and constraints to answer. Questions from the prompt list and from the sales team.
- What we know. Tests, numbers, case studies, expert opinion. The model can’t fill this part; if it’s empty, the page isn’t ready to be written.
- Sources. Official documents and data to use, with links.
- Internal links and the conversion step. Where will the reader go after this page, and what will they do?
If the “what we know” section is empty, no matter how good a skeleton the model builds, what comes out is what Google calls commodity content. We’ll get to that in the last chapter.
6. Reading pages against a checklist
Auditing existing pages is one of the most productive uses of AI. A model is fast and consistent at reading a page against a specific checklist and listing what’s missing. You could have it read a product page with questions like these:
- Which user constraints does this page answer, and which does it miss?
- Is there dated information on the page that may have gone stale?
- Does each paragraph keep its context when read on its own?
- Do the headings accurately describe the content under them?
- Are concrete details (capacity, price range, timing, region) written as numbers?
Most of these questions come from the readability and decision-support principles in Chapters 3, 10 and 11. A model can run this check across hundreds of pages much faster than you can.
Long texts have a limit, though. The “Lost in the Middle” study, published in 2024 by researchers from Stanford and other institutions, showed that models make better use of information at the beginning and end of a long text, and that performance drops noticeably when they need information from the middle (TACL). The study used the models of that time, and models have improved a lot with long texts since then. Still, I think the practical lesson holds. Instead of handing over a very long page, or dozens of pages at once, and saying “find what’s missing,” give it pages one at a time or section by section.
Anthropic’s guide to reducing hallucinations in Claude suggests a similar approach. For long documents, ask the model to first quote the relevant parts word for word and then base its analysis on those quotes; tell it to support each claim with a quote and to retract any claim it can’t support (Anthropic). In content audits the benefit is immediate. If the model says “there’s no service information on this page,” you can check that quickly; if it says “this paragraph is outdated,” you can see which paragraph it means.
Audits aren’t limited to individual pages. On a site with hundreds or thousands of pages, you can also use AI to classify the content inventory, putting each page under a label like “current,” “needs updating,” “merge” or “can be removed.” In the quarterly checks from Chapter 17, this saves a lot of time. Write the labeling rules yourself and ask the model to explain each label in one sentence. And don’t remove pages labeled “can be removed” without looking at their traffic and backlink data. The model can read a page’s content, but it can’t know how many visits and links that page brings to your site.
7. Technical SEO tasks
AI speeds up technical SEO too: regular expressions (regex) for Search Console filters, robots.txt drafts, redirect rules, structured data (JSON-LD) drafts, hreflang lists, small scripts that classify crawler output.
What these tasks have in common is that the result can be tested. A regex either works or it doesn’t. A robots.txt rule either blocks or it doesn’t. Don’t put any technical rule the model wrote into production without testing it.
One wrong line in robots.txt can close an important directory, or the whole site, to search engines and AI bots. The list of bots and the right rules were the subject of Chapter 9. Check the bot names the model suggests against official documentation as well; bot names change, and the model may suggest an outdated or nonexistent one.
Be careful with structured data too. Google’s guidance on generative AI content says that, along with AI-generated content, metadata such as titles, meta descriptions, structured data and image alt text should also be checked by hand before publishing. For structured data, it asks you to follow the general guidelines and the policies for the relevant features and to validate the markup (Google Search Central). A model can add a review rating or a price to the markup that isn’t on the page. That’s more than a mistake; it’s a policy violation risk.
8. The most common mistakes
We’ve covered the risks section by section. If you want them all in one place, here’s the list. How often they happen varies from model to model and version to version, but the types stay the same.
- Made-up numbers: search volume, click-through rate, backlink counts, traffic estimates. Unless the model is connected to real data, it guesses these.
- Made-up or wrong sources: a Google document that doesn’t exist, an announcement with the wrong date, a broken link. In Chapter 3 we saw that some tools in the Tow Center study produced links that didn’t exist.
- Outdated information. A model’s training data freezes at a certain date. Google’s policies, Search Console’s features and the names of AI bots may have changed since then. Many topics in this book changed in 2026.
- Overconfidence. The model states wrong and right things in the same tone. As the OpenAI study showed, models tend to guess rather than admit uncertainty.
- Losing context: missing information in the middle of a long conversation or a long document.
- Stretching the instruction. Tell it “improve this page” and the model may add claims, features or promises you never mentioned.
The most dangerous thing about these mistakes is that they look right. Plan verification as one of the steps of the work, not as a check tacked on at the end.
9. Rules for verification
These are the rules I suggest for the risks above:
- Data comes from the real source. Numbers come from Search Console, Analytics, your keyword tool or log files. The model processes data; it doesn’t produce it.
- The model is allowed to say “I don’t know.” Anthropic’s guide says that giving the model permission to admit uncertainty can significantly reduce false information. Add a line to your instructions like “If you’re not sure, or the data isn’t enough, say so clearly.”
- Every claim is tied to a source or a quote. If the model finds something missing on a page, it should show the relevant part; if it mentions a Google rule, it should give the link to the official documentation, and you should go to that link.
- The math is done in code or a formula. Don’t trust calculations the model does in its head.
- A sample gets checked. In grouping, classification and audits, review part of the results by hand.
- The same job is run twice. Anthropic’s guide also recommends running the same instruction several times and comparing the results; inconsistency is a warning sign. It’s the tool-side version of the variability we discussed in Chapter 3.
- Technical output gets tested. Regex, robots.txt, structured data and redirect rules are tried in a test environment or in validation tools.
- Final responsibility stays with a person. For a report going to a client, a page going live or a rule going into production, “the AI said so” isn’t an explanation.
At first glance these rules can look like they slow the work down. But the cost of a report built on wrong data, or of a wrong line in robots.txt, is far higher than the cost of these checks.
10. Client data and privacy
Agencies and in-house teams upload a lot of data to AI tools: Search Console exports, CRM lists, sales call notes, customer reviews. Some of it is a trade secret, and some of it is personal data.
I’m not giving legal advice here, but a few practical rules help. Read the data policy of the tool you use, and know whether the data you upload is used to train the model and how long it’s kept. For business use, prefer plans that make clear commitments on this. If you don’t need customers’ names, emails or phone numbers for the analysis, delete those columns before uploading. If you’re an agency, tell your client which tools you use to process their data. For work involving personal data, check your obligations under KVKK, Turkey’s personal data protection law, with your legal counsel.
11. Where AI fits on the team
In my view, AI adds the most value on an SEO team in preparation work: grouping raw lists, summarizing documents, drafting brief skeletons, doing the first pass of an audit. It also saves a lot of time on work that needs scale, like running the same check across hundreds of pages, classifying and labeling. And it’s useful as a second pair of eyes, reading a brief, report or piece of content a specialist prepared and looking for gaps.
Where it adds the least value is decisions. Which page to create, which task comes first, what to recommend to a client: these rest on business knowledge, client knowledge and accountability, none of which the model has.
As a team, collect the instructions that work in a shared library: a keyword clustering prompt, a page audit prompt, a brief template prompt. Next to each one, note which model it was tested with, which verification step it needs and its known weaknesses. Review the library as models change. It’s the team-level version of the continuous system from Chapter 17.
New specialists need extra attention. Someone who has never clustered keywords, audited a page or analyzed logs by hand will have a hard time noticing when the model is wrong. I think a new specialist should do these tasks by hand a few times first, then do them with AI and compare the two results. That way they learn the logic of the work and also learn to see where the model goes wrong. The ability to verify comes from having done the work yourself at least once.
12. Getting the speed from the right place
AI speeds up a large share of SEO work, but that speed only pays off when it’s used in the right places. Data should come from the real source, the model should do the language work, code should do the math, claims should be tied to quotes, and no technical output should go live without a test. With that in place, AI makes a good SEO specialist faster. Without it, it just makes a bad process wrong faster.
The last chapter turns to the most debated use of AI in SEO: producing content.
Checklist
| Check | Where to look | Why it matters |
|---|---|---|
| Numbers like search volume and backlinks aren’t taken from AI | The data source in reports | The model can make these numbers up |
| The keyword list comes from a real source | Search Console, keyword tool export | The model can produce plausible queries nobody searches for |
| Clusters are checked against search results | Results pages for sample queries from each group | Similar meaning isn’t similar intent |
| Calculations are done in code or with formulas | The code or spreadsheet used in the analysis | The model’s mental math can be wrong |
| A sample of results is checked by hand | Randomly selected rows | Errors often go unnoticed |
| Competitor analysis is based on actual page text | Competitor page links and quotes in the brief | The model can make up what competitors wrote |
| Audit findings are backed by quotes | Quotes in the model’s output | To quickly confirm a finding is correct |
| Technical rules don’t go live untested | robots.txt tester, Rich Results Test, regex tester | One wrong line can affect the whole site |
| Data uploaded to AI tools contains no personal data | File check before upload | Privacy and legal obligations |
| The team’s prompt library is up to date | Prompt list, last review date | Results change as models change |
Sources
- OpenAI: Why language models hallucinate (September 2025)
- Ahrefs: AI Can’t Replace SEO Tools, But It Can Use Them (October 30, 2025)
- Google Search Central: Optimizing your website for generative AI features on Google Search (last updated July 10, 2026)
- Google Search Central Blog: Streamline your Search Console analysis with the new AI-powered configuration (December 4, 2025)
- Liu et al.: Lost in the Middle: How Language Models Use Long Contexts, TACL (2024)
- Anthropic: Reduce hallucinations (accessed November 1, 2026)
- Google Search Central: Google Search’s guidance on using generative AI content on your website (last updated October 1, 2026)
- Nieman Lab: AI search engines fail to produce accurate citations in over 60% of tests (March 10, 2025)
Previous: Chapter 17, GEO as a Continuous System · Table of contents · Next: Chapter 19, Producing Content with AI