# safianov.com — llms-full.txt > Full text of every published article and case study on the site, in one file. Auto-generated; updates the moment new content is published. --- # Five AI Agent Protocols in 2026: What to Ship Now and What Can Wait - Type: blog post - URL: https://safianov.com/blog/five-ai-agent-protocols-in-2026-what-to-ship-now-and-what-can-wait/ - Summary: llms.txt, OKF, ARD, MCP, UCP — a guide to the protocols deciding whether an AI agent finds you, connects to your data, and buys from you. Simple to complex, with a table and recommendations. Over the past year, AI systems picked up not one new way to work with websites but five — and they solve different problems. Some just help a model read your site faster. Others let an agent find the right tool among thousands. A few give an agent the authority to act — up to paying for an order on your behalf. Confusing them means spending months on the wrong thing. ## What to know before implementing anything GEO/AEO used to boil down to one question: can AI read and cite your page (I have a separate breakdown of the "persistent agentic search" patent — search that doesn't end at the results page, for more on that). The five protocols below extend that question into three new things AI can do: discover the right resource among many sites, connect directly to your data and tools, and transact on a user's behalf without leaving the chat. They don't replace classic SEO or Schema.org markup — they sit on top of that foundation. They're not equally mature either: some are v0.1 community initiatives, others are backed by a consortium of Google, Microsoft, Anthropic and dozens more. Below, from simplest to most complex, with an honest read on what's actually worth doing right now. ## llms.txt In plain terms: a file at the root of your site that tells AI, in two sentences, what the site is and where to look next — a table of contents, but for robots. Formally, an open initiative proposed in September 2024 by Jeremy Howard (creator of fast.ai) that standardizes what a site hands language models at inference time. Like robots.txt tells search crawlers what they may crawl, /llms.txt gives AI agents, chatbots and IDE assistants (Cursor, Windsurf, Copilot) clean, structured context about a site. ### How it works The protocol rests on two ideas. First, a plain Markdown file, /llms.txt, at the site root: a short project description and a list of links to sections useful for AI. Second, "clean" Markdown versions of pages at the same URL with .md appended (e.g. /docs/intro.md) — no header, footer, ads, or JS. ### How a site owner can use it Place llms.txt at the root, describe the project's essence, and link out to documentation in a structured way. Set up serving "clean" .md versions of pages. CLI tools exist (e.g. llms_txt2ctx) that walk the links in llms.txt and bundle them into one context file — visitors can copy the whole thing straight into ChatGPT or Claude. ### Pros and cons - For: saves the AI's context window (no tokens burned on HTML wrapping), lowers hallucination risk for assistants, needs no database or API — just text files, already supported by Cursor and Windsurf. - Against: needs manual upkeep to stay current, unsuited to fast-changing data, still not an official W3C standard — a community initiative. I've implemented both layers of the protocol on this very site — see it live: /llms.txt, the site map, and /llms-full.txt, the full text of everything published in one file, both generated automatically the moment new content goes live. ## Open Knowledge Format (OKF) In plain terms: a folder of ordinary text files where fields like "title" and "type" always sit in the same place — so AI, not just a human, immediately understands the structure of your knowledge. Formally, an open, vendor-neutral specification formalizing the "LLM-wiki" pattern: a representation of metadata, context and curated knowledge readable by both humans and AI agents. It solves context fragmentation — when important knowledge is scattered across databases, Notion, code comments, and engineers' heads. ### How it works OKF is deliberately simple: no new runtimes, no mandatory SDKs. The document package has three parts: plain Markdown (.md), ordinary files (a .tar.gz archive, a Git repo, or a mounted filesystem), and YAML frontmatter — a small set of standardized fields (type, title, description, resource, tags, timestamp) at the top of each file. If you've used Obsidian, Notion, Hugo, or written a CLAUDE.md/AGENTS.md, the structure will look familiar — OKF just standardizes the field names. ### How a site owner can use it Create a public directory (or open Git repo) with OKF-formatted files — precise, structured context about services, pricing, APIs or products, instead of AI guessing from unstructured HTML. The same files can feed your own support chatbot, which answers without hallucinating because it has a clear metadata structure to work from. If documentation already lives in Git, a CI/CD pipeline can auto-update OKF files whenever services change. ### Pros and cons - For: remarkably easy to adopt (if you can write Markdown and YAML, you already know OKF), human-readable unlike JSON-LD or RDF graphs, Git-friendly (history, pull requests, rollbacks), designed from the start to be chunked cleanly for RAG. - Against: early stage (v0.1, introduced mid-2026), needs manual upkeep early on, access control has to be configured separately at the hosting level — no built-in security, unsuited to real-time data. ## Agentic Resource Discovery (ARD) In plain terms: a directory of your AI tools and APIs that an agent can ask "who has what I need right now?" and get a precise address back, instead of sifting through thousands of options itself. Formally, an open, decentralized protocol for discovering "agentic resources": specialized AI agents, MCP servers, plugins, APIs, tools, canvases, or workflows. It's being developed by a consortium including Microsoft, Google, Hugging Face, GoDaddy, Cisco, Databricks, GitHub, Nvidia, Salesforce, ServiceNow, and Snowflake, under the Apache 2.0 license. It solves a specific problem: an AI assistant can't hold thousands of API schemas in its context window at once, and ARD lets it ask, in real time, what tools are available for a given task. ### How it works ARD operates at the before-invocation stage — the actual tool call happens over its own native mechanism (MCP or REST, for instance). Five steps: a developer describes a resource per the AI Catalog standard; services collect these descriptions into collections (public, corporate, or niche); a standardized API sits on top of the collection — a mandatory POST /search for semantic search by natural-language task description, plus optional POST /explore and GET /agents; an AI client hits the search endpoint, finds a matching tool, and offers it to the user. ### How a site owner can use it Three steps. First, create an ai-catalog.json manifest: a static JSON file describing your resources, including a representativeQueries field — 2–5 natural-language example queries that semantic search will match your tool against. Second, host it at /.well-known/ai-catalog.json, with an Access-Control-Allow-Origin: * header so crawlers can read it. Third, optional — if your site is on GitHub Pages or S3 and you can't place a .well-known folder, add a _catalog._agents.yourdomain.com DNS TXT record pointing to the file instead. ### Pros and cons - For: a new visibility channel — your services get surfaced to users directly inside ChatGPT, Claude, or Copilot at the moment of a relevant task; saves AI context; decentralized — no single monopoly app store; backed by Google, Microsoft, and Hugging Face; basic participation needs just one static file. - Against: early stage (v0.1); a trust problem — anyone can publish a manifest, so discovery services will need to moderate spam and malicious entries; publishing the file doesn't guarantee indexing or ranking. ## Model Context Protocol (MCP) In plain terms: a universal adapter that lets any AI model connect to your data and tools the same way — instead of a separate plugin for every chatbot. Its creator, Anthropic (the company behind Claude), calls it "a USB-C port for AI applications": just as USB-C standardized connecting physical devices, MCP standardizes connecting models to external data, tools, and workflows. OpenAI, Cursor, and VS Code, among others, support it too. ### How it works MCP is built on a client-server architecture over JSON-RPC 2.0. Three parts: AI clients (Claude Desktop, ChatGPT, Cursor, VS Code) that initiate the connection; MCP servers — lightweight programs in Python, Node.js, or Go, local or remote, that "wrap" a specific database, API, or set of files; and data sources themselves — files, databases (PostgreSQL, SQLite), external APIs (GitHub, Slack, Google Calendar). A server hands the client three kinds of capabilities: resources (read-only data — DB schemas, logs, docs), tools (executable functions like "send a Slack message," called strictly with user consent), and prompts (ready-made system-prompt scenarios). ### How a site owner can use it Instead of separate plugins for ChatGPT, Claude, and a Cursor extension — one MCP server for your API: any developer connects it to their AI assistant and works with your service (analytics, orders, balance) right from the chat. If your site gives developers tools (cloud hosting, a database), an MCP server lets them manage infrastructure from Cursor or VS Code via AI. Internally, MCP servers can unify Notion, Jira, your site's databases, and Google Drive into one secure corporate search, without retraining any model. ### Pros and cons - For: "write once, use everywhere" — one server runs unchanged in Claude, ChatGPT, and Cursor; security — the model never touches your database directly, only the server's allowed commands, and critical actions need user confirmation; flexible transport (local Stdio or remote SSE); a growing public registry of ready-made servers for GitHub, Postgres, Slack, Google Drive. - Against: requires writing and continuously hosting a full server application, not just a text file; end users have to manually configure it in their AI client; the layered architecture (model → client → JSON-RPC → server → API) adds latency versus a direct API call. ## Universal Commerce Protocol (UCP) In plain terms: a protocol that lets an AI assistant not just recommend a product but actually buy it on your behalf, without leaving the chat. Formally, an open standard letting AI agents complete transactions — purchases, bookings — on a user's behalf directly inside the AI interface, skipping the site visit entirely. It's already expanding beyond classic retail into food service and lodging. ### How it works UCP ties together three parties: the AI surface (the client), the merchant, and payment/identity services. It uses a merchant's existing product feeds in Google Merchant Center to find and surface products the moment a user expresses purchase intent inside AI search, and builds a secure, transparent transaction trail between the merchant, credential providers, and payment gateways. Two checkout options: native checkout, where the purchase logic lives entirely inside Gemini or AI Search's interface, giving agents maximum autonomy; and embedded checkout, an optional path for approved major brands with complex purchase flows, handled through the merchant's own secured iframe inside the AI interface. ### How a site owner can use it Three steps for a store, food-delivery service, or hotel owner: make sure a Google Merchant Center account is set up and product data is current; apply to the program on Google's official site for your vertical (Retail, Lodging, or Food) — as of mid-2026 the protocol is still expanding by application; study the open UCP spec on GitHub and configure your payment and order systems to accept UCP-formatted requests. ### Pros and cons - For: zero-click purchases — no site visit, no re-registering, no re-entering a card, which sharply cuts cart abandonment; the merchant stays Merchant of Record — keeps customer data and manages fulfillment; ready-made access to Gemini and Google Search's AI Mode audience without building your own AI app; Google's roadmap includes multi-cart purchases, loyalty program linking, and post-purchase support via AI. - Against: closed testing and a waitlist, not open access out of the box; native checkout is technically demanding, including handling transactions initiated by external AI systems; dependence on Google's ecosystem as the key beneficiary; native checkout locks you into Google's standard interface, making upsell and your own brand design harder to show. ## Comparison table Protocol What it does Implementation effort Backed by Stage llms.txt Hands AI clean context about the site One text file Community (Jeremy Howard) Mature, widely supported OKF Standardizes a site's knowledge base Files + YAML frontmatter Community Early (v0.1) ARD Helps agents discover your tool/API One JSON manifest Microsoft, Google, Hugging Face, et al. Early (v0.1) MCP Connects a model to your data and tools Server application Anthropic, OpenAI, et al. Mature, growing registry UCP Lets an agent buy on your behalf Payments + Merchant Center integration Google Closed testing ## What to do: recommendations Ship now: llms.txt — it's literally one file, it can't break anything, and I can see on my own site that it actually works. If you run a SaaS, docs, or an API with knowledge scattered across a dozen places, add OKF alongside it — also just files, but it solves context fragmentation, which otherwise won't fix itself. Prepare and pilot: ARD, if you already have an API or MCP server worth making discoverable — a one-JSON-file manifest doesn't need major investment, and the standard is backed by too large a consortium to just disappear. MCP, if your site or service offers something people genuinely want to manage from a chat (analytics, orders, infrastructure): this is an engineering project, not a one-off edit, but it has both Anthropic and OpenAI behind it at once — a rare case for competitors to agree on anything. No need to rush yet: UCP — unless you're in retail, food delivery, or lodging with a Google Merchant Center account already running, this is premature for you: the protocol is at the waitlist stage, and spending resources on it now means preparing for a door that may or may not open within the year. Check back quarterly; don't reassign your dev team over it just yet. --- # Google's Former Chief Scientist Just Described Orakul Architecture - Type: blog post - URL: https://safianov.com/blog/googles-former-chief-scientist-just-described-oracles-architecture/ - Summary: Orakul is a platform for a team of AI agents that installs on the client's own server and takes over part of the work usually done by hired staff: sales, support, paperwork. Jeff Dean, Google's former Chief Scientist, said in a recent Y Combinator interview what actually decides the fate of AI products — not the model, but the tools, memory, and orchestration built around it. We didn't rewrite Orakul after this interview. That architecture was already there. Google just signed off on the blueprint we'd already built the house from. ## What Jeff Dean Actually Said Dean isn't a blogger or a marketer — he's Google's former Chief Scientist. In an interview with Y Combinator's Diana Hu, he made a point that cuts against the industry's favorite pitch of the last two years: which AI model you use matters less and less. Progress used to be measured by model size and training data volume. Today it's measured by what's built around the model. Three points from the interview (Search Engine Journal, by Roger Montti): - The model is one node in a system, not the whole system. Worrying about which foundation model to use distracts from what matters — the ecosystem of tools around it: search, APIs, knowledge bases. - Context beats training data. Training data, in Dean's words, is a "soup of trillions of tokens" dissolved across billions of parameters. Clean, task-specific context delivered at the moment of the task produces fewer hallucinations and sharper answers than a bigger model does. - The future belongs to multi-agent orchestration. A system needs to break a complex problem into subtasks, try different approaches, pick the best result, and keep a history of past decisions so it doesn't solve the same problem twice. The conclusion lands hard on a market that's spent two years selling "our model is bigger." The winners won't be whoever has the newest model — they'll be whoever built the best infrastructure around one. ## How Orakul Was Already Built — Before This Interview Here's each of Dean's points, matched to what's already running in the product. "The model is one node, not the whole system." In Orakul, the model is a setting on an individual agent, not the foundation of the platform. The account owner assigns a model to each specialist manually and can swap it in seconds without touching the rest of the system — Gemini for one agent, Claude for another, GPT for a third. The platform isn't locked to a single provider. "Context beats training data." Orakul has a RAG-backed knowledge base — an agent answers from documents the owner actually loaded in, not from a "soup of trillions of tokens": price lists, procedures, the message history with a specific client. That's the clean, task-specific context Dean is describing. "The future is multi-agent orchestration." For Orakul  that isn't the future — it's day one. When a task comes in, the classifier inside the system doesn't try to answer it itself — it routes it to the right specialist on the team: sales, support, accounting. Separately, a scheduler tracks deadlines and sends reminders when a task stalls, so nothing gets lost. That's the applied version of the memory Dean is talking about: not one brilliant answer from one model, but a system that doesn't forget. While the market spent two years arguing over which model would "win," Orakul never placed that bet in the first place. It bet on the team. ## Why This Isn't a Coincidence When we designed Orakul, the starting point wasn't "which model is smartest" — it was the plain question a small service-business owner actually asks: "I don't need a genius, I need a department that doesn't sleep and doesn't quit." A department, by definition, isn't one employee — it's several, each with a role, access to the right documents, and a memory of what happened yesterday. What Dean calls "context engineering" and "multi-agent orchestration" in 2026, a business owner just calls "a team that's actually organized." Orakul didn't predict Dean's interview. It was built to his blueprint before he ever put a name on it in public. ## How to Judge Any AI Tool By This Same Standard Now that Google has set the frame, you can use it to evaluate any AI tool being pitched to you, not just Orakul: - Can you swap the model without rebuilding the system, or are you locked in? No choice means you're paying for one model, not an architecture. - Does it have its own knowledge base, or does it only answer from general training data? Without context, answers are vague and go stale fast. - Does it solve tasks alone, or route them across role-based specialists? One agent doing everything is a bottleneck, not a team. - Does it remember what happened yesterday, or does every conversation start from zero? Without memory of deadlines and task history, it re-solves the same problem over and over. If most of your answers are "no," you're looking at a wrapper around one model, not a system. ## What This Means For You If you're evaluating an AI tool for your business and you're still comparing models on benchmarks, you're comparing the wrong thing. The question isn't "GPT-5 or Gemini 3" — it's whether there are tools, memory, and a team of agents around the model that actually see a task through. Orakul has answered that question from day one: it installs on your own server, works with any provider, and swaps models under the hood in seconds — because the architecture was never built around a single model to begin with. Want to see it work on your own task? Message us on Telegram: t.me/trafficnavigator_bot. Source: Roger Montti, "Google's Ex-AI Chief Jeff Dean Explains How To Improve Context Engineering" — Search Engine Journal, August 2026. --- # Yesterday: Keywords. Today: LSI. Tomorrow: Intent? - Type: blog post - URL: https://safianov.com/blog/yesterday-keywords-today-meaning-tomorrow-intent/ - Summary: Google patented search that doesn't end at the results page: the session waits in the background until an answer exists. See what it means for your content. Google is preparing a shift after which a search session will stop ending on the results page. Instead of "ask — get an answer right now," search that keeps working in the background until it finds a satisfying answer, then delivers it later on its own. This shift already has a patent number, a filing date, and a named inventor — this isn't futurology or someone's conference slide, it's registered engineering. If this blog has a slogan, it was written with exactly this kind of article in mind: "status: indexing the future of search." Here's what that looks like in practice. ## A patent, not a forecast On October 7, 2025, the US Patent Office granted Google LLC patent US12437012B2, "Autonomously providing search results post-facto, including in assistant context" — filed April 29, 2024, inventor Xi Wu. Its status as of this writing is Active, in force until November 18, 2036: this isn't a pending application, it's a granted, live patent. The mechanism is described in four steps: - The user submits a query — the system needs a specific fact, not a general answer. - The system searches and ranks resources, then checks whether any is flagged as an "authoritative answer" satisfying its quality criteria. - If none does, the system stores metadata linking the query to the user, and a monitoring engine periodically rechecks sources for a resource that now qualifies. - Once a qualifying resource is found, the content is delivered "post-facto" — via push notification, spoken aloud, or folded directly into a separate assistant conversation unrelated to the original query — without requiring the user to resubmit the query. The patent's diagram: a four-step loop that doesn't close until an answer meeting the criteria is found ## This isn't just a patent lawyer talking — Google itself confirms it At Google I/O, Google Search's own head, Liz Reid, said in an interview that the company is actively moving toward exactly this — "Agentic Search." She gave examples of routine tasks people currently have to manually recheck: a new exhibit opening at a museum, a local event schedule, a specific stock price swing. Instead of constant manual monitoring, a user will be able to hand the task to a search agent, which sends a notification itself once the right trigger fires. Telling: the interviewer's own framing of the question — asking how the user experience is "all set to change... after this IO," meaning right after that very conference, not someday. Reid doesn't correct that framing or push it into the future tense — she answers: "this is really the era of agentic search." Present tense. Already here, not coming. The "until November 18, 2036" date above is the patent's legal protection window, not a release timeline: a patent runs for thirty-odd years by default, regardless of whether the feature ships in a month or in ten years. Going by Reid's own words, 2036 isn't the year to wait for. ## What actually changes in the nature of search Previously, a search session ended the moment results were returned — whether the answer satisfied or not made no difference, the session was closed either way. Now search becomes a background task: the session stays active, continuously matching the original query against new data entering the web, until an exact answer is found. The difference isn't in the interface — it's that a query is no longer a one-time act, but an open, waiting task. ## What this means for anyone writing for search For SEO this creates conditions that didn't exist before. It now makes sense to optimize content for queries that have no instant answer right now — because the moment one exists, the persistent-search system will find and deliver your material on its own, ahead of anyone who writes about it later. Practical consequences: - Publishing speed becomes a trigger, not just a nice-to-have. The system monitors for updated data appearing — whoever closes the open question first gets delivered straight into an already-waiting session, instead of fighting for a click on a fresh results page. - Markup that flags a fact as an "authoritative answer" matters more than a page's overall SEO weight. The system looks for a specific field in the knowledge graph, not the page as a whole — structured, unambiguously stated facts get priority. - It's worth writing content for questions that don't have an answer yet. A page that already describes what will become known, and when, is a candidate to become exactly the "criteria-satisfying" source once the information appears. ## Toolkit: from hindsight to forecast We used to research keywords with KeyCollector, Google's own suggestions, Ahrefs — tools that look backward, at demand that has already happened. Today we cluster those queries into meanings — still retrospective, just one level of abstraction up. But how do you forecast demand for something that hasn't happened yet? What follows is my hypothesis, not a fact — I'm putting it up for discussion. If search really is becoming persistent and rewards whoever closes an unanswered question first, clustering past queries isn't enough anymore — you need a tool that speculates about future demand. Technically, that's an agent run at a deliberately cranked-up generation temperature, fed Google Trends, trying to guess what users in your niche will be asking a month from now — not pattern-matching the past, but controlled extrapolation. My bet: tools like this will become expensive and sought-after soon — precisely because what you're paying for isn't the data, it's being early: the exact advantage this whole article is about. Seriously enough that I'm considering building this tool myself. This is the same principle behind GEO and AEO generally: what matters isn't being indexed, it's whether a machine — a search agent, a language model, a knowledge-graph monitor — can pull the exact fact it's waiting for off your page. If you want to check how ready your site is for this today, the free audit shows it in a couple of minutes. --- # Google Patented Trust: The Content Brief That Survives the Next Core Update - Type: blog post - URL: https://safianov.com/blog/google-patented-trust-the-content-brief-that-survives-the-next-core-update/ - Summary: Google's patent computes Author Score as math. Here's what that means for a copywriter brief — rewritten live, for a real published page. Google patented trust. Not figuratively — literally: a patent covered in Harry Clarkson-Bennett's newsletter describes Author Score and Evergreen Score as computable metrics, not guideline suggestions for quality raters. If your copywriter brief still reads "rewrite the top 3 in your own words", it's mathematically obsolete, not just outdated. ## A top-3 compilation no longer ranks In How to Write Great Content for Search (that delivers), Clarkson-Bennett names the diagnosis: AI made compilation free, so only content with genuine Information Gain survives. Three consequences follow, and they apply to every SEO practitioner today. Behavioral signals decide. Dry copy sends readers pogo-sticking back to the results page — a negative signal to the algorithm. The engaging side of the "4 E" formula holds dwell time and scroll depth, exactly what Google measures. E-E-A-T is a shield, not a checklist. First-hand experience and expertise protect against demotion more than any technical fix. A first-person account and original research prove the text was written by a human for humans, not by a link-selling site network. The first traffic spike is a ranking factor. Discover and core search both watch social and newsletter traffic in the first hours after publishing. Distribution is no longer "after publishing" — it's part of publishing. ## What that looks like as a formula Clarkson-Bennett's second piece, Google's Evergreen Article Scoring System Uncovered, breaks the patent down in detail. Five findings that change the brief itself: What the patent found What it means for the brief A hard Commercial Score: aggressive CTAs and pricing in an informational article exclude it from the "in-depth article" index An informational blog stays informational; the sell lives elsewhere, handled tastefully A one-time link spike reads as manipulation; Evergreen Score grows from steady velocity Link building is a multi-year process, not a launch-day burst Subfolder Authority: a new article in a strong section gets a starting ranking bonus Publishing needs a clear hierarchy of sections, not content scattered across the site Author Score is a patented, actually computed factor Author markup, an on-site profile and external mentions aren't "nice to have" — they're a ranking factor The algorithm tells a deep semantic block apart from a shallow rewrite by text structure The brief needs complete semantic blocks that cover the topic fully, not a keyword list ## Google confirms: SEO is going multimodal In March 2025, Google's VP of Ads and Commerce Vidhya Srinivasan described the shift toward visual and multimodal search. For content strategy, that means: - Search via Google Lens and Circle to Search demands top-quality images with alt attributes and markup — page text is no longer the only entry point into the results. - AI Overviews capture the most valuable commercial audience — and only cite structured answers: comparison tables, lists, expert content that's easy to lift whole. - E-commerce SEO has merged with the Merchant Center feed: without full Product markup and every attribute, AI can't match your product to the query. - A "stable top 10" is dissolving under hyper-personalization — the focus shifts to topical authority and brand recognition in independent sources. - Video is becoming a mandatory entry point: YouTube is integrating into the buying journey alongside text. ## In practice: a brief for a real page Let's work an actual published page instead of an abstraction — Thanksgiving Music Classroom Activities on anastasiya.studio, my wife's store. Yes, the same site where we built the author entity and earned AI citations — identity signals and the depth of one specific article solve different problems, and this page shows what's still left to fix at the content level. Weaknesses against all five patent findings: - Thin content. Five activities are described at surface level, with no differentiation scenarios for different grades — exactly what the patent flags as a rewrite signature rather than depth. - Generic tone. "Wonderful way to teach", "ideal activity" — vague praise with no authorial voice and no single real classroom moment. - Zero E-E-A-T. No author credentials, no teacher testimonial, no proof the activities were actually run in a classroom. - Obvious keyword targeting. "Thanksgiving Music Worksheet" repeats mechanically across tags and product titles — easy to read as optimized for a robot, not a person. - Commercial Score risk. Five product bundles and a "get one free" block sit right under the text — the information/sell balance needs to become a clean, native integration. What follows isn't a shortened example — it's the actual rewrite brief, exactly as I'd hand it to a copywriter for this specific page. ### Rewrite brief: Thanksgiving Music Classroom Activities Page goal: an informational article for music teachers that also leads, natively, into five product bundles — with no pressure on the reader inside the body text. Target reader: a K-5 music teacher looking for ready-made Thanksgiving lesson ideas; secondary audience — Pre-K teachers. 1. Structure and length. Keep the H1. Before the list of activities, add a 60-80 word intro paragraph: why these five, and what ties them together (there is currently no intro paragraph carrying the author's own point of view at all). Each of the five activities gets a 150-200 word block (currently 60-80): description, step-by-step execution, expected outcome. 2. First-hand experience is mandatory in every block, not one general chunk up top. Each activity needs its own real classroom moment: how it actually went, what the kids said, what had to change mid-lesson. Not "a wonderful way to teach" — instead: "when we played freeze dance over the song's quiet part, half the class froze at the wrong beat, so we added a counted-out warning for the first three rounds." Without this, the block stays exactly the "generic tone" the patent distinguishes from real experience. 3. Age differentiation. Each activity gets its own "How to adapt it" line: one sentence for K-2, one for grades 3-5. The patent specifically reads this kind of detail as a depth signal, not a shallow rewrite. 4. Keywords — only from real queries. Before writing: pull every query this page already ranks for from Google Search Console (Performance → Pages → this page → Queries). Weave the actual phrasing of those questions into the text — not as a keyword list tacked onto a paragraph, but dissolved into the explanation. Check specifically whether "Thanksgiving Music Worksheet" repeats mechanically three times in a row — it currently does, and it's the most obvious tell of optimizing for a robot. 5. Meta description — using the method from "How to Write a Meta Description That Google Will Use": one question the whole page answers → a short answer → reworded as a standalone description → weave in the GSC queries → fit it into 157 characters with the substance in the first 120 → one imperative verb. 6. Image alt text. Each activity gets a photo or illustration with a substantive alt (not "thanksgiving music activity" — instead "kids doing freeze dance during the slow part of a song in music class") — in line with Google's shift toward visual search covered earlier in this same article. 7. E-E-A-T. Byline the article with the author's name linking to an About page with credentials. If you can get one, add a short testimonial from another teacher who used the material, naming them and their school (or at least their state). 8. Commercial balance. No product names as section headings, no CTAs inside the instructional paragraphs. The five product bundles live in one clearly separated block after the text, with nothing woven into the narrative. 9. Ending. Instead of a buy prompt, one practical takeaway: what the teacher can do this Monday morning, using one idea from the article without buying the bundle. The results of this brief — Google Search Console screenshots before and after, ranking changes, and an AI Overviews citation if it lands — go in a separate piece I'll fill in as the rewrite ships: "Rewriting the Thanksgiving Music Activities Page: What Happened." ## The takeaway Three sources — a practitioner's newsletter, a Google patent, and a VP's own statement — converge on one point: content is now scored as a system of identity, behavior and structure signals, not as text optimized for keywords. Compiling someone else's results page is detected by the algorithm and fails. First-hand experience, steady distribution and author markup are counted — and that is exactly the part no model can generate without you. --- # Rewriting the Thanksgiving Music Activities Page: What Happened - Type: blog post - URL: https://safianov.com/blog/rewriting-the-thanksgiving-music-activities-page-what-happened/ - Summary: Follow-up to the Author Score piece: the page has been rewritten per the brief. Before/after GSC screenshots, rankings and citations land here. Work in progress: the Thanksgiving Music Classroom Activities page is being rewritten per the brief from "Google Patented Trust". Before/after Google Search Console screenshots, ranking changes for target queries, and — if it lands — an AI Overviews citation will go here. --- # Where to Find an E-E-A-T Expert: I Built One — and Google Believed It in Two Months - Type: blog post - URL: https://safianov.com/blog/where-to-find-an-e-e-a-t-expert-i-built-one-and-google-believed-it-in-two-months/ - Summary: A virtual expert backed by real practice: within two months Google AI answered by his name. The method, the rhythm and the platforms — repeat it yourself. I created an expert who does not exist. He has a name, an author page, profiles and publications — but no passport. Two months in, Google's AI Overviews started answering a query for his name with a detailed profile: who he is and what he specialises in. The algorithm recognised him as a niche specialist. Below is the whole method: why it is legitimate, how it works technically, and the publishing rhythm that made it take exactly two months. ## Your business's best expert is you E-E-A-T rests on expertise, and its primary carrier is not a hired influencer — it is the business owner or a practising employee: nobody knows the processes, the cost of mistakes and the niche's fine print like you do. The problem is elsewhere: Google cannot read minds. If you have never published under your own name, your expertise does not exist for the algorithm. And many people don't want publicity — modesty, NDAs, safety. ## A pen name is legitimate. A fake is not Here is the line worth drawing in bold. Publishing under a pen name is a centuries-old practice — from literary pseudonyms to Nicolas Bourbaki, the "virtual mathematician" under whose name a collective of real scientists published fundamental work for decades. The key condition: real practice stands behind the name. The virtual expert in my experiment is a real practising employee of the company — under a different name. The opposite case — an invented "expert" with nothing behind him but a text generator — is exactly what Google burns out with its updates against scaled content abuse. One more caveat: do not build virtual experts in YMYL niches (medicine, finance, law) — the cost of error is different there, and the scrutiny is harsher. ## Step 1. The expert's digital office on your site - An author page — a business card on the site: biography, professional track, achievements, certificates. This is the entity's "home" that every other signal will point to. - Authorship on every article — an active link to the author page from each post. - Person markup — a schema.org node with name, title, credentials; articles link to it via the author property of Article/BlogPosting. - sameAs is the glue. Add every external profile from step 2 and the catalogue below into the Person node's sameAs array. This is the thread that stitches scattered mentions into one entity — without it the search engine sees a dozen namesakes. For a live example, inspect this site's markup: the Person here links profiles, credentials and projects. ## Step 2. Teaching the LLMs: external authority and Wikidata AI search — SearchGPT, Perplexity, Gemini — builds answers on entity mentions in sources it trusts. An entity that lives only on its own site is semi-transparent to them. Two moves: - One name everywhere. Identical spelling, one photo, one wording of the specialisation across all platforms — the algorithm needs something to stitch by. - Wikidata entities — a Person for the author and, where applicable, one for the project. Wikidata is the reference knowledge graph for most LLMs; an entry there turns "some author" into a verifiable node of the graph. In the anastasiya.studio case this was the step that moved the needle: zero-click mentions and direct citations. ## The experiment: two months to recognition Now the part that matters — a reproducible rhythm. No magic, only regularity: Rhythm Actions Once, at the start Author page + Person markup with sameAs to all profiles; an About.me card; Wikidata entities Daily (workdays) One blog article; announcements on X and LinkedIn; a rewrite of the article on Medium Weekly A Substack issue; a Prezi presentation based on the week's best article After two months of this rhythm, a Google AI Overviews query for the virtual expert's first and last name returns a detailed answer: who he is and what his expertise covers. The algorithm officially treats him as a niche specialist. A query for the name — Google AI replies with a detailed profile: the entity is recognised And the consequence the whole thing was built for: before the experiment the site had almost no informational traffic. From the moment the expert was "recognised", articles under his byline entered the rankings — and traffic jumped. GSC: informational traffic before and after ## Step 3. The platform catalogue — and what each one is for Platforms are not interchangeable: each plays a role in the structure. Three platforms with regular publishing beat fourteen with one post each. Platform The signal it provides About.me The entity's "home" outside your site: a concise card that indexes well Medium An expert blog on a domain with top-tier authority X (Twitter) Fast indexing of threads, presence in niche discussions LinkedIn Articles Long-form in a professional context + a live network Substack A newsletter with an open archive — regularity as a signal Prezi / Slideshare Presentations and PDFs — visual knowledge sources LLMs readily ingest ## Today's checklist - Create an author page and set authorship on every article. - Ship Person markup and start collecting sameAs. - Open About.me and profiles on 2–3 catalogue platforms — no more than you can feed regularly. - Create Wikidata entries: the author and the project. - Set the rhythm: an article a day on the blog, a rewrite on Medium, announcements on socials, Substack and a presentation weekly. - A month in, query the name in AI search — and run the free audit: it shows whether AI systems can see your author. E-E-A-T is built not on bought diplomas but on systematic, machine-readable proof of the author–practice–business link. The experiment shows the algorithms are teachable — and two months of discipline is enough. --- # How to Write a Meta Description That Google Will Use - Type: blog post - URL: https://safianov.com/blog/how-to-write-a-meta-description-that-google-will-use/ - Summary: Google now builds snippets on the fly — CTR drops follow. The data-nosnippet trap and a recipe for a meta description Google will use: check your pages. Since late April 2026, organic CTR on two of my projects has dropped by more than half — in sync, to the day, with Google's snippet policy update. Worse: the most obvious "cure", the data-nosnippet attribute, nearly made things worse — it cuts the page out of ChatGPT and Copilot too. Here is what happened and how to take back control of your snippet. ## What changed in April Google updated its snippet documentation. The key quote: Search result descriptions are created automatically and reflect the content from your page that most closely matches the search query. In other words, users will see different descriptions depending on the words or phrases they used in the query. The snippet is now assembled on the fly for every query. In practice that often means loosely connected phrases pulled from different parts of the page. E-commerce got hit hardest: product descriptions there are traditionally generated as "product name + CTA", and the algorithm simply has nothing coherent to assemble from. A project under NDA (can't name it — the graph speaks for itself): organic clicks fall the very day the update lands, in late April anastasiya.studio: same picture, same dates. Two independent projects — coincidence ruled out ## The data-nosnippet trap The first idea that comes to mind: if Google butchers your page text, forbid it — wrap the content in
. I almost did. It would have been a worse mistake than the CTR drop itself: since October 2025 Bing honours the attribute too — and Copilot and ChatGPT run on Bing's index. Hide your text from Google snippets and you hide it from the language models at the same time. The cure is worse than the disease: the page vanishes from AI answers entirely. ## Is writing meta descriptions even worth it? Google's John Mueller, answering "Meta descriptions pointless and useless?" on Reddit, put it this way: Yes, but also, there’s no penalty to writing your own, and sometimes it helps you to figure out a clear focus for a page. Overall, I think it’s still worthwhile to do so for individual pages that you care about, but it’s definitely not a requirement. Translated from the diplomatic: no guarantees, but per the documentation Google uses your version when it describes the page more accurately than the page's own content. So the job is to write a description that honestly beats the algorithm's cut-up. ## Roger Montti's recipe Roger Montti covered the topic in The Absolute Best Way To Write Meta Descriptions — read the original in full. His algorithm, briefly: identify the one question the page answers; write a short answer; rephrase it as a standalone description outside the question's context; keep it to roughly 120 characters for mobile; add one imperative verb. ## My recipe: check GSC first I agree with Montti on the essentials, but practice shows Google surfaces the same page for queries with entirely different meanings — and builds a different snippet for each. So before writing anything, open Google Search Console: Performance → Pages → pick the page → the Queries tab. That is the full list of real queries Google shows it for. If the queries are few and share one intent — Montti's recipe settles it. If they are all over the place, use my prompt: 1. Analyse [URL] and identify the one question the whole page answers. 2. Write a concise answer to that question. 3. Rephrase the answer as a standalone description of the page, clear outside the question's context. 4. Weave in as many meanings as possible from the real user queries: [queries from GSC]. 5. For a commercial page, add the minimum price — "from $12" — only if it is true. 6. Fit the text into 157 characters including spaces, with the whole point readable in the first 120. Use one imperative verb. Why 157 and 120 at once: 157 is the practical ceiling of a desktop snippet, but mobile truncates around 120 — so the substance must live at the start of the line, with the tail only refining it. ## The takeaway: your meta description now has two readers The first is the snippet algorithm, which uses your version only when it is more accurate than its own cut-up. The second is language models, for which the meta description remains the only self-controlled summary of your page. Hiding content behind data-nosnippet cuts you off from both. Writing descriptions against real GSC queries is the one strategy that works on both fronts. This article's excerpt was written with this very prompt — check the search results yourself. ## P.S. Tested it in practice On 2026-07-10 I replaced snippets using the technique described in this article on significant commercial pages. Below is the tracking table checked on July 13, 17 and 24: for each page, what Google actually shows in the snippet. July 13 — a notable share of pages still on the old snippet (red, 'Old'); by July 24 the vast majority had switched to the new one (green, 'New') Over two weeks the picture flipped from mostly red ("Old") to almost solid green ("New") — Google picked up the rewritten descriptions on most of the tracked pages. Not without exceptions: a couple of pages are still flagged "unclear whether it leads to the homepage" / "leads to the homepage" where Google pulls the wrong target, and one page's snippet is still assembled "from garbage" — the technique speeds up the switch, it doesn't guarantee it instantly for every URL. --- # ChatGPT has already been to your website. And left to quote a competitor - Type: blog post - URL: https://safianov.com/blog/chatgpt-has-already-been-to-your-website-and-left-to-quote-a-competitor/ - Summary: How does ChatGPT choose which sources to cite, and why does it prefer your competitors even if your content is superior? Two 2026 studies analyzed ChatGPT's internal network traffic and how AI agents "see" web pages. It turns out that AI values machine-readability and web accessibility (the Accessibility Tree) over beautiful design. Read our detailed breakdown of ChatGPT's logs and a practical checklist on how to optimize your website for AI agents. Two independent 2026 studies—intercepting ChatGPT's network traffic and analyzing the "vision" of AI agents—converge on a single conclusion: AI does not quote the best content, but the most machine-readable. Below is what exactly the robot sees on your website and what to fix to get into its answers. Here is a real recording of ChatGPT's internal monologue, extracted from its network traffic. The model visited a product's official website to check prices—and failed: "Prices are not displayed directly in the search results, perhaps they are hidden behind JavaScript... I cannot read them. I can use third-party sources... I will use quotes from G2 where appropriate." The owner of this website spent money on content, design, and SEO. Yet the link in ChatGPT's response—along with the user's trust—went to the G2 aggregator. Not because G2 has better information. But because the robot was able to read it. This recording was discovered by Suganthan Mohanadasan, co-founder of Keyword Insights and Snippet Digital, in the study "How ChatGPT Actually Picks Sources (I Read the Network Traffic, Not the Outputs)", published on Search Engine Journal in June 2026. Instead of the usual "black box" approach—thousands of prompts and response analysis—he uncovered the process itself: using the Network Panel in Chrome DevTools, he read ChatGPT's JSON traffic and collected about 1,240 records of sources that the model loaded during real search sessions. The second study came from a different angle. Slobodan "Sani" Manic, a CRO specialist and WordPress core contributor, in the article "How AI Agents See Your Website (And How to Build for Them)" on the No Hacks website, analyzed what kind of "vision" AI agents use—ChatGPT Atlas, Claude Computer Use, Google Project Mariner—when they don't just read a page, but act on it: click, fill out forms, make purchases. One author looked at how AI chooses whom to quote. The other looked at how AI physically sees the page. The conclusions matched. Let's break them down in order. ## Four channels through which ChatGPT accesses your website According to Mohanadasan, every document that ChatGPT loads into its context is marked with a hidden field result_source. There are four values, and they describe four different worlds:   Channel What it is Who gets in there labrador Licensed publisher "whitelist" Reuters, WSJ, The Guardian, Wikipedia, arXiv. Snippets of ~1080 characters—effectively full excerpts. You can't get in there without a direct agreement with OpenAI bright Bright Data proxy scraping network Commercial queries, e-commerce, finance. Through it, ChatGPT reads Reddit, Forbes, Rtings oxylabs Oxylabs proxy network Regional press and the general open web serp Regular web search (likely Bing index) Most often news queries Practical takeaway: a regular website—yours and mine—competes only in the scraping segment (bright and oxylabs). This means the first condition for visibility in AI is to be easily scrapable: clean HTML, no proxy network blocking, and no critical content hidden behind scripts. ## 30% of queries do not reach the web at all Before searching, ChatGPT classifies the user's intent (the turn_use_case field). And if the query is labeled text—web search is not triggered at all: the model answers from its own weights. Mohanadasan noted that even instructions ("how to change a tire") and medical queries ("latest guidelines for treating type 2 diabetes") were processed without a single internet request in about 30% of cases. Before optimizing a page for an informational query, it is worth checking: does this query initiate a search in principle? If not, there will be no physical traffic from it, no matter how much you invest in content. ## One question—up to 40 hidden queries In "reasoning" models, a single user question unfolds into a fan of 15–40 hidden sub-queries. Ask the AI to compare software prices, and it will start pinpointing the web: queries like site:domain.com/pricing, checking price assumptions, scanning competitors the user didn't even mention. Image Credit: Suganthan Mohanadasan The parsing mechanics are almost primitive: the model searches the HTML for currency symbols, numbers, and keywords—literally "grepping" the code. If the robot does not find $ and a number next to it in clean HTML, the page is discarded. Prices, rates, and specifications must reside in plain text, rather than being assembled on the fly by a script. ## Loaded ≠ Quoted: The Reddit vs. YouTube Case The most sobering observation of the study is the gap between the three states of a website in the AI's response: - Fetched—the page is downloaded into the context (the user does not see this); - Cited—the page has become a clickable footnote next to a specific sentence; - Mentioned—the brand is named in the text, but the link leads to someone else's website. In Mohanadasan's sample, Reddit and YouTube were loaded almost equally often: 278 and 201 times. But Reddit received 11 citations, while YouTube received zero. The reason is mechanical: a citation must be tied to a specific text. From Reddit, the robot pulls the entire thread text; from YouTube, only the title and description, but not the video transcript. Hence, two rules. To get a footnote, being relevant to the topic is not enough—you need to be the best textual proof of a specific fact. And second: ChatGPT deduplicates results by domain, so twenty "watery" articles will collapse into a single entry. One strong page with facts beats a network of weak ones. A separate detail for local businesses: the variable local_results_limit = 2 was captured in the traffic. For the query "coffee shop nearby," ChatGPT will show two establishments. The fight is not for the top 10—it's for the top 2. ## Now the second half of the picture: how an AI agent sees the page Mohanadasan's study explains whom the AI quotes. Manic's article explains what the AI is actually capable of seeing—and here, the main idea is formulated in a single line: Optimizing a website for AI agents is 90% the same web accessibility work that specialists have been promoting for decades. Manic describes three ways agents "look" at a page. Some (Claude Computer Use, Project Mariner) take screenshots and analyze pixels—flexible, but expensive and fragile. Others (ChatGPT Atlas, Playwright MCP) do not see pixels at all: they read the Accessibility Tree—the very structure created for screen readers of visually impaired users. Others combine both approaches. The consequence is direct: if the "Buy" button is coded as a 
without the button role, the agent does not understand that it can be clicked. The purchase will not happen—not because of the price or the text, but because of the layout. An AI agent navigates your website in exactly the same way as a blind user with VoiceOver or NVDA. Manic's recipe is prosaic and therefore convincing: - Semantic HTML instead of endless
s:
,