uk
Feedback
Mike Blazer

Mike Blazer

Відкрити в Telegram

Все прелести SEO: — результаты экспериментов — секреты продвижения — свежие идеи — SEO-фишки — кейсы — топы без ссылок Платный PRO-канал: https://t.me/MikeBlazerX/5841 ... Автор: @MikeBlazer Рекламу не продаю!

Показати більше
8 649
Підписники
Немає даних24 години
+57 днів
+4330 день
Залучення підписників
липень '26
липень '26
+133
в 3 каналах
червень '26
+227
в 4 каналах
Get PRO
травень '26
+167
в 2 каналах
Get PRO
квітень '26
+168
в 2 каналах
Get PRO
березень '26
+144
в 2 каналах
Get PRO
лютий '26
+189
в 2 каналах
Get PRO
січень '26
+191
в 2 каналах
Get PRO
грудень '25
+277
в 10 каналах
Get PRO
листопад '25
+199
в 6 каналах
Get PRO
жовтень '25
+243
в 4 каналах
Get PRO
вересень '25
+174
в 6 каналах
Get PRO
серпень '25
+193
в 3 каналах
Get PRO
липень '25
+228
в 5 каналах
Get PRO
червень '25
+214
в 5 каналах
Get PRO
травень '25
+203
в 4 каналах
Get PRO
квітень '25
+171
в 7 каналах
Get PRO
березень '25
+194
в 3 каналах
Get PRO
лютий '25
+199
в 4 каналах
Get PRO
січень '25
+181
в 3 каналах
Get PRO
грудень '24
+149
в 7 каналах
Get PRO
листопад '24
+188
в 4 каналах
Get PRO
жовтень '24
+221
в 5 каналах
Get PRO
вересень '24
+175
в 7 каналах
Get PRO
серпень '24
+198
в 6 каналах
Get PRO
липень '24
+217
в 5 каналах
Get PRO
червень '24
+226
в 6 каналах
Get PRO
травень '24
+329
в 11 каналах
Get PRO
квітень '24
+261
в 3 каналах
Get PRO
березень '24
+277
в 3 каналах
Get PRO
лютий '24
+301
в 10 каналах
Get PRO
січень '24
+253
в 2 каналах
Get PRO
грудень '23
+306
в 3 каналах
Get PRO
листопад '23
+266
в 8 каналах
Get PRO
жовтень '23
+273
в 5 каналах
Get PRO
вересень '23
+237
в 0 каналах
Get PRO
серпень '23
+336
в 0 каналах
Get PRO
липень '23
+201
в 0 каналах
Get PRO
червень '23
+278
в 0 каналах
Get PRO
травень '23
+216
в 0 каналах
Get PRO
квітень '23
+185
в 0 каналах
Get PRO
березень '23
+215
в 0 каналах
Get PRO
лютий '23
+203
в 0 каналах
Get PRO
січень '23
+354
в 0 каналах
Get PRO
грудень '22
+183
в 0 каналах
Get PRO
листопад '22
+143
в 0 каналах
Get PRO
жовтень '22
+209
в 0 каналах
Get PRO
вересень '22
+110
в 0 каналах
Get PRO
серпень '22
+281
в 0 каналах
Get PRO
липень '22
+163
в 0 каналах
Get PRO
червень '22
+363
в 0 каналах
Get PRO
травень '22
+177
в 0 каналах
Get PRO
квітень '22
+133
в 0 каналах
Get PRO
березень '22
+1 035
в 0 каналах
Дата
Залучення підписників
Згадування
Канали
30 липня0
29 липня+5
28 липня+6
27 липня+1
26 липня+4
25 липня0
24 липня+4
23 липня+8
22 липня+4
21 липня+7
20 липня+5
19 липня+1
18 липня+3
17 липня+3
16 липня+6
15 липня+5
14 липня0
13 липня+7
12 липня+3
11 липня+3
10 липня+4
09 липня+7
08 липня+7
07 липня+10
06 липня+4
05 липня+7
04 липня+4
03 липня+6
02 липня+4
01 липня+5
Дописи каналу
Правило верстки ссылок, которое спецы не палят джунам У техсеошников топ-уровня есть правило, которого не найти в публичных чек-листах. Оно жестко задает, как должен быть размечен каждый внешний линк на сайте. Без единого исключения. Соблюдаешь — поведенческие остаются при тебе. Игноришь — каждая исходящая ссылка втихую подтачивает сигналы вовлеченности. Разница всего в одном атрибуте разметки. Но на дистанции это пропасть в ПФ. Большинство сайтов прямо сейчас сливают сигналы на каждой внешней ссылке и даже не догадываются об этом. Точное техническое правило для всех внешних ссылок → @MikeBlazerPRO Проверь свой код, пока конкуренты не обошли.

2
Страницы под города вытаскивают выездной бизнес в локал-пак без пина на карте Сантехники, клинеры, кинологи и выездные механики работают без офиса, к которому можно привязать пин на карте. Гугл всё равно жестко учитывает близость к пользователю, поэтому бизнес в 30 милях сливает локальному конкуренту даже с более трастовым профилем. Физическую близость не сфальсифицируешь, но плотность сигналов релевантности закрывает этот разрыв. Начни с GBP. Скрой адрес, задай зону обслуживания по городу, региону или индексу — Гугл использует это для допуска в локал-пак. Платформа разрешает до 20 локаций на профиль — не заполняй все 20. Слишком широкая зона размывает сигнал гео-релевантности. Добавляй только те города, где реально берешь заказы, и выбирай именно города, а не округа или штаты — Гугл мэтчит на уровне города. Платформа всё равно требует реальный адрес для верификации выездного бизнеса; просто он не светится в выдаче. Без пина вся гео-привязка ложится на сайт. Собери отдельную страницу под каждый город: пропиши название города в H1 и мета-тайтле, сделай уникальный интро-абзац (никогда не дублируй его между страницами), добавь минимум одну локальную отсылку вроде района или ориентира, отзыв клиента из этого города, телефон и микроразметку зоны обслуживания. Шаблонные страницы "мы работаем в этих районах" не ранжируются. Закидывай в блог фото с гео-метками как дополнительный сигнал — это дает отдельный буст поверх отзывов и городских страниц. Без физической точки отзывы весят больше. Что реально двигает позиции: объем отзывов относительно конкурентов в конкретной зоне, упоминание города или района в тексте, стабильная динамика (а не 20 штук за раз и потом тишина) и ответы на каждый отзыв в течение 48 часов. Коммент "Приехали в Розвилл в тот же день" бьет "Отличный сервис"! по локальной релевантности. Цитации требуют специфичного подхода для SAB, так как нет физического адреса для синхронизации. В каталогах, где адрес обязателен, указывай только город и штат — никаких абонентских ящиков, за них Гугл накладывает фильтр. В GBP верифицируйся как SAB без вывода адреса, в Yelp используй функцию зоны обслуживания вместо поля локации, а в Apple Maps регистрируйся как бизнес без фиксированной точки. Рассинхрон в том, как разные каталоги обрабатывают листинги без адреса, ломает локальные сигналы. Для SAB правильная категория и единый радиус обслуживания по всем профилям весят больше, чем для офлайн-точек. Сокращай дистанцию контентом и бэклинками под каждый целевой город, отзывами с упоминанием локации от реальных клиентов, локальной микроразметкой со свойствами areaServed и serviceArea, а также местным контентом в блоге. Большинство конкурентов сидят с кривыми профилями, шаблонными страницами и нулем стратегии по отзывам — правильная настройка GBP, сборка городских страниц и сбор отзывов с привязкой к локации обходит 80% ниши. #LocalSEO #LocalPack #GBP @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO
676
3
​Файл robots.txt никогда не удалит страницу из базы — Гугл режет мусор на этапе первого краула Всплеск урлов со статусом "не проиндексировано" раскрывает структурный сдвиг: Гугл теперь применяет пороги качества при первичном краулинге, а не после включения в базу. Под одним симптомом скрываются две разные проблемы, и их нужно разделять. Массовая деиндексация выкидывает уже проиндексированные урлы (заброшенный контент, малоценные страницы, низкий траст, слабая внутренняя перелинковка). А вот отказ в индексации нового контента просто разворачивает свежие урлы на входе. Логика тут финансовая. AI Overviews и ИИ-моды меньше зависят от поискового индекса, поэтому держать слоты для страниц, которые Гугл все равно не покажет — это чистый убыток. Ловушка, которая незаметно убивает трафик: robots.txt никогда не удалит страницу из индекса. Если страница заблокирована, краулер на нее не зайдет, а значит, Гугл никогда не увидит на ней noindex. Чтобы деиндексировать урл, разреши краулинг и отдай noindex через мета-теги или HTTP-заголовок X-Robots-Tag. Этот заголовок — слепая зона для большинства аудитов. Его не видно в исходном коде, он инжектится на уровне сервера, CDN или edge-воркера. Получается, целый раздел может отдавать noindex через правила nginx или Cloudflare, хотя с HTML все в полном порядке. Проверяй это через curl -I, а не только визуально в коде. Статусы "Просканировано, но пока не проиндексировано" и "Обнаружено, но не проиндексировано" — это один и тот же вердикт, вынесенный разными путями. Это оценка качества и ценности, а не техническая блокировка. Повторный сабмит ничего не даст, править нужно саму страницу. Воспринимай рост этих ошибок как сигнал: туда могут падать ранее проиндексированные урлы, что означает падение качества, а не просто очередь из новых страниц. Soft 404 — еще одна скрытая дыра. Урл, который отдает HTTP 200 с пустой оболочкой "нет результатов" или "товары не найдены", на объеме считывается алгоритмом как страница ошибки. Отдавай честный 404/410 код или закрывай пустые шаблоны поиска и фильтров через noindex, вместо того чтобы скармливать боту пустые двухсотые. Чтобы отлавливать утечки тестовых серверов, настрой доменное свойство в GSC (а не префикс) как catch-all. Затем отфильтруй отчет эффективности по регулярке staging|stg|dev|uat|qa|preprod|sandbox, чтобы вытащить любые dev-среды, которые Гугл нашел и пустил в выдачу. По мнению автора, для фильтрации ИИ и программного контента Гугл может использовать эмбеддинги SBERT (Sentence-BERT), которые ловят сгенерированный текст даже после жесткого рерайта. Плюс снепшоты индекса для детектирования массовой генерации — это преподносится как вероятный механизм, а не подтвержденный факт. https://www.assertive-media.co.uk/blog/how-to-fix-non-indexed-page-reasons-in-google-search-console/ #Indexing #TechnicalSEO #CrawlBudget @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO
869
4
Десктоп отдает 404, мобилка возвращает 200 — mobile-first краулер держит мертвый урл в индексе Урл, который начал отдавать 404 семь месяцев назад, все еще может ранжироваться. Причина не в прошедшем времени, а в том, что гуглобот фактически получает при скачивании страницы. Первым делом проверяй код ответа на обоих рендерах: страница может отдавать 404 на десктопе, но при этом возвращать 200 на мобилке. Поскольку Google сканирует в режиме mobile-first, этот 200 — единственный ответ, который имеет значение. Получается, с точки зрения индекса страница никуда не пропадала. Одна внутренняя ссылка усугубляет ситуацию. Единственного упоминания с родительской страницы FAQ достаточно, чтобы поддерживать урл в живых — гуглобот переходит по ссылке, решает, что конечный адрес стоит пересканировать, и продолжает его подтверждать. Даже один входящий путь удерживает незначительный урл в ротации. Дальше удаление делится по целям. Для долгосрочного сноса работает noindex или честный 404/410, причем разницы в скорости между ними обычно нет. Джон Мюллер отмечает: инструмент удаления — это рычаг, чтобы снести что-то быстро, тогда как код ответа или noindex фиксируют результат намертво. Железобетонное решение бьет по ссылке, а не только по коду ответа. Если удалить ту единственную ссылку из FAQ, путь обнаружения уничтожается полностью, и гуглобот теряет причину для повторного визита. Альтернатива — изменить ссылку и закинуть запрос на удаление в GSC; в обоих случаях урл быстро вылетает. Один нюанс, который скрывает сам статус-код: пока мобильный эндпоинт продолжает отдавать 200, отдача 410 или 404 чисто для десктопа не меняет ровным счетом ничего, потому что mobile-first краулер этого просто не видит. #Crawling #Mobile #404Errors @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO
1 039
5
Бюджет рендеринга, а не краулинговый бюджет, сутками держит свежий JS-контент без индексации Google делит краулинг и рендеринг на два прохода. Краулинг — это быстро и дешево; выполнение JavaScript требует реальных вычислительных мощностей, поэтому тяжелые JS-страницы падают в очередь и рендерятся второй волной, иногда спустя часы или дни. Именно из-за этой очереди обновленный контент не появляется в выдаче. Краулинговый бюджет считает страницы, просканированные за день; бюджет рендеринга — это отдельный ресурс, определяющий, на скольких страницах Google выполнит JavaScript. Диагностируй это в GSC. Прогони ключевую страницу через URL Inspection и сравни дату Last crawl с датой Last crawl rendered. Большой разрыв означает, что гуглобот парсит страницу, но откладывает рендер. Сверься с отчетом Page Indexing, отфильтровав по Crawled, currently not indexed. Если тяжелые JS-урлы скапливаются там, причина — задержка рендера. Быстрый тест: открой исходный код через Ctrl+U. Если в сыром HTML нет основного контента, Гуглу придется отрендерить JS, чтобы вообще его увидеть. Четыре вещи выжигают бюджет рендеринга быстрее всего: бандлы тяжелее 1 МБ, сторонние скрипты (GA4, Hotjar, Intercom, Optimizely, GTM с 15+ тегами — в сумме это от 2 до 5 секунд выполнения), ленивая загрузка, которая не срабатывает при рендере, и бесконечный скролл. Гуглобот не скроллит: он рендерит начальный вьюпорт и останавливается, поэтому контент со второй по N-ную страницу, который подгружается только по скроллу, остается невидимым. Базовое решение — перенести критически важный контент, заголовки и метаданные на SSR. Next.js: getServerSideProps или getStaticProps. Nuxt: режим SSR или nuxt generate. Без фреймворков: отдавай полный HTML, а не пустую оболочку, которую JS заполняет после загрузки. Проверяй каждое изменение по отрендеренному HTML в URL Inspection. Затем срежь пейлоад. Целься в менее 200 КБ распарсенного JavaScript для контента первого экрана. Найди раздутые пакеты через webpack-bundle-analyzer или source-map-explorer, вычисти неиспользуемый код (tree-shaking), разбей бандл по роутам, отложи некритичные скрипты и запускай сторонние теги по Window Loaded, а не DOM Ready. Никогда не вешай ленивую загрузку на hero-изображения (используй fetchpriority="high"), основной текст, заголовки или навигацию — всё, что нужно Гуглу для понимания темы страницы, должно быть в первичном рендере. Для бесконечного скролла выкатывай резервные URL пагинации (/blog/page/2/) с атрибутами rel="next"/rel="prev", где каждый урл отдает полный контент в исходном HTML-ответе. Если SSR невозможен, пререндеринг через Prerender.io или Rendertron будет отдавать гуглоботу закешированный HTML-снапшот, тогда как юзеры получат JS-версию. Google разрешает такой подход, если снапшот совпадает с тем, что видят пользователи — расхождение контента считается клоакингом. Аудит раз в месяц: разрыв дат краулинга и рендера на 10 ключевых страницах, наличие контента первого экрана в сыром коде, Total Blocking Time ниже 200 мс в PageSpeed Insights, запуск сторонних скриптов по window load и наличие резервных ссылок пагинации на каждой странице с бесконечным скроллом. Инсайты комьюнити — Полевые тесты на 700-килобайтном бандле показали: Гуглу требовались дни на рендер нового текста; срезка сторонних скриптов и перенос ключевого текста на SSR сократили разрыв в рендере вдвое. Реальный рычаг — это связка сторонних скриптов и SSR, а не вес бандла сам по себе. #Rendering #JavaScript #CrawlBudget @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO
857
6
Комментарии на сайте: вытаскивают LLM-трафик только через новые слова У паблишера, чьи читатели уже пишут автору рассылки на почту, напрашивается очевидный шаг: включить комментарии и перехватить это обсуждение прямо на странице. Сама система комментариев — это фича, а не комьюнити. Включить тумблер легко, но заставить людей оставлять полезные обсуждения по теме — вот реальная работа, и только она определяет, будет ли от этого SEO- или LLM-профит. Поисковики и LLM вознаграждают контент из комментариев, а не саму форму ввода. Комменты помогают, только когда добавляют полезные ключи и реальные вариации юзкейсов — новые слова на странице, описывающие ситуации, которые не покрыла редакция. Без этого включение комментов не дает ничего, а запуск форума не генерирует новый Reddit. LLM также неравномерно оценивают UGC-источники: Reddit и YouTube имеют больший вес, чем собственная ветка бренда, а Google все еще экспериментирует с тем, какие форумы подсвечивать, пока выводя в ранжирование более мелкие площадки. Где UGC на сайте действительно вытаскивает измеримый трафик, так это в отзывах. Сайт, выкативший UGC-отзывы на своих страницах, собирает примерно 10 000 переходов из LLM за квартал — но эффект зависит от ниши и контекста, а не от комментариев в целом. В предложенном сетапе есть структурная дыра. Читатели пишут автору, а не друг другу — им нужен человек, а не бренд и не ветка с такими же юзерами. Переведи их в комменты, и главный вопрос: ждут ли они ответа автора. Если ждут, а автор молчит, ранее лояльные читатели превращаются в злых клиентов, не получающих ответов. Решение: автор или паблишер берет на себя обязательство регулярно появляться в треде; издания вроде 404 Media и Wired поддерживают комменты именно потому, что их авторы там присутствуют (возможно, это даже прописано у них в контрактах). Позиционирование этого как SEO-схемы — верный путь к провалу. Проекты комментариев под эгидой SEO выкатываются как голый MVP, с урезанным бюджетом, без кросс-канального плана и дальнейших шагов, после чего их игнорируют, и они загибаются. Тот же проект, поданный как построение комьюнити или бренда, подтягивает команды клиентского сервиса, брендинга и стратегии, делает SEO лишь одним из стейкхолдеров, а участие авторов поощряется и фиксируется в контрактах. Трафик — не та метрика успеха для этой задачи. Инсайты комьюнити — До запуска любых фич реши, где UGC будет самым ценным, легко генерируемым и наиболее вероятным для сканирования LLM в конкретной нише — затем проведи аудит, где текущая аудитория уже сидит и какие поисковики, сайты и LLM использует для поиска инфы (инструменты вроде SparkToro вскрывают это). Данные определяют потенциал до того, как фича выйдет в прод. — Мнения практиков разделились: делать ставку на офф-пейдж или на свой сайт. Первый вариант: перенести рассылку или её часть на Substack, синдицировать посты в винные сабреддиты и вести брендовый аккаунт для посева обсуждений, опираясь на персонализированную ленту Reddit для охвата вдолгую. Контраргумент: когда авторитетный отраслевой паблишер с 40-летней историей перегоняет аудиторию на чужую площадку вроде Reddit или Substack, он рискует словить рассинхрон между аудиторией и юзерской базой — для профильной рассылки лучше сработает собственная площадка для вовлечения. #UGC #ContentStrategy #LLM @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO
872
7
​Анализ 150 страниц вскрывает: топ-1 не оригинальнее топ-3, а четверть лидеров вообще не дает новой фактуры Исследование 150 страниц в топ-3 по 50 ключам в десяти нишах оценило, сколько новой информации добавляет каждый урл по сравнению с конкурентами по запросу. Сравнивали по смыслу, а не по формулировкам. Медианная оценка составила 52/100 — примерно половина контента типичной топовой страницы уже имеет семантический клон у соседей по выдаче. Позиция внутри тройки лидеров вообще не коррелировала с баллом. Медианы для топ-1, топ-2 и топ-3 составили 52, 51.5 и 52 соответственно. Что бы ни удерживало первую позицию, в этих метриках это не оригинальность. Четверть страниц из топ-3 получили балл ниже 40 (сплошные заимствования), а урлы с нулевой уникальностью фактуры стояли в топ-3 в четырех нишах. Самый сильный фактор на уровне страницы, коррелирующий с баллом — это оригинальные количественные данные. И в отличие от длины текста, этот параметр не имел потолка насыщения. Страницы с 15 и более уникальными дата-поинтами (цифрами, которых нет у конкурентов) в среднем набирали 62/100, тогда как урлы с одним фактом — всего 40/100. При этом медианная страница в топ-3 содержала всего 4 уникальные цифры. Объем контента практически не двигал метрику: самая длинная треть текстов получила медиану 57.5 против 50.5 у самой короткой, а средняя треть и вовсе сломала паттерн, набрав 49 баллов. Зона роста лежит на поверхности и никем не занята. В 90% серпов как минимум один частый вопрос пользователя (из пула под конкретный ключ) остался без ответа на всех страницах из топ-3. Разрыв между самой оригинальной и самой вторичной страницей внутри одного топ-3 в среднем составил 32 пункта: почти в каждой выдаче есть явный лидер по фактуре и явный аутсайдер. Ниже топ-3 доля вторичного контента подскакивает до 37-40% против 24% в тройке лидеров — чем ниже по первой странице, тем больше воды. Медианы по нишам разлетелись на 20 пунктов: от 42 в медицине до 62 в юриспруденции. Коммерция и B2B SaaS также оказались на самом дне. Редакционный ход везде одинаковый: коротко закрыть базу, которая есть у конкурентов, а затем влить объем в оригинальные замеры, внутреннюю аналитику и ответы на вопросы, которые другие проигнорировали. Исследование фиксирует состояние выдачи, а не алгоритм ранжирования — оно не утверждает, что именно этот балл форсирует позиции. https://api.on-page.ai/research/information-gain-study #ContentOptimization #OriginalResearch #SERPAnalysis @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO
910
8
​Данные 100 топ-блогов за 4 года раскрывают: медиана теряет 85% трафика, а выживают только практики Semrush мониторил оценки органики 100 блогов с апреля 2022 по апрель 2026 года. Все они публично светились в 2022 году как успешные проекты с шестизначным доходом. Итог: медианный сайт потерял 85% поискового трафика. 55 из 100 обвалились на 80% и больше; 20 потеряли от 99%; 12 упали в чистый ноль органических визитов. Вырос только 21 проект. Это не случайная выборка, а элита контент-модели — поэтому списать этот обвал на погрешность не выйдет. Сводные метрики скрывают реальную бойню. Общий ежемесячный трафик по всей сотне просел примерно с 17.8M до 12M — минус треть. Но эту среднюю цифру тащат на себе всего три кулинарных сайта: Kitchen Sanctuary, Pinch of Yum и Jessica Gavin. Без них остальные 97 проектов рушатся на 63%, с ~11M до 4M. Обвал четко бьется по одной переменной: насколько контент требует от автора реальных действий, которые машина не способна подделать. Если отранжировать ниши по медианному результату, картина складывается сама: Parenting +108%, DIY/crafts +2%, Food -44%, Travel -74%, Lifestyle -90%, make-money-blogging -93%, Health -93%, Fashion -95%, Finance -99%. Выжившие кучкуются вокруг контента с опытом из первых рук: рецепт реально приготовили, схему вязания проверили стежок за стежком. Органика Kitchen Sanctuary выросла с 950 000 до 2.4M; Crochet365Knittoo — в 4 раза, с 30 000 до 128 000. Уничтоженные ниши просто описывали теорию, а не показывали практику. Шаблонные финансы и здоровье — ровно то, на что AI Overview отвечает за три предложения без единого клика. Однако рейтинг медиан по нишам таит ловушку. Parenting и DIY в топе не потому, что там процветал каждый сайт. Выжившие проекты — это мелкие личные блоги, которые росли с низкой базы, тогда как крупных игроков в этих же нишах просто выпотрошили. Трафик Easy Baby Life рухнул с 54 000 до 1 100 визитов, а The Flooring Girl — с 29 600 до 1 200. Распределение бимодальное. Безопасных ниш больше нет. Остался только безопасный контент: нужен ли читателю конкретный автор, чтобы получить результат. Механизм работает в две волны. Сначала Helpful Content Update (сентябрь 2023) и мартовский кор-апдейт 2024 года пессимизировали шаблонный одноканальный контент. Затем в 2025–2026 годах дефолтным стал AI Overviews. Гугл перестал утруждать себя наказанием сайтов — алгоритм выдает ответ до того, как юзер кликнет. Данные Ahrefs фиксируют падение кликов по первому результату в органике на 58%, если в серпе висит AI Overview. Получается, одна и та же черта — контент легко сжать в саммари, нет рва из уникального опыта, полная зависимость от чужого канала — гарантированно ведёт к смерти от обеих волн по одной и той же причине. Любой, кто считает "прокачку AI-цитирования" новой золотой лихорадкой, неправильно читает данные: этот плейсмент контролировать ещё сложнее, чем классический поиск. Анализ Semrush доказывает: Reddit забирает около 40% цитирования в LLM, при этом сейчас только 38% ссылок в AI-ответах идут из топ-10 органики (падение с 76% в середине 2025-го). Доля самого Reddit в ответах ChatGPT обвалилась с ~60% до 10% буквально за шесть недель из-за единственного изменения логики извлечения у OpenAI. Видимость в AI — это диверсифицированный портфель, где правила переписывают создатели моделей. Построишь вокруг этого единственный канал привлечения — значит, обвал тех 100 блогов ничему тебя не научил. https://danielstanica.com/posts/Great-Blogging-Collapse #HCU #AIOverviews #ContentSEO @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO
865
9
​Логи WebSocket фиксируют: ChatGPT Deep Research читает исходный код строго сверху вниз, а навигация съедает бюджет Deep Research транслирует всю свою сессию обратно клиенту через WebSocket: каждый запрос, каждую открытую страницу, вытянутый сырой текст и цепочку рассуждений. Запись логов в DevTools с 10+ аккаунтов (по ~20 запросов на каждом) вскрывает, как именно читает агент и на чем сайты теряют это чтение. Бот читает HTML строго линейно сверху вниз: выкидывает <head>, игнорирует JavaScript. Порядок в исходном коде решает, что влезет в лимит, а не позиция на экране: меню, которое CSS отрисовывает наверху, но висящее в конце кода, не стоит ничего; а ответ, зарытый после массивного блока навигации, может вообще не попасть в первое чтение. Это первое чтение ограничено ~5700 символами (медиана, максимум — ~8000). Каждая ссылка отрисовывается инлайн как маркер 【n†anchor†url】, который тратит тот же бюджет. Метрика по количеству ссылок: до 20 ссылок оставляет ~78% лимита под ваш контент; 20-59 ссылок (стандарт для большинства страниц) снижает долю до ~55%; 60+ ссылок оставляет всего ~33% — две трети лимита сжирают меню до того, как агент дойдет до ответа. Ссылка "Skip to main content" не спасает: для ее активации нужен клик, а Deep Research не кликает вообще (команда click использовалась ровно ноль раз за все записанные сессии). Всё управляется тремя командами: search (читает сниппеты Bing через webwithbing, никакого Google), open (беглое чтение) и find (Ctrl+F внутри открытой страницы). Успешный find — главный триггер перечитывания; в 95% случаев выборки страница открывается заново ровно на найденной строке. Если искомого термина нет на странице буквально, агент пробует другой ключ или уходит; поэтому точное вхождение слова в тексте гарантирует второе чтение. Ещё два рычага, которые упускает большинство команд. Атрибуты alt отрисовываются как обычный текст — это единственное, что бот читает из картинок: бейдж с прописанным альтом закидывает факт прямо в ответ, тогда как alt="" пропускается как декор. Данные тянет юзер-агент OAI-SearchBot, он работает отдельно от GPTBot (сбор данных для обучения моделей); разблокировка одного ничего не дает другому. Блокировка в robots.txt отдает боту viewing lines [0 - 0] of 0: ноль контента, и страница молча выпадает из финального отчета. Механика (поиск через Bing, три команды, ноль кликов, лимит окна, чтение альтов) фиксируется стабильно; точные цифры — это срез на июнь 2026 года для платформы, которую OpenAI постоянно обновляет. https://peec.ai/blog/how-chatgpt-deep-research-reads-your-site-what-the-logs-reveal #ChatGPT #LogFileAnalysis #Bots @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO
1 007
10
То, что я разбираю в PRO сегодня, станет баяном в пабликах только в 2027-м. К тому моменту эти подходы перестанут давать хоть какой-то ROI. Конкуренты не умнее — подписчики @MikeBlazerPRO просто знают всё раньше. Смотри, чего ты себя лишил(a): 1. Х3 к цитируемости в ответах LLM — как одна строчка кода на программных страницах заставляет ИИ тащить мани-сайт прямо в выдачу. 2. Плюс 10% с ИИ и обвал органики — почему популярный структурный блок математически сжирает ваш основной поисковый трафик и как его сохранить. 3. Ваши PBN светятся как гирлянда — почему классическая склейка урлов стала главным футпринтом, за который прилетает по бошке и как профи прячут ссылочные сетки. 4. Непробиваемый do-follow траст без аутрича — как переупаковать мани-сайт в корпоративный бренд и стянуть ссылочный жир с платформ, куда не пускают с улицы. 5. Фасетка душит вашего краулера — пока бот вязнет в структуре сайта, один скрытый файл гарантирует полную индексацию без потери краулингового бюджета. 6. Отжим трафика у платформ-гигантов — как ранжироваться по чужим брендовым интент-запросам и собирать горячий спрос. 7. Слепая зона картографических систем — создание посадочных под теневые гео-кластеры, которых нет в официальных реестрах и сбор сотен лидов. 8. Снайпинг валидированных бизнес-моделей — как парсинг одной публичной базы позволяет втупую отжимать горячий трафик SaaS, перебивая их слабые сайты вашим трастом. 9. Клонирование кликабельности без галлюцинаций — как поставить на конвейер идеальные креативы, полностью исключив самодеятельность алгоритма. 10. 100 000 трафика из временных окон — как перехватывать одноразовый спрос и переливать его прямиком на коммерческие офферы с высоким интентом. - Твои конкуренты уже тестируют эти схемы на своих проектах. А ты всё ещё думаешь и ставишь смайлики под моими постами. 😜 Через квартал будешь молча смотреть на чужие графики роста. Либо ты платишь за скорость, либо за своё отставание. Решай, пока не поздно.
1 277
11
Новый сотрудник, пытающийся что-то изменить в нашей рабое И я, понимающий, что это совершенно бесполезная трата времени #Humo
Новый сотрудник, пытающийся что-то изменить в нашей рабое И я, понимающий, что это совершенно бесполезная трата времени #Humor @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO
1 417
12
Перелив ссылочного веса работает только на трафиковых страницах — закрывай остальное через nofollow Два реальных проекта у одного владельца — например, приложение с рецептами и магазин кухонной утвари — и руководство хочет, чтобы домен приложения публиковал контент и массово ставил ссылки на магазин ("Best Kitchen Equipment for {X}"). Оба продукта реальные, поэтому это не классическая PBN, но цель явно в том, чтобы перелить ссылочный вес, что выглядит как серое SEO. Цвет шляпы кроется не в самой тактике, а в том, переходят ли по ссылкам и используют ли их. Ссылка, по которой читатели реально кликают и находят полезной, может масштабироваться; декоративная ссылка, воткнутая только ради передачи веса — это то, что превращает серое SEO в проблему при тиражировании. Риск сидит в множителе масштаба, а не в одной-двух контекстных ссылках. Практический кейс от паблишера, который держал около двадцати нишевых доменов, непрерывно сливающих ссылки на основной проект, показывает сценарий провала: заброшенные, мусорные домены-доноры ушли под фильтр. Более безопасный сетап открывает вентиль для ссылочного веса в зависимости от того, что заработала каждая страница: — У страницы нет бэклинков → закрывай ссылку в nofollow. — Страница не собирает трафик → закрывай ссылку в nofollow. Отталкиваясь от этого, тестируй параметры: что именно дает достаточно оснований для dofollow-ссылки. У того паблишера применение nofollow ко всем ссылкам с примерно 75% доменов-доноров и срезка объема ссылок с оставшихся 25% дали умеренный рост — хотя параллельно изменилось столько всего, что профит нельзя приписать чисто этому шагу. Держи анкоры подальше от переоптимизированных коммерческих ключей на всех этапах. Честный расклад: руководство получает свои ссылки, пользователи видят их только если те реально полезны, а реакция Гугла остается неизвестной. Начинай с малых объемов и позволь полезности, а не количеству, решать, что передает вес. #LinkEquity #TieredLinkBuilding #Nofollow @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO
1 393
13
Reddit фиксирует покупку старых аккаунтов по семи сигналам и сносит всю инфраструктуру покупателя Покупка старого аккаунта на Reddit — это покупка ходячего мертвеца. Высокая карма и многолетняя история выглядят как трастовый профиль, но антиспам-стек Reddit заточен конкретно под отлов передачи прав, и он срабатывает по семи независимым сигналам. Первые три — разрыв идентичности. Смена email на спящем аккаунте считывается как перехват. Смена IP и локации считывается так же, причем ситуация усугубляется тем, что большинство продавцов пускают логины через дешевые прокси или датацентровые IP, которые уже сидят в блэклистах. Вдобавок Reddit снимает отпечаток железа, браузера и устройства, связывая аккаунты по этим параметрам — это та же обкатанная технология, которой они ловят обход банов, поэтому полная смена девайса при входе становится отдельным красным флагом. Следующий сигнал — поведенческий. Аккаунт, который молчал восемь месяцев, а потом начал пушить по 5 ссылок в день в сабреддиты, куда раньше не заходил, не попадает ни в один паттерн живого человека. Два сигнала лежат на стороне продавца, и ты их не контролируешь. Большинство маркетплейс-аккаунтов накачивались бот-фермами через репосты старого вирального контента ради кармы; системы Reddit часто уже пометили их флагами и просто ждут момента для удара. Плюс теневые продавцы перепродают один акк нескольким покупателям или оставляют себе резервную почту и возвращают доступ после оплаты. Седьмой вектор — человеческий. Модераторы нормальных сабреддитов чекают историю постов, и аккаунт, который фармил карму в r/aww, а теперь закидывает ссылки на SaaS, палится моментально. Один репорт от модератора может запустить админское ревью всего, что делал этот профиль. Модераторы сабреддитов подтверждают: они сносят без предупреждения любой аккаунт, который не приносит пользы в обсуждение, так что эта эскалация — рутина, а не редкость. Реальный кост — это радиус поражения. Когда Reddit банит купленный аккаунт, он часто сносит всё, что с ним связано: IP, устройство и иногда даже чистые личные аккаунты на том же домашнем Wi-Fi. 10 акков, купленных за $3500 и привязанных к одному домашнему IP, отлетели за пару недель без права на апелляцию, потому что для теневых покупок нет канала техподдержки. Провал не ограничивается только потерянными деньгами. #Reddit #SpamSignals #BlackHatSEO @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO
1 470
14
Массовые 301-е редиректы на главную сжигают ссылочный вес — направляй удаленные урлы на ближайший интент Закрытый бренд тянет за собой около 200k товарных урлов — примерно 10% от двухмиллионного сайта — и дефолтный план состоит в том, чтобы проставить с каждого 301-й редирект на главную. Этот массовый редирект почти не передает ссылочный вес: Гугл прокидывает ранжирование через 301, только если интент цели жестко совпадает с удаленным урлом. Настраивай перенаправление каждого удаленного урла на максимально похожую живую страницу, в идеале того же типа — товар на сопоставимый товар. Редирект работает только при реальном совпадении интента; если направить страницы на нерелевантные цели, ты просто уведешь трафик, не сохранив позиции. Если снятая с производства деталь не подходит ни к одному другому бренду и не имеет прямого аналога — как в этом кейсе — направляй ее на ближайшую родительскую категорию или PLP, чтобы не упирать пользователя в тупик. Сколько оригинального веса выживет, зависит от точности совпадения и скорости настройки: точные совпадения вытягивают приличный кусок, слабые — почти ничего не восстанавливают. Если закрытый бренд все еще собирает поисковый спрос, посадочная страница удержит эту видимость, а не сольет ее в ноль. Предупреждение стейкхолдерам перевешивает механику редиректов. Поскольку бренд сидит в подпапке на том же домене, что и живые бренды, снос 200k урлов убивает не только их собственный трафик и позиции — он сносит ссылочный вес, тематическую релевантность и траст, которые весь домен тянул из этого раздела. Жди просадки всего сайта на какое-то время, а не только потери удаленных страниц. Инсайты комьюнити — Для товарных страниц с жесткой привязкой к комплектации, где нет аналогов, есть альтернатива редиректам: отдавай страницу "похожие детали для той же комплектации" (модель eBay для истекших листингов). Так покупатели не упираются в тупик, продажи не теряются. Мониторь трафик и вкручивай 301 только когда трафик на эти урлы просядет. — Встречный взгляд на страницу-заглушку: любая страница "этот бренд закрыт" должна отдавать 404, а не 200 — полезная 404 всё равно решает задачу юзера. Это противоречит идее держать лендинг для остаточного спроса, так что решение зависит от того, есть ли у бренда еще живой поисковый трафик. #Redirects #LinkEquity #TechnicalSEO @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO
1 447
15
LLM выдумывают источники — генерация текста скрывает реальную проблему с поиском данных в 80% случаев Агентство, масштабирующее статьи через Claude и ChatGPT, уперлось в знакомую стену: черновики вылетают быстро, но модели выдумывают статистику, ссылаются на несуществующие отчеты и генерируют правдоподобные URL, которые отдают 404. Выдуманный маркетинговый отчет HubSpot за 2026 год с конкретными процентами проходил как реальный до первой проверки. Если направить вторую модель или "совет LLM" на текст для кросс-чека, они просто вернут новые битые ссылки. Надежные ссылки на источники — вот где модели сыплются примерно в 80% случаев. Смена фрейма, которая ломает старый пайплайн: написание текста никогда не было медленным этапом, время жрет поиск и фактчекинг. ИИ ускорил дешевый шаг, не тронул дорогой и добавил третью задачу — вычищать выдуманные URL. Это шорткат для генерации, а не для создания контента. Механика: LLM — это движок предсказаний, заточенный на удовлетворение запроса; при нехватке контекста он скорее сгенерирует правдоподобную цитату, чем не выдаст ничего. Диагноз диктует решение — перестань требовать от модели искать факты. Сначала скорми ей исходники (PDF, ссылки), жестко ограничь генерацию только этим материалом, зафиксируй факты в серии промптов, а затем пропиши, что именно выдавать в каждом разделе на базе предоставленных данных. Используй самую продвинутую модель. Для любого утверждения извне требуй моментальную инлайн-цитату — это срезает время на проверку. Один полевой тест внутреннего инструмента на API OpenAI зафиксировал цифры: статистика врет в ~40% случаев, попадает в 60% — это слишком высокий процент брака, чтобы выкатывать текст без вычитки. Там, где ручная проверка остается в пайплайне, решает избыточность, а не доверие. Выделенный скрипт фактчекинга прогоняет 7-8 проверок каждой метрики: пробивает ответ URL, ищет эту же цифру в других источниках, а при 404 ищет альтернативный источник, который сам уходит в начало очереди на подтверждение. Всё без валидного источника улетает на ручное ревью вместо релиза, поэтому одну галлюцинацию отлавливает следующий чек. Более тяжелый сетап прогоняет контент через 22 поэтапных чекпоинта, где несколько моделей критикуют выдачу друг друга до того, как профильный эксперт внесет финальные правки. Железобетонный потолок: всё это не дает точности без присмотра. ИИ годится для структуры и рерайта, но каждый факт всё равно проходит через человека. Если планка — 100% достоверность, придется вычитывать каждое слово независимо от того, какая система собирала черновик. Инсайты комьюнити — Быстрый триаж 404 прямо в доке: вставляешь сгенерированные URL в Google Doc и кликаешь по каждому один раз. Появился баннер с названием сайта и мета-деском — ссылка живая; нет баннера — выдуманная 404. — Где кончается профит от ИИ-генерации: если ты не сечешь в теме, модель звучит уверенно, но врет, и в итоге ты гуглишь каждое предложение — написать самому быстрее. — Ловушка второго порядка: подтверждение источника доказывает лишь доступность ссылки, а не достоверность. Реальный URL, который ссылается на фейковые данные из другой статьи, всё равно пройдет базовую проверку. — Ограничители слетают: кастомные инструкции под клиента, артефакты и задокументированные пайплайны в Claude повышают надежность, но модель всё равно периодически забивает на правила прямо посреди задачи и лепит отсебятину. Если после генерации спросить, не пропустила ли она шаги из чеклиста, иногда это вскрывает косяк. #AI #LLM #Hallucinations @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO
1 218
16
​Том Каппер доказал, что цитации — это, вероятно, неправильная метрика для отслеживания на конфе Search 'n Stuff, и я с ним согласен, пишет Марк Уильямс-Кук. Возьмем этот пример: кто здесь победитель? Audi упоминается в первом ответе, затем Audi S6, Audi A6 и Audi R8 как ответы на запрос; но цитация ведет на sealinkparts[dot]com. Используя цитации как метрику, вы бы сделали вывод, что у Audi нет видимости в этом результате. Это очевидно лишено смысла, так как именно бренд представляет наибольшую ценность для пользователя! Инсайты комьюнити — Полевые данные по 85 британским компаниям среднего бизнеса в ChatGPT, Claude и Gemini показывают: упоминание в самом ответе решает, услышит ли покупатель вообще о бренде. Если компания названа, в 63% случаев она сидит в топ-3, тогда как след из цитаций часто ведет вообще в другое место (на сайт запчастей или в директорию с данными). Оценка только по цитациям помечает отлично видимые бренды как невидимые и упускает из виду невидимые, прячущиеся за здоровым количеством цитаций. — Если LLM цитируют агрегаторы, нишевых паблишеров или сторонние инструменты (как тот сайт запчастей в примере с Audi) для формирования ответов, традиционный линкбилдинг ради DA устаревает. Офф-пейдж стратегия для B2B SaaS смещается в сторону Digital PR и гестпостов конкретно на тех доменах, которым LLM уже доверяют как первоисточникам. — Для локального бизнеса замените метрику цитаций на показатели результата, которые короткая локальная воронка раскрывает напрямую — звонки, запросы маршрутов, забронированные заказы. Цитация, которая не приносит ни звонка, ни заполнения формы — это пузомерка, тот же паттерн провала, который сделал позиции обманчивой главной метрикой. #AIOverviews #DigitalPR #LLM @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO
1 269
17
Ссылки из встроенных виджетов не передают ссылочный вес — Гугл помечает их как ссылочный спам Встраиваемый товарный виджет, закинутый на партнерские сайты для сбора бэклинков — это старая схема линкбилдинга, и Гугл прямо назвал ее поименно: виджетные ссылки упоминались в напоминании 2016 года и до сих пор висят в гайде по ссылочному спаму. Относись ко встроенной ссылке как к элементу, который алгоритм уже дисконтирует, а не как к источнику бэклинков. Механика решает, вопрос iframe против компонента: содержимое чистого iframe схлопывается со страницей-хостом, на которой он висит, если ты не заблокируешь это через robots.txt или noindex на встроенной странице. Большинство реальных реализаций используют JS со ссылкой в теге noscript, чтобы прокинуть ее на страницу-хост; ссылка, зашитая внутри фрейма, вообще не находится на странице-хосте, поэтому она почти не несет ценности в любом случае. Без окружающего контекста виджетная ссылка в лучшем случае имеет низкую ценность, даже когда Гугл ее просто игнорирует. Реальная угроза — это футпринт. Ссылка из виджета погоды в сайдбаре миллионов страниц на тысячах доменов словила санкции; решением стал nofollow плюс noindex на страницу iframe, восстановление шло медленно, и трафик так и не вернулся полностью — вскоре Гугл вшил собственный виджет погоды прямо в выдачу. Поэтому вешай nofollow на виджетную ссылку, а если она грузится внутри iframe со страницы под твоим контролем — закрывай ее через noindex. Держи виджет ради KPI, который он реально качает — реферального трафика, а не как схему линкбилдинга. Инсайты комьюнити — Раздача встроенного стороннего контента через обратный прокси может заставить Гугл атрибутировать этот контент сайту бренда-хоста — даже на других серверах или поддомене — поэтому встраивающая сторона не получает от этого никакого буста позиций. — Для легитимных, точечных виджетов реалистичный негативный сценарий заключается в том, что Гугл просто проигнорирует ссылку, а не впаяет санкции; кейсы с фильтрами прилетали за массовые футпринты (ссылки в сайдбаре на тысячи доменов), так что радиус поражения растет пропорционально масштабу развертывания виджета. #LinkSchemes #ToxicLinks #LinkBuilding @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO
1 350
18
Пока ты вылизываешь техничку, конкурент сливает твой краул-бюджет в ноль Ты оптимизируешь скорость, фиксишь редиректы, шлифуешь сайтмап. А в это время кто-то методично гоняет гуглобота по тысячам несуществующих страниц твоего сайта. И это не баг. Это дешёвая и злая схема негативного SEO через популярный софт. Конкурент в пару кликов генерит лавину фейковых урлов и строит на них мусорные бэклинки. В итоге Google тратит лимиты на твои "404" вместо реальных страниц. Свежий контент висит без индексации неделями. Ты даже не поймёшь причину просадки, пока не научишься читать след этой атаки. Как вычислить атакующего и закрыть дыру в краул-бюджете → @MikeBlazerPRO Действуй, пока тебя не закопали.
1 488
19
Статья на 3000 слов штампует 60 дистрибуционных атомов — каждый линкуется обратно и прокачивает основу Один лонгрид на 3000 слов пилится примерно на 60 атомарных кусков: 27 самостоятельных инсайтов, 12 неочевидных статистик, 8 пошаговых разборов и 15 цитат — каждый переупаковывается под конкретную платформу, а не тупо копипастится. Затраты на единицу контента — $0 (база уже есть), заявленный множитель охвата — 14x. Атомизация работает как повторяющийся конвейер: забираешь основу, нарезаешь на куски, подгоняешь под форматы площадок, раскидываешь по каналам и таймфреймам, а потом чекаешь, какие форматы зашли, чтобы скорректировать следующий круг. Специфика платформ решает: текст в LinkedIn — это 200-300 слов, Twitter требует быстрый факт плюс линк, короткое видео — это 30-60 секунд визуализированного инсайта, а email — глубокий разбор на 500-800 слов. Один месседж, разные обертки. Для органики решает перелинковка, а не сам объем. Каждый атом линкуется на оригинал. Так дистрибуция параллельно работает как заливка ссылочного веса на кластер и создает независимые точки входа — дополнительный трафик наслаивается на основу, а не каннибализирует ее. Выкатка размазывается на недели, а не вываливается за день, чтобы куски не топили друг друга в ленте. Стек под ключ обойдется в $300-500/мес: Opus Clip для нарезки видосов, Repurpose.io для автоматизации соцсетей, Canva под графику с цитатами, Loom для озвучки. Ошибки банальны: дословный кросспостинг, слив всех атомов разом, отсутствие CTAs на кусках и забытый линк на исходник, который вообще-то и превращает всю эту схему в полноценное SEO, а не просто в накрутку охватов. #ContentMarketing #ContentSyndication #InternalLinking @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO
1 450
20
Маскировка ссылок через JS не останавливает Google — бот парсит URL-строки напрямую из HTML и JSON Удаление <a href> и вывод внутреннего URL только через span с атрибутом data-link или инлайн-объект JSON не прячет его от Google. Поисковик парсит похожие на урлы строки везде, где их находит — в исходном HTML, в отрендеренном DOM или в JSON-блоках — и ставит их в очередь на краулинг. Разница между span и классической ссылкой только в одном: URL не будет считаться внутренней ссылкой и не передаст ссылочный вес. Но его все равно проиндексируют. Официальная документация Google по ссылкам намекает на это, помечая нестандартные конструкции как "не рекомендуется (но Google все равно может попытаться это спарсить)". Логи подтверждают это элементарно: закинь страницу с такой урлоподобной строкой, запроси индексацию и смотри, как бот стучится по этому адресу. Попытка спрятать ссылку от краулера работает так же паршиво, как безопасность через запутывание кода. Не отдавать URL Гуглу напрямую — нестабильный костыль, который никак не мешает третьим лицам сослаться на этот же актив извне. Если задача реально отрезать ботов от этих страниц, единственные железобетонные рычаги — это robots.txt (для послушных краулеров) и правила фаервола или WAF, сносящие запросы от нежелательных юзер-агентов. Инсайты комьюнити — Кодировка Base64 для URL-строк — это слабая обфускация: Google умеет декодировать Base64 (один практик отмечает, что не ловил бота на дефолтной настройке, но полагаться на это опасно). Чтобы клиентский энкодинг выжил, завяжи кастомный JS-декодер с правилом в robots.txt, которое блочит от сканирования сам скрипт — так бот тупо не доберется до логики, которая собирает URL. — Самый надежный вектор эксплуатирует механику Гугла: бот ставит цели URL в очередь, но никогда по ним не кликает. Сборка или расшифровка реального URL только внутри обработчика onclick означает, что доступный для краулинга DOM никогда не засветит парсящуюся URL-строку — и тогда блокировка через robots.txt вообще не нужна. Варианты внедрения: хешировать или шифровать урлы с клиентской расшифровкой через объект crypto (или микро-библиотеку), либо прогнать двустороннюю автозамену, меняющую / на символ, который никогда не встречается в урлах. #Crawling #JavaScript #TechnicalSEO @MikeBlazerX ⚠️ Закрытый канал: @MikeBlazerPRO
1 441