# 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.

---

# Chris Green Built a Chrome Extension for This. In Orakul It's Just Text

- Type: blog post
- URL: https://safianov.com/blog/chris-green-built-a-chrome-extension-for-this-in-orakul-its-just-text/
- Published: 2026-10-01
- Summary: On September 30, Chris Green wrote in Search Engine Journal that not every SEO task needs a frontier model: exact operations belong in code, light interpretation in a small local model, and the expensive frontier model should be called only for judgment. I built a product on exactly that principle. Here's how the same architecture gets assembled in text, with no code, and where my stack falls short of his design.

On September 30, Search Engine Journal published Chris Green's "Using Local (AI) Compute To Reduce Reliance On Frontier Models." The core claim: "Not every SEO task needs a frontier model." I agree with it enough to have built a product on that principle. Below: what Green actually proposes, where my stack doesn't cover his design, and how the same architecture gets assembled in text instead of code.



## What Green proposes


He describes three tiers of compute. Deterministic code handles exact operations. Light interpretation goes to a small model running locally — in his case Gemini Nano, built into Chrome. And only where real judgment is required does a frontier model get called. In his words:


"Exact computation happens in code, lightweight intelligence happens locally, and expensive intelligence is called only when it is truly needed."
He lists the routine work that needs no frontier model outright: extracting and deduplicating URLs from an XML sitemap, fetching pages and comparing HTML, checking response codes, matching elements, identifying canonical relationships, detecting destination changes, comparing raw HTML with the rendered DOM, and analyzing link attributes — anchors, destinations, broken links.


Look at that list and answer honestly: how many of those items are you paying a frontier model for right now?



## Where his own test broke his design


The most valuable part of the article isn't the idea — it's that he published the failure. He built a Chrome extension that examines discrepancies between raw HTML and the rendered DOM, then pitted Nano against Gemini Flash and ChatGPT Luna on the same evidence. Nano proved unreliable for final judgment calls, while the larger models, in his words, handled the same evidence "considerably better."


His conclusion wasn't "local models don't work" but an architectural one: code computes, Nano presents and lightly interprets, a larger model steps in where judgment is needed. And he states a separate requirement for a model of any size:


"It has to respect the facts... and avoid inventing information."

## What I don't have


Let me say this upfront, because what follows is an ad for my own product. Orakul does no local compute. Of Green's three tiers, two are implemented: tools that fetch the data, and a model that processes it. A small local model is still only on my roadmap.


So I'm not offering a finished implementation of his design. I'm offering the part of it that, in my view, delivers most of the effect — and I'd put the principle more bluntly than he does: the model is a processor of data, not a source of it.



## What this looks like in Orakul


Green's case study is a Chrome extension he wrote in code. My closest equivalent is a technical audit agent: it takes a URL and returns a finished report. It works like this:




- step 1 — page availability mapping, via the RAW Data tool;

- steps 2 and 3 run in parallel — mobile speed and Core Web Vitals through Google PageSpeed, backlink profile and Domain Rating through the link analysis tool;

- step 4 — an AI-crawler readiness check: robots.txt, structured data, DOM semantics;

- step 5 — competitor identification, via a subagent call;

- step 6 — writing the report, via an SEO expert subagent.

In steps one through four, the data is fetched by tools, not by the model. The model appears at step six and writes the text from what the tools collected. That's Green's split exactly, minus the local tier.


The difference is in the assembly. An extension has to be written and maintained. An agent in Orakul is a table: step order, instruction in plain text, selected tool. Zero code.



## How to check that the model isn't making things up


Green's "respect the facts" requirement sounds good, but you need a way to verify it. I have measurements from a live store, which I wrote up in the contrast analysis piece. Three facts from it.


The agent states its own sample size. Across four page reports it wrote that it managed to open 4 competitors out of 8, 6 of 9, 6 of 9, and 3 of 9 — Pinterest, Scribd, and direct PDFs return no HTML. A model that invents data doesn't add that caveat; it has nothing to constrain.



Where the data ran short, the agent refused to produce a checklist. Three pages out of nine isn't a sample, and it said so itself.

The agent refused the job. For "bass clef note naming worksheets pdf," the results were free PDFs while our page was a paid product. Instead of a generic list of improvements, it returned a finding about intent mismatch and called the sample insufficient. A refusal is what respecting the facts looks like in practice.


The numbers come from a connected source. The agent pulls the set of pages ranking 10–20 from Google Search Console, not from its own head.



This table came from Search Console through a connected tool. The model formatted it; it didn't invent it.

And where no demand data existed, the report says "Wordstat: zero, Bing: insufficient data" instead of a plausible-looking number. For a report you later show a client, that matters more than polish.



## What it costs in hours


The audit agent removes roughly three hours of manual work per report. At ten audits a month and a junior rate of $5 an hour, that's about $150 saved monthly. A modest figure, but one that's calculated rather than promised. And that's only the effect visible on a timesheet; the effect of not calling a frontier model to parse a sitemap shows up separately, on the API bill.



## What to take away




- Write your recurring tasks into three columns: code does this, a tool does this, and this genuinely needs judgment. Most will land in the first two.

- Check your API bill for what you're paying a frontier model to do. Parsing sitemaps and checking response codes shouldn't be on that list.

- Require a source for every number an agent gives you. If it can't name one, that's generation, not processing.

- Treat a refusal as a valid result. A tool that always returns a checklist returns one when there's no data too.

- Start with tasks whose data already sits in an API: Search Console, PageSpeed, link tools. There, the "tools fetch, model processes" split happens on its own.

If you want to build an agent like this in text, with no code, it lives in Orakul. And Chris's article is worth reading in full: it's a rare case of an author publishing both the design and the place where it didn't work for him.

---

# Google's Top 10 Still Feeds AI Answers. Three Signals the Rules Are About to Change

- Type: blog post
- URL: https://safianov.com/blog/googles-top-10-still-feeds-ai-answers-three-signals-the-rules-are-about-to-change/
- Published: 2026-09-17
- Summary: The common view is that AI answers have already changed search. Under the hood it is still the same two-stage ranking pipeline. I checked this on data from anastasiya.studio: 74% of pages with impressions in AI Overviews and AI Mode rank in the top 10 and collect 92.6% of AI impressions. But Google has already published the theory that removes that pipeline, started paying for contributions to AI answers, and opened a Search Console report for them. Here are the three signals and what to do right now.

The common view is that AI answers have already changed search. I don't think so. Under the hood, search still ranks pages in two stages, and good SEO still leads straight into AI citations. But in 2026 Google took three steps that make it worth preparing for real change: it published the theoretical groundwork for ranking without that pipeline, started paying publishers for their contribution to AI answers, and opened a Search Console report for them.



## How search ranks today: two stages


In February 2026, Google DeepMind researchers published "Autoregressive Ranking: Bridging the Gap Between Dual and Cross Encoders." Its introduction is a good short description of how ranking works today. The dominant approach has two stages:




- Dual Encoder (DE) — fast retrieval. The query and documents are turned into vectors, and the nearest candidates are pulled quickly from a huge corpus. Fast, but coarse: the whole relationship between query and document is squeezed into a single similarity score.

- Cross Encoder (CE) — precise reranking. The model reads the query together with each candidate document and assigns an accurate score. That's far too expensive for the whole corpus, so a CE only works on the retrieved candidates.

One caveat: the paper describes standard information retrieval practice, not the internals of Google Search. But the logic of the pipeline is universal. To reach precise reranking, a page first has to make it through coarse retrieval.



## That's why good SEO still works for AI answers


The data backs this up. Ahrefs analyzed 1.9 million citations from 1 million AI Overviews:




- 76.1% of cited pages rank in Google's top 10;

- another 9.5% rank at positions 11–100;

- 14.4% don't rank in the results at all;

- the median position is 2 for the first citation, 4 for the second, and 5 for the third.

If you're in the top 10, your odds of being cited are good. But the study has limits: AI Overviews only, only the first three citations per answer, and data from July 2025. The authors themselves say that even from position one, the chance of a citation is "a coin flip at best."



## I checked this on a live store


Ahrefs' numbers are market-wide averages, so I checked them against data from anastasiya.studio, a store selling printable music materials that I work with. I took two Search Console exports for the same period, June 15 – September 14, 2026: the new Generative AI report (page impressions in AI Overviews and AI Mode) and the regular performance report (average page position). Then I matched them by URL.


Over those three months the site had 43,983 regular impressions and 6,685 impressions in Google's AI features. 419 pages got impressions in AI.






Page's average organic position
Pages with AI impressions
Share of all AI impressions


up to 3
79 (18.9%)
13.8%


3 to 10
231 (55.1%)
78.7%


10 to 20
70 (16.7%)
4.8%


20 to 100
39 (9.3%)
2.6%


not in organic results
0
0%




What the comparison showed:




- 74% of pages with AI impressions rank in the top 10 by average position. Almost exactly Ahrefs' 76.1%. And those pages got 92.6% of all AI impressions.

- Not a single page outside organic results. In Ahrefs' data, 14.4% of citations point to pages that don't rank. Here, every page that appears in AI answers also appears in regular search.

- The top 3 gives no edge over positions 3–10. For every 100 regular impressions, top-3 pages get 15.9 AI impressions and pages at positions 3–10 get 17.2. Beyond the top 10 the share drops sharply: 6.1 at positions 10–20 and 2.8 at positions 20–100.

- AI impressions follow organic ones. Daily impressions correlate at 0.88. On days when the site's average position is better, there are more AI impressions: a correlation of −0.77 with position.

- Into the season, AI grew faster than organic. From August 15 to September 14, regular impressions grew 1.5x over the previous month, while AI impressions grew 2.1x. AI's share rose from 12.7% to 17.9% of regular impressions.

- AI is more visible on mobile: 41.3% of AI impressions versus 21.4% of regular ones. But the site's average mobile position is also better, 4.4 versus 10.6 on desktop. This is most likely a result of rankings, not a separate effect.

Caveats. This is one site in one niche. Google's report counts link impressions, not citations. I compared a page's average position across all its queries, while Ahrefs used the position for a specific query. And correlation doesn't prove cause. But the picture is exactly what a two-stage search should produce: what gets into AI answers is what has already passed retrieval. Which is why, when that retrieval step disappears, the rules will change.



## Signal 1. ARR — a theory of ranking without the two stages


The main point of the DeepMind paper isn't the description of today's pipeline but what could replace it. Autoregressive Ranking (ARR) is an approach where a language model doesn't score documents one by one — it generates the identifiers of relevant documents itself, token by token, already in order of relevance. The two stages collapse into a single model, and a separate vector index is no longer needed.


The authors prove two things:




- for a Dual Encoder to produce any ordering of k documents, its embedding dimension has to grow linearly with k. The bigger the corpus, the harder it is for fast retrieval;

- an ARR model with a constant dimension is theoretically able to rank any number of documents.

In the WordNet experiment, ARR performed on par with a Cross Encoder and clearly outperformed a Dual Encoder. And the authors' proposed loss function, SToICaL, cut the rate at which the model scored an irrelevant document above a relevant one from 27.66% to 0%.


It's important not to overstate this. It's a theoretical paper, the experiments are small (WordNet and the ESCI shopping queries dataset, on Mistral-7B), and nobody claims Google Search already works this way. But the direction is clear, and there is now a theoretical foundation for it.


What this means for SEO — this part is my conclusion, not the authors' claim. In a two-stage pipeline there's a step where a page is found by its similarity to the query, and classic SEO gets you there. In ARR, the model names the documents it considers relevant on its own, and there is no separate "make the candidate set" step. So the weight shifts from how closely a page matches the query to how well the model knows you, your site, and your content.



## Signal 2. Google has started paying for contributions to AI answers


On September 14, 2026, Digiday reported the launch of the AI contribution pilot. Google pays publishers not for every mention but when their content "significantly" contributes to answers in Gemini, AI Overviews, and AI Mode. The amount shows up in an AI earnings widget in Search Console. Google itself describes the program as testing a new model for working with websites "whose content helps keep its generative AI answers fresh and accurate."


There's plenty of criticism: publishers call the payouts "peanuts" and the calculation a "black box," and skeptics see the program as a hedge against regulators. But the fact itself says a lot. Google has acknowledged that content has value as raw material for AI answers, not just as a page in the results, and has started building an economy around it.



## Signal 3. An AI report is already in Search Console


Search Console now has a Generative AI performance report. It shows how many times links to your site were shown in AI Overviews and AI Mode, broken down by page, country, date, and device. According to Google, the report has been available to all sites since August 31, 2026. It will be empty if your site doesn't get enough impressions in AI features, and it doesn't include Search Labs experiments.



The Generative AI features report (beta) in Search Console for safianov.com over 3 months: 12 impressions in AI Overviews and AI Mode for a two-month-old site.

My own numbers are modest: 12 impressions, with the biggest spike at 3 in a single day. The site is two months old, so this isn't a result but a baseline, which I cover in point 7 below. The beta's limit is already visible too: the report shows only impressions, with no clicks, CTR, or position.


A separate report means a separate channel with its own metrics. Google has split AI impressions from regular ones, and now they can be measured.



## What to do right now


This blog's tagline is "indexing the future of search." Here's what I recommend preparing for while the top 10 still leads to citations.



### 1. Content: every article needs a "nugget"


A nugget is something competitors don't have: your own data, an experiment, a screenshot, a conclusion that can't be rewritten from someone else's site. A model that generates the answer itself has no use for the hundredth rehash of the same thing. Content farms are already ineffective and will soon be dead for good.



### 2. Expertise: stop being modest


If the model is going to pick the people it knows, it needs to know you. It's time to put yourself on as many authoritative platforms as you can: about.me, Medium, industry directories, Wikidata. Be careful with Wikidata: it has notability rules, and items created for self-promotion get deleted. Create one once independent sources are already writing about you. I showed how this works in practice in the article about building an E-E-A-T expert.



### 3. Networking


Active participation in professional communities may not bring you leads. But mentions in discussions, forum answers, joint pieces, and talks build your authority in the eyes of AI. Models learn from what other people write about you.



### 4. Don't abandon classic SEO


As long as the pipeline has two stages, 76% of citations come from the top 10 according to Ahrefs, and on anastasiya.studio top-10 pages collected 92.6% of AI impressions. Indexing, speed, internal linking, and rankings remain your ticket into AI answers. Preparing for the future at the expense of the present is a bad strategy.



### 5. Become an unambiguous entity


If the model has to recall you on its own, it needs to know exactly who you are. The same name, job title, and brand name everywhere. Person and Organization markup with sameAs links to all your profiles. The same spelling of your name on every platform. Scattered profiles under different versions of your name may never get connected into one person.



### 6. Make your content machine-readable


Prices, specs, and key facts belong in the HTML, not hidden behind JavaScript. AI cites what it can read. There's a detailed breakdown with data in the ChatGPT article.



### 7. Take a baseline in the new GSC report


Open the Generative AI report now and note which pages get impressions in AI Overviews and AI Mode. Compare it with the regular performance report. Pages that show up in AI but are weak in organic search, and the other way around, will tell you what the model values on your site. When the rules change, you'll have something to compare against.



### 8. Update your key pages and show dates


In describing its pilot, Google talks about content that keeps answers "fresh and accurate." A publish date and an updated date on the page, current numbers, and change notes are a cheap way to show freshness to both people and models.


Search hasn't changed yet. But Google has already written the theory, opened the cash register, and installed the meter. Better that when the rules change, the model already knows you by name.

---

# Which Page-Two Rankings Are Worth Fixing: Contrast Analysis by an AI Agent on a Live Store

- Type: blog post
- URL: https://safianov.com/blog/which-page-two-rankings-are-worth-fixing-contrast-analysis-by-an-ai-agent-on-a-live-store/
- Published: 2026-09-15
- Summary: An agent in Orakul pulled 5 anastasiya.studio pages ranking 10–20 and compared each one with Google's top results. Two are worth fixing, one has a ceiling of 1–2 positions, the agent refused to suggest edits for one, and one has nothing to compare. Here's the data, what I changed on the site right away, and how I'll check the result in a month.

Contrast analysis is one of the most useful and most tedious jobs in SEO. Open the top results, write down what competitors cover, compare it with your own page, and repeat for every query. I handed that work to a router agent in Orakul and ran it on a real store — anastasiya.studio, which sells printable music worksheets for kids. Below is the data: what the agent found, where its export needed a second look, what I changed on the site right away, and how I'll check the result.



## What contrast analysis is


It answers one question: what is my page missing compared with the pages already in the top results for this query? Not "write 2,000 words" and not a generic checklist, but specific subtopics that most competitors cover and you don't. If a subtopic shows up on 4 pages out of 6, that's a signal. If it shows up on one, it's probably just that site's quirk.



