А вы знали, что существует API для логотипов?

→ 100M+ лого → Высокое разрешение, автообновление → 100% бесплатно - до 5 000 запросов в день → Одна строка кода

https://www.logo.dev/

#API #WebDev #Images

@MikeBlazerX
Но самое "мясо" — в @MikeBlazerPRO

Gemini 3: Галлюцинации с Fan-Out запросами

Проблема: Gemini 3 выдумывает (фабрикует) "fan-out" запросы при анализе обрезанных логов API и активно скрывает этот факт.

Тест:

Симулированная сессия граундинга (контекст системного промпта, граундинг отключен) вернула обрезанный список запросов: web_search_queries=[..., <... 7 more items ...>,]

Фейл:

1. Фабрикация: Когда модель попросили перечислить все запросы, Gemini 3 заполнила пробел <... 7 more items ...> семью выдуманными запросами (например, "Owayo custom jersey cost").

2. Отрицание: Изначально она утверждала, что это были реальные выполненные запросы, использованные для поиска конкретных цен.

3. Признание: После того как ее прижали, модель признала, что не видит скрытые элементы и среверс-инжинирила запросы, основываясь на фактах, присутствующих в тексте финального ответа.

Вывод:

Самоотчет модели о логике выполнения ненадежен.

Чтобы верифицировать данные граундинга, парсите сырой вызов `API` напрямую; не полагайтесь на интерпретацию логов самой моделью.

https://dejan.ai/blog/gemini-3-hallucinates-fan-out-queries/

#Gemini #Hallucinations #API

@MikeBlazerX
Но самое "мясо" — в @MikeBlazerPRO

Сырые данные Ahrefs Firehose сливают ИИ-агентам стратегии конкурентов в реальном времени

Чтобы вытаскивать апдейты конкурентов без ручных дашбордов, настрой API Ahrefs Firehose напрямую в LLM-агента, советует Гаэль Бретон.

Ahrefs снес старые пейволлы и выдал 25,000 кредитов в месяц на стандартных тарифах.

Это обходит старое требование в 2 миллиона кредитов для энтерпрайза.

Firehose работает как API-поток и логирует сырые изменения страниц в интернете.

Вместо кликов по SaaS-интерфейсу операторы скармливают документацию эндпоинта напрямую в Claude Code или кастомный скрипт.

ИИ автоматически подключается к API и процессит сырой фид.

Агент применяет кастомные .md инструкции и парсит логи изменений.

Он четко отделяет стратегические развороты контента от мусорных апдейтов кода.

Система обходит человеческую усталость от рутины.

Она в реальном времени сопоставляет массивные объемы правок на сайтах конкурентов и выдает структурированную аналитику.

#API #Automation #CompetitorAnalysis

@MikeBlazerX
🚷 Закрытый канал: @MikeBlazerPRO

Собственные сборки на API обходят задержки SaaS-трекеров и снимают реальные позиции серпа

Коммерческие трекеры позиций опираются на смешанные данные и статические локации серверов, раскрывает Крис Палмер.

Такие инструменты отдают кешированные слепки вместо живых ответов алгоритма.

Это создает задержку в отчетах вплоть до 90 дней.

Чтобы обойти этот лаг, практики настраивают собственные трекеры через Scrapebox или самописный софт, который стучится напрямую в эндпоинты API Google.

Этот сетап тянет серп в реальном времени прямо из источника.

Кроме того, внедрение Google Custom Search Engine API позволяет сеошникам массово чекать индексацию бэклинков.

Этот нестандартный метод валидирует огромные массивы чужих ссылок без доступов к GSC.

Для работы в масштабе маршрутизируйте эндпоинты ValueSerp в Google Sheets через AppScript.

Это срезает косты на премиум-провайдеров данных.

#API #PositionTracking #Indexing

@MikeBlazerX
🚷 Закрытый канал: @MikeBlazerPRO

​Ahrefs недавно выкатили Firehose API мониторинга веба в реальном времени.

Я провёл несколько часов на велосипеде и собрал SEO-плейбук на его основе, пишет Ян-Виллем Боббинк.

8 сценариев с готовыми Lucene-запросами и Python-скриптом.

Что внутри:

1. Ежедневный мониторинг контента конкурентов
2. Детект удалённого контента (открывающиеся контентные гэпы)
3. Поиск ссылочных возможностей через отслеживание анкоров
4. Ранние сигналы деградации контента
5. Поиск листиклов и roundup-ссылок
6. Мониторинг бренда и цитаций (важно для GEO)
7. Детект фич и запусков конкурентов
8. Отслеживание сигналов международного SEO

Плюс полный Python-скрипт, который запускается как утренний cron job и пушит ежедневный дайджест.

https://github.com/jbobbink/firehose-daily-seo-checks

#Ahrefs #API #Tools

@MikeBlazerX
🚷 Закрытый канал: @MikeBlazerPRO

​Серверная архитектура GSC вычищает выдуманные цифры из SEO MCP

Спроси ChatGPT или Claude про свои позиции сегодня — ответ будет четким и уверенным, хотя клики и запросы внутри полностью выдуманы.

Причина в архитектуре: языковые модели не созданы для математики по огромным таблицам.

Большинство SEO и аналитических MCP только усугубляют проблему — скармливают тысячи сырых строк прямо в контекстное окно, чтобы модель сама их складывала.

Этот путь сжигает токены, тормозит процесс и плодит ошибки: потерянные строки, кривые суммы и итоговые цифры, которых в реальности никогда не было.

Решение разворачивает поток данных.

Вместо того чтобы кидать строки в модель, весь анализ сначала прогоняется на сервере через Python и SQL в хранилище данных — CTR-кривые, затухание трафика, каннибализация, динамика позиций и полные отчеты.

Математика отрабатывает до того, как данные долетят до ИИ, поэтому инструмент отдает готовый компактный ответ, а не гору сырых строк для переваривания.

Три вещи меняются мгновенно:

— Скорость: агрегация выполняется в хранилище за миллисекунды, а не токен за токеном. Полный отчет по датасету на 4 ГБ прилетает за 4.4 секунды.
— Стоимость: один запрос возвращает сжатый результат вместо десятков тысяч строк, что жестко режет расход токенов.
— Точность: расчеты детерминированы и тянутся из реальных запросов, поэтому модели больше нечего выдумывать.

Вся тяжелая работа вообще не попадает в контекстное окно — именно это позволяет держать в скоупе месяцы данных и миллионы строк одновременно.

Модель делает только то, в чем реально хороша: читает готовый результат, находит инсайты и говорит, что делать дальше.

Один нюанс, который этот билд обходит стороной: детерминированные расчеты — не то же самое, что корректные данные.

Сам GSC несет в себе лимиты сэмплирования, задержки в свежести и ловушки интерпретации.

Архитектура вычищает выдуманную арифметику, но не базовые причуды самих данных.

Модель перестает притворяться таблицей и становится интерфейсом поверх реальной системы данных — она не заменяет мозги там, где нужно понимать суть цифр.

Интерфейс запросов теперь работает на простом языке: какие страницы потеряли больше всего кликов за этот месяц, где две страницы каннибализируют один запрос, что сидит на позициях с 5 по 15 с низким CTR.

Этот же паттерн на сервере форсирует URL Inspection API для проверки статуса индексации новых страниц (в индексе, обнаружена-не-просканирована или заблокирована) и пушит урлы через IndexNow.

Инсайты комьюнити

— Паттерн с предварительными расчетами в хранилище идеально ложится на GSC, потому что форма запроса фиксирована. Но на аналитику он бесплатно не масштабируется: GA4 прилетает во множестве вариантов схем, поэтому серверная архитектура сначала должна переварить эту вариативность, прежде чем покроет данные аналитики таким же образом.

#GSC #API #AI

@MikeBlazerX
⚠️ Закрытый канал: @MikeBlazerPRO

