Mike Blazer

Mike Blazer pinned «SERP — это джунгли, где нет друзей, а есть только жёсткая пищевая цепь. Думаешь, твоя белая оптимизация спасёт от тех, кто юзает сливы из @MikeBlazerPRO? Систему можно честно переиграть, если бить в её уязвимости. Вот какие схемы ты упустил на этой неделе:…»

SERP — это джунгли, где нет друзей, а есть только жёсткая пищевая цепь. Думаешь, твоя белая оптимизация спасёт от тех, кто юзает сливы из @MikeBlazerPRO? Систему можно честно переиграть, если бить в её уязвимости. Вот какие схемы ты упустил на этой неделе: 1. Миллионы целевых доноров без прокси и серверов — методика, которая дает мгновенный доступ к сырым базам под простановку ссылок в обход классического ручного сбора. 2. Синтетический авторитет в эпоху AI-ответов — связка дистрибуции аудио- и текстового контента, которая заставляет нейросети считать вас лидером ниши без реальных заслуг. 3. Аппаратная изоляция против детекторов накрутки — как жесткое отключение одного сетевого протокола в браузере позволяет ботнетам безнаказанно фармить лайки на Reddit. 4. Выход из-под фильтра через прерывание цикла проверки — как отследить секретный трекинг поисковика и заставить алгоритм запустить массовую индексацию зависшего сайта. 5. Моментальная массовая индексация страниц без песочницы — контринтуитивный трюк с правами доступа, который заставляет Google применить повышенную толерантность к новому домену. 6. Броня от страйков и пессимизаций в высокорисковых нишах — перенос трафика в популярную стриминговую платформу, которая спокойно льет лидов, даже когда мани-сайт стерт из поиска. 7. Взлом фильтра аффилиатов через маркер предвзятости — как смена местоимений и один жесткий дисклеймер снимает санкции и доказывают Гуглу вашу подлинность. 8. Слив бюджета на мертвые площадки с накрученными цифрами — методика проверки, которая показывает, почему "трастовый" сайт с десятками тысяч визитов не передаст вам ни капли ссылочного веса. 9. Обход детекторов ИИ-контента через фейковую верстку — как смена структуры информационной статьи ломает визуальные классификаторы поисковика и моментально форсит дикий траст. 10. Ваши старые URL — это оружие в руках черных сеошников — как эксплуатация теневой памяти Гугла позволяет конкурентам ранжироваться по серой тематике прямо под вашим брендом. - Почти все, кто зашёл в PRO на старте, продлили доступ. Больше половины новых подписок приходят по рекомендациям от своих же. Люди не платят дважды за воду, они остаются за результат. Если знаешь тимлида, кому важен профит — перешли ему этот пост. Пусть он решает, кто будет забирать топ.

No comments #Humor @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO

​Большинство людей фокусируются на том, как LLM сканируют страницы. Меня всё больше интересует, что они на самом деле сохраняют после сканирования, пишет Акарш. Взгляните на этот ответ от системы ИИ-поиска. Вместо того чтобы хранить весь HTML целиком, одной из ключевых извлекаемых частей информации становится сниппет. Этот сниппет — не просто мета-дескрипшн. Это сгенерированное ИИ краткое содержание страницы, которое захватывает: ✅ Главную тему ✅ Важные сущности ✅ Ключевые выводы ✅ Контекст, помогающий определить релевантность А теперь подумайте о том, что происходит дальше. Когда кто-то спрашивает: "What's the best laptop for gaming"? LLM не читает тысячи веб-страниц с нуля каждый раз. Она сначала ищет по таким репрезентациям, как эти сниппеты, чтобы определить релевантные документы, прежде чем решить, какие страницы извлечь, проанализировать или процитировать. Подумайте об этом так. Прежде чем LLM решит, использовать ли ваш контент... Ей сначала нужно понять, о чём ваша страница. Это понимание в конечном итоге превращается во что-то вроде сниппета, который вы видите ниже. Если в этой репрезентации отсутствует ключевой контекст, сущности или выводы... У LLM может никогда не появиться повода вернуться на вашу страницу. Возможно, новая проблема оптимизации заключается не только в том: "Может ли Google просканировать мой контент"? Но и в том: "Может ли LLM точно представить мой контент"? Инсайты комьюнити — Сохранённые репрезентации страниц в системах ИИ-поиска обычно составляют около 1080 символов; сниппет заметно длиннее этого — редкость. — Показанный сниппет создаётся в процессе живого извлечения RAG во время запроса, а не вызывается из обучающих данных модели. #LLM #AI #SearchEngines @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO

​Common Crawl — это КРУПНЕЙШИЙ источник обучающих данных для LLM. Вот как за 5 минут проверить, попал ли ваш сайт в обучающие данные: Примечание автора: Чтобы получать подобные советы прямо на почту, подписывайтесь на рассылку по ссылке в моем профиле, пишет Крис Лонг. Джейсон Мелман вчера поделился классной фишкой на нашей внутренней встрече Nectiv. Common Crawl недавно выпустил гайд "The AI Visibility Audit" с действительно полезной информацией о том, как вашему сайту попасть в датасет Common Crawl. Для тех, кто не в курсе, Common Crawl — это, пожалуй, самый крупный источник данных для обучения LLM. Это огромный публичный ресурс, который большинство передовых моделей почти наверняка использовали для обучения своих баз знаний. Так вот, в статье они реально показывают, как через командную строку проверить, включен ли ваш сайт в последнюю версию Common Crawl. Звучит сложно, но на деле все довольно просто. Покажу пример проверки на DocuSign. 1. Откройте командную строку на вашем устройстве 2. Задайте домен: DOMAIN="docusign(dot)com" 3. Проверьте, есть ли у CCBot доступ к сайту: curl -A "CCBot/2.0" -I "https://$DOMAIN/" 4. Проверьте, есть ли домен в последней версии Common Crawl: curl "https://index(dot)commoncrawl(dot)org/CC-MAIN-2026-21-index?url=$DOMAIN/*&output=json" | head Затем вы получите ответ, по которому видно, включен ли ваш сайт в последнюю версию. Если вы видите, что ваш сайт есть в ответе, вы подтверждаете, что Common Crawl его подхватывает. Тогда у вас будет подтверждение того, могут ли LLM использовать ваш сайт в обучающих данных. Инсайты комьюнити — Присутствие в индексе Common Crawl подтверждает только crawlability, а не попадание в обучающую выборку. Утверждение из поста о том, что появление в индексе гарантирует использование сайта LLM, некорректно. AI-лаборатории прогоняют жесткую фильтрацию (dedup, классификаторы качества, perplexity filters) перед запуском обучения. В итоге малоценные страницы краулятся, но отбрасываются; плюс доступность для краулера никогда не гарантирует, что LLM обучится на этой странице, упомянет ее или сошлется. — Главный рычаг в 2026 году — это извлечение данных (retrieval), а не претрейн, так как обучающие выборки заморожены и содержат потери. Разрешайте CCBot, но также открывайте доступ для GPTBot, PerplexityBot, ClaudeBot и Google-Extended в robots.txt. — Сначала проверяйте robots.txt через curl. Сайты часто блочат CCBot из-за глобального запрета для AI-ботов, который автоматически вешает CDN или плагин безопасности, а потом удивляются, почему LLM их не видят. Проверяйте это, прежде чем списывать все на проблемы с контентом. — Дополнительный шаг проверки: скачайте полный отрендеренный сервером HTML с юзер-агентом CCBot, чтобы убедиться, что краулер получает реальный контент, а не пустую оболочку на JavaScript. Команда для Windows PowerShell: curl(dot)exe -A "CCBot/2.0 (https://commoncrawl(dot)org/faq/)" -L -sS "https://example(dot)com/" -o homepage-ccbot(dot)html, а затем откройте сохраненный файл. — Common Crawl работает на основе самостоятельного поиска — краулер сам находит контент, добавить сайт вручную нельзя. Эту базу чаще используют развивающиеся LLM, в то время как фундаментальные модели от OpenAI, Anthropic и Google опираются на нее меньше из-за большого количества дублей и слабой структурированности датасета. #AI #Crawling #Bots @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO

​Один классный трюк, если вы гоняете локальные LLM через Screaming Frog... Многие знают, что интеграцию Ollama можно натравить на локальную модель. Но мне кажется, мало кто в курсе, что можно также перепрофилировать интеграцию OpenAI. Достаточно поменять Server URL на другой совместимый с OpenAI эндпоинт, отмечает Крис Левер. Это значит, что один краулинг может параллельно использовать несколько локальных моделей. Теперь Screaming Frog может отправлять разные ИИ-задачи в разные локальные модели во время одного сканирования. Простое изменение в настройках, но оно позволяет задействовать куда больше ИИ при сканировании, и задачи не будут конкурировать за одну и ту же модель. Например: 🟢 Эндпоинт Ollama в SF → Gemma4 4B крутится на одной машине для быстрого обогащения в больших объемах. 🔵 Эндпоинт OpenAI в SF → Перенаправьте Server URL на OpenAI-совместимую модель, работающую на другой машине, например на еще одну Gemma4 4B через Ollama, LM Studio или другой совместимый сервер. Думаю, это открывает реально интересные возможности для более продвинутых рабочих процессов в техническом SEO. К тому же, вы можете фактически удвоить локальные ИИ-мощности внутри одного краулинга Screaming Frog, используя преимущества его отдельных интеграций провайдеров. #ScreamingFrog #LLM #TechnicalSEO @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO

​Медленный краулинг Screaming Frog снимает блокировки Cloudflare — подмена на Googlebot делает только хуже Если Screaming Frog отдаёт статус "too many requests" после первых ~50 URLs на мелком сайте (до 500 URL) на WordPress за Cloudflare (хостинг Cloudways) — это сработал лимит запросов, а не проблема SEO. Здоровая статистика краулинга в GSC подтверждает: блокировка идёт от защиты от ботов на стороне клиента. Снижение скорости краулинга в самом Screaming Frog до минимума реально снимает этот блок. Смена User-Agent краулера на Googlebot делает блокировку жёстче, а не мягче. Cloudflare сверяет IP запроса с официальными пулами Googlebot, а не просто смотрит на строку UA. Поэтому UA Googlebot с IP Screaming Frog читается как самозванец и отлетает в блок моментально. Надёжное решение — вайтлист на стороне клиента: пусть добавят краулер в белые списки Cloudflare, связав IP и UA, потому что правила только по IP работают криво. Полностью скипай правила по IP, если у машины для краулинга нет статического адреса — кастомный UA или bearer-токен держатся лучше при ротации адресов. Для анализа логов прогоняй логи сервера через Log File Analyser в Screaming Frog — он вообще не касается Cloudflare. И если твой краулер заблочен, это не значит, что заблочен Googlebot. Пока логи и GSC не показывают проблем — это просто система управления ботами Cloudflare, а не ошибки сканирования сайта. Инсайты комьюнити — Чтобы подтвердить, что причина именно в управлении ботами Cloudflare, настрой Screaming Frog на сбор заголовков ответа и ищи там заголовок bot score — его наличие показывает, что скоринг ботов Cloudflare активен, хотя это фича enterprise-уровня. — Обойти Cloudflare на объёме через curl-cffi или obscura больше не работает. Чтобы парсить сайты под защитой CF, которые активно блочат, теперь нужно управлять реальным профилем браузера. Screaming Frog не заточен под обход сайтов, которые не хотят, чтобы их парсили, поэтому меняй инструмент, если добавить в вайтлист не вариант. #BotBlocking #Crawling #TechnicalSEO @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO

​Миф о «токсичных ссылках» вредит вебу. Вот дружеское напоминание, почему это бред. Когда ты используешь крупные SEO-инструменты вроде Semrush, Majestic или SE Ranking, ты сталкиваешься с концепцией "токсичных бэклинков". Она основана на термине "неестественные ссылки", который Google ввел лет 15 назад и, судя по всему, уже перестал использовать. Сейчас в их документации фигурирует просто "ссылочный спам". Однако популярные SEO-инструменты заставили "неестественные ссылки" звучать еще хуже, окрестив их "токсичными ссылками". Semrush, например, в своем анализе бэклинков показывает, сколько твоих ссылок "потенциально токсичны" или точно токсичны. Это довольно пугающая формулировка и цвет (красный или оранжевый). Ниже ты видишь аудит бэклинков для немецкого поддомена самого Semrush. Как видишь, 94% их собственных входящих ссылок были помечены как токсичные. Поэтому, прежде чем паниковать, угрожать другим сайтам или отправлять их ссылки в дизавау, прими к сведению! Даже у лучших из нас (а Semrush — SEO-платформа номер один) преобладают токсичные ссылки, отмечает Тадеуш Шевчик. Инсайты комьюнити — Пингвин алгоритмически обесценивает спамные ссылки, а не пессимизирует принимающий сайт, если нет явного паттерна манипуляции. Превентивный дизавау по флагу от вендора может снести ссылки, которые тихо приносили целевой реферальный трафик. Оценка "токсичности" в инструменте маркирует домен, а не доказанный вред. — Google отошел от старой формулировки "неестественные ссылки" и преуменьшает значение "плохих ссылок", но "ссылочный спам" остается отдельной категорией, по которой они все еще принимают меры. — Оправданный сценарий для редкого использования дизавау: когда получаешь в наследство сайт с историей покупных ссылок, или для очистки аудита бэклинков, чтобы выявить реальные возможности для линкбилдинга. Ценность здесь — в гигиене аудита, а не в страхе перед фильтром. #ToxicLinks #Disavow #Backlinks @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO

Схема "прокладки": как отмыть любой трафик в трастовые реферальные сигналы от самого Гугла Главная боль сейчас — не позиции, а где взять качественный трафик, которому поверит алгоритм. Один из практиков спалил многоуровневую схему. Она отмывает любой твой траф в реферальный сигнал, исходящий как бы от самого Гугла. Трюк в том, КАК именно ты заводишь аудиторию на трастовый сервис. Не в лоб, а через специфическую прокладку. Алгоритм видит переход с родного доверенного ресурса и засчитывает его как мощный буст твоему мани-сайту. Схема масштабируется на разные сервисы экосистемы Гугла — все они работают как прокладки. Пока конкуренты скупают дорогие ссылки, инсайдеры отмывают мусорный трафик в сигналы максимального траста. Точная схема маршрутизации трафика через прокладку → @MikeBlazerPRO Действуй, пока конкуренты думают.