## Step 1. Where to look: clicks, but positions 10–20


The first request to the agent is a 30-day Google Search Console export: pages that got clicks but sit on page two of the results. Clicks confirm there is demand, and page one isn't far away.



The SEO Expert agent in Orakul: Search Console export for August 13 – September 12, 2026. Five anastasiya.studio pages with clicks at positions 10–20.





Page
Query
Average position


/tag/music-tracing-worksheets/
music note tracing worksheets
10.0


/tag/free-printable-music-theory-worksheets/
music color by number
10.5


/tag/free-printable-music-coloring-pages/
music coloring sheets for elementary free
15.5


/product/back-to-school-bass-clef-note-naming-worksheets/
bass clef note naming worksheets pdf
16.2


game.anastasiya.studio/002_star.html
twinkle twinkle little star game
18.4





## A manual check: the number matches, but it rests on 2 impressions


An export shouldn't be taken on faith, so I checked one pair in the Search Console interface, filtering by both query and page.



Manual check in Search Console: position 10 matches the agent's data. It also shows the catch right away — 2 impressions in 28 days.

The position matched: 10 in GSC, 10.0 from the agent. But behind it are 2 impressions and 1 click on a single day, September 4. That's not a ranking, it's a fluke. A "has clicks + position 10–20" filter with no impression floor lets pairs like this through, so the request to the agent should include a minimum number of impressions.


The other rows can't be checked the same way: the GSC interface won't build a page + query table across several URLs at once. For those, you have to trust the export the agent pulls from the connected Search Console.



## Step 2. How the agent compares a page with the top results


The second request goes page by page: "analyze the page for query X and determine what it needs to reach the top." The agent takes Google's first page of results, opens the competitors, extracts subtopics, counts how many pages cover each one, and checks whether ours does. Each subtopic becomes one line. For example, for "music color by number":


Add explicit age groups and grade levels (Preschool, Pre-K, Kindergarten, Grade 1) to the page copy and product data. Found on 4 out of 6 competitors. On our page: weak — ages are mentioned only in navigation and product titles.
Besides the list of edits, the report has a "what's already good" section and demand context. All of it is in the public document covering all five pages.


Two caveats the agent states in the report itself. First, the samples are incomplete: it managed to open 4 pages out of 8, 6 of 9, 6 of 9, and 3 of 9. Pinterest, Scribd, and direct PDF files don't return HTML, so there's nothing to compare. Second, it found no demand data for the exact long-tail queries. Wordstat shows zero for an English-speaking audience, and Bing only reports the broader topic: "music coloring pages," for example, had 141 impressions over 4 weeks.



## What the five queries showed



### 1. "music note tracing worksheets," position 10.0 — a ceiling of 1–2 positions


The top results belong to big players. Content work might move the page up 1–2 positions, no more. The agent still found gaps: grade levels and ages (3 of 4 competitors), sequential note reading from Middle C (3 of 4), and instrument-specific sections (2 of 4).



### 2–3. "music color by number" (10.5) and "music coloring sheets for elementary free" (15.5) — worth working on


Here the report gives a clear list. For color by number:




- worksheet and page count on the product card — 4 of 6;

- an explanation of the mechanics and color key ("1 = red, 2 = purple") — 4 of 6;

- ages and grade levels — 4 of 6;

- file format (PDF) and how to download it — 4 of 6;

- skill benefits in visible copy: number recognition, fine motor skills — 3 of 6.

For the coloring pages, the main gaps are character-driven themes (5 of 6) and the total number of sheets available (3 of 6).



### 4. "bass clef note naming worksheets pdf," position 16.2 — the agent refused to suggest edits



Instead of a checklist, the agent flagged an intent mismatch: the results are free PDFs, and our page is a paid $2.50 product.

This is the most useful result of the whole run. The results are direct PDF files from school sites and free directories where the file downloads in one click. Our page is a $2.50 product with a cart. The searcher wants a free file, and added subtopics won't change that. On top of that, only 3 of the 9 results returned HTML, which is too few for a reliable comparison.


The agent offered two paths: retarget the product page to commercial queries (for example, "printable bass clef music theory worksheets for kids"), or build a separate free page with 1–2 PDFs that links to the full paid 10-worksheet pack.



### 5. "twinkle twinkle little star game," position 18.4 — nothing to compare


This is a game page with no text content. Contrast analysis doesn't apply.



## What I changed right away




- "A4 PDF" and "Instant Download" badges on every product. 4 of 6 competitors state the file format and instant download explicitly. Our product cards didn't.

- A "grade level" field in the admin. Anastasiya is filling it in for the top products. 3 of 4 and 4 of 6 competitors state ages and grades.

- Free products now hand over the file immediately.

- A reminder in one month to check the average position for these pages.

I deliberately left the snippets alone. Snippets move CTR, content moves position. Change both at once, and a month from now there's no telling which one worked.



## What's in the report but not done yet




- Sheet count per pack on the product cards (4 of 6 competitors).

- A block explaining how color by number works, with the color key (4 of 6).

- Skill benefits in the visible page copy. Right now they're only in the meta description (3 of 6).


## Seasonality: why the analysis runs every two weeks


The store is highly seasonal: back-to-school, Halloween, Christmas, Easter. In two weeks people will be searching for Halloween coloring pages, and a fresh export will surface different pages. So there are two cycles. A new export and analysis every two weeks, for pages that have just reached positions 10–20. A check after one month, for what has already been fixed.


That leads to a practical takeaway. Changes take weeks to show up in the results, so seasonal pages are better analyzed before the season, using last year's data, rather than waiting for them to surface on page two.



## How I'll check the result


In a month, mid-October, I'll compare average positions. I'll look at each page as a whole, not at page + query pairs: with two impressions, any change is meaningless. And not at clicks: by October back-to-school demand will have faded, and clicks will drop no matter what I changed. I'll publish the result as an update to this article, even if it's zero.



## What to take away




- Pick pages with clicks at positions 10–20, but set an impression floor.

- Check at least one row of the export by hand in GSC.

- Count frequency: a subtopic most of the top covers is a must; one covered by 1–2 sites is optional.

- Check intent first. A paid product page doesn't belong in a SERP full of free PDFs, and no amount of copy fixes that.

- Change one lever at a time, or you won't know what worked.

- With seasonal demand, repeat the analysis on a schedule, not once.

The agent behind this analysis runs in Orakul. The full report on all five pages is in the public document.



## Update, September 29, 2026: what happened to the rankings


A month has passed and the check is done — twice, because the first time I measured the wrong thing. Below are both attempts: first the one that's useless, then the honest one. Unfortunately, the verdict on the edits didn't improve along the way.


As a reminder, here's what was done right after the analysis: "A4 PDF" and "Instant Download" badges on all products, a grade level field in the admin, and instant file delivery for free products. I deliberately left the snippets alone.



### Attempt one: page + query pairs






Query
Before

Aug 13 – Sep 12
After

Aug 31 – Sep 27
Change


music note tracing worksheets
10.0 (2 impressions)
8.1 (10 impressions)
+1.9


music color by number
10.5
11.1 (7 impressions)
−0.6


music coloring sheets for elementary free
15.5
6.2 (39 impressions)
+9.3


bass clef note naming worksheets pdf
16.2
13.8 (8 impressions)
+2.4


twinkle twinkle little star game
18.4
not measured
no edits were made





Attempt one: position 8.1 versus 10.0 a month ago. The sample is 10 impressions over 28 days.

It looks decent, which is exactly what makes this kind of measurement dangerous. It has two holes. The periods overlap: 13 shared days out of 28, so part of the "growth" is the same days appearing in both samples. And I measured something other than what I promised: the article says to look at a page as a whole, not at page + query pairs. Query three showed why pairs fall apart.



### Google swapped the page



For "music coloring sheets for elementary free," Google now ranks the music theory worksheets tag page and an old blog post. Neither is the page we analyzed.

That jump from 15.5 to 6.2 happened where we made no edits at all. The page the agent analyzed, /tag/free-printable-music-coloring-pages/, no longer shows up for that query. Google ranks /tag/free-printable-music-theory-worksheets/ instead (2 clicks, 34 impressions), along with an old blog post, /blog/enhancing-elementary-music-lessons-with-music-colo/ (10 impressions).


The takeaway that justifies the whole exercise: the page that ranks isn't the one you picked to work on — it's the one Google picked. And Google changes its pick without telling you.



### Attempt two: whole pages, against a baseline