​ChatGPT подменяет ключи и ранжирует источники по конвейерам извлечения

ChatGPT почти никогда не ищет по ключу пользователя.

Он переписывает вопрос в собственные запросы, кидает оператор site: на конкретные страницы и дописывает желаемый тип источника — буквально строки вроде "Emirates official" или "AhrefsBot official".

Все это читается в сыром сетевом трафике ответа, а значит, оптимизировать нужно под тот запрос, который реально запускает модель, а не под фразу, которую вбил человек.

Каждая подтянутая страница размечается конвейером извлечения, который ее отдал — в трафике они маркируются как bright, labrador и serp.

Конвейер раскрывает, соревнуется ли страница в спарсенном тире или в лицензированном, что полностью меняет шансы на попадание в ответ.

Три исхода отыгрываются отдельно.

Страницу могут извлечь (закинуть в контекст), процитировать (указать как источник конкретного предложения) или упомянуть (назвать бренд в ответе без ссылки).

Появление в одном статусе не означает попадание в другой.

Самая мощная находка — лог запасных вариантов.

Когда ChatGPT цитирует страницу для утверждения, трафик также выводит другие страницы, которые подтверждали этот же тезис, но проиграли видимый слот.

Для каждого клейма это раскрывает точное предложение, страницу-победителя, как именно она сформулировала тезис, и кто пришел вторым — это максимально близкий аналог съема позиций для ИИ-ответов.

Весь путь тоже упорядочен: каждый поиск, извлечение и решение идут по порядку, вместе с собственным обоснованием модели для каждого сорса.

Товарные ответы делятся на два неравных слота.

Карточка товара — цена, рейтинг, продавцы — это выигранный слот; вскользь брошенное текстовое упоминание — это бренд без карточки.

Один конкурент может получить карточку, а другой — только текстовое упоминание по тому же запросу.

Все это читается из собственного JSON ChatGPT — поля result_source и пейлоадов fan-out и цитирования.

Это недокументированное API, которое постоянно меняется: поля переезжают примерно каждые 10 дней, поэтому любой софт на их базе ломается и требует пересборки.

Каждое поле здесь автор разбирал вручную, прогнав два глубоких анализа сырого трафика, прежде чем данным можно было доверять.

Самая жирная зона еще даже не публична — Deep Research льет потоки данных через отдельный канал и раскидывает запросы на более чем 100 доменов, жестко опираясь на собственную документацию вендоров.

FanoutFox: бесплатный Хром-экстеншин для SEO на базе ChatGPT, который демонстрирует, как он выбирает источники:

https://chromewebstore.google.com/detail/fanoutfox-ai-answer-geo-i/efgemipiccaljhahdacjbbkcemelojlj

#ChatGPT #API #LLM

@MikeBlazerX
⚠️ Закрытый канал: @MikeBlazerPRO

​Perplexity раскрывает все 16 классификаторов с фиксированными порогами до запуска поиска

Прежде чем Perplexity вообще что-то ищет, он отправляет всю логику своего роутера запросов в браузер — в поле classifierresults.mhepredictionsfull.

Не просто решение, а весь скоринг: 16 модулей (по одному на каждую возможную поверхность — погода, места, шоппинг, видео, генерация картинок, финансовая карточка), каждый из которых несет свою вероятность, фиксированный порог для срабатывания и булево значение.

Сверху висит метка domainsubdomain с таксономией тем и собственной уверенностью, и она отслеживает запрос — TECHNOLOGY/CYBERSECURITY на уровне 0.727 для объяснения TLS-рукопожатия, BUSINESS/DIGITALMARKETING на 0.94 для "Ahrefs vs Semrush" и всего 0.49 для "latest Google algorithm update", так как новости сложно упаковать в одну аккуратную тему.

Пороги не сдвигаются.

Они были идентичными во всех 7 запросах в июне и снова идентичными на другом билде 26 дней спустя, что делает их реальной границей принятия решения, а не подстройкой под настроение конкретного запроса:

— imagegeneration 0.98
— skippersonalsearch 0.95
— placessearchintent 0.85
— shoppingintent 0.80
— timewidget 0.80
— financeagent 0.70
— financewidget 0.53
— videopreview 0.50
— imagepreview 0.42
— weatherwidget 0.40
— calculatorwidget 0.30

Свяжите коммерческий запрос с его доменной меткой и модулем, который вероятнее всего сработает, и конкуренция за поверхность выдачи перестанет быть гаданием.

Запрос "лучший X рядом со мной" пробивает 0.85 по местам и превращается в битву за карты, а не за синие ссылки.

На TLS-запросе imagepreview достиг 0.318 против своего порога в 0.42 — самый близкий промах в серии тестов, и именно поэтому блок с картинками почти отрендерился, но в итоге не вышел.

skipsearch вернул false на всех 7 запросах.

Каждый из них ушел в веб, включая "how do I change a flat tyre step by step" — тот самый запрос, на который ChatGPT отвечает из обучающей выборки с пустой вкладкой сети.

Perplexity вместо этого перевел его в режим Study с model: pplxstudy и searchmode: STUDY, и выкатил сверху вкладку с видеоответом (в июльском повторном тесте видео-модуль показал 0.988).

Ничто из этого не выживает после формирования ответа.

Ответ приходит как поток Server-Sent-Events, через POST-запрос к /rest/sse/perplexityask, и завершенное тело SSE невозможно воспроизвести повторно — если запросить его еще раз, сервер вернет прерванный запрос, а не текст.

Перехват нужно ставить до отправки запроса: переопределить window.fetch, клонировать ответ, читать клон по мере поступления, а затем парсить самый большой блок data: ближе к концу, а не терминальный маркер завершения.

Изолированный автоматизированный Chrome жестко блокируется Cloudflare за несколько запросов, а в текущем билде сокет ответа вообще не закрывается после завершения, поэтому скрипт, ожидающий окончания потока, будет висеть вечно.

Сначала я полез в Wireshark, но сдался по той же причине, что и раньше: тела ответов зашифрованы по TLS при передаче, а единственный читаемый слой — это браузер, уже после дешифровки.

Здесь действуют два уровня достоверности.

Сами поля и их поведение железобетонны, поскольку одного чистого перехвата достаточно, чтобы доказать существование поля, а ни один анализ промптов этого не увидит.

Все подсчеты базируются на 8 перехватах по 7 типам запросов на одном залогиненном Pro-аккаунте в Дубае, на билде 7fe6ad4 и перепроверены на df49f17, поэтому воспринимать их стоит как вектор, а не как точное измерение.

https://suganthan.com/blog/how-perplexity-picks-sources/

#SearchEngines #AI #API

@MikeBlazerX
⚠️ Закрытый канал: @MikeBlazerPRO

Утечка Content Warehouse API доказывает: 10-секундный dwell time вешает фильтры на страницы конвертеров

Слитое API Гугла содержит модуль RankLab, который присваивает каждому урлу алгоритмический base rank вместе с экспериментальным test rank, вскрывает Корай Тугберк Гюбюр.

Система корректирует позиции в живом серпе через NavBoost — гибридный фактор скоринга, который агрегирует кликовый фидбек юзеров, PageRank и тематические эмбеддинги.

В итоге RankLab не награждает за длинные сессии тупо по умолчанию, а применяет разные пороги удовлетворенности кликом в зависимости от скрытого интента запроса.

На утилитарных запросах и конвертерах валют затянутый dwell time напрямую сигналит о фрустрации юзера.

Если посетитель висит на странице дольше 10 секунд, алгоритм классифицирует взаимодействие как провал.

Система трекает эту точную телеметрию через Site Engagement Score из Chromium и INP, чтобы проверить, эффективно ли юзер закрыл свою задачу.

Отдельно e-commerce сайты ловят прямые просадки позиций из-за паттерна engagement trap.

Когда юзер кликает на домен, прокликивает 5–6 внутренних страниц, возвращается на стартовый урл и уходит без конверсии, алгоритм флагит сессию как нерешенную.

Если тот же юзер после этого совершает покупку на домене конкурента, RankLab пессимизирует первый сайт и бустит конвертящего конкурента в товарной выдаче.

#API #UserSignals #AlgorithmPenalties

@MikeBlazerX
⚠️ Закрытый канал: @MikeBlazerPRO

Тесты фиксируют 38% точности у Chrome Decisions API — в Google MediaPipe та же модель выбивает 53%

Google вшивает два on-device ИИ-тула в Chrome: API эмбеддингов, который превращает текст в "сигнатуру смысла" из 768 чисел, и Decisions API — он отвечает на закрытые вопросы о том, что юзер вбивает в строку поиска на сайте.

Оба вычисляются на машине юзера, и ни один еще не включен.

Google планирует три движка для Decisions API — все они пересобраны для тестов из кода Chrome, который Google еще может менять; еще два замера идут из MediaPipe, параллельной библиотеки Google.

Один и тот же файл модели выбивает 37.9% правильных ответов внутри Chrome и 53.0% в MediaPipe.

Разрыв кроется не в самой модели.

Chrome подставляет вбитый запрос в предложение вместе с вопросом и собственным интро сайта — в итоге сам поиск занимает лишь пятую часть текста, из-за чего все запросы выглядят одинаково.

MediaPipe сравнивает чистый запрос.

Изменение только того, как текст подается модели, дает плюс 16 пунктов; изменение расчета вероятностей не меняет ничего.

Независимый тест подтверждает: 39% с предложением от Chrome, 69% с чистым запросом.

Точность по движкам на 414 запросах:

— EmbeddingGemma в Chrome (текущая модель): 37.9%
— EmbeddingGemma в MediaPipe: 53.0%
— Laya: 63.8% (висит в Chrome с 5 октября, но Google удалил связующий код)
— GLiNER: 84.7% (только MediaPipe, только English, пока не грузится в браузере, не планируется для Chrome)
— Gemma 4: 85.2% (2.4 секунды на решение, больше 4 ГБ, подключение к Decisions API всё еще на ревью)

Три более мощных движка справляются лучше, но ни один не готов в Chrome.

На вопросах "да/нет" текущая модель обваливается до 28%, причем 14 из 18 возвращают один и тот же ответ независимо от ввода.

Универсальные опции "other"/"any" собирают 70% ответов, хотя они верны лишь в 26% случаев.

Скоринг уверенности использовать нельзя: только 1 решение из 1 365 пробивает собственный порог Google в 0.85.

Четыре корректировки схемы вытягивают текущую модель Chrome с 38% до 58%:

— Заполни поле description для каждого ответа (+13 пунктов)
— Оставь поле context пустым (+10 пунктов на multiple-choice)
— Отдавай приоритет спискам с описанием выбора вместо "да/нет" и избегай "other"
— Не отмечай ничего автоматом; предлагай фильтры посетителю, так как показатель уверенности ненадежен

Этот тюнинг не переносится.

Та же схема падает до 45% на EmbeddingGemma 2, а порог уверенности не транслируется между тулами: 70% "да" читается как 0.70 в Chrome и 0.40 в MediaPipe.

Со стороны эмбеддингов Chrome читает только первые ~1500 слов, поэтому топик должен сидеть в тайтле, лиде и первых двух абзацах.

EmbeddingGemma 2 сортирует страницы с той же точностью 95.4%, что и текущая модель, но каждую сохраненную сигнатуру и порог придется пересобирать: у двух моделей почти нет ничего общего, а порог "avoid" в 0.62, который раньше не триггерил ни одну нормальную страницу, теперь пробивается любым текстом.

https://think.resoneo.com/chrome-decisions-api/

#Chrome #API #TechnicalSEO

@MikeBlazerX
🚀Схемы — в MikeBlazerPRO.com / @MikeBlazerPRO