Взвешенный скоринг контента предсказывает вероятность топа-10 еще до публикации Прогоняй каждый черновик через восемь измеримых факторов: итоговая цифра предсказывает шансы на ранжирование достаточно точно, чтобы выступать фильтром для публикации. На выборке из 2400 текстов контент с оценкой 80+ баллов влетал в топ-10 в 82% случаев за три месяца (средняя позиция 5.3). Диапазон 60–79 баллов давал просадку до 54% (позиция 12.4). Ниже 60 баллов лишь 18% цеплялись за десятку (позиция 23.1). Собери формулу скоринга по 100-балльной шкале: 1. Объем 2000–3500 слов = 25 баллов 2. Структура, 5–8 заголовков H2 = 20 баллов 3. Оригинальные данные (статистика/исследования) = 20 баллов 4. Внутренняя перелинковка, от 3 релевантных ссылок = 15 баллов 5. Бэклинки на старте, от 2 штук = 10 баллов 6. Keyword difficulty ниже 30 = 5 баллов 7. Попадание в интент выше 90% = 5 баллов 8. Пройденные Core Web Vitals = 5 баллов Разрыв между лидерами и аутсайдерами не назовешь косметическим. Тексты в топ-10 в среднем имели 3240 слов, 7.2 заголовка H2, 87% содержали оригинальные данные, 4.1 внутренние ссылки, 2.3 бэклинка на старте, KD на уровне 24, 96% попадания в интент и 98% пройденных Core Web Vitals. Аутсайдеры выходили с 1450 словами, 2.1 H2, 12% с оригинальными данными, 0.4 внутренними ссылками, нулем бэклинков на запуске, KD 42, 68% попадания в интент и 64% успешных проверок. Самый мощный коррелирующий рычаг — ссылочное на старте: 3+ бэклинка при публикации коррелируют с ростом шансов на топ-10 на 156%. Это максимальный буст от одного фактора, обошедший попадание в интент (+92%) и оригинальные данные (+89%). В скоринге этому параметру отведено всего 10 баллов, но именно из-за его веса черновик на 78 баллов выдает лишь 54% вероятности зайти в десятку. Пересчитывай баллы перед публикацией: если текст пробивает ниже 70, вытащить его можно за счет глубины H2, аутрича на старте, сдвига на менее конкурентный ключ или сбора свежей фактуры. Публикуй строго от 75 баллов. Корреляция не означает причинность, и модель это учитывает: иногда слабый по баллам контент всё равно берет топ, а перекос в один фактор (например, только объем слов) ломает весь прогноз. Ценность системы в приоритизации: ты знаешь шансы черновика еще до слива бюджета на продвижение, хоть это и не дает гарантию ранжирования. #ContentStrategy #ContentOptimization #Rankings @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

​Эту метрику Tech SEO-специалистам и CTO нужно проверять до Core Web Vitals. Посмотри на этот график. Я обожаю этот график, пишет Нати Элимелех. Это прекрасный график. Три месяца статистики краулинга крупного сайта моего реального клиента. Самая наглядная демонстрация того, что управляет активностью гуглобота, которую я когда-либо видел. Две линии: — Оранжевая: Среднее время ответа (мс) — Синяя: Ежедневные запросы гуглобота Сценарий разыгрывается дважды, в противоположных направлениях: В апреле время ответа падает с ~500 мс до ~120 мс. Объем краулинга взлетает с ~15 тыс. в день до ~100 тыс. в день, почти мгновенно. В июле время ответа возвращается к ~500 мс. Объем краулинга падает обратно до ~15 тыс. в день. Зависимость работает в обе стороны. Время ответа меняется, а объем краулинга мгновенно движется в обратном направлении. Сервер здесь ни разу не был перегружен. За весь период не было ни 503-х статусов, ни всплесков ошибок. Google урезал краулинг исключительно из-за времени ответа. Время ответа лежит в основе Core Web Vitals. Оно напрямую влияет на LCP, поэтому быстрый ответ также подтягивает твой CWV. Это же время ответа задает твою пропускную способность сканирования и меняет ощущения реальных пользователей на странице. Исправь его — и всё это вырастет одновременно. И в отличие от большинства SEO-задач, это объективная цифра, с которой могут работать твои девы. Чем крупнее сайт, тем это важнее. На небольшом проекте медленный ответ едва ли заденет краулинг. Но на миллионах урлов эта задержка умножается на каждый из них. Поэтому, если ты ведешь крупный сайт и новые страницы слишком долго не сканируются и не заходят в индекс, это первое место, куда я бы посмотрел. До внутренней перелинковки или сайтмапов проверь, как твой сервер отвечает гуглоботу. Медленный ответ режет лимиты сканирования, и новые урлы — первое, что начинает голодать. Открой статистику сканирования в GSC. В первую очередь смотри на линию среднего времени ответа. СПАСИБО ЗА ВНИМАНИЕ К ЭТОМУ ВОПРОСУ. Инсайты комьюнити — Время ответа управляет лимитом краулингового бюджета (crawl limit). Вторая половина — потребность в краулинге (crawl demand) — зависит от того, насколько важными Google считает страницы: качество контента, брендовая частотка, ПФ. И именно здесь кроется максимальный эффект. — Среднее время ответа может вводить в заблуждение, когда смешиваются ответы API и HTML, поскольку HTML обычно отвечает медленнее. Размещение API на отдельном поддомене изолирует каждый тип для более чистой аналитики времени ответа и скорости краулинга. — Урезание краулинга из-за времени ответа имеет значение только там, где работает гуглобот: для пабликов, e-commerce и сайтов под SEO это критично, но для закрытых SaaS-систем с авторизацией или внутренних дашбордов это сводится к чистому UX (отзывчивости интерфейса). #CrawlBudget #ServerResponse #TechnicalSEO @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO

​AI Overviews забирают самый структурированный кусок с консенсусом — на качество текста им плевать Снимаем мистику с GEO: AI Overview — это тот же серп, просто с текстовой надстройкой. У него тот же базовый индекс, тот же перекос в сторону авторитета и та же механика консенсуса. Алгоритм разбивает один запрос на веер подзапросов, а семплирование токенов заставляет каждую генерацию расставлять цитаты немного иначе. Но этот рандом живет на этапе генерации, а не отбора. Пул источников, на которые машина сошлется по запросу, остается стабильным — а стабильный пул можно отреверсить. Метод сводится к объемам до анализа: собери ~30+ выдач по целевому запросу (в чистом профиле без логина, затем с логином, затем с мобилки) и логируй то, что повторяется — какие урлы цитируются и где они лежат в классическом серпе, как структурирован ответ, какие сущности выделены жирным, что всплывает при каждом рефреше, а что — только иногда. Stable Core — это то, что выпадает при каждом парсинге: источники, сущности и форматы, которые система считает обязательными. Попасть в пул — не значит получить цитату: страница может висеть в пуле кандидатов каждый раз, но появиться лишь в половине твоих выдач, потому что финальный выбор включает встроенный рандом. Когда Overview выделяет сущность жирным, он бесплатно отдает тебе карту значимости тех токенов, которым выдал максимальный вес. Затем отследи каждую страницу из Stable Core до конкретного пассажа, который вытянул Overview. Это редко бывает одно чистое предложение, потому что синтез сшивает куски со всей страницы или из разных источников. Единственный вопрос к каждому экстракту: почему этот кусок было легко забрать? Он сразу давал ответ, был самодостаточным, лежал под заголовком, точно совпадающим с запросом, в нужном для Overview формате и подтверждал данные других источников. Машина не оценивает экспертность или качество письма. Она цепляется за кусок, который проще всего спарсить и безопаснее всего привязать к источнику, потому что заземленный ответ спроектирован так, чтобы выдавать только то, что можно железобетонно подтвердить ссылками. Сетевой трафик самого Gemini раскрывает эту механику: извлеченный пассаж передается в атрибуте, который буквально называется snippets. Сборка идет по принципу "скопируй и добей", где есть два сценария провала. Слишком уникальный контент ломает консенсус, и ты вообще не попадаешь в пул; полная копия не дает машине ни одной причины менять уже проверенного лидера. Скопируй структуру, которую извлекает Overview, собери все сущности из Stable Core и правильно их свяжи (это дает тебе пропуск в пул), сверстай прямые ответы под заголовками из запросов и подтверди консенсусный ответ. Только после этого добавляй единственный дифференциатор: обновленную статистику, сущность, которую никто не покрыл, или таблицу, которая напрашивалась в ответе, но отсутствовала у конкурентов. Та же механика работает в ChatGPT, Claude, Gemini, Grok и Perplexity — трастовые источники меняются в зависимости от модели, но логика "извлечь и подтвердить" не меняется никогда. Входной барьер — это не возраст домена и не четырнадцать лет наработки авторитета. Страница с DR30, правильными сущностями, нужной структурой и одним куском реальной добавленной ценности может стоять в Overview рядом с брендами, сжигающими миллионы. Это окно возможностей из 2010 года, только сейчас на рынке крутятся рекордные корпоративные бюджеты, а большинство продавцов GEO-услуг не могут объяснить саму механику. И это окно будет закрываться по мере взросления моделей и коммодитизации тулзов. Сейчас главный защитный ров — это скорость и объемы итераций. Инсайты комьюнити — Идеальная структура лишь заставляет алгоритм распарсить страницу; вход в пул решает консенсус — но он сверяется с запросом, а эти запросы разговорные. Страница может иметь идеальную разметку, но пролететь мимо, потому что дает ответ канцелярским языком спецификаций, тогда как люди спрашивают простыми словами. #AIOverviews #GEO #SERPAnalysis @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO

​Бот-фильтр ГА4 — это текстовый файл на 40 КБ. Все думают, что Google тихо вычищает ботов из вашей аналитики. Так и есть — отчасти. Настройка "Exclude all hits from known bots and spiders" работает по списку известных нарушителей от IAB: текстовый файл с user-agent весом около 40 КБ, который обновляется раз в месяц. Если бот представляется — "Привет, я Googlebot" — его отбрасывают. На этом всё. Боты, о которых реально стоит беспокоиться, не представляются. Headless-браузер на Puppeteer или Playwright приходит с обычным user-agent Chrome, выполняет ваш JavaScript и выглядит в точности как человек. Его нет в списке, поэтому ГА4 фиксирует его как сеанс. Команда Plausible провела эксперимент. Они нагнали скриптовых ботов на ресурс ГА4 через headless Chrome — десять сессий меньше чем за десять секунд, очевидно, не люди. ГА4 записал 100% из них как реальный трафик. Одна пачка шла с user-agent, который буквально гласил "PostmanRuntime". Их тоже засчитали. Получается, фильтр отсекает ботов, которые никогда и не были проблемой, но пропускает тех, кто реально вредит. Цифры ГА4 годятся для отслеживания трендов. Хотите настроить раннее предупреждение внутри самого ГА4? Повесьте тег на navigator.webdriver в GTM. Большинство автоматизаций забывают его отключить, поэтому он тихо превращает часть ваших невидимых ботов в сегмент, за которым можно следить. Инсайты комьюнити — В полевых тестах флаг navigator.webdriver поймал лишь около 1% подтвержденных ботов, при этом примерно 99% обошли его — стелс-плагины для Puppeteer и Playwright сносят флаг в первую очередь, так что это ловит в основном самых ленивых. — Более надежный сигнал — client hints: Headless Chrome объявляет бренд "HeadlessChrome" в navigator.userAgentData.brands (и в заголовке sec-ch-ua при каждом запросе) даже когда строка UA подменена на обычный Chrome, а настоящий Chrome никогда не передает этот бренд. Пометьте это в той же настройке GTM, что и проверку webdriver. — Когда оба браузерных флага пропатчены, проверка по ASN выхватывает остаток: один тест отметил трафик из 18 сетей, и каждая из них оказалась хостинг-провайдером с нулем резидентных провайдеров. Проверки на стороне IP ловят то, что упускают браузерные флаги. #Bots #GoogleAnalytics #TechnicalSEO @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO

​Оптимальный LCP лежит в окне от 100 мс до 1 сек, а не в гугловских 2.5 сек Гугловский порог "хорошо" в 2.5 секунды для Largest Contentful Paint (LCP) строится на агрегированных данных миллионов сайтов. Он описывает, что считается быстрым в вакууме — алгоритм ничего не знает о ваших пользователях, вашем продукте или вашем показателе отказов. Месяц данных real-user monitoring (RUM) от десяти крупных онлайн-ритейлеров, где сессионный LCP сопоставили с показателем отказов по каждому сайту, показывает другую картину. У всех десяти оптимальный LCP — точка с наименьшим показателем отказов — оказался в диапазоне от 100 миллисекунд до 1 секунды. Каждый сайт фиксировал пик вовлеченности задолго до гугловской отметки в 2.5 секунды. Более того: для четырех из десяти сайтов плато производительности — момент, когда ускорение или замедление перестает влиять на отказы — начиналось раньше 2.5 секунд. К моменту, когда эти сайты достигали порога "хорошо" от Google, они уже фиксировали свой минимум по отказам: скорость удовлетворяла Гугл, но бизнес от этого уже ничего не выигрывал. По всем десяти сайтам старт плато варьировался от 500 мс до 5.6 сек. Ловушка в том, чтобы воспринимать 100 мс – 1 сек как новую цель для гонки — это такая же иллюзия, как и 2.5 сек. Главный вывод здесь — это методология, а не готовый таргет: собирайте собственные данные RUM, стройте график корреляции LCP и показателя отказов (или конверсий), ищите, где ваши отказы реально ниже всего и где начинается ваше плато. Ставьте цели на основе этих цифр, а не по метрике, выведенной из миллионов чужих сайтов, которыми вы не управляете. Связь между скоростью и бизнесом реальна: когда LCP или Interaction to Next Paint (INP) проседает, отказы растут, а конверсия падает. Ошибка — думать, что внешний бенчмарк обозначает финишную черту. Для четырех из этих десяти сайтов отметка в 2.5 секунды находилась далеко за пределами точки, где скорость перестала приносить прибыль. https://embrace.io/blog/research-core-web-vitals/ #CWV #LCP #SiteSpeed @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO

​ИИ-краулинг и трафик расходятся — главные страницы забирают в 15 раз больше ботов, а услуги получают х3 визитов Анализ 560 695 запросов ИИ-краулеров по 74 аккаунтам Cloudflare и 446 267 реферальных переходов от ИИ на 27 аккаунтах с тарифом Pro раскрывает разрыв, который бренды оптимизируют вслепую: то, что ИИ читает, и то, куда он отправляет живых юзеров — это два разных паттерна. Cloudflare стоит до GA4, поэтому реферальные переходы — это реальные клики, а не просто цитации. Главные страницы получают примерно в 15 раз больше ИИ-краулинга, чем предсказывает их доля в структуре урлов. С поправкой на то, что главная — это одна страница против десятков или сотен других, цифры просто зашкаливают: ничего похожего и близко нет. Вывод переворачивает привычный вопрос: где публиковать теперь важнее того, что публиковать. Хочешь, чтобы ИИ узнал что-то о бренде — вешай это на главную. Объем сайта почти идеально коррелирует со вниманием ИИ — корреляция 0.86 между общим числом урлов и запросами краулеров, без просадок и без эффекта сложного процента при масштабировании. Больше страниц — больше точек входа для совпадения с промптами. Впрочем, корреляция не абсолютная: некоторые сайты на 50 страниц собирают столько же запросов, сколько и тысячники. Скорее всего, дело в сильном присутствии бренда в обучающих данных или лучшей оптимизации страниц. Трафик показывает картину резче, чем краулинг, хотя данные по переходам взяты из меньшей выборки в 27 сайтов на тарифе Pro, так что воспринимай их как вектор. Страницы услуг и товаров собирают в среднем в 3 раза больше ИИ-трафика на страницу, чем типичная статья. ИИ читает и суммаризирует статьи, но по реферальным переходам они проигрывают главным страницам почти на 20%. Это Dark Library Effect — та же динамика нулевых поисков, которая перекроила классический поиск: юзеры с информационным интентом получают ответ прямо в выдаче и не кликают, тогда как коммерческий интент всё ещё заставляет людей переходить на главную или страницы услуг перед покупкой. При этом 47% всех страниц в датасете сгенерировали ноль переходов. Глубина папок накладывает налог на архитектуру. ИИ-краулеры без проблем находят страницы на третьем-четвертом уровне вложенности, но в реферальных данных тарифа Pro виден жесткий обвал: страница в трех папках от корня собирает около четверти ожидаемого ИИ-трафика, а на четвертом уровне эта цифра падает почти до нуля. Паттерн сохраняется независимо от размера сайта и типа страниц. Это корреляция, а не причинно-следственная связь — если просто вытащить страницу выше, это не нальет ей ИИ-трафика автоматом. Но при запуске нового проекта или переезде держать ключевые услуги в одном-двух кликах от главной — это железобетонная тактика. #LogFileAnalysis #Crawling #AI @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO

​Четыре метрики вычищают мусор из индекса и срезают микро-каннибализацию Штамповка страниц не качает тематический авторитет. Каждая лишняя страница задирает стоимость извлечения для Google и плодит микро-каннибализацию. Почти идентичные документы размазывают PageRank, историю кликов, релевантность запросу и сигналы GBP по страницам, которые дерутся за один интент. Тест Query Deserves a Page (QDP) — аналог алгоритма Query Deserves Freshness Амита Сингхала — решает, заслуживает ли вариация вроде "Nylon Glock Holster" отдельной страницы или ложится блоком внутри "Glock Holster". Вариация получает свой урл, только если пробивает четыре порога: — Высокий поисковый спрос — Разные сущности — Низкая схожесть запросов — Повторяющийся паттерн запроса Схожесть запросов — это не просто совпадение строк. Алгоритм взвешивает важность сущностей и поисковый спрос: BERT считает "Nike" тяжелее, чем "running" или "shoes". Поэтому ключ "Los Angeles Car Accident Attorney" нельзя разобрать, не понимая фактический вес "Los Angeles". Если самый тяжелый термин повторяется во всех вариациях, метрика низкой схожести падает — и эти вариации схлопываются в один документ. Данные подтверждают: удаление мусора дает рост. Агрегатор клиник с 4 000 000 непроиндексированных почти дублей снес лишние страницы — и вытащил 600 000 дополнительных кликов при неизменных показах. Мельбурнский сайт юристов по травмам склеил ~19 почти идентичных урлов [услуга]+[локация], собрав 232 новых ключа и подкинув 60 позиций. Вычистка дублей под конкретные запросы в нише аренды яхт дала 248% рост кликов, 37% рост показов и плюс 29% к средней позиции. Целься в самую важную пару "услуга-локация" прямо с главной — в страницу с максимальным PageRank и плотным краулингом — и усиливай точным или частичным вхождением ключа в домене или названии сайта. Google оценивает качество ресурса по исходящим с главной внутренним ссылкам; прокидывай линки на самые сильные "узлы качества" напрямую оттуда. Дальше сверяйся с четырьмя KPI краулинга: процент обхода HTML не ниже 99%; сумма 200 и 304 статусов от 99%; процент обнаружения выше 20%; 100% обходов HTML направляется только на индексируемые урлы с кодом 200, зашитые в sitemap и перелинковку. GSC раскрывает лишь около 30% реальных данных — за остальным лезь в сырые логи. Ценность страницы работает как гейт для тяжелых алгоритмов. Согласно антимонопольным показаниям Панду Наяка, Google не гоняет дорогие системы вроде RankBrain на мусорных документах — они получают только базовую проверку тематики и локальности. Быстрый сбор успешных кликов форсирует запуск этих тяжелых алгоритмов. https://searchengineland.com/how-semantics-and-topical-authority-improve-local-seo-482980 #Cannibalization #CrawlBudget #Crawling @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO

Белые сеошники покорно ждут апдейтов, а подписчики @MikeBlazerPRO берут нечестное преимущество. Ты уверен, что твой опыт перекроет закрытую инфу с PRO? Только в PRO сливаются темы, которые рушат любые твои привычные подходы. Вот что прошло мимо тебя на этой неделе: 1. Гео-математический взлом Local Pack — как вычисление невидимой "зоны отвала" и одна точная координата заставляют алгоритм искусственно расширять ваш радиус присутствия. 2. Визуальный спуфинг AI-краулеров — как внедрение фейкового интерактивного элемента в самый верх исходного кода заставляет систему классифицировать обычную текстовую страницу как полезный инструмент. 3. Генерация авторитетной сущности за сутки — специфическая цепочка промптов, которая заставляет ИИ панически склеить ваш ноунейм-бренд с признанными трастовыми брендами и выкатить вам панель знаний. 4. Пессимизация за сдвиг макета в глазах краулера — как отсутствие одного ограничителя в стилях CSS заставляет бота физически опустить ваш текст в "подвал" и лишить его ранжирующего веса. 5. Автоматизированный хак институционального траста — сливаю схему, как абузить слепые зоны чужих сайтов и забирать элитный авторитет, который не сгорает после окончания контракта. 6. Брутфорс системы модерации Google Maps — как архитектурная уязвимость тикет-системы позволяет сносить негатив за счет искусственного перегруза ручной очереди проверок. 7. Буст внутренних страниц грубой силой — забытое примитивное структурное решение на мобильной версии, которое до сих пор пашет и вливает чистый ссылочный вес в нужные URL. 8. Многофазная инъекция ПФ для рывка позиций — логическая дыра, позволяющая скормить системе синтетический спрос и вытащить URL из жопы в топ. 9. Слепая зона мультимодального поиска — как серверная жадность Гугла позволяет старым доменам ранжировать любой нерелевантный визуал, пробивая фильтры проверки картинок. 10. Алгоритмический захват фичерд-сниппетов — особая архитектура связей в тексте, которая генерирует уникальные факты и намертво пробивает фильтры на бессмысленный переспам. - Здесь нет теории — только мясо, которое даёт реальный рычаг. Разрыв между твоим подходом и реальностью растёт с каждым днём. Оставаться на месте сейчас — значит откатываться назад. В PRO не учат SEO, в PRO вооружают. Перестань быть зрителем. Приходи прямо сейчас!

Тот момент, когда ты пережил очередную рабочую неделю и осознаешь, что уже пятница #Humor @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO

​🚨 Фрилансеры, агентства и разработчики: это была довольно сложная новая попытка взлома, которая пришла под видом лида от клиента! 🚨 Мы получили письмо от "потенциального клиента" Омара Хашема из Nemo IT Solutions. Обычное на первый взгляд сообщение с брифом по проекту, правдоподобными деталями (сроки, бюджет и т. д.), рассказывает Марк Уильямс-Кук. Они также прислали zip-архив, содержащий стандартные с виду документы по проекту и NDA (файлы .md). Но благодаря быстрой проверке безопасности мы избежали абсолютной катастрофы от крайне опасной атаки через репозиторий. Вот как работает эта схема: 🎣 Подготовка Новый клиент обращается за оценкой проекта. Он присылает репозиторий или архив с безобидной на вид документацией, утверждая, что внутри спрятаны технические детали или NDA. 🪤 Скрытая ловушка Вы не знаете, но в папке скрыта директория .git. Мошенники намеренно заразили папку .git/hooks/, жестко привязав вредоносные скрипты к рутинным командам вроде commit-msg, pre-push и post-checkout. 💥 Полезная нагрузка Как только вы открываете эту папку в локальном терминале и запускаете стандартную команду Git, скрипт, замаскированный под файл-пример, тихо выполняется в фоне. Он мгновенно определяет вашу операционную систему (Windows, Mac или Linux) и запускает скрытую команду PowerShell или Bash для загрузки и выполнения удаленного кода по внешней ссылке. Вам даже не нужно компилировать или запускать их код, чтобы заразиться. Выполнение обычной команды git checkout или git status на локальной машине уже запускает взлом. Будьте осторожны! Отличная работа нашего консультанта по безопасности Джона Скиннера — он вовремя это заметил. Инсайты комьюнити — Вредоносная полезная нагрузка пришла по ссылке на Dropbox во втором письме, а не прямым вложением. Это произошло после нормального на первый взгляд первичного запроса, что стало одним из признаков поддельного лида. — Параллельный вариант фишинга: реальная (но подделанная) компания присылает ссылку на бронирование в Calendly. Она ведет на фейковый логин Google, где пароль нужно вводить вручную, тогда как легитимный Google OAuth подключается автоматически без повторного ввода. Признаки: домен отправителя похож на реальный, но не совпадает, а при наведении на кнопку закрытия логина появляются русские символы. — Эвристика обнаружения: входящий бриф с детально прописанным бюджетом, сроками, пошаговыми результатами и файлами .md должен немедленно вызывать подозрения. — Открывайте непроверенные репозитории и файлы только в песочнице; скрипты для кражи данных, написанные ИИ-агентами, сделали тихий слив информации рутиной. #Security #WebDev #SEOAgency @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO