Что по статейникам?

Это наиболее частый вопрос который задают в личке. После апдейтов Гугла и Яндекса с зачисткой AL контента пострадали в том числе и вполне нормальные сайты.

Личные потери - меньше 1К баксов. Еще в 2020 году я понял что инвестирование в статейники начало терять смысл. Поэтому с того момента я создавал небольшие статейники на 10-30 страниц и продавал тем кто заходил в разные ниши. С точки зрения затрат-прибыли это было очень выгодно.

После изменений в этом году выживут меньше 20% сайтов. На многих биржах (к примеру etxt) падение заказа контента в более 10 раз. Много кто наполнял сайты стопнули заказы. Я тоже ушел с заказа статей, так как в 90% получаешь генерированное гуано, даже если просить не использовать чатботы. Пока биржи не решат эту проблему - возвращаться не планирую.

Что же будет развиваться? Если ваш статейник не прихлопнуло (а я своих нишах вижу даже которые выросли в 2 раза) - наполняйте и развивайте, у вас есть шанс охватить всю семантику.

Стоит ли развивать статейник сейчас? Стоит, если заходить в ниши на подобии новостей, появляющихся тем (те же чатботы, пример - реновация, где любая инфа от чатботов не подойдет, так как нужны актуальные данные).
Ближайшие время будут расти сайты с отзывами (там очень хорошая доходность не зависящая от контекстной рекламы).
А если у вас старый статейник вырос в трафике - нужно заливать больше!

Ближайшее время должны появится новые методы создания статейников, так как понятно, что старые методы вымирают. Парсить вордстат уже бессмысленно, нужно дополнительно чекать конкуренцию, выдачу (на чатбота, картиночную выдачу, видео в топе).

🚨 Решение проблемы с индексацией RSS лент комментариев в WordPress 🚨

Google упорно пытается индексировать страницы, даже если они заблокированы в robots.txt. Особенно это касается RSS лент комментариев, которые не всегда нужны и могут попасть в дополнительный индекс, ухудшая ранжирование сайта.

💡 Как я решил проблему: Создал плагин для WordPress, который блокирует индексацию RSS лент комментариев, но сохраняет основную ленту и Яндекс Турбо.

Плагин: ссылка на скачивание

Прописывает 301 редирект с комментариев на посты.
Позволяет сохранить нужные RSS ленты.

Полный пост с описанием на моем блоге.

Из слива ранжирования Гугла стало более понятно как передается вес от донора акцептору.
Гугл для каждого сайта и страницы рассчитывает вектора.
siteFocusScore - определяет сосредоточенность на определенной теме (тематичность).
siteRadius - указывает на охват темы (чем больше тем лучше, указывает насколько вы выписали ядро по кластеру).
siteEmbeddings и pageEmbeddings - это средний вектор сайта и страницы.
Отдельно также высчитывается вектор анкора ссылки (anchorMismatchDemotion).
На практике это позволяет передавать меньше веса нерелевантным донорам (используется весь topicEmbeddingsVersionedData) и наоборот - увеличивать вес ссылок которые опубликованы с тематичного сайта и тематической статьи.

Как это использовать: под каждую ссылку пишите в ГГЛ или Миралинксе релевантную статью или в требованиях указывайте на это условие, если вы хотите контекстную ссылку.

Если тема вам интересна, можете протестировать Top2Vec и BERTopic или попроще TF-IDF с Word2Vec.

Вопрос от Андрея Сороки по показам в Google:

Мне может кто-то объяснить как так получается, что показы на сайте в консоль растут на проекте одном - но средняя позиция - 60. То есть по логике мою страницу в среднем человек видит на 60 странице ?

Кто туда долизывает и как так может быть много показов и почти нет кликов ? По логике пр такой позиции средней по всем ключам столько показов просто быть не должно, или не прав?)

Для начала самая простая ситуация - у нас страничка (url) ранжируется по 5 ключам. Средние позиции каждого ключа (8,70,70,72,80). Высчитываем среднюю позицию страницы (8 + 70 + 70 + 72 + 80) / 5 = 60 = средняя позиция.
По показам то же самое. К примеру сумма всех ключей 200 показов. Из них 150 показов 8 места, у остальных по 5-10. Для 8 места средний органический ctr = в районе 1.62 % = получим около 2 кликов с копейками (на практике у меня в рунете ctr в разы ниже для 8 места и для своей выдачи я возможно бы и не получил клики).
Также нужно учитывать что вы смотрите среднюю позицию в моменте, как правило среднюю средней. Каждый по своему выставляет диапазон дат, но я как правило смотрю диапазон в 3 месяца. Как вы понимаете, за это время страницы могут быть как в топе (генерируя показы и клики, так и вылететь за +40 среднюю позицию, а потом снова вернуться).

Окей скажите вы, с страницами все понятно. Но откуда на 60 позиции конкретного ключа генерируется 30 показов? Неужели люди туда доходят?

Варианты - мигание в топе, когда вы топ 10, то топ 100. Второе - это персональная выдача, где вы для всех на 60 месте, но для пользователя который не раз ваш сайт посещает на 3 месте. Это региональная выдача, где за счет лучшего ctr вы в топе. Третье - это искусственные показы сгенерированные Ахрефсом, Семраш, AL ботами которые постоянно сканируют выдачу на новый контент с помощью которого можно обучить нейросеть. Это скан позиций, вредоносные парсеры, сервисы LSI, поиска n-gram и так далее. Многие парсеры выдачи получают сразу топ 100 выдачу, показ засчитывается, но ваш сайт никто не видел, парсер сразу импортирует топ 100 url с title и описанием.

Но как быть с ситуацией, когда у вас к примеру 4 позиция в Google , 1000 показов и 0 кликов или ctr в десятые доли процента? Бывает и такое.

Основные причины такой ситуации:
1) Много рекламы + у вас очень плохой сниппет.
2) Фичи в выдаче - к примеру в обычной выдаче блок с картинками. Например по запросу "виды грибов" вы можете показываться на первой позиции, но при этом сайт будет в вкладке "еще 6 изображений"
3) Вы в "Вопросы по теме"
4) Вы в топе по брендовым запросам, по которым может быть 10К показов и пару кликов, потому что люди ищут конкретный бренд или сайт.
5) Ваш сайт вышел в топ по стране в которой ваш сниппет непривлекательный (у меня была ситуация где я получил 3000 показов для русскоязычного сайта из ОАЭ в выдаче ). Для понимания представьте что вы увидите нечто подобное - сильно хочется кликать? А для араба из ОАЭ русский в выдаче выглядит такими же крокозябрами.

Нужны ли подобные посты на канале? Потому что кому то они покажутся элементарными и хочется контент на более senior уровень? Накидайте редакций, там и лайки и дизлайки есть.

#seo #google

Роскомнадзор заблокировал все сайты с технологией Encrypted Client Hello (ECH), поэтому если вы юзаете Cloudflare пора действовать.
1. SSL > Edge Certificates > TLS 1.3 - Выключить.

2. Caching > Configuration > Purge Everything - Сбросить кэш

Если у вас бесплатная версия, то решение через API тут.

Обсуждение проблемы на Серче.

Вроде бы сам Cloudflare пытается что то сделать, судя по Хабру.

Если просуммировать, то думаю с сервиса Cloudflare пора валить, так как РКН ему жить не даст.

Наверное подписчики заметили снижение количества постов последние 4 месяца. Почему не постил?

Знакомые знают, но в блоге я особо не писал, что в 2021 году я пошел получать высшее образование (в почти 35 лет). За это время я апнул бакалавра и магистра (оба красных диплома) по специальности "Компьютерные науки".🧨

Последние пару месяцев я работал с дипломной работой, которую я для себя выбрал. Она напрямую связана с seo оптимизацией, а конкретно семантическим поиском и использованием LLM типа BERT.

Таким образом удалось нехило прокачаться не только в общем понимании работы LLM на основе трансформеров, но и использовать их на практике, работая как с чистым BERT, так и LaBSE для организации поиска с использованием векторных представлений с помощью косинусного расстояния. С BERT удалось поработать не только как пользователь, но и обучать нейронную модель на основе своего датасета.
Паралельно прокачал опыт работы с Python и Streamlit, методами оптимизации задач, хешированием, парсингом.
Кому особенно интересно, может глянуть презентацию работы (на украинском языке).

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

В общем обещаю больше постов в телеграм канал, так как свободного времени стало больше🥹

🔥 Расчет релевантности текстов с помощью нейронных сетей
Скрипт на Python использует LaBSE для оценки текстовой релевантности через косинусную близость. Это мощный инструмент для анализа запросов, статей и URL из выдачи.

📌 Как начать
1️⃣ Установите Python и PyCharm .
2️⃣ Скачайте код с GitHub.
3️⃣ Запустите. При первом старте загрузится нейронная сеть LaBSE (2 ГБ).

📊 Возможности

Проверка релевантности абзацев и заголовков, title.
Автоматическое скачивание текстов из сайтов и расчет семантической релевантности.

Полное описание запуска, работы и скриншотов на сайте

Почти 2 месяца назад я увидел видео от Синди Крум, в котором она утверждала, что Гугл уже давно использует наш Google Chrome для рендеринга JS страничек сайтов прямо на наших мобильных устройствах. Тут короткая статья по теме.
Так как тема очень мне интересна, я решил организовать проверку этого утверждения.
По логике все происходило так:
Пользователь телефона заходил на страничку. Гугл определял, что страница не проиндексирована и отправлял страницу себе с нашего телефона. Далее уже на своих мощностях читал содержимое и решал, стоит ли индексировать или нет.

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

Для проверки этого утверждения я набросал скрипт, который может отловить бота на странице (js+php+mysql). Далее создал страницу html с статьей в отдельной папке (это нужно чтобы гугл не нашел случайно страницу из данных GA,XML карты или д.р.). Для работы с страницей использовался браузер который 100% не сливает данные (Google Chrome, Firefox или Operu не использовал).

С помощью AirtestIDE создал скрипт автоматизирующий действия на своем телефоне в Google Chrome (мне важно было создать скрипт заранее, так как если бы это не возможно автоматизировать - то зачем вообще проверять?)
В результате после 2 месяца я могу сказать:
Теория Синди Крум не подтвердилась. Хотя я не один раз пытался заходить на свой сайт, паралельно просматривая другие сайты, бот так и не пришел.
Я дополнительно проксировал телефон и смотрел, что при просмотре сайтов на телефоне Google Chrome довольно много отправляет данных на свои сервисы (к сожалению зашифровано), но индексирующий бот так и не пришел.

Я пробовал как Wi-FI трафик, так и загрузку страницы с мобильного трафика (была мысль что Гуглу нужны дополнительные данные ). Дополнительно проверил теорию о том, что индексирующий бот может прийти после проверки в сервисе Chrome-Lighthouse - тоже неудачный эксперимент.

И хотя в целом эксперимент неудачный, именно через такие эксперименты вы можете стать senior SEO специалистом. Не верить кому то на слово, несмотря на все регалии и титулы, а проверять самостоятельно.

Ну и напоследок - код отлова бота надо? Может задумаетесь над своими экспериментами. Если нужен - налепите огоньков под постом.

Обещанный скрипт для отлова ботов Google. Скрипт собирает все ip и юзерагенты зашедших на тестовую страницу. Работает даже с кешированными страницами.
В тестовой странице test.html в самом низу вставлен скрипт, который записывает ip и юзерагент в базу данных с помощью write.php.
Посмотреть записанные данные можно с помощью log.php.
В subnets.txt хранятся ip и подсети Google ботов (список не полный, можете редактировать)

Как протестировать.
Создаем с помощью FTP папку и заливаем туда файлы.
В файлы write.php и log.php прописываем данные для подключения к базе данных Mysql.
Создаем таблицу в базе данных (к примеру в Cpanel) заходим в Базы данных->PhpMyAdmin-> выбираем базу данных и переходим в вкладку SQL.
Выполняем код:

CREATE TABLE user_ip_data (
id INT(11) AUTO_INCREMENT PRIMARY KEY,
ip_address VARCHAR(45),
user_agent TEXT,
date_time DATETIME
);

База создана, теперь у вас все должно работать. Проверяем:
1) Переходим по url https://mysite.com/papka/test.html
2) Заходим на https://mysite.com/papka/log.php и увидите свой ip и юзерагент.
3) Проводите эксперименты, привлекая бота на https://mysite.com/papka/test.html

Ссылка на архив.

Если будет интерес, доработаю функционал, тот который напрашивается больше всего - работа с WordPress, показ стран ip и другое.

Много кто считает туристическую тематику не сильно конкурентной. Но это много лет не так. Многие услуги (продажа туров, экскурсий, билетов) попадают под YMYL (с англ. Your Money or Your Life, или дословно «Твои деньги или твоя жизнь»). Поэтому конкуренция тут не хуже медицины или финансов. Кроме этого без внедрения факторов EEAT ранжироваться сложно.

В сливе факторов ранжирования Гугла есть модуль GoogleApi.ContentWarehouse.V1.Model.QualityTravelGoodSitesData который описывает структуру данных помогающих ранжировать сайты туристической тематики. Стоит уточнить, что это не основной модуль, так как основа ранжирования туризма - это прежде всего local SEO.

Давайте пройдемся по основным атрибутам этого модуля.

i18n - Список локализованных версий данных, связанных с сайтом. Фактически это привязка к языку или локальным регионам (напомню что в Гугле работает Local Authority Links - это метод повышения веса ссылок локальным сайтам, к примеру когда сайт на домене fr ссылается на французский сайт).

isAggr - флаг указывающий на агрегатор или агрегацию данных (пример - Букинг или Tripadvisor). По многим нишам агрегаторы имеют приоритет, так как считается что они не являются ангажированными при формировании подборок данных (топ экскурсий, ресторанов и т. д. ).

isAttractionOfficial - официальный источник информации для туристической достопримечательности. Таким сайтам Гугл дает приоритет по кластерам запросов связанным с достопримечательностью. Пример - официальный сайт Лувра.

isHotelOfficial - Аналог для отелей.

isEntity - Указывает, связан ли сайт с конкретной сущностью (например, отель, достопримечательность, курорт). Это может быть полезно для определения релевантности сайта по запросам, связанным с этими сущностями. Кто не понимает о чем речь - гляньте скриншот.

normalizationFactor - данные могут быть в разных числовых значениях и требуют нормализации, к примеру к [0:1].

signal - Список сигналов, связанных с качеством туристического сайта. Это могут быть различные метрики, такие как пользовательские оценки, репутация, поведенческие факторы и т. д.

site - Url сайта

totalScore - сумма всех факторов после нормализации.

type - возможно тип сайта (информационный, коммерческий и т.д.) или по описанию (блог, форум, социальная сеть, каталог, сервис). Может использоваться для отдельных кластеров запросов ранжирования, к примеру для отзывов по достопримечательностях, где нужно давать приоритет форумам, блогам или соцсетям.

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

🔍 Яндекс обновил алгоритмы поиска — качество контента теперь важнее, чем когда-либо


Яндекс внедрил масштабные обновления в своих алгоритмах. Теперь в приоритете — реально полезный контент, а не просто тексты, сгенерированные ИИ на автомате и содержащие низкоуровневый контент.

✅ Точность распознавания низкокачественных и ИИ-сгенерированных страниц выросла до 99%
📉 Количество сомнительных сайтов на первой странице результатов поиска сократилось в несколько раз


📌 Важно: использование нейросетей не запрещено, но контент должен быть ценным, проверенным и не вводить в заблуждение.



🚫 Сайты, маскирующие некачественные тексты под видом экспертного контента, будут терять позиции.
📈 А вот проекты с действительно качественными материалами — получат рост трафика.

Отдельно Яндекс упомянул о том, что использование траста старых доменов (например перехваченных), если они будут злоупотреблять низким контентом - будет ограничено.
Привет всем строителям PBN сеток на перехваченных доменах на ауках. В тоже время похоже что апдейт уже активирован и если вас сильно не покосило - все будет ок.

В процессе работы над дипломным проектом в университете я выделил много времени для работы с BERT. И в процессе обнаружил, что BERT как то очень плохо работает с семантической релевантностью. Напомню, что я написал парсер основных сайтов вакансий работы в Украине и реализовал векторный поиск с помощью BERT (LaBSE). При этом чистый BERT показывал очень плохие результаты.

Когда контекст понятен, вроде запроса "вакансия seo специалиста" , все работает как часы. BERT отлично справляется даже с редкими вакансиями и запросами (хотя тут и bm25 справился).
Но стоит использовать запросы что то вроде "вакансия seo специалиста без знания английского" и BERT не в состоянии дать нормальный ответ, так как по его логике используя косинусную близость ты фактически ищешь по доп ключу "английский" и он не понимает смысла "без".
В процессе оказалось, что то что чаще всего приписывают BERT по настоящему реализовывают алгоритм Колибри и RankBrain, он не шарит не в контекст, не в интент.

К примеру RankBrain задает дополнительные веса релевантности обрабатывая данные по кликам и конечным намерениям пользователя.
Для использования BERT в задачах семантической релевантности часто требуется его дополнительное обучение (fine-tuning) на специфических наборах данных, содержащих пары предложений с оценками их семантического сходства.
Тогда проявляется вся мощь классификации в алгоритме. Классический же BERT это просто расширенный word2vec с точки зрения релевантности.

Имея набор данных dataset 25000 профессий, я взял чистый BERT и дообучил его на этих данных для конкретной задачи - классификации вакансий по запросу, чтобы нейронная сеть угадывала по вакансиям (текст вакансии + заголовок) профессию.
С помощью Python и Google Colab обучил BERT на своих данных (общий процес занял более 8 часов). В результате моя обученная модель угадывала профессии с точностью 60%.
Так как датасет был только по IT профессиям, основные ошибки делались на схожих профессиях, к примеру SEO или SMM специалист, могла попутать Котлин и Java программиста.

При проверке оказалось, что из 25К вакансий всего около 350 профессий, причем данные распределяются по принципу Парето, то есть по большинству профессий не хватает данных для обучения, отсюда и такие плохие результаты.

Вместо вывода - чистый BERT без набора данных у SEO специалиста - довольно слабая вещь для расчета текстовой релевантности (и это не только мой вывод). У Гугла все хорошо работает именно по той причине, что он накопил много данных для расчетов и обучения нейросети. Но если вы задумаетесь использовать BERT для себя, используйте модели с Sentence Embedding (Sentence-BERT (SBERT), LaBSE). Именно они идеально годятся для расчета текстовой релевантности как Title, h1 или всего текста статьи, а также в расчетах siteEmbeddings и pageEmbeddings.

Палю сеточку под travel которую нашел в выдаче. По многих запросам некоторые сайты конкурируют с моими сайтами. Если вы спец по PBN, то вы не линкуете свои сайты, разносите по разным не то что ip, а подсетям. Это все в прошлом 🤨

Вот небольшой список из сетки:

praguecastletickets.tours
romecolosseumtickets.tours
vatican-tickets.tours
neuschwansteincastletickets.tours
acropolistickets.tours
plitvice-lakes.tours
paristickets.tours
oxford.tours
niagarafallstickets.tours
jetskidubai.tours
londontickets.tours
istanbultickets.tours
dubaitickets.tours
amsterdamtickets.tours
florencetickets.tours
barcelonatickets.tours
madridtickets.tours
newyorktickets.tours
tuscanywine.tours
amalfi-coast-tours.com
capri-boat.tours
pompeiitickets.tours
seineriver.cruises
thamesriver.cruises
positanoboat.tours
sorrentoboat.tours

Тупо половина на одном Ip , все на сетке Google Cloud. Залинковано через контакты (прокрутите вниз).

Сайты на одном шаблоне Astra, но выглядят очень хорошо, лендинги, я даже вначале повелся и подумал что это сайты тур агентства. А это сайты под партнерку Getyourguide. По достопримечательностям заюзаны EMD домены.


Неплохой контент, релевантные сущности, микроразметка (в том числе структурированные данные в формате JSON-LD Product и FAQPage). Много языков (автоперевод, похоже на translatepress ).
Еще в контактах в картах используются или оригинальные адреса достопримечательностей, или адрес реального бизнеса. Я даже вначале подумал, что это для микроразметки гео сущности, но в коде такого не вижу, только фейковая Organization в schema-graph.
Сайты создавались на основе настроенного шаблона и иногда случалась беда - вебмастер забывал поменять ссылки на картинки, как следствие некоторые фотки грузятся с других доменов.

И хотя не все сайты ранжируются, но видно что им не хватает ссылочного, иначе бы все это было бы в топе.
Отличный пример как надо делать сайты.

🕵️‍♂️ Эксперимент: работает ли 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.