What does the model actually know before the product dresses it up? You can find out in five minutes without an SEO tool. Martin McGarry gave me this as his top tip for anyone learning SEO right now, and it's the kind of thing a developer runs once and never sees ChatGPT the same way again. Martin runs Search Assistance out of Leeds, twenty years into SEO with the first ten on the black hat side. Most of what follows is him. The disavow story is mine. Ask the raw API, then ask the chat product Here's the experiment in his words: "Anyone learning SEO right now, I've got a top tip, is to try the API. Do a little bit of learning. You can pop up Visual Studio, and you can access the API in your terminal. And just ask the raw API a question. So that's the OpenAI LLM, the Gemini LLM, whatever else you use. And just ask a raw question. What you get back is junk." That's it. No tools, no web search flag, no system prompt beyond the question. Something like this, with a question your actual customers ask: curl https://api.openai.com/v1/chat/completions \ -H "Authorization: Bearer $OPENAI_API_KEY" \ -H "Content-Type: application/json" \ -d '{"model":"gpt-4o","temperature":0, "messages":[{"role":"user","content":"Which precast concrete fence should I buy for a windy lot in Tennessee?"}]}' Save the answer. Then paste the identical question into ChatGPT or Gemini and save that answer too, along with every citation it shows you. Now diff them. "And then you realize that there's some background process augmenting the chat results. So when you use ChatGPT or Gemini, there's something else working in the background." Everything the chat product knew that the bare model didn't came from a fetch. Martin doesn't dress this up: "the standalone LLM on its own is rubbish, in my opinion. And there's definitely some, we know there's RAG in the background. OpenAI has been called Googling." You already knew a chat product is model plus retrieval. What you probably haven't done is measure the gap on your own money queries. That gap is the only part of the answer you can actually influence, and the citations tell you where it fetched from. Martin's version: "we know SEO is not dead first of all, because these LLMs are having to go out and get extra information from somewhere. So if you learn how that happens, you still learn where you're needed and you still learn where your site needs to be positioned for that RAG or that augmentation to happen." Three things that keep the experiment honest: Temperature 0 on the raw call, so the junk is the same junk twice and the delta you record is retrieval, not sampling noise. Date every sample. The chat products change what they fetch without telling you. Keep the key in an environment variable. The spreadsheet you hand a client is not the place for it. Your RSS feed might be the next llms.txt This is the idea Martin thinks nobody else has said yet, and you can act on it this afternoon. "I've not really heard anyone say we should be optimizing our RSS feeds or API." Everyone is arguing about llms.txt and markdown mirrors. But if part of the retrieval step moves server-side, the machine-readable outputs you already publish (/feed/, /wp-json/wp/v2/posts, your XML) are the surfaces a fetch is most likely to read. And most WordPress feeds are actually a mess: truncated excerpts, missing images, junk categories. "there's a lot of talk about .md files and llms.txt files at the minute and it may be simpler than that. Maybe we just all build RSS feeds" He's careful to call it a hunch. "Maybe I'm the first to go down that route. There'll be a whole raft of courses on it by next week on LinkedIn." So treat it as a hypothesis, not a result. But the cost of testing it is close to zero: Open your own /feed/ and read it the way a parser would. Is it full content or an excerpt? (In WordPress that's Settings, Reading, "For each post in a feed, include", or rss_use_excerpt in the options table.) Open /wp-json/wp/v2/posts?per_page=5 and check the content.rendered field isn't full of shortcodes that only your theme understands. Tail your access logs for feed and API hits from AI user agents. If something is reading it, you'll see it there before any dashboard tells you. I've been running a static markdown experiment on my own podcast site. Martin's point is that I may have been building a new door when the machine was already coming in through the one WordPress installed in 2005. The grace period is the hole the spam drives through Now the part that explains why a clean site falls off page one for no reason. Telegram link sellers have scaled an old trick, adding links to brands with their own anchor text advertising their services, to hundreds of thousands of sites. Google largely can't judge a page it hasn't seen ranking, so every new page gets a window: "I think the reason it fails and the reason the expired domains work is because there's a grace period where Google needs things in the SERPs to understand if it's what the user wants or what the user doesn't want." Inside that window the loop runs like a queue: "these spam sites can rank a page for two or three days. It gets tanked almost instantly, but there's another 10 waiting to be loaded. And what these spam links have done is made a system where Google is actually reassessing the organic listings that were already there." That last sentence is the one to read twice. The collateral damage isn't the spam ranking. It's that while Google decides, it re-evaluates the incumbents, and a clean site with a suddenly diluted anchor profile goes under a temporary link penalty it never earned. "you've got 20 sites that are under a temporary link penalty, your expired domain just slots in instantly." I had this happen to a door manufacturer. Someone was standing up twenty domains a month on rotated themes and the same CMS content library, pointing junk anchors and image hotlinks at every site in the top 10. Our fix wasn't clever: "we had to develop a hygiene program of an aggressive disavow and check every week." They launched ten more, we disavowed ten more, and the rankings that had tanked climbed back. If you take one operational habit from this piece, make it a weekly job that pulls new referring domains and flags the batch that launched together. Perspective is the thing the fetch can't return Ask Martin what a company selling hard goods should do for AI search and he doesn't say schema. "You have a perspective on the product that you sell. And your opinion and your perspective is going to be your currency in the future." The retrieval step can pull size, scale, colour and every spec in seconds. What it can't pull is a point of view that isn't on the page yet. His standing example: "Who buys a flip-flop for the rain?" Everyone assumes it's summer clothing; someone in a tropical country has a different answer, and that angle only shows up down in the granular buying personas for one product. "AI can't reproduce perspective or opinion." For a developer that turns the content problem into a data-modelling one. You don't need a general product page. You need a persona-by-use-case matrix, and a page (or a feed entry) for each cell that says something only you would say. So, three things to run this week. What does the raw model say about your best-selling product, and what did the chat product have to fetch to say more? What does your /feed/ actually look like to something that isn't a browser? And which of your pages says something about the product that only you could say? This is a developer's cut of the full interview. The complete recap, with Martin's read on the Helpful Content Update as entity-graph profiling and his iGaming war stories, is at unscriptedseo.com/martin-mcgarry. The step-by-step version of the raw API experiment is an SEO SOP on SEO Arcade.