Mike Blazer

​Я отслеживаю Bing и Yandex на сайтах, где они почти не дают кликов, рассказывает Ян-Виллем Боббинк. Я продолжаю это делать, потому что они показывают, когда проблема именно в Google (с 28-летием!). Когда клики падают в GSC, причиной может быть кор-апдейт, самостоятельный выбор каноникала со стороны Google, блокировка Googlebot на уровне CDN или реальная техническая проблема, с которой столкнется каждый краулер. GSC в одиночку не может сказать, в чем именно дело, потому что вам не с чем сравнивать. Bing и Yandex сканируют те же URL и обращаются к тем же серверам, но у них своя логика ранжирования и каноникализации. Я никогда не сравниваю их клики, так как они слишком малы, но каждую неделю сравниваю статусы индексации и ошибки сканирования во всех трех поисковиках. Если проиндексированные страницы падают во всех трех одновременно, я в первую очередь смотрю на свой сайт, потому что такой паттерн обычно означает изменения в robots.txt, сломанный сайтмап, случайный noindex или ошибки сервера. Если падает только Google, а Bing и Yandex остаются на месте, с сайтом, скорее всего, всё в порядке, и я начинаю копать в сторону Google. Каждый поисковик также репортит некоторые проблемы лучше, чем Google: 1. Yandex точно говорит, почему страница вылетела из индекса, указывая такие причины, как группировка зеркал, обработка Clean-param или noindex, для до 50.000 URL через свой API. 2. Bing разделяет ошибки сканирования на сбои DNS, таймауты и коды состояния, а его отчет AI Performance показывает, какие страницы цитирует Copilot и для каких опорных запросов. 3. IndexNow доходит до Bing и Yandex, но не до Google, поэтому, когда Bing индексирует новую страницу за несколько часов, а Google не индексирует ее вообще, я знаю, что страница рендерится нормально, а задержка связана с краулинговым спросом Google. Запуск трех API не делает позиции в Bing прокси для позиций в Google, и поисковики постоянно расходятся во мнениях по причинам, не связанным с вашим сайтом. Для меня ценность именно в паттерне по всем трем поисковикам. Успешной оптимизации! Инсайты комьюнити — Не каждый API возвращает данные, необходимые для сравнения трех поисковиков: часть еженедельного трекинга идет через Google Indexing API, а агент, который логинится через браузер, парсит данные, которые API не отдают. — У ИИ-краулеров нет статуса индекса или отчета об ошибках, чтобы служить третьим контрольным показателем, оставляя логи доступа единственной контрольной группой; LLM собирают информацию через отдельные пути (обучение, RAG), и блокировка Common Crawl, вероятно, снижает представленность в обучающих данных. #TechnicalSEO #Crawling #LogFileAnalysis @MikeBlazerX 📈 "Пушки" — в @MikeBlazerPRO

Разница между сырым и отрендеренным кодом вскрывает контент, который AI-краулеры скипают по умолчанию Контент, который подгружается только после отработки JavaScript, может тихо выкинуть бренд из ответов ИИ. Двойной парсинг страницы — без JS и с рендером — точно изолирует, какой именно это контент. Cloudflare Browser Rendering поддерживает оба режима: запрос без JS показывает примерно то же самое, что получают боты ChatGPT, Claude и Perplexity, а парсинг с JS близок к тому, что Гугл видит после рендера. Отрендеренная версия обходится дорого, поэтому большинство AI-ботов её скипают. Джон Мюллер называет это сравнение хорошим прокси и отмечает, что Cloudflare не обязателен: Puppeteer запускает Chrome для скрипта, перехватывает сетевые запросы, проверяет каждый на разрешение в robots.txt и блокирует при необходимости. Тулзы, которые делают это без кастомного кода, вероятно, существуют. Механика сбоя абсолютно конкретна. В кейсе, переданном через вторые руки от сотрудника ИИ-платформы, клиент оказался единственным брендом, выпавшим из ответа ИИ, где перечислялись 10 брендов. Без JavaScript названия не было в HTML, так как JS подтягивал его в таблицу, поэтому AI-боты по умолчанию получали таблицу лишь с 9 брендами. Получив урл напрямую с инструкцией прочитать страницу целиком, ChatGPT выдал все 10: ChatGPT видит JS-контент только когда его форсируют, а не по умолчанию. Данные по конфликтам рендеринга AI-краулеров по умолчанию: — Анализ 500+ млн запросов GPTBot от Vercel зафиксировал нулевое выполнение JS. Тот же паттерн чистого сырого HTML актуален для ClaudeBot и PerplexityBot, что делает разницу между сырым и отрендеренным кодом рабочим прокси для всех трех: https://vercel.com/blog/the-rise-of-the-ai-crawler — Мюллер парирует со стороны логов: серверные логи показывают, что OpenAI уже давно рендерит как минимум часть страниц, и каждая ИИ-система, юзающая современный поисковик для граундинга, также имеет доступ к отрендеренной версии. Инсайты комьюнити — Отрендеренный гуглоботом HTML не стоит считать прокси для всех ИИ-ботов: разные краулеры по-разному парсят и рендерят. По возможности сравнивай сырой HTML и отрендеренный DOM под юзер-агентом каждого конкретного AI-бота — GPTBot, ClaudeBot, PerplexityBot — а не предполагай, что все они работают как гуглобот. — Если паттерн сырого HTML актуален для самостоятельных AI-ботов, то AI Overviews остается исключением: он наследует рендеринг гуглобота, поэтому отрендеренный на стороне клиента контент всё равно может туда попасть. #AICrawlers #JavaScript #Rendering @MikeBlazerX 📈 "Пушки" — в @MikeBlazerPRO

Я создал инструмент, который использует векторные эмбеддинги Bert Base Uncased в связке с косинусным сходством и евклидовым расстоянием, делится Кунджал Чохан. Он измеряет, насколько контент веб-страниц близок к целевому запросу. Вы вставляете текст, который система конвертирует в векторные эмбеддинги, а затем сравнивает векторный эмбеддинг одной страницы с другими, а также с целевым запросом. На базовом уровне это помогает оценить разрыв, указывая на неполноту контента. Это не значит, что одно только это всегда будет работать как сигнал ранжирования, поскольку мы знаем, что существуют сотни факторов; иногда мы видим, как авторитетный сайт ранжируется выше с малоценным контентом. Тем не менее, полнота контента, его богатство и покрытие сущностей — это тоже факторы ранжирования, и этот инструмент помогает оценить имеющийся разрыв или дистанцию. Косинусное сходство = Чем выше число, тем вы ближе Евклидово расстояние = Чем ниже число, тем вы ближе Вот ссылка на инструмент: https://contentvectordistancecorrelation-fe6hxfbywh9tcr2dnvhmdo.streamlit.app/ Видео тут. Инсайты комьюнити — Сначала считайте дистанцию эмбеддингов между запросами, а уже потом — от страницы к запросу: в одном списке ключей для школы танго шесть почти идентичных строк схлопнулись в одну страницу, а кластер вокруг 'private dance coach' без основного термина "tango" выделился как самая дорогая услуга, которую сортировка по основному термину скрывала. — Замер дистанции от всего контента до ключа оказался слишком зашумленным в тестах одной из команд; они остановились на кластеризации запросов в темы/подтемы с помощью графовых алгоритмов, после чего измеряли дистанцию до векторных саммари страниц. — Стоимость эмбеддингов составляет около $0.00002 за 1000 токенов или вообще бесплатно с sfr-embedding-mistral через Ollama; протестируйте более новую модель эмбеддингов, чем BERT base, на тех же страницах, прежде чем доверять дистанциям. #Tools #Embeddings #VectorSearch @MikeBlazerX 📈 "Пушки" — в @MikeBlazerPRO

Кривые ARIA-лейблы перебивают верстку — ChatGPT Agent кликает Cancel первым в 25 из 25 тестов Когда браузерный агент фейлится на сайте, это нигде не фиксируется: ни тикетов, ни логов, ни чистого сигнала в аналитике. В контролируемом тесте "Изменить документ" зеленая кнопка Save имела атрибут aria-label="Cancel", а серая кнопка Cancel — aria-label="Save the document". Задача: сохранить документ. ChatGPT Agent в Atlas кликнул Cancel первым действием в 25 из 25 запусков (март 2026 года). При этом Claude Computer Use и агент Perplexity в Comet уверенно жали Save в 25 из 25 случаев — Computer Use работает исключительно по скриншотам и вообще не читает ARIA. Этот раскол раскрывает скорее модальность восприятия, чем качество конкретного вендора. Трейс действий не показывает, на какое именно представление опирался агент, но следование кривому доступному имени вместо визуально очевидного Save — самая правдоподобная механика, пусть и не доказанная на 100%. Семантическая метадата остается частью исполняемого интерфейса: aria-label работает как сигнатура функции, и в этом случае она нагло врала. Неправильный ARIA хуже, чем его отсутствие — без доступного имени гибридный агент может поймать неопределенность и откатиться к визуальному контексту, а вот кривое имя спровоцировало ошибочное первое действие. Замените Cancel на Delete, и возможность восстановления уже не имеет значения. Такая страница получила бы почти идеальный балл в любом чекере готовности для агентов: у каждого контрола есть доступное имя, все роли валидны, при загрузке ничего не прыгает. Экспериментальный Lighthouse Agentic Browsing рапортует о коэффициенте прохождения, а не об успешном закрытии задачи от начала до конца. Правило label-content-name-mismatch в axe-core (WCAG 2.5.3) могло бы поймать эту ложь, но оно экспериментальное и по умолчанию отключено. Плюс ни одно правило не флагит лейбл, который совпадает с видимым текстом, но при этом неправильно описывает реальное действие кнопки. В 100 узконаправленных тестах на разных моделях модальность жестко определяла тип фейла: — Атрибут aria-hidden="true" на видимой кнопке Buy Now делает её невидимой для агентов, ориентированных на структуру, но остается очевидной для визуальных агентов. — Соседние кнопки с отступом до 4px не влияют на клики по элементам, но превращают точность визуальных агентов в бросок монетки. — Прозрачный оверлей с opacity:0 и pointer-events:auto проглатывает клики по координатам: средний успех всех агентов вырос с ~32% до ~41% с ноября 2025 по март 2026 года. — CSS-свойство content-visibility:hidden вырезает элементы из дерева доступности: успех вырос с ~24% до ~30%. Средний показатель успеха по всем тестам за время исследования скакнул с 30% до 60%. Поэтому каждый результат привязан к конкретной версии — это производная от версии сайта × задачи × агента × модели × локали. Фундаментальные фиксы нужно выкатывать до любых ставок на конкретный протокол: 1. Замените контролы на <div> и <span> реальными тегами <button> и <a>, и проверяйте ARIA на правдивость, а не на наличие. В первую очередь — кнопки деструктивных действий и оплат. 2. Сносите прозрачные оверлеи, начиная с баннеров куки-файлов и согласия на возраст. Сделайте состояния успеха и ошибки постоянными, а не всплывашками на четыре секунды. 3. Пропишите контракты задач под каждый сценарий ("добавить товар X в корзину", а не "использовать магазин"), прогоняйте их для каждой локали и добавьте тесты взаимодействия с агентами в CI/CD. 4. Зафиксируйте семантику на уровне дизайн-системы, чтобы каждый инстанс Button наследовал правильную роль и доступное имя. Рост оценки готовности с 30 до 100 не говорит ровным счетом ничего о том, завершил ли еще один агент хотя бы один чекаут. https://merj.com/blog/agent-interaction-research #AgenticSEO #AI #UX @MikeBlazerX 📈 "Пушки" — в @MikeBlazerPRO

​Утечка атрибутов QualityFringe раскрывает динамический порог качества для спорных запросов Утечка ContentWarehouse за май 2024 года показывает, что QualityFringeFringeQueryPriorPerDocData лежит внутри шардов индекса как PerDocData, а не в таблицах DocJoins на этапе после извлечения. Это значит, что скоринг спорного контента (fringe) отрабатывает за доли миллисекунды во время первичного сбора кандидатов. В рамках фреймворка автора атрибуты из этой схемы компилируют Search Quality Rater Guidelines в автоматические фильтры: — encodedFringePriorScore (целое число 0–1000): вероятность того, что запрос ищет маргинальный контент при условии возврата этого документа. encodedFringeSitePriorScore — аналогичная метрика на уровне домена. — encodedDaftScore (float 0–1): "Document About Fringe Topic", вовлеченность в псевдонауку или неподтвержденные заявления. — encodedChardXlqHoaxPrediction и encodedChardXlqYmylPrediction: предикты по фейкам и YMYL-дезинформации. — encodedPseudoraterPxlqScore: оценки асессоров, транслированные в предикты модели в пространстве pXLQ. — encodedProximityScore: векторное расстояние до известных "сидовых" маргинальных документов. — encodedDocumentFringeVulnerability и sensitiveEntitiesMids: порог и ID из Графа Знаний для отслеживаемых живых людей или уязвимых групп. Предложенная механика — это динамические пороги, а не баны доменов. Когда запрос демонстрирует повышенную чувствительность к маргинальным темам или триггерит уязвимую сущность, минимальный порог качества (Q*) взлетает, и документы ниже него вылетают из пула кандидатов. Контент, находящийся топологически близко к известным фейкам, наследует риск через близость, что тянет вниз оценки DAFT и pXLQ. На уровне сайта автор читает siteQualityStddev как дисперсию оценок качества страниц по всему домену: микс из фактологических статей и неподтвержденного мусора задирает разброс и рушит базовый траст. В итоге сайт пессимизируется за разброс качества, а не ранжируется только по своим лучшим материалам. Теорию подтверждают два внешних источника. Эксплойт эндпоинта от Марка Уильямса-Кука (2+ ТБ логов, 90 млн запросов) вскрыл метрику sitequality на уровне поддоменов со шкалой 0–1. Сайты с оценкой ниже 0.4 вылетают из фичерд сниппетов и PAA. Также он обнаружил questionfringescore, который гипотетически измеряет нетипичность запроса, и эндпоинты "консенсуса", оценивающие, совпадает ли контент с консенсусом в вебе, противоречит ему или остается нейтральным. Материалы суда DOJ против Google фиксируют, что RankEmbed и RankEmbedBERT обучались примерно на 70 днях логов поиска плюс ручных оценках. Выходит, оценки асессоров — это тренировочные данные, а не бенчмаркинг. Автор сразу обозначает жесткие лимиты: утечка раскрывает структуру данных, а не веса. Реальный множитель за siteQualityStddev неизвестен, а часть параметров может быть отключена. Впрочем, практический вывод железобетонный. Освещение спорных тем — это не то же самое, что маргинальный документ. Паттерн риска — это выдача неподтвержденных заявлений за установленный факт, связка YMYL-тематики со слабыми источниками или ведение домена, страницы которого дико скачут по качеству. Формулировки в рамках консенсуса, первоисточники и обработка неопределенности на странице — это те рычаги, которые контролирует паблишер. https://www.hobo-web.co.uk/google-fringe-query-classifier-framework-qualityfringe-from-2019-leaks-to-2024-api-schema/ #GoogleLeak #YMYL #Rankings @MikeBlazerX 📈 "Пушки" — в @MikeBlazerPRO

Проверка сайтмапов вскрыла мусор у топов — редиректы, noindex и шаблонные каноникалы Google заявляет, что будет "пытаться сканировать ваши URL точно так, как указано", поэтому каждая запись в сайтмапе, которая редиректит, выдает ошибку, содержит noindex или прокидывает другой каноникал, сжигает краулинговый бюджет на URL, который сайт сам же просит не использовать. Проверка в реальном времени через Sitemap Inspector (Chrome-расширение, которое фетчит URL из сайтмапа и фиксирует редиректы, ошибки, noindex, чужие каноникалы и правила гуглобота), запущенная 27 сентября 2026 года, вскрыла массовый провал у тех, кто должен делать всё идеально: — Adobe UK Learn: 978 страниц; 98 из первых 100 проверенных отдают каноникал на плейсхолдер, например /uk/learn/indesign/web/add-pages → /uk/learn/indesign/web/__template__. В том же файле 43 значения lastmod делят между собой больше 10 URL; самая частая отметка — в пределах двух минут августовским вечером, что с головой выдает пакетную выгрузку. — Anthropic: 537 URL, 21 под noindex (условия, приватность, политика использования), один 404, четыре редиректа. — Manchester City: 1964 страницы; 12 адресов задублированы с разными lastmod. Из первых 100 URL 17 отдают HTTP-ошибки, а 16 редиректят — в основном это страницы бывших игроков (одни клеятся на страницу состава, другие отдают 404). — GOV.UK: sitemap1.xml содержит 25 000 URL (лимит протокола — 50 000); 118 из первых 500 закрыты через noindex (почти всё — решения трибуналов с именами физлиц). Сам noindex явно задуман, баг кроется именно в добавлении этих урлов в сайтмап. — X: robots.txt ссылается на x.com/sitemap.xml, который вообще не отдает сайтмап. — Semrush: индекс из 23 сайтмапов, ноль lastmod, новостной сайтмап отдает 404, один урл редиректит 301 на продуктовую, а два элемента сами являются индексами сайтмапов, что прямо запрещено документацией Search Console. Semrush продает аудиты как раз для этого. Анализ делит косяки на два тира. Отсутствие lastmod, даты без времени или куча страниц с одной датой — это небрежно, но допустимо. Редиректы, ошибки, noindex и левые каноникалы — это тупо провал: сайтмап говорит "индексируй", а страница говорит "нет". Директивы priority и changefreq безвредны — это просто лишние байты, так как Google их игнорирует. Гипотеза автора о корне проблемы: сайтмап генерируется одной системой, а редиректы, каноникалы и noindex живут в другой. Никто не проверяет их синхронизацию, а поскольку файл проходит валидацию, внутрь больше не лезут. Обратный пример доказывает это: каждый проверенный автором сайтмап от Yoast SEO (плагина, который он создал) отрабатывает чисто, потому что этот же плагин прописывает каноникалы с noindex и сам вычищает всё, что запрещено к индексации. Шаблонный каноникал невидим при чтении сырого XML — его выводит на чистую воду только прямой фетч каждого URL. https://joost.blog/broken-sitemaps/ #Sitemaps #TechnicalSEO #Crawling @MikeBlazerX 📈 "Пушки" — в @MikeBlazerPRO

Закрыли очередную неделю в @MikeBlazerPRO. Основная причина, почему люди не подписываются — психология нищего — иллюзия халявы. "Не готов платить за инсайты". При этом платят цену -х20 за свои ошибки, плохие решения и просто тупость. Хотя 90% этих проблем можно было бы легко избежать... Вот что было разобрано за неделю: 1. Изолированная маршрутизация веса — как отрезать старую архитектуру донора и влить весь траст точечно в коммерческие ключи. 2. Реверс-инжиниринг графа сущностей — бесплатный системный эксплойт, который палит реальные связи сущностей под ранжирование по тысячам микро-НЧ запросов. 3. Автономная слежка за краулерами — инфраструктурный скрипт, который вскрывает реальные маршруты ботов и использует это для быстрой индексации страниц. 4. Обход физического радиуса на картах — как один скрытый атрибут привязки позволяет отжимать трафик из соседних районов без реальных адресов. 5. Доступ к 20 миллиардам визуальных поисков — как добавление одной специфической детали в фото форсит распознавание сущности и перехватывает трафик у стерильных эком-площадок. 6. Защита сеток от обнуления в апдейты -как черные ниши спасают агрессивную генерацию от спам-фильтров через искусственную эмуляцию одного показателя. 7. Отжатие выдачи у независимых сетей — как расщепление профиля бизнеса собирает весь локальный интент и монополизирует выдачу по конкретным услугам. 8. Вечный топ в специализированной выдаче — примитивный технический переключатель, который заставляет систему раз в неделю считать старый урл абсолютно новой сущностью. 9. Сотни аккаунтов вебмастера без банов — как инхаус-генератор кодов напрочь исключает человека из цепочки авторизации и спасает фермы от алгоритмических чисток. 10. Вывод из-под пессимизации DMCA за 24 часа вместо 5 месяцев — какой контринтуитивный микро-триггер сбрасывает баг в системе и вытаскивает урлы обратно в СЕРП. - Инструменты — это расход. Знание, как их юзать нестандартно — это преимущество. У всех один Screaming Frog. Не у всех есть схема, как им парсить висячие DNS. Разница — не в тулзах. Разница — в механиках использования. Либо вы платите за преимущество, либо вы платите за отставание. Второе всегда дороже.

Когда навайбкодил свой первый сайт и предвкушаешь его успех #Humor @MikeBlazerX 📈 "Пушки" — в @MikeBlazerPRO

​Spotify сократил счет за токены Claude Code на 90%. Затем они выложили свое решение в опенсорс. Инсайт почти скучный: большую часть дня кодинг-агент не думает. Он занимается вводом-выводом (I/O). Claude читает пять файлов, чтобы ответить на вопрос об одном. Он пишет тестовый файл, почти идентичный двадцати предыдущим. Это передовая модель, занимающаяся вводом данных. Вот как они это исправили: 1. Найдите рутину. Чтение файлов, шаблонные тесты, заглушки конфигов, обновление документации. Ни для чего из этого не нужны рассуждения. 2. Маршрутизируйте, а не апгрейдите. Вся рутина уходит дешевой рабочей модели (они использовали Gemini 2.5 Flash). Дорогая модель остается для задач, где она действительно нужна. 3. Всю работу делают два небольших режима. Один читает файлы и отдает буллиты. Второй пишет шаблонный код прямо на диск. Claude никогда не видит сырые файлы, поэтому за их чтение не приходится платить. 4. Принуждайте, а не предлагайте. В первой версии они зашили правила маршрутизации в конфиг. Claude прочитал их и проигнорировал. Рабочая версия блокирует дорогое чтение хуком (hook) еще до того, как оно произойдет. Что нельзя маршрутизировать: редактирование, дебаг, архитектуру. Дешевая модель пропустила неочевидный баг с потокобезопасностью (thread-safety), который передовая модель отловила за секунды. Блог разработчиков Spotify: https://engineering.atspotify.com/2026/9/portal-by-spotify-cut-my-claude-code-token-usage-by-90 Плагины (open source): https://github.com/spotify/portal-ai-plugins Дешевая модель для рутины. Дорогая — для принятия решений. Инсайты комьюнити — Практики оспаривают цифру из заголовка: попытки повторить подход с маршрутизацией экономят лишь несколько процентов токенов, а не 90% — изначальные 90% отражают экономию конкретно на массовом чтении файлов, что и близко не составляет большую часть общих затрат токенов за сессию. — Реальный рычаг экономии кроется в ограничении контекста, который скармливается дорогой модели, а не в самой замене на дешевую — перенос рутины на дешевую модель значит меньше, чем тот факт, что передовая модель просто не видит сырые файлы, которые ей иначе пришлось бы читать. — Выпущенные плагины — это не полная open-source копия сетапа: часть работы по сокращению токенов выполняет сам Portal, а не только выложенный в открытый доступ код. #Claude #Gemini #Automation @MikeBlazerX 📈 "Пушки" — в @MikeBlazerPRO

Jev просто безумен для SEO-аудитов 🤯 за 45.1 секунды он прочитал все 586 страниц на моем сайте и перестроил карту перелинковки, рассказывает Борха. роставил 584 ссылки, на 139 страниц отказался ссылаться, потому что честно ничего не подошло. общая стоимость $0.21. Claude Opus 5, те же 586 страниц, тот же тайминг, осилил 21 из них и потратил $1.43. в пересчете на страницу это примерно в 190 раз дешевле. полный проход Opus обошелся бы в $43. перелинковка — идеальная задача для Jev. это не генерация текста, это 8 790 ответов да/нет: есть ли у этой страницы реальная причина ссылаться на ту, и есть ли уже анкор в тексте. это задача классификации, а мы платили по тарифам флагманских моделей, чтобы делать это по одной странице за раз. то, что ты видишь: левая колонка — это Jev, правая — Opus, та же очередь, та же рубрикация. прогон останавливается в тот момент, когда Jev заканчивает, чтобы Opus перестал сжигать токены. #InternalLinking #AI #Audits @MikeBlazerX 📈 "Пушки" — в @MikeBlazerPRO

​Мульти-интентные урлы режут трафик — сплит страниц приносит на 23% и 73% больше кликов Годами Мюллер твердит, что одна сильная страница бьет четыре маленькие, а с внедрением passage ranking Гугл может оценивать отдельный блок текста сам по себе. Но есть условие: четыре маленькие страницы из примера Мюллера закрывали один интент, и там консолидация работает. Если урл пытается ранжироваться под два интента, три разные аудитории или четыре вариации продукта — этот совет перестает работать. Два кейса этого года: — На e-commerce сайте страницы категорий смешивали общую категорию, топовый бренд, самый дешевый вариант и гайд по выбору на одном урле. Каждую сузили до одного интента, остальное вынесли на отдельные страницы: получили 23% рост кликов год к году по всем страницам категорий. — SaaS-провайдер на страницах решений накрывал аудиторию и юзкейс одним документом. Разделение на отдельные страницы под аудиторию и под юзкейс, каждая со своей перелинковкой и ключами, принесло 73% рост кликов год к году. В B2B-кейсе результаты пошли уже через неделю: первые 10 разделенных страниц вышли в индекс за 3 дня. Когда запустили passage ranking, Мартин Сплитт назвал его самой неинтересной вещью для тех, кто понимает, что делает, и предостерег от слива тем в большие документы ради оптимизации под этот алгоритм. Passage ranking помогает Гуглу найти ответ внутри страницы; он не делает эту страницу лучшим результатом. Документ, который раскрывает тему на 20%, всё равно конкурирует со страницами, раскрывающими её на 100%, и сфокусированная страница выигрывает за счет тайтла, сниппета и ссылок. Passage ranking — это фоллбэк для страниц, где всё свалено в кучу, а не стратегия. Сплит также создает цели для внутренней перелинковки: ни одна страница не зайдет в топ-5 по запросу, если от нее требуют ранжироваться еще по шести другим темам. Как выбрать, что делить: 1. Разверни анализ каннибализации в обратную сторону. Каннибализация — это когда куча страниц бьется за один ключ; кандидат на сплит — одна страница, собирающая показы по нескольким несвязанным кластерам запросов. Инструмент GSC Wizard выводит и отчет по каннибализации, и анализ формы запросов по каждой странице. Два четких кластера интентов с частоткой на одном урле — кандидат идет в работу. 2. Проверь выдачу по каждому кластеру. Разные типы результатов или разные конкуренты означают, что Гугл видит здесь разные интенты; следуй за Гуглом. 3. Разделяй только тогда, когда новая страница может стать полноценным документом: уникальный тайтл, уникальный контент, свое место в навигации. Малоценный дубль хуже комбинированной страницы, и после августовского спам-апдейта это уже не теория. 4. Никаких 301-х редиректов. Исходный урл сохраняет основной интент и ссылается на новые страницы. Инсайты комьюнити — Практики расходятся во мнениях насчет редиректов: один подход проставляет 301-й редирект со старого урла на переопубликованную страницу по самой сильной теме и линкует дальше; другой — оставляет старый урл, чтобы сохранить накопленный траст. — Урл, выполняющий четыре задачи, — это обычно четыре типа контента на одном шаблоне. Разделение требует новых шаблонов, карты редиректов и решения по каждой внутренней ссылке на старый урл. Если оформить это как контентную задачу, через три недели она упадет на разработчика на полпути, поэтому закладывай косты на разработку до того, как согласуешь сплит. — В бельгийском e-commerce сплит делают дважды, для FR и NL, и интенты между языками редко совпадают один к одному. — Нерешенный риск: слишком мелкое дробление может спровоцировать Панду, тогда как LLM предпочитают очень узкие страницы; баланс между видимостью в LLM и SEO пока не найден. #ContentOptimization #SearchIntent #Cannibalization @MikeBlazerX 📈 "Пушки" — в @MikeBlazerPRO

​ИИ убивает надзаголовки (eyebrow heading), а это один из моих любимых SEO-трюков, пишет Даррен Шоу. Надзаголовок — это небольшая строка текста над главным заголовком страницы. Я люблю его для SEO, потому что могу сделать надзаголовок тегом H1 и вписать туда точные ключевые слова, например, "personal injury lawyer Dallas", а большой заголовок сделать цепляющим копирайтом для людей. И я стилизую большой заголовок через тег <span>, а не H1. Но сгенерированные ИИ сайты теперь используют надзаголовки ПОВСЮДУ, поэтому они начинают выглядеть как маркер ИИ-контента, вроде тире. И это бесит, потому что надзаголовки реально полезны для SEO, но теперь из-за них люди думают, что твоя страница — это ИИ-шлак. Мне плевать. Я продолжу их юзать. Борьба с системой ✊🏻 Инсайты комьюнити — Деталь, которую многие упускают при внедрении, — это разделение тегов между надзаголовком и визуальным заголовком: один получает тег H1, а другой стилизуется как <span>. Именно из-за упущения этой детали некоторые владельцы сайтов удивляются, почему тактика не дает буста в позициях. — То, что считывается как "маркер ИИ", — это сама визуальная стилизация в CSS, а не скрытый тег H1. Сохранение надзаголовка как H1 для SEO-целей при изменении его визуальной подачи в CSS позволяет избежать клейма ИИ-шлака без ущерба для SEO-структуры. — Гипотеза: системы Гугла, скорее всего, могут напрямую детектить паттерн "надзаголовок как H1" через анализ HTML/CSS (структура тегов, размер шрифта), хотя несет ли это какое-то снижение позиций — пока не подтверждено. #HeaderTags #AIContentDetection #OnPage @MikeBlazerX 📈 "Пушки" — в @MikeBlazerPRO

​Тег noindex на страницах пагинации отрезает краулер от каталога — в худшем случае отваливаются две трети сайта Запусти краулинг в Screaming Frog (или любом другом краулере), исключив все урлы пагинации вроде /page/2 и ?page=2, а затем сравни с обычным краулингом. Каждая исчезнувшая страница — это та, до которой Гугл может добраться только через пагинацию, и в крайних случаях это две трети сайта. Проставь noindex на этих страницах пагинации, и дорога ко всем ним исчезнет. Страницы пагинации — это точки доступа, а не контент. Именно через них Гугл добирается до глубоких страниц продуктов и статей, и именно так ссылочный вес перетекает на них. Точные шаги из этого: 1. Настрой каноникал каждой страницы пагинации саму на себя. Страница 2 должна говорить: "Я страница 2". Если она указывает на страницу 1 как на реальную, Гугл перестает заходить на вторую страницу, и всё, что доступно только с неё, становится страницей-сиротой. 2. Никогда не закрывай пагинацию через noindex, nofollow или блокировку от ботов. Гугл выбрасывает страницу, а затем перестает передавать сигналы через ее ссылки: индекс выглядит чище, а каталог становится сиротой. Комбинация noindex, follow не спасает, потому что со временем Гугл может начать относиться к ссылкам на noindex-странице как к nofollow. 3. Не бойся индексации страниц пагинации. Сами по себе они почти никогда не ранжируются, а весь профит оседает на продуктах и статьях внутри них. 4. Сделай кнопку "Далее" реальной ссылкой <a href> и по возможности рендери пагинацию на сервере. Отключи JavaScript и перезагрузи страницу: если номера страниц исчезают, примерно это и видит Гугл. 5. Никогда не используй # в урлах пагинации. Гугл игнорирует всё после решетки, поэтому /shoes#page=3 превращается просто в /shoes, а страниц с 2 по 50 не существует. 6. Параметры вроде ?page=2 работают, если параметр пагинации отделен от параметров фильтрации и сортировки, и каждый из них обрабатывается целенаправленно. 7. Бесконечный скролл отрабатывает хуже всего. Гугл не скроллит как живой юзер, поэтому продукты, подгружаемые только после скролла, могут вообще никогда не проиндексироваться. Если бесконечный скролл остается, добавь под ним реальные ссылки с номерами. 8. Пофикси структуру до пагинации. Блог, растянутый до 40-й страницы, имеет проблему с архитектурой: разбей его на категории, чтобы под каждой лежало по 10 постов, а не 400 под одной. 9. Добавь прямые ссылки. Блок "1 2 3 … 25" вместо одинокой кнопки "Далее" делает 25-ю страницу доступной в один клик вместо двадцати четырех. 10. Настраивай порядок осознанно. Первая страница получает максимум внимания, поэтому сортируй по выручке или трафику, а не по дефолту CMS. 11. Вычищай уникальный текст со страниц пагинации. Вводный абзац на четвертой странице может начать каннибализировать главную страницу категории. 12. Проверяй наличие дубля первой страницы. Многие CMS плодят и /shoes, и /shoes/page/1 — выбери что-то одно. Инсайты комьюнити — Практики расходятся во мнениях насчет noindex, follow. Один полевой отчет подтверждает: Гугл продолжает краулить закрытую от индексации пагинацию и урлы на ней, при этом пессимизации связанных страниц не наблюдается. Встречная позиция утверждает, что вдолгую это работает как noindex, nofollow. — Гибридный подход сохраняет краулинг при бесконечном скролле: каждый шаг подгружает новый урл с настроенными атрибутами rel-next/prev, поэтому у каждой страницы остается единая точка входа. — Самоканоникализированная пагинация имеет больший ссылочный вес на новостных сайтах, как для видимости, так и для прокачки тематического авторитета. #Pagination #Crawling #Canonical @MikeBlazerX 📈 "Пушки" — в @MikeBlazerPRO

​Если Гуглобот давно не читал XML-сайтмап (скажем, 253 дня)... это признак того, что системы Гугла считают урлы в сайтмапе "низкокачественными". Простая метрика в GSC, которую все упускают из виду. Но это может быть реальным индикатором того, что Гугл думает о твоем сайте. Помни, качество пронизывает всю их систему. От ранжирования до сайтмапов 😝. Инсайты комьюнити — Сегментируй урлы в сайтмапах по давности — выноси старые урлы в отдельный сайтмап, отдельно от часто обновляемых страниц, — чтобы проблемы с качеством сайтмапа было проще изолировать и анализировать. — Гипотеза: постоянная отправка технически битых или некачественных по контенту урлов сайтмапа заставляет Гуглобота снизить частоту краулинга. Оставлять индексируемую страницу "в разработке" открытой, с бэклинками и в сайтмапе — плохая идея по той же причине: это сжигает краулинговый бюджет и оттягивает запуск новой версии, что называют худшим решением в такой ситуации. #Crawling #Sitemaps #GoogleBot @MikeBlazerX 📈 "Пушки" — в @MikeBlazerPRO

​11 часов перелинковки выжимают +30% органических кликов без новых текстов и ссылок Сайт клиента закрыл август 2026 года на 123 222 органических кликах в месяц — на 30% выше августа 2025-го — после 11 часов работы с перелинковкой. За этот период не было ни нового контента, ни линкбилдинга. Правки контента затронули всего 3% ранжирующихся страниц, поэтому бóльшая часть роста — заслуга перелинковки. Прунинг вычищает страницы, которые тянут сайт на дно. Вырастут ли оставшиеся страницы — зависит от перелинковки, а большинство сайтов по-прежнему размазывают ссылочный вес по привычке. Навигация разрасталась вместе с оргструктурой, футер превратился в помойку, а блоки "похожее" ссылаются на то, что CMS выбрала еще в 2019 году. Изменения в порядке импакта: 1. Упрощенные пути навигации: меньше уровней, меньше боковых ссылок, меньше страниц конкурируют за один и тот же слот в меню. Справка Google просит лишь о том, чтобы каждая важная страница получала ссылку хотя бы с одной другой страницы. У большинства сайтов обратная проблема: сотни ссылок на страницу и никаких сигналов о том, какие из них реально важны. 2. Фокус на показах: цели для перелинковки выбираются по показам запросов, а не по кликам, потому что именно показы отражают спрос. Страница с 50 000 показов, относительно высокими позициями и 1% CTR обычно сидит в конкурентном серпе и требует больше внутренней поддержки, а не меньше. Страница с высокими кликами и низкими показами уже побеждает и ей больше не нужны ссылки из шаблонов. 3. Перехват со второй страницы: вытащи страницы, застрявшие на 8–15 позициях в GSC, оставь те, где есть реальные показы, и сошлись на них со страниц, которые уже ранжируются по этой теме. Используй описательные анкоры в тексте, а не в футере. Google заявляет, что внутренние анкоры не дают видимого эффекта в поиске, и само по себе это так. Но в связке с тематической релевантностью ссылающейся страницы — это самый надежный способ закинуть страницу в топ-5, не трогая контент. GSC Wizard подсвечивает этих кандидатов напрямую, но отфильтрованный экспорт из GSC тоже пашет. 4. Рутинная зачистка, которая бьет по: — внутренним ссылкам на 301-е и 404-е — страницам-сиротам, о которых знает сайтмап, но на которые никто не ссылается — анкорам "читать далее" и "кликни сюда" — ссылкам, которые рендерятся только через JavaScript и никогда не превращаются в полноценный <a href> для краулера — одному и тому же анкору, который ссылается на три разных урла Логика принятия решений: — Высокие показы, 8–15 позиции: добавь перелинковку с ранжирующихся страниц. — Уже в топе, низкие показы: не трогай. — Никогда не линковалась, никогда не ранжировалась: сноси или линкуй, но прими решение. Прогоняй симуляции внутреннего PageRank до и после каждого изменения. Симуляция заодно закрывает возражение "это просто апдейт алгоритма". Страницы, которые набрали PageRank, принесли бóльшую часть этих 30% роста, а те, с которых сняли ссылки, просели. Эта просадка была приемлемой, потому что эти страницы не генерили выручку. Инсайты комьюнити — Перед простановкой ссылок прогоняй кандидатов с 8–15 позиций через текущий контентный инвентарь. Некоторые страницы сдерживаются проблемами с канонизацией. — Не проверено, но подразумевает: ИИ-системы оценивают страницу отчасти по связанным страницам, которые на нее ссылаются, поэтому изолированный ответ несет меньше траста, чем поддерживаемый кластер. Если это так, эта же перелинковка влияет и на видимость в ИИ. #InternalLinking #Audits #TechnicalSEO @MikeBlazerX 📈 "Пушки" — в @MikeBlazerPRO

Это исследование показало, что блокировка "Google-Extended Bot" может привести к меньшему числу цитаций в AIO, вопреки заявлениям Google. https://arxiv.org/pdf/2604.27790 #BotBlocking #AIOverviews #GoogleBot @MikeBlazerX 📈 "Пушки" — в @MikeBlazerPRO

​Google заявляет, что AI Overviews в поиске создают лучший пользовательский опыт и "более качественные" клики. Нам прислали исследование, которое ясно показывает обратное, документирует Джейсон Кинт. — AI Overviews не улучшили удовлетворенность — и они не улучшили качество визитов — они просто сократили клики на источники Влияние на клики очевидно. Убери AI Overviews, и исходящие органические клики из поиска подскочат на 68% с 0.37 до 0.62 на поиск. Так что да, AI Overviews заменяют собой трафик на те источники, которые они парсят. С AI Overviews нулевые поиски становятся гораздо хуже. С AIOs: 73% поисков завершаются без клика на внешний сайт. Без AIOs: 54%... уходят в Google Zero, @reckless. Тот скандал с OpenAI и Microsoft в свете софитов — у Google та же проблема. А эти "цитаты" внутри AI Overviews? Они не решают проблему. Я слышал анекдотичные данные о том, что, возможно, подписки конвертятся лучше, но никаких данных в подтверждение этого не представлено. Атрибуция без значимого трафика или ценности — это не бизнес-модель. суть: ИИ-поиск — это не просто твик продукта. Он переписывает дискавери. Контент стал инпутом. Трафик исчезает. Ценность утекает к Google, если только паблишеры не установят свои условия. Незаконная монополия Google этого не допустит. https://digitalcontentnext.org/blog/2026/09/15/research-casts-doubt-on-ai-search-value-for-sites-and-searchers/ *** Да, рандомизированный эксперимент Агарвала-Сена подтверждает: AI Overviews срезают исходящие клики на ~40% без какого-либо измеримого роста показателей удовлетворенности или метрик качества визита, таких как время на сайте и отказы. Цитаты возвращают лишь малую часть потерянного трафика. Эти независимые причинно-следственные данные опровергают заявления Google об улучшении удовлетворенности пользователей и более качественных кликах, независимо от любых агрегированных трендов частотки. Инсайты комьюнити — Один паблишер сообщил, что отключил Gen AI в GSC и после этого не заметил падения трафика, позиционируя этот отказ как способ заморить ИИ-фичи голодом, лишив их инпутов. — Защита по брендовым запросам в платном поиске становится важнее, поскольку AI Overviews сжимают органический CTR: без выделенных ставок на бренд в поиске плюс Local Service Ads, блокирующих серп, конкуренты могут ставить на твои брендовые запросы и перехватывать их. — Отдельное августовское исследование показало: деградировавший опыт AI Mode заставляет некоторых пользователей сбегать в другие поисковики — эффект оттока, выходящий за рамки простого подавления кликов. #AIOverviews #ZeroClick #CTR @MikeBlazerX 📈 "Пушки" — в @MikeBlazerPRO

Мы только что опубликовали огромный бесплатный гайд от Man of Many на 65+ страниц по GEO — плейбук для маркетологов и агентств, чьи клиенты теперь спрашивают ИИ перед покупкой, пишет Скотт Пёрселл. Mumbrella любезно осветили эту новость. Мы написали его, потому что большая часть того, что продается как Generative Engine Optimisation, не выдерживает проверки данными. Поэтому мы привлекли почти 50 источников (AirOps, Semrush, Ahrefs, Similarweb, SparkToro, Ipsos, официальные заявления Гугла, Лили Рэй, Кевин Индиг, Рэнд Фишкин, наша внутренняя аналитика и многие другие!) и позволили фактам говорить за себя. Несколько выводов, которые должны изменить твой подход к бюджетам: — 85% упоминаний брендов в ответах ИИ приходят со сторонних сайтов, а не с собственного домена бренда. Паблишеры — крупнейший источник этих упоминаний. — 99% покупателей, ищущих информацию через ChatGPT, по-прежнему гуглят перед принятием решения (собственный опрос Гугла через Ipsos, 12 038 пользователей, 25 стран). — Две самые агрессивно продаваемые тактики не дают измеримого выхлопа. Внедрение микроразметки на 1885 страницах привело к падению цитируемости в AI Overviews на 4,6%. Файл llms.txt не показал никакой связи с цитированием на выборке из примерно 300 000 доменов. — Масштабирование ИИ-контента дает обратный эффект. Из 220+ сайтов, которые это сделали, 54% потеряли 30% или больше от своего пикового трафика. И наша собственная неудобная цифра: ИИ-ассистенты дают 0,59% сессий Man of Many. Полпроцента — это не канал. Любой, кто продает тебе стратегию ИИ-трафика, продает статистическую погрешность. Деньги лежат в цитировании, а не в кликах. Большую часть того, что ИИ говорит о твоем бренде, написал не ты. Это написали о тебе те паблишеры и обзорщики, которым модель научилась доверять. Хорошее SEO было хорошим GEO еще до появления ChatGPT. Гайд завершается 23 прикладными советами, каждый из которых подкреплен исследованием, а также методикой проверки того, могут ли твои страницы извлекаться ИИ-системами, и инструкцией по сбору in-house панели для отслеживания промптов. Ссылка на полный гайд: https://mumbrella.com.au/man-of-many-releases-guide-to-generative-engine-optimisation-for-brands-938081 #GEO #AIOverviews #AI @MikeBlazerX 📈 "Пушки" — в @MikeBlazerPRO

​Этот 6-месячный немецкий сайт с меню заработал $370 в августе при 58 000 просмотров. Монетизируется через Google AdSense. Это около $6.4 RPM. Владелец просто обозревает меню крупных сетей фастфуда. Сайт на 100% ИИ. Аудитория — Германия. Около 80% трафика идет из Google. Сайт на 100% ИИ. Аудитория — Германия. Около 80% трафика идет из Google. PS: Прикрепленные скрины взяты из официального листинга на Flippa. Flippa: https://flippa.com/13933449-speisekartemenus-de-6-month-old-website-monetized-with-google-adsense-guest-posting-german-menu-price-niche-perfect-for-earning-through-google-adsense Инсайты комьюнити — Полевые наблюдения указывают: сайт на 100% ИИ стабильно держится во время Helpful Content Updates, что говорит скорее о правильном выборе ниши, чем о факторе ИИ, несмотря на типичный риск санкций за сгенерированный контент. — 58 000 просмотров в месяц сгенерированы всего с 38 опубликованных страниц, что указывает на высокую концентрацию трафика на страницу. — Гипотеза: связка AdSense с партнерскими ссылками на локальные доставки может повысить RPM на контенте с меню такого типа. #AIContent #Affiliate #CaseStudies @MikeBlazerX 📈 "Пушки" — в @MikeBlazerPRO

​В твоих данных из GSC полно мусора. Я написал бесплатный инструмент, чтобы это исправить, пишет Сугантан Моханадасан. Выгрузка из GSC может содержать 100 000+ запросов. Но это не значит, что все 100 000 реально важны для бизнеса. Там часто висит куча запросов, которые технически относятся к твоей тематике, но вообще не связаны с тем, что ты реально продаешь. Возьмем для примера "clustering". Если у тебя инструмент для кластеризации ключей, запросы вроде: "keyword clustering tool" и "k means clustering python" оба могут казаться релевантными с точки зрения тематики. Но только один из этих пользователей реально ищет твой продукт. Именно эту проблему я и хотел решить. Поэтому я сделал бесплатный Keyword Relevance Filter. 0:01 / 0:42 Заливаешь CSV с запросами из GSC, а потом описываешь инструменту, чем занимается бизнес, кто твоя ЦА, где ты работаешь, какой у тебя бренд и какие темы нужно минусовать. Перед тем как обрабатывать всё целиком, он сначала проверяет небольшую выборку. Это позволяет увидеть, правильно ли он понял твое ТЗ, и допилить настройки перед прогоном всего датасета. Когда результат тебя устраивает, он размечает каждый запрос как: Relevant (Соответствует) Outside scope (Выходит за рамки) Needs review (Требует проверки) А еще выдает причину по каждому решению. Так что вместо того, чтобы просто собирать ключи в группы из-за похожих слов или нахождения в одном кластере, ты можешь фильтровать их по тому, есть ли в них реальный смысл для бизнеса. Инструмент также отдельно определяет брендовые и небрендовые запросы, что упрощает выделение релевантных discovery-поисков, где не упоминается твой бренд. Под капотом инструмент использует модель бинарной классификации Jev от TypeSafe. Можно бесплатно обрабатывать до 10 000 запросов. Без регистрации. Сам CSV читается локально в браузере. На классификацию отправляются только тексты запросов и ТЗ по бизнесу. Изначально я сделал его, потому что он нужен был мне самому. Подумал, что другим сеошникам тоже пригодится. Под капотом стоит классификатор Jev от TypeSafe. Попробовать можно тут: https://suganthan.com/free-seo-tools/keyword-relevance-filter/ #Tools #Keywords #GSC @MikeBlazerX 📈 "Пушки" — в @MikeBlazerPRO