🕵️‍♂️ Эксперимент: работает ли SEO-hide в 2025 году?

Решили вместе с seo блоггером Евгением Молдовану проверить метод SEO HIDE — способ маскировки ссылок от поисковиков через замену <a> на <span>. Для пользователя такие элементы выглядят как обычные ссылки, но для поисковых систем — это уже не ссылки, а просто теги разметки фразового контента.
Задача эксперимента — перестать сливать PageRank на служебные страницы типа "Контакты" или "Политика", но оставить для пользователей функционал рабочих ссылок, чтобы обеспечить навигацию на сайте.

🔬 Что сделали:
Создали на сайте Евгения страницу с 4 замаскированными ссылками, оформленными через span (в некоторых случаях с onclick, в других — просто стилизованные как ссылки), и одной обычной ссылкой <a> для контроля.
Способы обработки ссылок были разные (можете сами посмотреть в исходном коде). Это и использование decode64(url), и использование link.replace, и подстановка ссылки из атрибута data-href после события 'scroll'.

🔍 Критерии:
При постановке эксперимента единственным объективным показателям того "видит" ли Google ссылки считалось наличие такой ссылки в Google Search Console. Конечно всем известно, что Search Console показывает не все ссылки. И ссылка может существовать, учитываться в ранжировании, но при этом не отображаться в Search Console. Но других реалистичных показателей нет

📉 Результат:
В Google Search Console отобразилась обычная (контрольная) ссылка.
Замаскированные через span — поисковиком частично проигнорированы. Полной неожиданностью стало учёт ссылки вида <a href="#" data-href="https://example", в которой в атрибут href подставлялось значение url после событися scroll (то есть прокручивания страницы). Были проведены дополнительные эксперименты, которые показали, что учёт таких ссылок происходит не сразу после индексирования страницы, а через какой-то промежуток времени. Фактически это означает GoogleBot на каком-то этапе (рано или поздно) не только рендерит страницу, но и скролит её!!!

❗️ Вывод:
Метод SEO-hide (в зависимости от реализации) действительно препятствует индексации ссылок и передаче веса. Это может быть полезно для сохранения веса на продвигаемых страницах.
Но важно понимать: невозможно так скрыть сам факт перехода с вашего сайта на другой. Эти переходы все равно определяются с помощью браузера Chrome и GA, поэтому маскировать офферы или партнерские ссылки нет смысла, Google определит что переход был с вашей страницы. Такой способ подойдёт только для манипуляций с PageRank.

✅ Где это сработает:
Метод может хорошо сработать на больших сайтах (от 500+ страниц), так как при таком большом количестве страниц статистический вес еще играет роль. Кроме того экспериментально доказано, что чем меньше ссылок ведёт на условную служебную страницу про "Политики на сайте", то тем реже GoogleBot её посещает, а значит чаще посещает важные целевые страницы.

⚠️ Disclaimer:
Есть сеошники, которые считают, что не все учтенные ссылки отображаются GSC. Эксперимент проводился больше 3 лет и за такое время ссылка все таки бы отобразилась бы, тем более что тестовая зашла в консоль.

💡 Почему сработал каноникал на внутреннюю страницу после апрельского апдейта Google

После апдейта примерно 16 апреля главные страницы (особенно одностраничники) начали терять позиции (обратили внимание в гембле). SEOпаб заметили: трафик начали собирать внутренние страницы, если:

1) главной странице задавали другой lang (например, fr-BE)

2) копию клали в подпапку (/fr-fr/) с lang="fr-FR"

3) с главной ставили rel=canonical на новую страницу

4) обе страницы связывали через hreflang

Тема 100% рабочая, обсуждалась у Игоря Бакалова и Strong SEO.


Почему это работает — смотрим в слитых факторах ранжирования Гугла:

CompositeDocForwardingDup и CompositeDocExtraDup
Google считает главную дубликатом и передаёт весь вес новой странице (/fr-fr/), учитывая canonical (non-forwarding dup). Lang на главной меняется чтобы не было языковым дублем.
ecnFp скорее всего хранит фингерпринт (хеш функцию) текстовой части для сравнения тектов. При этом примечательно, что с помощью rawPagerank и purposes можно передать на новую версию не только все ссылочное, но и выборочные накопленные данные (например с navboost - поведенческие факторы). Это объясняет почему внутренняя страница начинает себя вести как будто она главная - все данные ссылочного и поведенческих передаются.


CompositeDocLocalizedVariations
dupsComputedAlternateNames - хранит все версии, которые записаны в language
Пример
<link rel="alternate" href="https://site.com/" hreflang="fr-BE">

<link rel="alternate" href="https://site.com/fr-fr/" hreflang="fr-FR">

IndexingDupsComputedLocalizedAlternateNamesLocaleEntry
Примечательно, что шаблонизатор может получать из пути url данные (в примере из url подпапки (/fr-fr/) ) - данные хранятся в urlRegionCode, используется для хранения альтернативных языков/локалей, влияет на приоритет показа нужной языковой версии. То есть теоретически метод бы сработал и без lang="fr-FR".


CompositeDocIndexingInfo
Когда каноникал передается внутренней странице, это все сохраняется в noLongerCanonicalTimestamp для нужного url. Это нужно чтобы 2 страницы при смене локали или языка не стали каноничными. Для сохраненного текста это дублируется с помощью indexingTs.

Данные более высокого уровня хранятся в CompositeDoc, а конкретно в localizedvariations и localizedAlternateName.

В результате новая внутренняя страница получает все сигналы и позиции. Google сам "перепривязывает" учитывая каноникал, потому что новая страница является правильным языковым дублем. Тут нет никакой магии, все это заранее реализовано в ранжировании.

Остается главный вопрос - почему Гугл вообще ополчился на главные страницы? По моей теории, Google решил дать больший приоритет не региональным сайтам, а сайтам которые имеют локальные версии. Самый простой способ это реализовать - обнулять регион для главной и смотреть на hreflang на внутренних. А так как это были региональные одностраничные сайты вида casino.fr у них просто не было нужных языковых версий на внутряках, что и приводило к жесткому падению в выдаче.
Еще возможно что все намного проще -что глюкнуло у Google и у главных отлетели lang.

Массированные ложные жалобы на сайты в Cloudflare - обсуждение на Серче.

Мы столкнулись с ситуацией, когда на наш сайт (обычный WordPress-блог, без логинов, сид-фраз, форм ввода) в течение 5–10 минут поступили жалобы с 5–7 разных Gmail-адресов. Все письма были якобы от "пользователей", которые утверждали, что сайт занимается фишингом. Ни одного доказательства — только текст "ваш сайт редиректит, украл данные, срочно блокируйте" и т.п.

⚠️ Через несколько часов сайт оказался помечен как фишинговый, без какой-либо верификации со стороны Cloudflare. После этого:

— Доступ к сайту блокируется через браузеры
— Весь аккаунт или заказ в хостинге может быть отключён "до разбирательств"
— Репутация домена портится

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

Первоначально думал что это локальная ситуация с конкретным сайтом, но нет. Оказывается тема началась еще в 2024 году, но в 2025 дошла и русскоязычного комьюнити, бомбили в основном серые тематики.
На самом форуме куча обсуждений 1, 2, 3, 4, почти везде указывается что результат блокировки - это ложные письма в поддержку Cloudflare.
О массовых ложных заявлениях о фишинге есть целые топики 1, но самое еще хуже это то что если ты отбился - прилетают опять. Основные жалобы пошли с апреля 2025 года, даже на Серче есть топик.

В чем же причина такого поведения Cloudflare ? Почему домен могут локнуть даже после пачки ложных доносов с временных почт?
Похоже что причина в том, что на сервис прилетело много обвинений в том что он скрывает фишинговые сайты, в 2024 был пик, жаловались все, от Спамхауза, до тематических СМИ, которые обвиняли Cloudflare в прикрытии фишинга.

Как защититься?
Мониторить все уведомления, быть готовым в любой момент отключиться от сервиса, иметь бекап.

Яндекс закрывает доступ к старому old.wordstat.yandex.ru через 2 месяца и открывает доступ к бета-версии API Вордстата — сервиса, который показывает статистику запросов к Поиску Яндекса.

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

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

Доступ к API ограничен двумя видами квот:
Общая квота: при превышении — ошибка 503 (Service unavailable).
Персональная квота (по OAuth-токену): ограничение на количество запросов в секунду и в сутки.

Update:
Кстати кто пробовал подавать заявку на Beta Wordstat API и у него была ошибка с ClientId в заявке - отправьте заново, я писал в поддержку сервиса и там исправили ошибку.
Опубликован faq по запросам к сервису.

13 июня :
Спасибо за вашу заявку! На данный момент мы получили достаточное для проведения этапа бета-тестирования количество заявок.
Новые аккаунты будут подключаться после релиза полной версии API.

На мероприятии Google Search Central Live впервые официально озвучен набор сигналов, которые влияют на индексацию страниц. Эти сигналы определяют, какие страницы Google решает включить в свой индекс и когда.

✅ Влияют на индексацию:
Country
Совпадение стран домена + к шансу индексации.
Language
Тоже по языку.
HTTPS / Secure Site
Наличие защищённого соединения (HTTPS) — положительный сигнал индексации и доверия.
Crawlability
Если страница доступна для сканирования, она может быть проиндексирована.
Core Web Vitals
Ключевые метрики производительности страницы (скорость загрузки, интерактивность и стабильность) влияют на индексацию.
Dofollow Links
Ссылки с атрибутом dofollow + к шансу.
Content Recency & Freshness
Актуальность и свежесть контента повышают шанс на быструю индексацию.
Spam Policies Violations
Нарушения антиспам-политик Google — негативный сигнал, который может привести к исключению из индекса.

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

Пример таких сайтов:
http://tap.link
https://taplink.ru/
https://taplink.cc/
https://linktr.ee/
https://lnk.bio/ru/
https://smart.bio/
https://tap.bio/
https://hipolink.net/
https://choko.link
https://obio.me/ru/
https://campsite.bio/
https://taplink.ws

Зачем это все надо:
— Попадают в топ по брендовым запросам
— Формируют “сущность” бренда в глазах поисковиков (особенно Google) - это сейчас очень хорошо работает.
—Можно юзать для партнерских ссылок с брендом, пример.
— Разбавка ссылочного профиля — естественные анкоры и разнообразие доноров (в том числе с nofollow )
— Такие страницы легко продвигать поведенческими и они реально могут выйти в топ
— Можно в топе по бренду вытеснять негатив (идеально для SERM)
⠀
По минусам:

Многие сервисы ограничивают количество символов описания, количество ссылок. Поэтому не рекомендую использовать для него генеренку ChatGPT, страницы могут вылетать из индекса.
Поэтому раз в полгода нужно прогонять их через индексаторы или строить ссылки на них с соцсетей.

Почему PBN ссылочное легко палится.

У Гугла есть интересный патент на метод обнаружения ссылочного с PBN сеток.
Кроме стандартных методов обнаружения перелинкованных сеток есть идеальный метод обнаружения манипулирования выдачей.

Метод использует математическую производную функции важности узла по отношению к так называемому коэффициенту связи (coupling factor). Проще говоря:
1) Строится направленный граф всех ссылок.
2) Вычисляется PageRank (или аналогичная мера важности) всех узлов.
Затем анализируется, как меняется важность узлов при изменении параметра связи.
Фактически coupling factor - это результат функции, которая рассчитана на десятках параметрах (авторитет домена, статистический вес, анкоры, качество текста). В классическом PageRank это было статическое значение 0.85 , означающее необходимость передачи 85% статистического ссылочного от донора к источнику.

Далее фактически отключая вес (coupling factor) по 1 домену у всех PBN , которые ссылаются на продвигаемую страницу и замеряют результат.
Если сайт теряет основной вес — значит на него ссылаются с помощью PBN
В ответ — Google снижает его позицию или игнорирует эти ссылки.

Фактически - если каждый PBN сайт имеет общие ссылки с другими сайтами PBN, то ссылки на продвигаемую страницу будут сильно ослаблены или вообще не учтены. В сливе Гугла факторов ранжирования я обнаружил, что используются не только ссылочные факторы для определения PBN, но и whois, общие IP, подсети, страны, дата регистрации домена, уровни домена (всего около 30 факторов).

Если вы покупаете ссылки с сайтов PBN, обязательно смотрите ссылочное, не гонялись ли эти сайты по общей базе профилей, адмитов и доноров.

Если доноры не имеют собственного ссылочного, которое было на момент дропа и превращения в PBN - я бы вообще не рекомендовал брать.

Патент Google против спама
Google более 10 лет использует способ борьбы с манипуляциями в поисковой выдаче.
Как это работает:
Допустим, ваша страница сейчас на 7-м месте. Вы "улучшаете" её спам-техниками — добавляете ключевые фразы или LSI, невидимый текст или создаёте ссылки с PBN. Алгоритм может решить, что вы заслуживаете первого места. Но вместо резкого скачка рейтинг меняется постепенно или вообще падает.

Зачем Google временные позиции?

Если вы пытаетесь быстро поднять страницу в топ, алгоритм может замедлить рост рейтинга ( ранг растёт медленно, за 70-90+ дней) или даже временно понизить его ( сначала падение на 20+ дней, потом рост), также есть момент рандомизации, чтобы вы это не отслеживали.

Если вы будете пытаться вернуть старую позицию (например, удаляя изменения или переписывая текст), рейтинг может упасть ещё ниже.

Если страница имеет явные сигналы манипуляции, её могут пометить как спам и понизить в выдаче .

Последнее время не палю кейсы, потому что показывать свои сайты особо не хочется. Но этот мой сайт многие знают, так как я его покупал и продавал на Телдери.
Юзал его для тестов - проверял фишки, влияние оптимизации, внедрения сущностей, микроразметки. Паралельно продавал ссылки, дабы просто так не пылился.

В кейсе пример, что даже с такого гавносайта можно поднимать денежки, если ловить трафик на узкие ниши.
Кейс - как я в 2023 году продал около ненавистных мне 30 Iphone 15 и не смог продать не одного в 2024 😅 Надеюсь пафоса нагнал😆
https://e-moldovanu.com/seo/kejs-prodvizhenie-sajta-po-prodazhe-iphone/

Я много времени тратил на поиск интересных патентов и их анализ вручную. Недавно Андрей Джилавдаров и @hoolz выкатили бесплатный сервис в котором сделана выборка и классификация патентов которые относятся к поиску:
Патенты Гугла
Патенты Яндекса

Теперь можно удобно анализировать нужные вам патенты на русском языке. Также можно копировать промпт из постов и вставлять в Gemini (я юзаю его) для более детального анализа.
Или копировать ссылку на pdf патента и кормить сервису https://notebooklm.google.com/
Иван @hoolz отвечает за реализацию, я пообщался и он поправил распознавание части патентов, поэтому по каким то косякам у сервиса пишите ему.

Новый Яндекс Wordstat API - используем с помощью скрипта на Python.

Парсим до 2000 ключей за 1 запрос. Можно спарсить все ключи по запросу из Wordstat , для этого установите рекурсивный сбор побольше (ограничение от Яндекса в сутки 1000 запросов).

Перед запуском устанавливаем библиотеки:

pip install streamlit requests pandas

Подробнее о подключении.
Структура запросов в справке Яндекса.

В исходник вставьте свой Яндекс OAuth, вот подробнее о его получении.
Ссылка на исходник (Гитхаб).

ПОВЕДЕНЧЕСКИЕ ФАКТОРЫ GOOGLE В ТОПЕ: от чего зависит позиция в выдаче.

Google учитывает клики в топе для формирования новой выдачи (патент). Это позволяет бустить страницы, которые имеют лучшие поведенческие факторы и понижать с плохими. Финальная оценка получается получается путем умножения исходной оценки релевантности (IR Score) или авторитетности на коэффициент корректировки (Adjustment Factor, еще один фактор).

Факторы которые используются:
1. Глубина вовлечения (Dwell Time)
Система анализирует данные внутри одной поисковой сессии (search session), сравнивая, как долго пользователи остаются на вашем URL относительно конкурентов, которые были открыты (co-clicked) в той же сессии.

• «Победы» (X): Ваш URL удерживал пользователя дольше, чем URL конкурента. Это сигнал высокого Dwell Time и качества контента.

• «Потери» (Y): Ваш URL удерживал пользователя меньше, чем конкурент.
Для SEO: Если клик длится дольше, чем у соседа по Топу, это плюс к вашему рейтингу.

2. Привлекательность сниппета (CTR)
Метод оценивает, насколько хорошо ваш сниппет «отрабатывает», когда он показан (impressed) в выдаче.
• «Победы» (X): Ваш сниппет был кликнут, в то время как конкуренты, находящиеся, например, выше вас, были показаны, но проигнорированы. Это говорит о высоком CTR и релевантности сниппета.
• «Потери» (Y): Ваш сниппет был показан, но проигнорирован, в то время как конкурент (часто ниже вас) был выбран.

Корректировка рейтинга
1. Проверка данных: Прежде чем применить корректировку, система проверяет, собрано ли достаточно данных (сумма X + Y должна превысить порог надежности).

В патенте указан пример кратности = 10 кликов.

2. Фактор домена: Если данных для конкретного URL не хватает, используется корректирующий фактор всего домена.
3. Финальный ранг: Если X > Y, рейтинг страницы бустится. Если Y > X, рейтинг понижается. Таким образом, ПФ напрямую влияют на финальную позицию в Топе.

В общем классика - хочешь быть в топе нужно иметь не только лучший ctr в выдаче, но и лучшие поведенческие на странице по сравнению с конкурентами. Не стоит воспринимать патент как 100% то что работает в Гугле - сама формула намного сложнее.