The second measurement works differently. I take each page's average position across all its queries: before is June 15 – September 14, after is the week of September 21–27. No overlap. And crucially, I add a baseline: the same change for every other page on the site. The baseline is the median across 90 pages with at least 10 impressions that week and 40 over the three months.


The baseline came out at −1.85 positions. The site as a whole climbed almost two positions on its own. So our pages had to climb at least that much just to keep up.






Page
Jun 15 – Sep 14
Sep 21–27
Δ
vs. baseline


/tag/music-tracing-worksheets/
8.17
9.21
+1.04
+2.89 worse


/tag/free-printable-music-theory-worksheets/
16.33
8.45
−7.88
−6.03 better


/tag/free-printable-music-coloring-pages/
24.44
20.94
−3.50
−1.65 better


/product/back-to-school-bass-clef-note-naming-worksheets/
21.50
17.83
−3.67
−1.82 better




Three pages out of four beat the baseline and one fell behind. But before celebrating, look at where the biggest success happened. The page that beat the baseline hardest, by 6.03, is the music theory worksheets tag — the very page Google swapped into the results in place of the one we analyzed, and one that got no targeted edits. As for the bass clef product page, it had 6 impressions that week; at that volume its −1.82 means nothing.


There's a more direct test available. The "A4 PDF" and "Instant Download" badges went onto every product page, while tag and blog pages got nothing. That's a ready-made split between pages that were edited and pages that weren't:




- product pages: median −1.75;

- tag, blog, and everything else: median −3.50.

The edited pages climbed less than the untouched ones. That doesn't prove badges hurt — the untouched group is only 11 pages. But it firmly settles whether a positive effect from the edits is visible in the data. It isn't.



### Caveats




- The windows differ in length. "Before" is a three-month average, "after" is a single week. Those three months include the slow summer, so part of the overall climb is the season rather than the work. That's exactly what the baseline is for: the season hits the whole site equally.

- Impressions fell on all four pages: 2,159 → 166, 1,020 → 70, 3,321 → 108, 203 → 6 on a weekly basis. Back-to-school demand is over, which is one more reason to look at position rather than clicks.

- Week over week shows almost nothing. I checked that too: September 21–27 against September 14–20. The median across 82 pages is +0.12, meaning a flat baseline. Meanwhile the Compare card in Search Console reports the site's average position improving from 4.8 to 4.3 — that figure is impression-weighted and gets moved by a handful of large pages, not by the site as a whole. A useful reminder that the number on the card and the median across pages are different things.


### What was actually tested, and what wasn't


Before extending this verdict to the approach itself, it's worth stating what went into the measurement and what didn't.




- Only a small part of the report was implemented. The agent asked for the sheet count per pack on product cards (4 of 6 competitors have it), a block explaining the color-by-number mechanics and color key (4 of 6), and skill benefits in the page's visible copy (3 of 6). What got done was badges, a grade level field, and instant file delivery. So what was tested is the three cheapest edits, not the report's recommendations.

- The window is short. The edits went live on September 15, the measurement covers September 21–27. That's one to two weeks — not much for recrawling and recalculation, especially on pages with dozens of impressions per week.

- The season worked against us. Back-to-school demand ended and impressions on the analyzed pages fell several times over. The baseline removes part of that interference, but any effect is harder to see on falling demand.

- There was no control group. Every product got the badges at once, so the comparison had to be product pages against tag pages — different page types with different behavior.

So the correct way to state the result is this: three cosmetic edits, over a week and a half, on falling demand, produced no effect visible in the data. This measurement can't support the claim that contrast analysis doesn't work — its main recommendations were never implemented.


The agent did pay for itself once in this run, though not in rankings. It refused to suggest edits for bass clef and took off the table a page that has no business ranking in a SERP of free PDFs. Work not wasted is a result too; it just doesn't show up in Search Console.



### What's next


Waiting another two weeks wouldn't help: the data would get noisier, not cleaner. The next round will be set up as a proper experiment.




- I implement the report's substantive recommendations — sheet counts, the mechanics block, benefits in visible copy — on 10 pages.

- Another 10 similar pages stay untouched as a control.

- I measure in 4–6 weeks: whole pages, non-overlapping windows, baseline from the rest of the site.

- I add an impression floor to the agent's export so queries with two impressions don't make it in.

- For bass clef I pick one of two paths: commercial queries or a separate free page.

I'll publish the result here either way.

---

# Negative SEO Link Bombing Is Real. That SEJ Disavow Story Was Something Else.

- Type: blog post
- URL: https://safianov.com/blog/negative-seo-link-bombing-is-real-that-sej-disavow-story-was-something-else/
- Published: 2026-09-06
- Summary: A widely shared Search Engine Journal story about a Reddit user's ranking collapse is making the rounds as proof Google can't stop negative SEO. It isn't that story — it's about someone disavowing their own paid links by mistake. The real threat is separate, and one of our clients lived through it: a coordinated spam-link attack, a same-day disavow file, and months of Search Console data that still hasn't fully recovered.

A Search Engine Journal piece about John Mueller's comments on ranking recovery is circulating as a cautionary tale about Google and negative SEO. I read it closely, because I had a very similar-sounding case land on my own desk this year. The SEJ story turns out to be about something else entirely — but the thing it got mixed up with is real, it's cheap to pull off, and Google still doesn't have a fast answer for it.



## What the SEJ story actually says


The article centers on a Reddit user who disavowed roughly 800 links and watched their rankings collapse within two weeks. Retold secondhand, that sounds exactly like a site getting hit by an attack and Google failing to protect it. It isn't. The user later admitted those 800 links were guest posts they had bought themselves on Fiverr — their own paid link-building, disavowed out of fear that it looked spammy in hindsight.


John Mueller's actual response undercuts the "Google can't stop this" reading rather than supporting it: disavowing a handful of links, he said, wouldn't cause a drop that sharp on its own — the more likely cause was a spam update landing around the same time. On timing, he was specific: disavow files typically take "maybe three, four, five, six months" to show their effect, not two weeks. So the SEJ story is really a warning against panic-disavowing your own links, not evidence that negative SEO goes unpunished.



## The real problem it reminded me of


Here's what the SEJ story isn't about, and what I actually deal with: paying for a large batch of low-quality, spammy backlinks and pointing all of them at a competitor's site, not your own. It's a real, deniable, and currently one of the cheapest ways to try to knock a rival's rankings down without spending a dollar on your own SEO. It doesn't take a sophisticated operation — link marketplaces that sell bulk "toxic" backlinks exist precisely because this works often enough to be worth the price.



## What happened to one of our clients


One of AviGroup's clients was hit by exactly this. We spotted the spike in their backlink profile, built a disavow list the same day, and submitted it to Google through Search Console. That's the fast part. The slow part is everything after: Search Console for that site still shows the aftermath, months later.



Search Console, trailing 12 months: impressions spike sharply, then collapse and stay flat for months — the shape of an attack and a recovery that hasn't finished.

By our own tracking, the site's average position slipped by about two spots after the spike and still hasn't fully climbed back. That matches Mueller's timeline, not the two-week drama in the Reddit post: we disavowed immediately, and months later the graph is still working through it.



## Why Google isn't fixing this faster


Disavow is a self-serve text file you upload and then wait on — there's no equivalent of a spam report that gets a human or a fast-acting system to intervene on your behalf when someone else buys links to sabotage you. I don't think that's a conspiracy; it's a prioritization call, and Google's engineering attention this year has visibly gone elsewhere. Gemini 3.7 shipped less than a month before the announcement of Gemini 3.8. I'm not claiming one team's headcount explains the other's backlog — I just haven't seen anything from Google this year that suggests defending targets of negative SEO got any faster.



## What to actually do




- Watch your backlink profile on a schedule, not just when rankings already dropped — a spam-link spike is far easier to disavow on day one than after it's had weeks to compound.

- If you do find a coordinated spike, build the disavow file and submit it immediately, but set expectations with your client or your boss up front: three to six months, per Mueller, not days.

- Don't disavow your own guest posts or paid links just because they look risky in hindsight — that's what actually tanked the Reddit case, and it's easy to repeat if you read that story as "when in doubt, disavow more."

- Keep dated Search Console screenshots of anything that looks like an attack. It's the only evidence you'll have later, for a client, for your own records, or for Google if it ever asks.

- Treat disavow as damage control, not defense. The sites that shrug off a link-bombing attempt are the ones with enough real authority that a few thousand junk links can't move the needle much in the first place.

