Mike Blazer

Сеошники во время апдейта #Humor @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO

Переход в проблемный проект: 800 фейковых ИИ-страниц срезали трафик с 50k до 10k визитов Я устроился в компанию 60 дней назад, и всё, что я могу сказать... это катастрофа, делится AbbreviationsIll9150. Они постоянно сносили страницы, которые приносили трафик. Пример: писали контент вроде "top 10 LMS for education in 2024" и вшивали "2024" прямо в урл. Они использовали ИИ для написания контента, который нагенерил больше 800 фейковых урлов. В итоге ссылки вели на страницы, которых не существует ни на сайте, ни в сайтмапе. В октябре 2025 года они выкатили 800+ единиц ИИ-контента. Это был тупо текст и битые таблицы, которые они вставляли на автомате. Трафик просел с 50k визитов в месяц до 10k. Да, большая часть старого трафика была мусорной. Могли ли все эти прошлые действия убить нас вдолгую? Я начал с того, что сфокусировался на написании контента под 5 ключевых ниш, на которые мы хотим таргетироваться. Для начала — общие страницы под нишу + блоги (выкатываю строго по 1 посту в день). Плюс цель — пилить видео-контент под каждый кластер. На что еще мне смотреть, чтобы остановить это падение? Такое чувство, что мне подсунули свинью... Заранее спасибо! Инсайты комьюнити — Массовый маппинг сотен битых урлов на редиректы: выгрузи список битых ссылок из Ahrefs, скорми его вместе с картой живого контента в Claude, чтобы он подобрал наиболее релевантную замену для каждого урла. Затем вручную проверь маппинг перед накаткой `301`х. По отзывам, схема отлично работает с бэклогом на 800 урлов. — Восстанавливай ссылочный вес, а не просто заклеивай `404`е ошибки: прокидывай `301`й редирект с любой удаленной или осиротевшей страницы, у которой был трафик ИЛИ бэклинки, на самый релевантный пост в блоге или корневую страницу. Плюс настрой внутреннюю перелинковку с этих целевых страниц обратно на главную и страницы услуг, чтобы вес перетекал дальше, а не оседал в тупике. — Описанный паттерн — 800+ ИИ-страниц с кривыми автогенерированными таблицами и фейковыми урлами вне сайтмапа — это прямой профиль под ручник. Поэтому ИИ-шлак нужно переписывать, а не просто редиректить; зачистка страниц-сирот и простановка `301`х — это только базовый минимум, а не полноценное решение. — Расставляй приоритеты по отдаче на вложенные усилия параллельно в трех направлениях (зачистка контента, который тянет сайт на дно; дооптимизация контента, который уже ранжируется; выкатка нового качественного контента и бэклинков) и не трать время на косметические правки, которые не влияют на позиции. #TechnicalSEO #Redirects #AIContent @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO

ИИ-советы по деиндексации обрушили показы спортивного сайта с 5000 до 10 в день Я создал спортивный сайт около года назад, и сейчас я в полной растерянности, делится Ambitious_Local5218. Сайт выкатывает кучу ежедневного контента: статьи, превью матчей, статы для ставок и отчеты по данным. Некоторые страницы с отчетами — это тупо голые цифры, таблицы и статы. Недавно я послушал ИИ, который посоветовал закрыть от индексации пачку таких страниц, так как они могут считаться малоценным контентом или дублями. Плюс я запутался, нужно ли пихать ежедневные превью и страницы со статами в сайтмап или лучше их исключить. До всей этой истории сайт собирал 4000–5000 показов в день в GSC. Теперь показы рухнули примерно до 10 в день. Я вложил год крови и пота в этот проект, и смотреть, как он складывается из-за кривых советов ИИ, — это жестко. Пытаюсь понять, как вытянуть проект и что делать дальше: — Стоит ли индексировать ежедневные спортивные статьи и превью? — Нужно ли оставлять в индексе или закрывать через noindex ежедневные отчеты с массивами данных? — Включать ли такие типы страниц в сайтмап? — Можно ли безопасно откатить ущерб от массового закрытия страниц через noindex? — Как подходить к восстановлению, если показы упали с тысяч в день почти до нуля? Буду рад любым советам. Не ищу волшебную кнопку. Просто хочу понять следующие шаги, чтобы не сделать хуже. Инсайты комьюнити — Диагностика методом исключения: если закрытые через noindex страницы до изменений сами получали около нуля показов в GSC, обвал нельзя списывать на их прямую потерю. Причина лежит глубже — переоценка качества на уровне хоста или дефицит ссылочного веса, а не деиндексированные урлы. — Снятие тегов noindex не запускает восстановление само по себе. Гуглбот перестает обходить урлы, которые ему запретили индексировать, и не придет перепроверять их по своей воле. Открытые страницы будут висеть мертвым грузом, пока ты вручную не запросишь индексацию и не закинешь сайтмап (где должны лежать только индексируемые урлы). — Пошаговая схема восстановления: в отчете по страницам в GSC отфильтруй Excluded by 'noindex' tag и проведи аудит каждого паттерна урлов. Уникальные страницы под интент реального времени (ежедневные превью, статьи по играм) почти всегда должны быть в индексе. Шаблонные дампы таблиц без текстового обвеса расцениваются как малоценный контент даже без noindex. Фикси их редакторски — пиши короткий лид с объяснением данных, строчку с главным выводом, а уже потом давай таблицу — обычно именно это вытаскивает основную долю трафика при восстановлении. Полный откат после ошибочного noindex обычно занимает от 6 до 12 недель, как только краулинг снова разгонится. — Поскольку Гугл переоценивает качество на уровне сайта, не откатывай всё за один день на крупных проектах: сначала верни самый сильный контент, дай ему отлежаться пару недель, затем выкатывай следующую пачку. — Снос или деиндексация контента ради накрутки средних метрик качества страницы (средняя свежесть, длина, бэклинки, показы на документ) не двигает позиции вверх — Гугл не дает бонус за красивую "среднюю" температуру по больнице. Того же фокуса на сильном контенте можно добиться без удаления всего остального. #Indexing #ThinContent #GSC @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO

Заменил картинки с .png на .webp — нужна помощь! У меня есть сайт, где я менял картинки с .png на .webp, пишет silailor, но потом я прочитал статью о том, что если поменять картинку, то позиции старых изображений упадут, и Google придется краулить новые картинки с нуля. Например, урл картинки — example. com/2022-05/old-image.png Она ранжируется в картинках Google, собирает клики и показы. Теперь я заменил ее в 2026 году на урл example. com/2026-05/new-image.webp Раз я удалил старую картинку, ее позиции упадут, а клики обнулятся до тех пор, пока новая картинка не начнет показываться в выдаче. Поэтому статья советовала мне настроить редирект со старого урла картинки на новый. Потом я посмотрел видео, где говорят, что можно заменить картинку (НЕ поменять), при этом маппинг урла останется прежним даже после замены на новое изображение. Я так и сделал. Теперь я заменил картинку, урл остался старым — example. com/2022-05/old-image.png, но само изображение стало .webp, хотя в урле всё равно написано .png. Размер файла тоже изменился с 900 КБ до 108.4 КБ (так как картинка теперь в формате webp), но в урле по-прежнему стоит example. com/2022-05/old-image.**png**. Теперь мне вообще ничего не надо делать! Все работает, но главная проблема в том, что сама картинка — это .webp, а в урле написано .png (из-за старого маппинга). Это плохо для SEO? Если да, то почему, а если нет, то почему? Во-вторых! Стоит ли мне залить новую картинку с новым урлом? Скажем, example.com/2026-05/new-image.webp, и настроить редирект со старой картинки на новую? ПОМОГИТЕ! Инсайты комьюнити — Отбой панике по поводу замены картинок: позиции в поиске по картинкам привязаны к самому объекту изображения, а не к SEO родительской страницы — потеря кликов из картинок не тянет за собой вниз позиции страницы, на которой они висят. Приоритет диагностики смещается на тематический авторитет и ссылочный профиль самой страницы, а не на сохранение урла картинки. — Полевые данные из e-commerce: замена файла картинки на странице товара вместе с изменением урла обвалила позиции товара с 1-3 места за пределы топ-50. Рабочий фикс — проксирование изображений на бэкенде по стабильному урлу (например, /product/{id}/image), который отдает актуальный файл. Это сохраняет проиндексированный урл картинки при замене ассетов без редиректов. — Отдача файла .webp по урлу с расширением .png (несовпадение расширения/MIME) со временем путает краулеров; полевой кейс на блоге с 5–10k кликов по картинкам в месяц: стандартный 301 редирект со старого урла .png на реальный урл .webp дал небольшую просадку на пару недель во время переиндексации, затем стабилизировался — в долгосрок это безопаснее, чем хак с подменой расширения. — Массовый переезд урлов картинок (например, 200+ ассетов): одно правило редиректа по регулярке через плагин может перенаправить старый паттерн путей на новый, если структура путей и имена файлов остаются идентичными. Это избавляет от необходимости писать 301 правила под каждую картинку отдельно. #TechnicalSEO #Images #Redirects @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO

​Wikimedia Foundation выкатила полную английскую и французскую Википедию в виде предварительно распарсенного Parquet на Hugging Face. 10.47M статей. 44 GiB. Разделы, инфобоксы, таблицы и ссылки уже структурированы. Для всех, кто когда-либо пытался скормить #Wikipedia в RAG-архитектуру, использовать для бенчмарков или просто собрать личного компаньона для исследований: вот этот датасет 📖 В каждой строке уже есть аннотация в виде простого текста, тело статьи в виде JSON-разделов, распарсенные инфобоксы, извлеченные таблицы и вынесенные ссылки с их собственной метадатой. Там есть даже новые сигналы достоверности: referenceneed помечает утверждения, которым, вероятно, нужна ссылка, а referencerisk помечает сомнительные цитаты. 👉 Датасет: https://huggingface.co/datasets/wikimedia/structured-wikipedia Инсайты комьюнити — Флаги referenceneed / referencerisk работают как бесплатный фильтр соотношения сигнал/шум для извлечения в RAG — вшейте их в скоринг поиска, чтобы пессимизировать фрагменты, где утверждениям не хватает ссылок или сами ссылки выглядят сомнительно, еще до того, как они попадут в генератор. #LLM #AI #HuggingFace @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO

Хит краулера доказывает только загрузку URL, а не попадание в память модели Записи о GPTBot, CCBot или ClaudeBot в логах сервера кажутся доказательством того, что следующая модель узнает ваш бренд. Это не так. Хит краулера означает лишь то, что бот запросил URL — и ничего о том, что было дальше. Просканировано, обучено и извлечено — это три разных этапа; если их спутать, аудит видимости в ИИ пойдет по ложному следу. Лог краулинга — это не чек об обучении. Попадание в модель происходит уже после того, как контент нашли и признали достойным сохранения. Реальная цепочка выглядит так: хит краулера → архив → извлечение текста → фильтрация → дедупликация → микс данных → обучение → поведение модели, и контент может отвалиться на любом шаге. "Мы есть в Common Crawl" и "модель нас выучила" — это разные вещи: Common Crawl — это сырье, а данные для обучения — уже отобранный результат. В пейперах по датасетам эта курация прописана прямым текстом: FineWeb документирует фильтрацию и дедупликацию снапшотов Common Crawl, DataComp-LM рассматривает саму сборку датасета как эксперимент, исследование Lee et al. показывает, что дедупликация режет заученную выдачу, а пейпер по LLaMA перечисляет Common Crawl, C4, GitHub, Wikipedia, книги, arXiv и Stack Exchange как источники с разными весами. Дедупликация — это не просто косметическая чистка: одна и та же статья или бойлерплейт висят на сотнях URL, и финальный корпус сэмплируется неравномерно. Второй миф — "обновил сайт, обновилась модель" — сыплется на той же механике. Как только модель обучена и развернута, её параметрическая память замораживается. Поиск в реальном времени может подтянуть свежую страницу и сослаться на нее как на контекст для одного ответа, но он не трогает веса. Новый контент попадает в память модели только на следующем цикле обучения, прогоне дообучения (continued-pretraining) или при релизе новой версии. Поэтому хит тренировочного бота нельзя коррелировать с изменением знаний модели: между публикацией страницы и появлением в ответе ИИ могут пройти месяцы. Получается, аудит разбивается на три уровня. Сначала — доступность для краулинга: могут ли боты физически пробиться к контенту сквозь robots.txt, CDN и правила WAF/защиты от ботов, есть ли домен вообще в индексе Common Crawl и отдает ли сервер контент в чистом HTML, а не прячет его за JS. Чистый robots.txt не спасет, если WAF отдает 403, а ранжирование в Google не означает, что обучающий краулер доходит до страницы. Уровень, который пропускает большинство команд — готовность к обучению: если контент просканируют, стоит ли его сохранять? Снаружи это идеально не замерить, но пейперы по датасетам дают ориентир: описывайте бренд консистентно на сайте, в Wikidata, Wikipedia, Crunchbase, G2 и прессе, и пишите контент, который пройдет фильтр качества, а не малоценные коммерческие тексты. Цель — извлекаемый, уникальный, подтвержденный и последовательный контент, а не просто больше страниц. Это смещает фокус SEO в сторону гигиены сущностей и Digital PR. Автор делает важную оговорку: лаборатории не раскрывают, как именно боевые поисковые ИИ-движки ранжируют и отбирают источники, поэтому специфика строится на выводах, а не на подтвержденных фактах. Краулинговый доступ — это лишь базовое условие, а не то, что кладет ваш контент в память модели. #AI #LLM #Crawling @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO

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

​Гугл только что тихо обновил гайдлайны по переезду доменов.... При переезде на новый домен теперь нужно отправлять запрос Change of Address для каждой версии старого домена. Это значит, что придется учесть каждый поддомен, даже те, которые больше активно не используются. Если не сообщить Гуглу о переезде поддомена, краулинговый бюджет будет сливаться на "новые урлы", даже если они закрыты в noindex. Как быть абсолютно уверенным, что перед согласованием стратегии клиенту вы не упустили забытый поддомен пятилетней давности? Я написала простой инструмент для поиска поддоменов, чтобы можно было собрать список, передать его клиенту и убедиться, что все варианты учтены при переезде, рассказывает Бет Вудкок. В любом случае важно знать, что происходит с видимостью поддоменов; даже если вы ДУМАЕТЕ, что бюджет не тратится впустую, я видела примеры, когда скрытые поддомены создавали проблемы, а клиенты об этом даже не подозревали... Забрать инструмент можно здесь!: https://github.com/bethwoodcock/guisublist3r #Migration #CrawlBudget #GSC @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO

​Микроразметка LocalBusiness не влияет на позиции в Google — профит выдает только ChatGPT В ходе 10-недельного контролируемого теста микроразметку вычистили с 29 клиентских доменов, разбили их на гео-сопоставимые контрольную и тестовую группы, а затем внедрили продвинутую микроразметку LocalBusiness только на главные страницы тестовых сайтов. Статзначимость измеряли односторонним t-критерием Уэлча для двух независимых выборок, при этом ревьюеры (включая Ярно ван Дриеля, Moz и Yoast) валидировали методологию еще до получения результатов. Порог статзначимости в 90% отделял реальные выводы от шума. В десктопном и мобильном Google, Bing и Yahoo микроразметка LocalBusiness не дала никакого прироста ни в позициях, ни в поисковой видимости. В Google Maps всё оказалось еще хуже: контрольная группа обошла тестовую как по среднему ранжированию, так и по Share of Local Voice, поэтому t-критерий даже не пришлось применять. Единственной поисковой системой, показавшей хоть какой-то сигнал, стал Yahoo, но статзначимость осталась ниже 85%. Настоящий разрыв происходит на уровне LLM. Google AI Mode, AI Overviews, Gemini и Grok выдали результаты на уровне подбрасывания монетки (статзначимость 50–60%). А вот ChatGPT оторвался от остальных: статзначимость 92,91% доказала, что микроразметка LocalBusiness улучшила позицию в рекомендациях на 3,33 пункта; и со статзначимостью 91,51% — что она увеличила частоту цитирования бренда в ChatGPT на 10 процентных пунктов. Почему ChatGPT взвешивает микроразметку именно так — неизвестно; тест фиксирует эффект, а не причину. Фокус исследования специально заузили: одна ниша (локальные бизнесы с выездом к клиенту), один тип микроразметки, только главная страница, никаких rich snippets. Микроразметка по-прежнему критична там, где Гугл опирается на нее для рендера выдачи — списки вакансий, отели и билеты, а также товарная разметка для органического Shopping. Но споры, где микроразметка считается фактором ранжирования, направлены не на ту систему. https://evergrowmarketing.com/how-schema-affects-google-and-ai/ #LocalBusinessSchema #ChatGPT #StructuredData @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO

​Гугл проактивно сносит из выдачи даже непроиндексированные урлы по запросу трастовых правообладателей Крупнейший отправитель DMCA-запросов в Гугл, компания Link-Busters, вышла на плато в 60–70 миллионов запросов на удаление URL в неделю и держит эту планку уже около года. На счету компании более 6,5 миллиардов запросов на деиндексацию — это больше трети от почти 18 миллиардов, полученных Гуглом за всё время, и в четыре раза больше, чем у ближайшего преследователя. При текущих темпах они отправляют около 3,5 миллиардов урлов в год. Но две детали важнее, чем общие объемы. Доля ошибок у Link-Busters держится ниже 1% (что сильно лучше среднего показателя), а почти 8% отправленных ими урлов еще даже не были проиндексированы Гуглом. Гугл вычищал эти непроиндексированные урлы проактивно, идя навстречу правообладателю, и блокировал страницы до того, как они вообще попадали в индекс. Механизм, позволяющий пробивать потолок, — это скрытый от глаз канал: Trusted Content Removal Program (TCRP), путь для массовой загрузки жалоб, который Гугл предоставляет проверенным партнерам. На прямой вопрос о наличии дневных лимитов Гугл не дал ни подтверждения, ни опровержения, заявив лишь, что трастовые партнеры "могут отправлять то количество, которое им необходимо". Это куда более осторожный ответ, чем в 2013 году, когда Гугл заявлял, что лимитов на уведомления "не существует". Тогда его обвиняли в жестком ограничении правообладателей планкой в 10 000 урлов в день. Один заявитель, зачищающий сейчас около 10 миллионов урлов ежедневно, означает скачок в 1000 раз. Остается вопросом, являются ли 70 миллионов в неделю намеренным лимитом, техническим бутылочным горлышком или же пределом мощностей краулеров самих Link-Busters. Данные о прозрачности подтверждают двухуровневую реальность: трастовые отправители работают в таких масштабах и с таким проактивным подавлением индексации, до которых обычным отправителям DMCA никогда не дотянуться. https://torrentfreak.com/googles-top-dmca-sender-plateaus-at-70-million-takedowns-per-week/ #DMCA #Indexing #GoogleBot @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO