Почти 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 на странице своего сайта.
Для проверки этого утверждения я набросал скрипт, который может отловить бота на странице (js+php+mysql). Далее создал страницу html с статьей в отдельной папке (это нужно чтобы гугл не нашел случайно страницу из данных GA,XML карты или д.р.). Для работы с страницей использовался браузер который 100% не сливает данные (Google Chrome, Firefox или Operu не использовал).
С помощью AirtestIDE создал скрипт автоматизирующий действия на своем телефоне в Google Chrome (мне важно было создать скрипт заранее, так как если бы это не возможно автоматизировать - то зачем вообще проверять?)
В результате после 2 месяца я могу сказать:
Теория Синди Крум не подтвердилась. Хотя я не один раз пытался заходить на свой сайт, паралельно просматривая другие сайты, бот так и не пришел.
Я дополнительно проксировал телефон и смотрел, что при просмотре сайтов на телефоне Google Chrome довольно много отправляет данных на свои сервисы (к сожалению зашифровано), но индексирующий бот так и не пришел.
Я пробовал как Wi-FI трафик, так и загрузку страницы с мобильного трафика (была мысль что Гуглу нужны дополнительные данные ). Дополнительно проверил теорию о том, что индексирующий бот может прийти после проверки в сервисе Chrome-Lighthouse - тоже неудачный эксперимент.
И хотя в целом эксперимент неудачный, именно через такие эксперименты вы можете стать senior SEO специалистом. Не верить кому то на слово, несмотря на все регалии и титулы, а проверять самостоятельно.
Ну и напоследок - код отлова бота надо? Может задумаетесь над своими экспериментами. Если нужен - налепите огоньков под постом.
YouTube
Phase II of Google's Mobile-First Indexing is just Chrome
Cindy Krum explains how the second phase of Google's Mobile-First Indexing is actually just Real User Metrics and rendering from Chrome on real users' actual computers and the implications that this has for SEO, Privacy and entrenching Google's Monopoly in…
🔥19👍5🤔3
Forwarded from ChatGPT, AI, Python для SEO - автоматизация
Обещанный скрипт для отлова ботов Google. Скрипт собирает все ip и юзерагенты зашедших на тестовую страницу. Работает даже с кешированными страницами.
В тестовой странице test.html в самом низу вставлен скрипт, который записывает ip и юзерагент в базу данных с помощью write.php.
Посмотреть записанные данные можно с помощью log.php.
В subnets.txt хранятся ip и подсети Google ботов (список не полный, можете редактировать)
Как протестировать.
Создаем с помощью FTP папку и заливаем туда файлы.
В файлы write.php и log.php прописываем данные для подключения к базе данных Mysql.
Создаем таблицу в базе данных (к примеру в Cpanel) заходим в Базы данных->PhpMyAdmin-> выбираем базу данных и переходим в вкладку SQL.
Выполняем код:
База создана, теперь у вас все должно работать. Проверяем:
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 и другое.
В тестовой странице 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 и другое.
Lightshot
Screenshot
Captured with Lightshot
🔥3👍2
Много кто считает туристическую тематику не сильно конкурентной. Но это много лет не так. Многие услуги (продажа туров, экскурсий, билетов) попадают под 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 в нише. Получить ссылку с такого сайта - огромная удача. Поэтому если у вас есть возможность получать ссылки с официальных сайтов - постарайтесь их получить любым путем.
В сливе факторов ранжирования Гугла есть модуль 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 в нише. Получить ссылку с такого сайта - огромная удача. Поэтому если у вас есть возможность получать ссылки с официальных сайтов - постарайтесь их получить любым путем.
Le Louvre
Musée du Louvre Official Website
Welcome to the Louvre – prepare your visit, explore the palace and museum collections and check out the latest news
👍8🔥3
🔍 Яндекс обновил алгоритмы поиска — качество контента теперь важнее, чем когда-либо
Яндекс внедрил масштабные обновления в своих алгоритмах. Теперь в приоритете — реально полезный контент, а не просто тексты, сгенерированные ИИ на автомате и содержащие низкоуровневый контент.
✅ Точность распознавания низкокачественных и ИИ-сгенерированных страниц выросла до 99%
📉 Количество сомнительных сайтов на первой странице результатов поиска сократилось в несколько раз
📌 Важно: использование нейросетей не запрещено, но контент должен быть ценным, проверенным и не вводить в заблуждение.
🚫 Сайты, маскирующие некачественные тексты под видом экспертного контента, будут терять позиции.
📈 А вот проекты с действительно качественными материалами — получат рост трафика.
Отдельно Яндекс упомянул о том, что использование траста старых доменов (например перехваченных), если они будут злоупотреблять низким контентом - будет ограничено.
Привет всем строителям PBN сеток на перехваченных доменах на ауках. В тоже время похоже что апдейт уже активирован и если вас сильно не покосило - все будет ок.
Яндекс внедрил масштабные обновления в своих алгоритмах. Теперь в приоритете — реально полезный контент, а не просто тексты, сгенерированные ИИ на автомате и содержащие низкоуровневый контент.
✅ Точность распознавания низкокачественных и ИИ-сгенерированных страниц выросла до 99%
📉 Количество сомнительных сайтов на первой странице результатов поиска сократилось в несколько раз
📌 Важно: использование нейросетей не запрещено, но контент должен быть ценным, проверенным и не вводить в заблуждение.
🚫 Сайты, маскирующие некачественные тексты под видом экспертного контента, будут терять позиции.
📈 А вот проекты с действительно качественными материалами — получат рост трафика.
Отдельно Яндекс упомянул о том, что использование траста старых доменов (например перехваченных), если они будут злоупотреблять низким контентом - будет ограничено.
Привет всем строителям PBN сеток на перехваченных доменах на ауках. В тоже время похоже что апдейт уже активирован и если вас сильно не покосило - все будет ок.
Блог Яндекса
Сайты с качественным контентом смогут получать больше трафика после обновления алгоритмов в Поиске Яндекса
Яндекс активно работает над совершенствованием технологии определения качественного контента в поиске. За последний месяц было внедрено несколько изменений, которые уже принесли положительные результаты: количество источников с некачественным контентом на…
👍8👎7
В процессе работы над дипломным проектом в университете я выделил много времени для работы с 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 программиста.
Вместо вывода - чистый BERT без набора данных у SEO специалиста - довольно слабая вещь для расчета текстовой релевантности (и это не только мой вывод). У Гугла все хорошо работает именно по той причине, что он накопил много данных для расчетов и обучения нейросети. Но если вы задумаетесь использовать BERT для себя, используйте модели с Sentence Embedding (Sentence-BERT (SBERT), LaBSE). Именно они идеально годятся для расчета текстовой релевантности как Title, h1 или всего текста статьи, а также в расчетах siteEmbeddings и pageEmbeddings.
Когда контекст понятен, вроде запроса "вакансия 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.
Telegram
Канал seo блоггера Евгения Молдовану
Из слива ранжирования Гугла стало более понятно как передается вес от донора акцептору.
Гугл для каждого сайта и страницы рассчитывает вектора.
siteFocusScore - определяет сосредоточенность на определенной теме (тематичность).
siteRadius - указывает на охват…
Гугл для каждого сайта и страницы рассчитывает вектора.
siteFocusScore - определяет сосредоточенность на определенной теме (тематичность).
siteRadius - указывает на охват…
👍6🔥6
Палю сеточку под 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.
Сайты создавались на основе настроенного шаблона и иногда случалась беда - вебмастер забывал поменять ссылки на картинки, как следствие некоторые фотки грузятся с других доменов.
И хотя не все сайты ранжируются, но видно что им не хватает ссылочного, иначе бы все это было бы в топе.
Отличный пример как надо делать сайты.
Вот небольшой список из сетки:
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.
Сайты создавались на основе настроенного шаблона и иногда случалась беда - вебмастер забывал поменять ссылки на картинки, как следствие некоторые фотки грузятся с других доменов.
И хотя не все сайты ранжируются, но видно что им не хватает ссылочного, иначе бы все это было бы в топе.
Отличный пример как надо делать сайты.
👍9🔥4
Год назад запустил travel сервис под Яндекс и Гугл (новорег домен). На примере хорошо видно, что только через 3-4 месяца начали появляться первые позиции, а на 6 месяц начался старт реального роста. Это к вопросу существует ли песочница.
Такой рост типичен для проектов с зареганным доменом без истории, никогда не встречал на своем опыте роста с первого месяца (хотя это возможно).
На втором скриншоте позиции в Яндексе, я вручную проверил, они +- 5 позиций соответствуют реальности. По основному запросу ( 450К запросов по точному вхождению в Вордстате) сайт болтается в пределах 80-120 места.
Но даже по тем запросам что есть залезть в топ не получится - на сайте нет поведенческих факторов и сотни ссылок.
По сайту дооптимизировал текст и жду результатов. Пора бомбить ссылочным.
Такой рост типичен для проектов с зареганным доменом без истории, никогда не встречал на своем опыте роста с первого месяца (хотя это возможно).
На втором скриншоте позиции в Яндексе, я вручную проверил, они +- 5 позиций соответствуют реальности. По основному запросу ( 450К запросов по точному вхождению в Вордстате) сайт болтается в пределах 80-120 места.
Но даже по тем запросам что есть залезть в топ не получится - на сайте нет поведенческих факторов и сотни ссылок.
По сайту дооптимизировал текст и жду результатов. Пора бомбить ссылочным.
👍12👏3
Forwarded from SEO Лаборатория
🕵️♂️ Эксперимент: работает ли SEO-hide в 2025 году?
Решили вместе с seo блоггером Евгением Молдовану проверить метод SEO HIDE — способ маскировки ссылок от поисковиков через замену
Задача эксперимента — перестать сливать PageRank на служебные страницы типа "Контакты" или "Политика", но оставить для пользователей функционал рабочих ссылок, чтобы обеспечить навигацию на сайте.
🔬 Что сделали:
Создали на сайте Евгения страницу с 4 замаскированными ссылками, оформленными через
Способы обработки ссылок были разные (можете сами посмотреть в исходном коде). Это и использование
🔍 Критерии:
При постановке эксперимента единственным объективным показателям того "видит" ли Google ссылки считалось наличие такой ссылки в Google Search Console. Конечно всем известно, что Search Console показывает не все ссылки. И ссылка может существовать, учитываться в ранжировании, но при этом не отображаться в Search Console. Но других реалистичных показателей нет
📉 Результат:
В Google Search Console отобразилась обычная (контрольная) ссылка.
Замаскированные через span — поисковиком частично проигнорированы. Полной неожиданностью стало учёт ссылки вида
❗️ Вывод:
Метод SEO-hide (в зависимости от реализации) действительно препятствует индексации ссылок и передаче веса. Это может быть полезно для сохранения веса на продвигаемых страницах.
Но важно понимать: невозможно так скрыть сам факт перехода с вашего сайта на другой. Эти переходы все равно определяются с помощью браузера Chrome и GA, поэтому маскировать офферы или партнерские ссылки нет смысла, Google определит что переход был с вашей страницы. Такой способ подойдёт только для манипуляций с PageRank.
✅ Где это сработает:
Метод может хорошо сработать на больших сайтах (от 500+ страниц), так как при таком большом количестве страниц статистический вес еще играет роль. Кроме того экспериментально доказано, что чем меньше ссылок ведёт на условную служебную страницу про "Политики на сайте", то тем реже GoogleBot её посещает, а значит чаще посещает важные целевые страницы.
⚠️ Disclaimer:
Есть сеошники, которые считают, что не все учтенные ссылки отображаются GSC. Эксперимент проводился больше 3 лет и за такое время ссылка все таки бы отобразилась бы, тем более что тестовая зашла в консоль.
Решили вместе с 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 лет и за такое время ссылка все таки бы отобразилась бы, тем более что тестовая зашла в консоль.
👍8🤔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.
После апдейта примерно 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.
👍5🔥3
Массированные ложные жалобы на сайты в Cloudflare - обсуждение на Серче.
⚠️ Через несколько часов сайт оказался помечен как фишинговый, без какой-либо верификации со стороны Cloudflare. После этого:
— Доступ к сайту блокируется через браузеры
— Весь аккаунт или заказ в хостинге может быть отключён "до разбирательств"
— Репутация домена портится
Особенно тревожно, что это можно устроить автоматически — с подставных Gmail-ящиков. Вероятно, конкуренты пользуются этой схемой, чтобы обвалить сайты без фактических оснований.
Первоначально думал что это локальная ситуация с конкретным сайтом, но нет. Оказывается тема началась еще в 2024 году, но в 2025 дошла и русскоязычного комьюнити, бомбили в основном серые тематики.
На самом форуме куча обсуждений 1, 2, 3, 4, почти везде указывается что результат блокировки - это ложные письма в поддержку Cloudflare.
О массовых ложных заявлениях о фишинге есть целые топики 1, но самое еще хуже это то что если ты отбился - прилетают опять. Основные жалобы пошли с апреля 2025 года, даже на Серче есть топик.
В чем же причина такого поведения Cloudflare ? Почему домен могут локнуть даже после пачки ложных доносов с временных почт?
Похоже что причина в том, что на сервис прилетело много обвинений в том что он скрывает фишинговые сайты, в 2024 был пик, жаловались все, от Спамхауза, до тематических СМИ, которые обвиняли Cloudflare в прикрытии фишинга.
Как защититься?
Мониторить все уведомления, быть готовым в любой момент отключиться от сервиса, иметь бекап.
Мы столкнулись с ситуацией, когда на наш сайт (обычный WordPress-блог, без логинов, сид-фраз, форм ввода) в течение 5–10 минут поступили жалобы с 5–7 разных Gmail-адресов. Все письма были якобы от "пользователей", которые утверждали, что сайт занимается фишингом. Ни одного доказательства — только текст "ваш сайт редиректит, украл данные, срочно блокируйте" и т.п.
⚠️ Через несколько часов сайт оказался помечен как фишинговый, без какой-либо верификации со стороны Cloudflare. После этого:
— Доступ к сайту блокируется через браузеры
— Весь аккаунт или заказ в хостинге может быть отключён "до разбирательств"
— Репутация домена портится
Особенно тревожно, что это можно устроить автоматически — с подставных Gmail-ящиков. Вероятно, конкуренты пользуются этой схемой, чтобы обвалить сайты без фактических оснований.
Первоначально думал что это локальная ситуация с конкретным сайтом, но нет. Оказывается тема началась еще в 2024 году, но в 2025 дошла и русскоязычного комьюнити, бомбили в основном серые тематики.
На самом форуме куча обсуждений 1, 2, 3, 4, почти везде указывается что результат блокировки - это ложные письма в поддержку Cloudflare.
О массовых ложных заявлениях о фишинге есть целые топики 1, но самое еще хуже это то что если ты отбился - прилетают опять. Основные жалобы пошли с апреля 2025 года, даже на Серче есть топик.
В чем же причина такого поведения Cloudflare ? Почему домен могут локнуть даже после пачки ложных доносов с временных почт?
Похоже что причина в том, что на сервис прилетело много обвинений в том что он скрывает фишинговые сайты, в 2024 был пик, жаловались все, от Спамхауза, до тематических СМИ, которые обвиняли Cloudflare в прикрытии фишинга.
Как защититься?
Мониторить все уведомления, быть готовым в любой момент отключиться от сервиса, иметь бекап.
searchengines.guru
Массированные ложные жалобы на сайты в Cloudflare — новая схема - Хостинг и серверы для сайтов - Сайтостроение - Форум об интернет…
С таким I am writing to report a serious and active phishing scam that is currently being hosted on a domain registered through your service WEBSITE This fraudulent website is designed to trick users into divulging their sensitive information. Notify WEBSITE…
👍10
Яндекс закрывает доступ к старому old.wordstat.yandex.ru через 2 месяца и открывает доступ к бета-версии API Вордстата — сервиса, который показывает статистику запросов к Поиску Яндекса.
API предоставляется бесплатно, для его подключения нужно подать заявку.
Доступ к API ограничен двумя видами квот:
Общая квота: при превышении — ошибка 503 (Service unavailable).
Персональная квота (по OAuth-токену): ограничение на количество запросов в секунду и в сутки.
Update:
Кстати кто пробовал подавать заявку на Beta Wordstat API и у него была ошибка с ClientId в заявке - отправьте заново, я писал в поддержку сервиса и там исправили ошибку.
Опубликован faq по запросам к сервису.
13 июня :
Спасибо за вашу заявку! На данный момент мы получили достаточное для проведения этапа бета-тестирования количество заявок.
Новые аккаунты будут подключаться после релиза полной версии API.
В API доступны те же данные, что и в самом Вордстате: частотность запросов, топ популярных и похожих формулировок, динамика интереса к теме, срезы по регионам, устройствам и периодам. Эти сведения позволяют оценить спрос на товары и услуги, выявить новые тренды, спланировать продажи с учётом сезонных колебаний спроса и провести конкурентный анализ.
API предоставляется бесплатно, для его подключения нужно подать заявку.
Доступ к API ограничен двумя видами квот:
Общая квота: при превышении — ошибка 503 (Service unavailable).
Персональная квота (по OAuth-токену): ограничение на количество запросов в секунду и в сутки.
Update:
Кстати кто пробовал подавать заявку на Beta Wordstat API и у него была ошибка с ClientId в заявке - отправьте заново, я писал в поддержку сервиса и там исправили ошибку.
Опубликован faq по запросам к сервису.
13 июня :
Спасибо за вашу заявку! На данный момент мы получили достаточное для проведения этапа бета-тестирования количество заявок.
Новые аккаунты будут подключаться после релиза полной версии API.
👍5🤔3
Forwarded from ChatGPT, AI, Python для SEO - автоматизация
Этот инструмент позволяет наглядно отобразить векторную семантическую близость между статьями. Он использует модель BERT (LaBSE) для оценки смысловой схожести текстов и визуализирует результат в виде интерактивного графа.
Как пользоваться:
Подготовьте CSV-файл с двумя колонками: Address (URL статьи) и H1-1 (заголовок) - экспорт из лягушки.
Загрузите файл в интерфейс Streamlit - простым перетаскиванием.
Инструмент автоматически скачает и распарсит текст каждой статьи.
Можно настраивать порог релевантности, выбирать отображение одиночных узлов и скачивать CSV со списком схожих пар.
Зачем нужно:
1) Найти малорелевантные страницы для улучшения siteEmbeddings, поможет увеличить тематический траст после удаления.
2) Найти страницы с 100% совпадением - каннибализация и дубли.
3) Найти наиболее семантически релевантные страницы для ручной перелинковки.
4) Можно проверять разные сайты - таким образом среди списка страниц разных доменов искать релевантные (для PBN).
Ссылка на Гитхаб.
Как пользоваться:
Подготовьте CSV-файл с двумя колонками: Address (URL статьи) и H1-1 (заголовок) - экспорт из лягушки.
Загрузите файл в интерфейс Streamlit - простым перетаскиванием.
Инструмент автоматически скачает и распарсит текст каждой статьи.
Можно настраивать порог релевантности, выбирать отображение одиночных узлов и скачивать CSV со списком схожих пар.
Зачем нужно:
1) Найти малорелевантные страницы для улучшения siteEmbeddings, поможет увеличить тематический траст после удаления.
2) Найти страницы с 100% совпадением - каннибализация и дубли.
3) Найти наиболее семантически релевантные страницы для ручной перелинковки.
4) Можно проверять разные сайты - таким образом среди списка страниц разных доменов искать релевантные (для PBN).
Ссылка на Гитхаб.
1👍13
На мероприятии 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 — негативный сигнал, который может привести к исключению из индекса.
✅ Влияют на индексацию:
Country
Совпадение стран домена + к шансу индексации.
Language
Тоже по языку.
HTTPS / Secure Site
Наличие защищённого соединения (HTTPS) — положительный сигнал индексации и доверия.
Crawlability
Если страница доступна для сканирования, она может быть проиндексирована.
Core Web Vitals
Ключевые метрики производительности страницы (скорость загрузки, интерактивность и стабильность) влияют на индексацию.
Dofollow Links
Ссылки с атрибутом dofollow + к шансу.
Content Recency & Freshness
Актуальность и свежесть контента повышают шанс на быструю индексацию.
Spam Policies Violations
Нарушения антиспам-политик Google — негативный сигнал, который может привести к исключению из индекса.
👍12🔥2
Таплинки - идеальные сайты для разбавки своего ссылочного и улучшения ранжирования сайтов. Кто никогда не видел такие странички - вот пример с оформлением.
Многие сайты очень хорошо ранжируются что в Гугле, что в Яндексе.
Пример таких сайтов:
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, страницы могут вылетать из индекса.
Поэтому раз в полгода нужно прогонять их через индексаторы или строить ссылки на них с соцсетей.
Многие сайты очень хорошо ранжируются что в Гугле, что в Яндексе.
Пример таких сайтов:
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, страницы могут вылетать из индекса.
Поэтому раз в полгода нужно прогонять их через индексаторы или строить ссылки на них с соцсетей.
👍11