Update, September 7, 2026: As they say around here, "or do gor" (roughly: "the scream carries to the mountains" — local shorthand for something too on-the-nose to be believed) — you couldn't write this. Twelve hours after this article went up, an email landed from Google Search Console: "Disavow File Updated. The new disavow file contains 1074 URLs and 0 domains." Coincidence, obviously — Google isn't reading my blog. But the timing is too good not to mention. Google, are you watching me?




The confirmation email, received almost exactly 12 hours after this article was published.


The bottom line: the disavow file was submitted on May 28, 2026. Google confirmed it was applied on September 7, 2026 — just over three months for the file itself to register. Per Mueller's own timeline quoted above, the ranking effects of a disavow still take another three to six months to fully show after that. For an actual business, that adds up to one thing: roughly half a year with the entire budget riding on CPC, because there's no organic traffic left to lean on.

---

# Technical write-ups are moving to Habr (Russian-only) — starting with the case of the vanishing IPv6

- Type: blog post
- URL: https://safianov.com/blog/technical-write-ups-are-moving-to-habr/
- Published: 2026-09-01
- Summary: Technical deep-dives now live on Habr, in Russian only. Today's case: a client's site was blamed on Russian network-level blocking for three months — the real cause was three ordinary misconfigurations on one server.

A quick housekeeping note. This blog stays focused on what's happening in SEO and GEO — trends, algorithm updates, how search actually works. Purely technical write-ups — infrastructure, networking, server-side debugging — now go to a specialized outlet instead: my Habr profile.


Today's piece there is worth knowing about even if you don't read Russian. A client — a large online publication — had lived for three months with the explanation "it's Russian network-level filtering, nothing to be done." Their site kept vanishing for search and AI crawlers: 89 days straight of a fluctuating failure rate, anywhere from 0.2% to 78%. The explanation was convincing precisely because it couldn't be checked by hand.


There turned out to be three causes, all on the same server, none of them network filtering: an IPv6 address that existed only in DNS, nginx listening on IPv6 for the wrong server block, and a whole-country geo-block buried in the hosting panel's firewall. That last one came down with a single console command — which is itself the tell: a real network-level block can't be fixed with one command on your own box.


Read the full case on Habr → (Russian only)


Apologies in advance — Habr is Russian-only for me. If a particular piece interests you, email me and I'll send you an English version.

---

# The August 2026 Google Spam Update: The Real Facts, and the S-CTS Myth

- Type: blog post
- URL: https://safianov.com/blog/the-august-2026-google-spam-update-the-real-facts-and-the-s-cts-myth/
- Published: 2026-08-29
- Summary: A text is circulating claiming this update runs on an algorithm called "S-CTS." S-CTS is real — it's just YouTube's video-spam system, not a web search ranking mechanism. Here's what's actually confirmed, plus honest Search Console data from my own two-month-old site.

A write-up about the recent Google Spam Update is circulating online (and, judging by its style, was likely generated without a fact-check), built around an algorithm called "S-CTS" — supposedly the engine deciding web pages' fate in this update. I checked the primary source. S-CTS is real. It just isn't what that write-up claims. Here's what's actually confirmed, what got mixed up, and what Search Console honestly shows for my own, very young site.



## What actually happened


Google finished rolling out the August 2026 spam update — the rollout took 2 days and 16 hours (August 18–21), confirmed by Search Engine Roundtable. It's the third spam update of 2026: March finished in a record 19 hours 30 minutes, June took 2 days 1 hour. Google didn't publish a dedicated blog post or announce any new spam policy categories — meaning the same rules as before still apply.



## The "S-CTS" myth: where it came from and what it actually is


The name "S-CTS" (Scalable Cluster Termination System) isn't invented. It's a real Google system, described in the research paper "Scalable Detection of Adversarial Synthetic Slop and Coordinated Media Abuse" (Mathur, Liu, Tan, Liu, Google). The problem is what it's for: the abstract's very first sentence states the target — "online video platforms (OVP)." The system hunts for coordinated clusters of accounts (bots sharing the same generative infrastructure) and bans them as whole clusters, rather than evaluating individual web pages. Independent press reported results specifically on YouTube: roughly 130,000 channels across 50,000 clusters terminated over six months. The paper itself reports engineering metrics — a 32% reduction in cluster validation turnaround time and a 50% reduction in synthetic content review time versus manual moderation, with an overturn rate under 1%.


In other words: someone (or something) took the real name of a real system and assigned it a role it doesn't have — the mechanism of the current web spam update. Neither the paper's authors nor Google's own material on the Spam Update itself makes that connection.



## What Google actually calls spam


The official terminology in Google's Search spam policies is far less exotic than an invented system. Two key terms: scaled content abuse — mass-producing pages to manipulate rankings, regardless of what generated them (AI, scraping, synonymizing); and site reputation abuse — hosting low-quality third-party content on an authoritative domain to borrow its ranking signals (Google updated this policy back in November 2024). Both are about a page's purpose and value to the user, not about which tool wrote it.



## Context beats the size of the training data


Google's former Chief Scientist Jeff Dean, interviewed by Diana Hu of Y Combinator — covered by Search Engine Journal — described a model's training data as "trillions of tokens stirred together into a soup of hundreds of billions or trillions of parameters." His point wasn't about this spam update or SEO at all — it was about context engineering: clean, purpose-built context for a specific task is more useful to a model than the sheer fact that it was trained on an enormous dataset. The idea still lands squarely on this topic: a page that just restates what a model already "knows" from that soup of tokens adds nothing new for the reader — a page with its own data, specific detail, and verifiable facts does.



## What I actually tried to check by hand


Before writing this up, I manually ran the site: operator against 20 WordPress sites from one PBN network, all over a year old, with an average DR around 20. Roughly half of them show up in Google's index. That's not evidence of a drop from the update: for an auto-published network, 50% indexation is normal background noise even with no spam update in play — not every auto-generated article gets indexed on its own merits in the first place. There's no way to tell how much of that 50% is a reaction to this specific update versus just how that kind of network normally behaves. The only site where I saw any signal at all tied to this timeframe was my own.



## What's happening on my own site



Search Console for safianov.com, July 30 – August 26, 2026: 136 impressions, 1 click, average position 40.1.

Impressions grew starting around August 11 — but that isn't proof either. The site has only been connected to Search Console for a month, and it's two months old overall: 136 impressions and 1 click mean it hasn't had rankings to lose in the first place. The growth started before the update itself even began (August 18–21), so it looks more like Google indexing fresh pages than any reaction to spam policy. That's the honest answer to "how did the update affect traffic": neither on 20 sites that weren't mine, nor on my own, did I find a signal worth treating as evidence. The dramatic -84%/+38%-style cases that usually get attached to write-ups like this exist somewhere out there — but I won't pass one off as an example when I haven't verified it against my own data.



## What to do




- Don't tie your actions to an algorithm that doesn't exist for this purpose. If a piece cites "S-CTS" as the reason web pages dropped, that's a mix-up at best — check the primary source.

- Check Google's actual official terms (scaled content abuse, site reputation abuse) — that's what actually gets visibility reduced.

- If you publish a lot of templated pages, the question isn't "who wrote this" — it's "what's here that nobody else has."

- Don't borrow someone else's drop/growth numbers as an argument for your own strategy — every site has its own age, history, and link profile. Look at your own Search Console data, not market averages.

---

# 68.9% vs. 2.1%: How to Get Baked Into an LLM's Weights

- Type: blog post
- URL: https://safianov.com/blog/689-vs-21-how-to-get-baked-into-an-llms-weights/
- Published: 2026-08-19
- Summary: ChatGPT decides who to cite before it even searches. Three steps that move a brand from the rejected 2.1% into the pre-selected 68.9% — plus a tool that tests the first one right now.

ChatGPT decides who to cite before it ever opens a browser tab. Independent studies of the model's network traffic show: brands the model names itself, in its own first search query, get cited 68.9% of the time. Brands surfaced only through the subsequent search — 2.1%. A 33x gap, decided not at search time, but earlier — inside the model's weights. Here's what to do about it.


I already wrote about how ChatGPT physically can't see prices hidden behind JavaScript, and quotes G2 instead, in "ChatGPT has already been to your website. And left to quote a competitor." That piece was about content accessibility once the model is already searching. This one is about what happens earlier: how a brand enters the model's field of view before it opens a single tab.



## Two stages: the shortlist first, then the filter


Two further studies by the same author, Suganthan Mohanadasan, including a separate piece on what ChatGPT decides before it searches, expose the mechanism in detail. It runs in two stages.


First, the model builds a competitive shortlist — right inside the first search query, before it has opened a single page. In 21 of 27 tested conversations, ChatGPT's first search already contained product names the user never mentioned. Ask "best AI note-taking app" and the JSON traffic shows a query like "Granola Notion AI Otter Fireflies Fathom Mem Limitless" — assembled by the model itself, from what it already "knows" about the category.


Then comes a hard positional filter. Even among pre-shortlisted sources, few get cited: 1st position in the results gives a 5.2% citation chance, 2nd — 4.6%, 6th and beyond — 0.3%. Of 3,554 pages the model actually retrieved in one measurement, only 110 made it into the final answer — 3.1%.


Which is where the three steps below come from. The first two are about making the shortlist — decided before any search happens. The third is about passing the filter, once the model does check you live.



## Step 1. Dense semantic entity anchoring


Contextual proximity. ChatGPT's shortlist isn't random — it's an imprint of what the model saw sitting next to what in its training text. If a brand is regularly mentioned in the same sentence or paragraph as its competitors and category — on Reddit, GitHub, Hacker News, Wikidata, industry media — the model learns that association and pulls the brand into the shortlist by default, before ever touching the live web.


One consistent positioning sentence. Write the entity down as one phrase: "[Brand] is the [category] for [audience]" — and use it everywhere, unchanged, from press releases to a founder's LinkedIn bio. Inconsistent phrasing dilutes co-occurrence; repeating the same pairing reinforces it.



## Step 2. Dominate the primary training datasets


LLMs aren't trained on the whole web indiscriminately — they're trained on filtered, high-quality slices: Common Crawl, C4, technical documentation corpora. Presence there matters more than a ranking position in Google.




- Aggregators and listings. A complete, current profile on G2, Capterra, Product Hunt, Trustpilot, Crunchbase isn't just about leads — it's text that's highly likely to end up in training data, paired directly with the category name.

- Open source and the tech ecosystem. GitHub repos, documentation, integrations with popular APIs and frameworks — code and technical writing are among the cleanest, most heavily used corpora in training.

- Multimodal traces. YouTube review transcripts, Spotify and Apple Podcasts episodes. Models increasingly train on text transcripts of audio and video — a review nobody will ever cite directly still leaves a text footprint in the dataset.


## Step 3. Site infrastructure for the "site probe"


Even once the model has shortlisted a brand, it still runs a live check — the exact kind of query the research surfaces: site:yourbrand.com pricing features 2026. Your site has to pass that probe, or none of the co-occurrence work above gets you a citation.




- Transparent URL structure. Clear, predictable paths: /pricing, /features, /integrations, /vs-competitor.

- Machine-readable formatting. Prices and plans in plain HTML text or a table — not behind a lead-gen form or a dynamic script. Same conclusion as part one of this research: the model simply can't see JS-loaded prices.

- llms.txt and Schema.org markup. A short, machine-readable file describing your product structure, plus SoftwareApplication, Product, and Offer schema — a direct hint to the model instead of a guess.

- Crawler accessibility. None of the above matters if GPTBot, PerplexityBot, ClaudeBot, or Bingbot physically can't reach the page — because of a robots.txt rule or a Cloudflare JS challenge.

That last point is the one you can test today, not after six months of content work. I built a free tool that does exactly this: it reads your robots.txt and, at the same time, sends a live request under each major AI crawler's user-agent — GPTBot, ChatGPT-User, ClaudeBot, PerplexityBot, Bingbot — and shows which ones your site actually lets through, and which it blocks, even when robots.txt formally allows access.


Check your site's AI-bot accessibility →



## What to do today


All three steps solve the same problem — not ranking higher, but getting baked into the model's weights before the user even asks the question. Ranking in classic search is a competition for a click, right now. A seat in an LLM's shortlist is what decides the outcome of that competition before it even starts.


Where to start today: run your site through the AI-bot accessibility check — it takes seconds, and either confirms there's no technical barrier, or points at the specific block worth fixing first. After that come Step 1 and Step 2, which don't resolve in seconds but don't require a big-brand budget either: consistent, repeated mentions in the right context are almost always more within reach than they look.

---

# 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/
- Published: 2026-08-13
- 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.


## WebMCP


In plain terms: a way for an open browser tab to become an MCP server for a desktop AI assistant by itself — no server code required. This article was built around five protocols, but a sixth showed up while I was writing it, and it would be dishonest not to mention it: WebMCP isn't one protocol — it's two parallel efforts sharing the same name. The first is the official W3C/Chrome draft standard (navigator.modelContext), the same declarative and imperative API I showed above using this site's own MCP markup — check /mcp/, it's exactly what that standard describes. The second is an independent experimental project by developer Jason McGhee (jasonjmcghee/WebMCP), solving the same problem differently: through a local WebSocket bridge running on the user's own machine. The two aren't compatible with each other — worth knowing which one you're actually shipping.



### How it works (the McGhee approach)


A site owner adds one script tag (<script src="webmcp.js"></script>) — a widget appears on the page asking for a token. The user runs a local process on their own machine (npx -y @jason.today/webmcp@latest --config claude), which spins up a WebSocket server on localhost and connects to an MCP client like Claude Desktop. The client generates a one-time registration token; the user pastes it into the site's widget — the token is destroyed, and the site is issued a session channel scoped to its own domain (webmcp.dev:search, site.com:order — no mix-ups even with ten WebMCP-enabled tabs open at once). From there, the AI assistant sees the tools the site declared and calls them directly on the open page — not through an API, but against the tab's live state.



### How a site owner can use it


Best fit where an AI needs to operate the interface, not just read data: filling out a complex booking form, filtering a catalog, flipping a dashboard's state — on the live page, without a separate backend per action. For sites that already have an open API, the native path makes more sense (Method 1 from the MCP section above, or the declarative attributes I used on this site's own blog search) — it asks nothing of the visitor to run locally.



### Pros and cons




- For: a site only needs one script tag and a set of JS functions — no separate backend or server-side MCP required; client-side safety — the AI gets no hidden access to files or browser cookies, authorization only happens after an explicit token is entered on a specific tab; more interactive than a plain API — the AI works against the page's live state (an SPA, a dashboard, a canvas), not just reading data.

- Against: an early, unofficial community prototype — not compatible with the W3C standard being built for browsers in parallel, and easy to confuse with it; the user still has to run a local process — today's browsers still can't talk to MCP clients directly without a bridge; the connection only lives as long as the tab stays open — close the site, and its tools disappear immediately.


## 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


WebMCP
Turns a browser tab into an MCP server for a desktop AI
Script+widget (community) or attributes/JS (native)
Community (J. McGhee) / Chrome, W3C
Early prototype / draft standard


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. If your site already has simple GET forms — search being the obvious one — add toolname/tooldescription attributes to them for free: it changes nothing for ordinary browsers and costs nothing to add, which is exactly what I did on this site's own blog search.


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. The same goes for WebMCP's community-bridge flavor (webmcp.js): a neat idea, but it asks your visitor to run a local process on their own machine — and the official browser standard it isn't compatible with is still being built in parallel. Watch it; don't build a product around it 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/
- Published: 2026-08-09
- 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/
- Published: 2026-07-26
- 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/
- Published: 2026-07-21
- 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.

---

# 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/
- Published: 2026-07-14
- 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/
- Published: 2026-07-13
- 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 <div data-nosnippet>. 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/
- Published: 2026-07-09
- 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 <div> 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 <div>s: <header>, <nav>, <main>, <article>, <button>, <a>—this automatically builds a correct accessibility tree;




- 
ARIA attributes (aria-label, aria-expanded)—where HTML is not enough, but they do not fix broken layouts, they complement clean ones;




- 
SSR/SSG instead of heavy SPAs: agents can execute JavaScript, but server-side rendering is parsed faster, more stably, and with fewer errors—which directly connects to the G2 story from ChatGPT's logs.




And you can test this without a single AI tool: a screen reader, the Accessibility tab in Chrome DevTools, Lighthouse, Axe. Manic formulates a criterion that is worth hanging on the wall: if you can make a purchase on your website with your eyes closed—from the keyboard, using a speech synthesizer—an AI agent will manage too.



## What to do: a checklist based on both studies


According to Manic, the share of non-human traffic on the internet has already exceeded 51%. The robot is no longer a secondary visitor, but half of your audience. Here is what both studies, independently of each other, prescribe to do for it:




- 
Expose facts in clean HTML. Prices, rates, specifications—in plain text, without JS rendering. The robot looks for $ and a number; if it doesn't find them, it quotes G2.




- 
Check that you are not blocking scrapers. Your channel into ChatGPT is the Bright Data and Oxylabs proxy networks. If you block them, you disappear from the answers.




- 
Write fact-proving pages rather than "overview fluff." The citation goes to the best textual proof of a specific statement. One strong page > 20 weak ones (deduplication by domain).




- 
Code semantically and test with a screen reader. The accessibility tree is the interface through which an AI agent clicks and buys. A <div> button is invisible to it.




- 
Check if your query triggers a web search at all. ~30% of informational queries are answered by ChatGPT from its own memory—optimizing for them is pointless.




- 
For local businesses—aim for the top 2, because local_results_limit = 2.




For ten years, accessibility was sold as ethics and caring for a minority of users. As it turned out, it was preparation for an audience that already makes up half of the traffic and decides whom to quote and whom not to. The cheapest SEO of 2026 looks like work for screen readers.


Sources:




- 
Suganthan Mohanadasan, "How ChatGPT Actually Picks Sources (I Read the Network Traffic, Not the Outputs)" — Search Engine Journal, June 2026.




- 
Slobodan "Sani" Manic, "How AI Agents See Your Website (And How to Build for Them)" — No Hacks, February 2026.

---

# Turning around a declining SEO site through two Core updates

- Type: case study
- URL: https://safianov.com/cases/turning-around-a-declining-seo-site-through-two-core-updates/
- Summary: Traffic had been declining since October 2025, rankings stuck at 15-25. Six months, two Core updates later, core keywords are back in the top 10 and traffic has more than doubled off the bottom.

Since October 2025, prmotion.me — a service selling followers and engagement across Instagram, Telegram, YouTube, VK and TikTok — had been rapidly losing rankings and traffic. By February 2026, when I joined the project, its key pages sat at positions 15–25 — effectively invisible, on page two or three of Google.



## Three problems at once, not one




- A "grey" niche. Engagement-boosting services are a niche Google treats with above-default suspicion — manual action risk and E-E-A-T scrutiny well beyond an ordinary commercial site.

- Two major Core updates during the engagement. Stabilizing a declining site around even one core update is a challenge; here there were two back to back, at the worst possible moment for a recovery.

- Starting from a deep hole. Not "optimizing a good site" — a turnaround from positions 15–25, where commercial pages effectively weren't shown to buyers at all.


## What was done




- Page speed to 85–90 on PageSpeed. Together with the dev team, no tricks — strict, methodical execution of PageSpeed Insights' own recommendations, one by one.

- An expert built for E-E-A-T. The method and result are covered in a separate article — "Where to Find an E-E-A-T Expert: I Built One".

- Every commercial page's copy rewritten — not cosmetic edits, a full rewrite around real queries and buyer intent.

- Structured markup added — Product, Listing, Person, Article, Organization — the site became machine-readable where it used to be just HTML.

- Snippets rewritten using the method from "How to Write a Meta Description That Google Will Use."

- A daily blog content pipeline built — not a one-off push, a running process.

- TrustPilot connected, old negative reviews addressed — a reputation signal both buyers and the search engine read.


## The result


Key rankings are back in the top 10 — and that's not a vague claim, here are the actual numbers on the core commercial queries:




"instagram followers boost" (RU query) — position 3, "10,000 free instagram followers" — position 4, "instagram followers boost" (broader) — 5.7, "followers boost" — 5.9, "free instagram likes boost" — 7.5


The decline stopped: March–May held a flat, stable traffic line at the bottom of the drop, with no further slide even through the core updates. Real growth started in June — traffic climbed from a ~8–9K plateau to 16K by the end of July, more than double the low point.




Organic traffic: a plateau at the bottom of the drop through March–May, steady growth from June — roughly 8K to 16K by late July


The recovery shows up in visibility across the platforms the service is built around too — Instagram, Telegram, YouTube, VK, TikTok:




The same drop-plateau-growth pattern across every tracked entity — Instagram remains the main traffic source (57.9%) but the other platforms are climbing too


None of these steps is impressive on its own — page speed, markup, copy, reviews, a publishing habit. What's impressive is doing all of it together, seeing it through, and not dropping it halfway while Google changed the rules twice along the way.

---

# PBN Panel: the domain-network SaaS platform I built for AviGroup

- Type: case study
- URL: https://safianov.com/cases/pbn-panel-the-domain-network-saas-platform-i-built-for-avigroup/
- Summary: Hostings, servers, domains, WordPress and health monitoring — one encrypted panel. Not an internal tool but a working subscription SaaS: pbn.avigroup.pro, three pricing tiers, real customers.

A network of 500+ domains means hundreds of WordPress logins, dozens of servers and SSH passwords, and a renewal calendar nobody remembers by heart. Normally all of that lives across three spreadsheet tabs, a password manager, and the head of whoever built the network. I built AviGroup a SaaS platform that sells the fix for exactly this problem — not an internal script, a commercial subscription product: pbn.avigroup.pro.



## "Take full control of your PBN" — and it's not an empty slogan


The product's promise is stated with unusual precision: instead of juggling spreadsheets and a dozen disconnected services, one dashboard. The audience runs from a freelancer with a personal network to a large agency running client PBNs, across three paid tiers: Start from $24/mo, Growth from $59/mo, Control from $99/mo. This isn't a demo prototype — it's a working SaaS with real paying customers across all three tiers of the market.




Network visualization: the whole network — domains, links, statuses — on one interactive map


## What's actually behind the "one dashboard" promise




- Domain health checks itself. A domain checker with daily title monitoring and status history — if a domain gets hacked, parked, or deindexed, it shows up in the panel the same day, not a month later as a traffic drop.

- A domain's history is one request away. The Wayback Archiver asynchronously pulls a snapshot from the Wayback Machine, rewrites resource paths, and packages it into a downloadable archive — a standard step when bringing a newly acquired aged domain into the network.

- Publishing without opening WordPress. Content is posted through the WP REST API right from the panel — no need to keep admin panels open across hundreds of sites.

- Reporting that can leave the panel. Data export and API/webhook integrations, including Google Looker Studio — network numbers are available outside the panel itself, for an agency's own client reporting.

- Team access and accountability, built in. Team access management and an activity log — a requirement for any agency where more than one person touches the network.



Security: IP/ASN isolation and anti-fingerprinting protection — the actual reason this niche exists


## The engineering the landing page doesn't show


Under the interface: Django with Celery/Redis for async work (Wayback archiving, domain health checks, notifications), server and WordPress passwords Fernet-encrypted right in the database, SSH and WP password rotation across the whole network via management commands, no manual server-by-server logins. Database backups run on a schedule, upload to external storage, and restore in one click. This is what actually backs the product page's "save up to 40% on your link-building budget" — the savings don't come from a slogan, they come from routine work that used to need a dedicated person or hours of manual effort now taking seconds.


It's the same skill as the rest of my case studies — not SEO consulting, but engineering that makes an SEO operation manageable at scale. If you have a service or internal process that's overdue to become a real subscription product instead of a pile of scripts, I know how to get it to production.

---

# Orakul: a multi-agent AI back office in Telegram for a service company

- Type: case study
- URL: https://safianov.com/cases/orakul-a-multi-agent-ai-back-office-in-telegram-for-a-service-company/
- Summary: A Django + Gemini/OpenAI platform: agent 'employees' in Telegram, scheduled PDF reports, a knowledge base, a public API. Built for myself — it runs the audits on this site. I deploy it turnkey on the client's server.

The routine of a service company looks the same in every niche: scheduled client reports, audits and checks, answers to the same questions, tasks someone must not forget. People do all of it — across ten tabs and three services. I built Orakul for myself, as my own back office; today it is a platform that can be deployed for any company that earns by providing services.



## One Telegram contact instead of a dozen services


The interface is a plain Telegram chat. Type, dictate a voice message, drop a photo or a document — an intent classifier decides which "employee" takes the job: every agent on the platform is a role with its own instructions, tools and permissions. Need a specific specialist — address them directly, like a colleague.




A  task in Telegram — a finished TXT/PDF report in the chat.


## What the platform does instead of people




- Scheduled work does itself. The task scheduler — one-off and CRON — runs agents with no human involved: daily checks and weekly client reports arrive in Telegram as finished PDFs.

- Company knowledge answers questions. A knowledge base: upload your regulations, price lists and manuals — agents answer from them via semantic search instead of making things up.

- Tools for real work, not chit-chat. Nearly thirty tools: website parsing, Google PageSpeed, Google Ads, Search Console, GitHub, image generation — and agents that delegate subtasks to each other.

- The platform remembers people. A memory of facts about every user — regular clients never have to re-explain their context.

- It works the storefront too. A public REST API with rate limiting and a WordPress widget: the same engine can deliver a service right on the company's website.


## Proven on live projects


This is not a concept: Orakul is what runs the free LLM visibility audit on this site and the website-analysis widget on a client's WordPress site right now. Access is whitelist-only, API keys and tokens live in encrypted storage (Fernet), each user can bring their own LLM key, and agents, tasks and permissions are managed in a web dashboard — no programmer required.




The dashboard: agent roles, task schedules and the knowledge base are configured without code


## I will deploy it for your company


The platform is installed on your server — your data, keys and conversations stay with you. I am ready to deploy the full server version turnkey: initial setup of agents around your processes, knowledge-base loading, tools and access wiring — plus ongoing technical support. If your company's core business is services, Orakul will take over the part of the work that repeats.

---

# anastasiya.studio: a small store vs a marketplace — GEO/AEO wins top rankings and AI citations

- Type: case study
- URL: https://safianov.com/cases/anastasiyastudio-a-small-store-vs-a-marketplace-geoaeo-wins-top-rankings-and-ai-citations/
- Summary: A family teaching-materials store on a custom Django engine. Six months of GEO/AEO rework: top rankings next to TeachersPayTeachers, zero-click mentions, and direct citations in AI answers.

Anastasiya.studio is my wife's teaching-materials store and my laboratory at the same time: every hypothesis gets tested here first and only then goes into client projects. The site runs on a custom Django engine — store, cart, orders, blog; before that it was WordPress. Its competitor in search is not another store but TeachersPayTeachers: a marketplace with millions of pages.



## First, the biggest failure


An honest case study starts with a mistake. In the WordPress era I failed to noindex the folder with finished products — and about 100 PDFs simply leaked to the web: anyone could download them from search without paying. It is my biggest fail in SEO and development, and also the lesson I now repeat in every project: search hygiene starts on day one of development, not after launch.



## January 2026: search had changed, the site had not


Another sales dip coincided with buyers increasingly getting answers not on the results page but in AI answers above it — and the store was not in them. I reworked the site for GEO/AEO along three lines:




- An identity a machine can verify. A reworked About page with real achievements, Person schema markup and — the furthest-reaching step — Wikidata entities for the author and the project. "Who is this and why trust her" is no longer text, it is a verifiable graph a language model can anchor to.

- Answers where people ask. A new home page layout and FAQ blocks written for buyers' actual questions — self-contained passages an answer engine can lift whole.

- Proof instead of promises. A widget with live Google reviews — social proof visible to people and crawlers alike.



The zero-click block: the store is named in an AI answer — the buyer sees the brand without opening a single link


## The result, six months on




- Top rankings for the niche's high-volume queries — for many of them this family store stands next to TeachersPayTeachers in the results.

- Mentions in zero-click blocks: the brand is visible even when the buyer never clicks at all.

- Direct citations in AI answers — language models reference the store as a source.



A direct citation: an AI assistant answers a buyer's question and references anastasiya.studio as the source

The point of this case: visibility in AI answers is not a privilege of giants. A small site with a verifiable author identity, honest answers and real reviews competes with a marketplace exactly where the purchase is decided. This is the same playbook — entities, markup, citable passages — I apply in client GEO/AEO projects.

---

# Sundrax: 2–4 contracts a week from organic search in a Smart City B2B niche

- Type: case study
- URL: https://safianov.com/cases/sundrax-24-contracts-a-week-from-organic-search-in-a-smart-city-b2b-niche/
- Summary: The site was indexed half-built, the niche narrow, the deal cycle months long. Fifteen months later: a clean index, DR up from 31 to 56, and a steady 2–4 contracts a week from organic search alone.

Sundrax LTD (London) manufactures control systems for urban and architectural lighting — a narrow Smart City B2B niche where a deal takes months to mature and buyers number in the hundreds, not millions. I joined streetlighting.sundrax.com when Next.js development had been running for over six months — and Google had been watching the construction site the whole time: the project was never closed to robots, so test pages, duplicates and empty sections had made it into the index.



## First, resuscitation


Before any talk of growth, the bleeding had to stop. Cleaning the junk out of the index created a second problem — mass 404s eating the crawl budget and the search engine's trust. I set up correct redirects and error handling, then wrote and shipped a technical spec for Next.js: server-side rendering, meta tags, Schema.org markup for the products. The foundation stopped crumbling — now something could be built on it.







## PPC as reconnaissance for SEO


Waiting for organic data in a niche with this deal cycle means losing a year. I launched Google Ads not for leads but for data: within weeks, paid traffic showed which "Smart Street Lighting" queries convert and which bring onlookers. Landing pages were optimised on real buyer behaviour — long before organic traffic could have produced the same statistics.



## Authority you cannot buy with links


In an engineering B2B niche, decisions are made by specialists — they need expertise, not "texts for the search engine". The bet was E-E-A-T: an expert blog, a series of niche podcasts placed on trusted platforms including Apple Podcasts, our own Google Group, and a live presence on industry forums and directories. Every element worked twice: reach inside the community, and natural, authoritative backlinks.





## The result: November 2023 — February 2025




- Technical errors eliminated completely; indexation of the Next.js site is stable.

- Domain Rating grew from 31 to 56.

- Organic search became a sales channel: a steady 2–4 signed contracts a week — from organic alone, ads not counted.



For a B2B manufacturer with a long deal cycle, this is what SEO is for: not rankings for their own sake, but a predictable flow of contracts from search. If your site was built with no thought for search engines — it is treatable: resuscitation first, then data, then authority.

---

# tptseo.tools: SEO analytics for a marketplace Ahrefs can't see

- Type: case study
- URL: https://safianov.com/cases/tptseotools-seo-analytics-for-a-marketplace-ahrefs-cant-see/
- Summary: From two household scripts to a free public SaaS: daily rank tracking, SERP benchmarks and demand data for TeachersPayTeachers sellers — built solo on Python and Django, running on voluntary donations.

TeachersPayTeachers is a marketplace where millions of teachers sell their own learning materials. It runs its own search — Algolia under the hood, with its own ranking rules — and no mainstream SEO suite looks inside it. Ahrefs and Semrush see Google; they do not see the TpT results page. Even TpT's native Search Analytics only looks backward: it reports what has already happened to your store. It cannot tell you what to build next.



## From household scripts to a product


The first scripts were written at my wife's request, for her TpT store: check positions, look at competitors. Once it was clear that every seller needs these answers and nobody gets them by hand, the scripts grew into tptseo.tools — a working SaaS with accounts, a dashboard, and a daily data pipeline.




## The tools, by the job they do




- Keyword Suggestions — find demand before you create. Ideas come from TpT's own live autocomplete and Google Ads data: what teachers actually type, not guesses. A single seed like "3rd grade math" fans out into the phrases buyers use.

- Keyword SERP Analysis — see what the top really takes. For any phrase the tool benchmarks the top-20 products: description length, ratings, downloads, pricing. One real example: 12,000 competing results, and the leaders average a 3,665-character description, a 4.9 rating and 28,298 downloads at $22.82. That is the bar — visible before you spend a month making the product.

- Product Analyser — a listing diagnosis in one paste. Drop in a link to any product, yours or a competitor's, and get its SEO signals laid out.

- Keyword Monitoring — positions without manual checking. Daily checks of every tracked keyword, with a Telegram alert when something moves. A seller learns about a drop the day it happens — not a month later from a sales report.



## The result — and an honest one


The service runs unattended: scheduled checks on headless browsers cover every active user daily. I did try paid plans — the niche was not ready to pay for SEO, and I made the service completely free. It lives on voluntary donations, and sellers keep finding it, signing up and building their store SEO on its data. As a business experiment it failed; as a product, a data pipeline and a marketing lab it works every day.


The most honest proof of demand happened on its own: the service spent almost a year down with a 404 — and when it came back, sellers returned without a single email or banner. Today it gets three sign-ups a day, all organic.


The point of this case is not TpT. It is that a niche platform "without tools" is a solvable problem: the data can be collected, the metrics can be built, and the routine can be automated — by one person who does both the marketing and the code.