Ого, уже даже кто-то сделал на основе данных удобную табличку со всеми факторами яндекса. Можно применить фильтры, что гораздо удобнее.
https://docs.google.com/spreadsheets/d/17gMlLrYtJlrSUcqSs95bLw76XCrzJJ8YnOdc63JMhFo/edit#gid=671136320

Информация только для ознакомления!

Update: https://t.me/Lord_Alfred/101
Автор нашел коэффициенты одной из ранжирующих формул, кому-то может понадобиться.

Выделил для вас "текстовые факторы", то есть именно те, что используются/использовались для оценки выложенного контента под тегом TG_DOC_TEXT, судя по всему TG_DOC относится ко всему документу. Исключил deprecated.
Могу сделать вывод, что данные для оценки общепринятые в науке информационного поиска, поэтому можно предположить, что в Google, Bing должны быть похожие критерии оценки, так как сходятся с теми, что находятся в исследовательских работах сотрудников компаний.
https://docs.google.com/document/d/1zr-qMpNggckOpJCqnvteS01dGcpgU7atDaNQgaPdfoo/edit?usp=sharing

Про факторы ранжирования

Более правильный термин – feature, который используют в англоязычной Machine Learning среде, а фактор – это синоним, но учеными используется редко. Есть целая задача в науке, которая называется feature engineering.

В зависимости от задачи используются различные feature, если мы говорим про поиск по документам, то задача называется Learning to rank. Для удобства пара «запрос-документ» представляется численными векторами, которые называют feature vectors.

Традиционно делятся на 3 группы:

1. Query-independent или static features – те, что относятся к документу, но не запросу, например, длина документа, Pagerank между документами и т.д. Такие данные можно посчитать заранее, а также использовать для подсчета общего static quality score, что значительно ускоряет ответы на запросы.

2. Query-dependent или dynamic features – те, что относятся и к документу и к запросу, классическим примером является TF-IDF.

3. Query-level features или query features – те, что относятся только к запросу, например, число слов в нём.

Где еще можно получить примеры feature или факторов, помимо слитого списка Яндекса?

Например, из PDF-ки к известному среди специалистов по информационному поиску датасету LETOR (46 шт):
https://arxiv.org/pdf/1306.2597v1.pdf

Также список есть в датасете MSLR (136 шт):
https://www.microsoft.com/en-us/research/project/mslr/

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

Видео на тему работы с ChatGPT, как промпты для GPT-3 также подходит. Очень рекомендую использовать как помощь в написании шаблонов генерации меты для доров! На видео это показано. Также очень удобно делать шаблоны генерации и многое другое на этапе перед заливом дорвеев.
https://t.me/sneex_seo/67

Палевная темка на cloudflare сквоттерах. DoberOK’а знаю, как классного практика, видел не раз его дорвеи в выдаче — рекомендую! Сам пробовал сквоттерский трафик лить в году 2020м, но потом пожалел дорвейного собрата :)

Как улучшить парсинг сниппетов?

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

Есть способ как собирать сниппеты эффективнее, особенно под информационный интент. Нужно к каждому запросу добавлять оператор define:. Например, define:essay on celluar immunity.

Оператор define: работает в Google и Bing, позволяя добавить чуть больше информации по запросу в сниппеты, как минимум в первые две страницы выдачи. Эффективнее всего работает для английского языка, хуже на других языках, на некоторых будто вообще не работает.

На скрине представлено сравнение bolded words или подсветки для Google и Bing, которое наглядно показывает разницу в выдаче с отсутсвующим оператором define: и при использовании оператора.

Баг со склейкой редиректов в Google

Многие видели пост Lily Ray о баге тайтлов в Google, но я не видел, чтобы кто-то обратил внимание на то, что используется достаточно давний баг Google, когда при 302-м редиректе, донор начинает ранжироваться с контентом акцептора при имеющихся внешних ссылочных сигналах и некоторых манипуляциях на акцепторе. Работает через раз, поэтому нужно много доноров.
Особенно массово такие сайты появляются после кривых core-апдейтов у Google, собственно, и другие темы частенько начинают снова работать. А пока горячо, умельцы срывают куш, паразитируя на тысячах сайтов, которые позволяют вставить ссылку в редиректный url!

А почему Untitled? Скорее всего из-за того, что в контенте акцептора нет ни <title>, ни заголовка. Иногда в заголовках выдачи Google проскакивают анкоры ссылок, которые массово ставят с других дорвеев на редиректы, но и это тоже давний баг (или фича?).

Бонусом: haiku rancho solano - запрос по которому можно найти и проанализировать различные доры в выдаче Google.

Пинг sitemap’а RIP

…но не сразу. Через 6 месяцев отключат.

Заабузили его лишнего, говорят, что используют только спамеры. Значит работает…:)

Дальше останется только строка в robots.txt и залив в search console.

Также установка новой даты в lastmod без значимого изменения на странице видимо приведет к ухудшению краулинга.

Напомнили, что не используют changefreq и priority.

https://developers.google.com/search/blog/2023/06/sitemaps-lastmod-ping

Тема для education дорвеев

Есть такой сайт Brainly, где постоянно задают свежие вопросы по учебе. Примеры: https://brainly.com/all-questions

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

При беглом поиске один похожий старый дорвей нашелся в Google: https://brainsanswers.com/

Пик его пришелся на 2019-й, после чего словил бан, но потом еще раз на 2022-й и до сих пор несет трафик. Кстати, это хороший пример того, что не стоит сносить "дорвеи для людей". Они могут словить спам-фильтр, но его ставят на 2-3 года, а после снятия могут нести стабильный траф, особенно, если сайт постоянно обновляется.

Лайфхак: Сейчас Brainly закрывает свои ответы, но продолжает их выдавать в JSON-LD, пример на скрине.

Также определенную релевантность придают похожие вопросы в блоках линковки.

Сливать такое можно на essay или какие-либо другие tutoring и homework help партнерки, варианты слива могут быть разными, нужно проводить a/b тесты для вашей темы, возможно менеджеры партнерок смогут помочь.

Programmatic на мета-поиске

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

srtfiles.com - сайт, который заточен под поиск субтитров через Programmable Search Engine от Google. Создан в 2020-м на дроп-домене, с тех пор получил много ссылок, но я бы не сказал, что они качественные :)

В Google сайт ищется по запросам фильм + субтитры, затем пользователь должен посредством интерфейса осуществить поиск в custom search, который заточен на поиск только по определенным сайтам с субтитрами. Сами фильмы и сериалы скорее всего получены с дампа базы IMDB.

Подобные сайты делал раньше я сам, отдавая юзеру результаты по определенным видам файлов через API-запрос к A-Parser'у, например, осуществляя поиск по PDF в нескольких поисковых системах.

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

Критика поста Dejan'а

В нескольких чатиках 2 дня уже обсуждаем этот пост https://twitter.com/dejanseo/status/1684216376704081921, где Dejan предложил методику автоматической линковки. Пост довольно сложно написан, поэтому вот перевод на более-менее человеческий:

1. Каждый документ преобразуется в векторное пространство через SBERT, являющийся адаптацией BERT, где в векторное пространство преобразуются не слова, а целые предложения.

2. Затем находится семантическая близость между документами, которая позволяет подобрать наиболее близкие между собой странички.

3. На этом этапе мы разбиваем документ, с которого ставим ссылку на предложения и сравниваем каждое предложение по семантической близости с документом, на который собираемся ставить ссылку.

4. Далее мы уже предложение разбиваем на слова, каждое из которых сравниваем семантически со всем документом, на который собираемся поставить ссылку, чтобы подобрать близкие к документу слова из выбранного предложения.

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

Патент ранжирования UGC

Пришлось мне немного углубиться в ранжирование UGC (user-generated content) и я вспомнил, что у Google есть патент https://patents.google.com/patent/US8965883B2/en, который считали, что связан с Google+, но сейчас он является активным и продлили его аж до 2030-го года, поэтому у меня есть предположение, что может использоваться для ранжирования UGC в поиске Youtube, поскольку патент предполагает вариант использования на видео-шеринг платформах, а также часть патента может использоваться в самом поиске Google.

1. Идентифицируются взаимодействия между пользователями. Этими взаимодействиями могут быть комментарии в блог посте, ответ на вопрос на Q&A сайте, ответы на пост на форуме. Каждое взаимодействие предполагает, как минимум двух юзеров: кто задает исходный контент и кто на него отвечает.

2. Присваиваются веса. Каждому взаимодействию присваивается вес, который считают на основе факторов качества, которыми могут быть: релевантность элемента контента одного юзера предшествующему элементу контента другого юзера; оригинальность элемента контента по отношению другим элементам; использование нетипичных терминов; richness и timeliness контента (спросите ChatGPT подробнее про эти два термина).

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

4. Присваиваются оценки учетным данным юзера. На основе весов присвоенных каждому взаимодействию генерируется оценка каждому юзеру. Эта оценка является показателем достоверности и качества их вклада в сайт. Эта оценка хранится вместе с юзерским идентификатором.

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

Как видим, какая-то часть этого патента действительно может использоваться в поиске Google, поэтому можно взять на вооружение хотя бы 2-й пункт и четко следить за тем, что пишете по теме на экспертных платформах.

Google’s Reasonable Surfer Model

💡 Идея модели отражает тот факт, что не все ссылки, связанные со страницами, могут быть пройдены с одинаковой вероятностью. Примеры ссылок, по которым маловероятен переход, могут включать ссылки «Terms of service», рекламные баннеры, не связанные со страницей ссылки.

Методология:

⚙️ Генерируется модель. Модель основана на поведении пользователей и факторах. Эта модель помогает понять по каким ссылкам кликают пользователи. Модель может постоянно меняться в процессе получения новых данных.

⚖️ Ссылкам присваиваются веса. На основе модели каждой ссылке со страницы на страницу присваивается вес.

🥇 Страницам присваиваются ранги. Страницы ранжируются на основе весов присвоенных ссылкам, а также на основе рангов ссылающихся страниц.

Факторы для ссылок

🔸 Размер шрифта анкора
🔸 Расположение ссылки (например, в списковом теге HTML, в бегущей строке, над или под первым экраном, просматриваемым на дисплее браузера 800×600, сторона (сверху, снизу, слева, справа) документа, в футере, сайдбаре и т.д.)
🔸 Если ссылка в списковом теге, то позиция ссылки в нём
🔸 Цвет шрифта и/или атрибуты ссылки (курсив, серый, цвет такой же как у фона и т.д.)
🔸 Число слов в анкоре
🔸 Тип ссылки (например, ссылка картинка)
🔸 Если ссылка связана с изображением, то соотношение сторон
🔸 Контекст нескольких слов до и/или после ссылки
🔸 Тематический кластер с которым связан анкор ссылки
🔸 Ведет ли ссылка на тот же хост или домен
🔸 Если ссылка ведет на страницу на том же домене, является ли URL ссылки более коротким, чем у ссылающейся страницы и/или содержит ли URL адрес другого сайта (например, для редиректа)

Факторы для исходной страницы

🔸 URL адрес или часть URL адреса
🔸 Веб-сайт связанный со страницей
🔸 Число ссылок на странице
🔸 Наличие других слов в заголовке страницы
🔸 Тематический кластер документа и/или степень связанности тематического кластера исходной страницы и тематического кластера анкора ссылки

Факторы для целевой страницы

🔸 URL адрес или часть URL адреса
🔸 Веб-сайт связанный со страницей
🔸 Находится ли URL-адрес страницы на том же хосте, что и URL-адрес ссылающейся страницы
🔸 Находится ли URL-адрес страницы на том же домене, что и URL-адрес ссылающейся страницы
🔸 Слова в URL страницы и/или длина URL

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

🖼️ На изображении представлена примерная диаграмма, которая включает три страницы: A, B и C. Как показано, A включает одну прямую ссылку на C и две обратные ссылки из B и C. B включает одну прямую ссылку на A. C включает одну прямую ссылку на A и одну обратную ссылку из A. Конечные ранги страниц на основе весов ссылок, после рассчета формулы ранжирования: r(A)≈0.237, r(B)≈0.202, and r(C)≈0.281. Наибольший ранг у страницы C.

ℹ️ В патенте используют термин документы, поскольку имеются в виду не только страницы сайтов, но и, например, ссылки на файлы, но для простоты восприятия я использовал термин страницы, как страницы веб-сайта.

ℹ️ Все факторы упомянуты в патенте и в реальности их число может различаться

ℹ️ Ссылки включают любую ссылку со страницы на страницу или на часть той же страницы.

ℹ️ Прямая ссылка - это ссылка с исходной страницы на целевую с точки зрения исходной страницы.

ℹ️ Обратная ссылка - это ссылка с целевой страницы на исходную с точки зрения целевой страницы.

ℹ️ Example.com - это домен, server1.example.com - это хост.

Источник: Ranking documents based on user behavior and/or feature data https://patents.google.com/patent/US8117209B1/en

Google’s Reasonable Surfer Model (дополнение)

📝 Описанные в патенте примеры правил, которые может генерировать модель из предыдущего поста:

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

📎 Ссылки, расположенные ближе к верху страницы, имеют более высокую вероятность быть выбранными, чем ссылки, расположенные ближе к низу страницы.

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

📎 Ссылка, размещенная под заголовком «More Top Stories» на веб-сайте cnn.com, имеет высокую вероятность выбора.

📎 Ссылка, связанная с целевым URL-адресом, который содержит слово «domainpark», имеет низкую вероятность быть выбранной.

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

📎 Ссылка, связанная с целевым доменом, который заканчивается на «.tv», имеет низкую вероятность быть выбранной.

📎 Ссылка, связанная с целевым URL-адресом, который включает в себя множественные дефисы, имеет низкую вероятность быть выбранной.

Источник: Ranking documents based on user behavior and/or feature data https://patents.google.com/patent/US8117209B1/en

Большие изменения на канале

Sәıam! Хочу сообщить об изменениях, которые давно назревали. Теперь этот канал будет не только про черные методики продвижения. Из того, что я планирую здесь постить:

🔸 Разбор патентов
🔸 Бесплатные no code решения для проведения анализа и обработки
🔸 Бесплатные скрипты
🔸 Разбор методик генерации сайтов
🔸 Разбор манипуляций поиском, как было и раньше
🔸 Любые другие посты по теме SEO

Также название канала меняется на Advanced SEO, поскольку сфера моих интересов более широкая, нежели Black Hat SEO.
Рекламы всё так же не будет, но возможно я буду рекомендовать сервисы и продукты моих друзей, если это действительно что-то стоящее.

Лимиты Google Indexing API

⚠️ Из-за бестолковых или намеренно вводящих в заблуждение статей, многие считают, что пресловутый лимит в 200 URL в день – это лимит на один аккаунт Google.

Действительные лимиты:

🔸 Лимит 200 URL в день по умолчанию дается на один проект в аккаунте Google Cloud с возможностью запроса на расширение

🔸 Лимит проектов на аккаунт варьируется от 10 на свежие аккаунты, от 20 на старые аккаунты с возможностью запроса на расширение

Таким образом, на одном новом аккаунте Google с 10-ю проектами по 200 URL в день можно отправлять на индексацию или удалять из индекса до 2000 URL в сутки, главное добавить каждый из проектов для сайта в консоли Google.

ℹ️ Однажды я видел аккаунт с безлимитом на создание проектов.

Накрутка поведенческих факторов в Яндекс

🔬Из научного интереса погрузился в изучение поведенческих факторов различных поисковых систем, поэтому недавно пообщался с давним знакомым @Vadik_Root. Я работал с ним в проектах по играм, которые популярны в Восточной Европе и ЛАТАМе. Помимо зарубежа, у него есть проекты рассчитанные на СНГ, в которых понадобилось разобраться с ПФ в Яндексе. Исходя из нашей беседы был написан обзорный материал ниже. В конце патенты Яндекса, которые заинтересуют специалистов.

На какие факторы воздействуют через накрутку:

🔸 Посещаемость сайта
🔸 Показатель кликабельности в выдаче (CTR)
🔸 Глубина посещения на сайте
🔸 Время пользователя на сайте
🔸 Повторные возвраты пользователей
🔸 Показатель отказов (является предметом дискуссии среди накрутчиков)

Посредством реверс-инжиниринга, специалисты по накрутке установили, что большую часть информации по поведенческим факторам Яндекс черпает из данных Яндекс.Метрики:

🔸 Учитывает профиль интересов пользователей
🔸 Опыт посещения, а также взаимодействия с элементами (особенно которые размечены как цели в Яндекс.Метрике) на предыдущих сайтах
🔸 Время жизни пользователя
🔸 Уникальные характеристики пользователя (ip, fingerprints)

Что делают специалисты по накрутке:

🧑 Создают уникальные характеристики и поведение пользователей посредством программного обеспечения и инфраструктуры в виде серверов и мобильных прокси, которые либо арендуют у третьих лиц, либо создают сами.
🏄 Посещают определенные сайты, на которых установлена Яндекс.Метрика, остуствует защита от ботов.
🎭 Выбор сайтов, в основном, опирается на такой показатель, как Долгосрочные Интересы (ДИ), однако при должной сноровке можно им пренебречь.
🚀 Осуществляют правильные переходы на целевой сайт.

Формирование “живых” новых пользователей для Яндекса занимает определенное время, обычно это около 10-ти дней, перед тем как запустить на ваш сайт.

В дальнейшем, “прокачка” пользователей и переходы выполняются параллельно, как правило 90% всего времени работы занимает фоновая работа системы, и всего 10% - целевые переходы.

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

Очень большое значение имеет техническая подготовка и настройка оборудования накрутчиком, поэтому лучше отдавать предпочтение специалистам/командам, которые самостоятельно организуют всю инфраструктуру, не обращаясь к помощи подрядчиков, поскольку они в первую очередь заинтересованы в оптимизации ресурсов, а также могут быстро подстроиться под новые изменения. Именно таким техническим специалистом является @Vadik_Root. Так как есть свободные ресурсы, он может взять несколько сторонних проектов в работу по цене от 1000 USDT в месяц.

ℹ️ Базовый патент связанный с ПФ:

СПОСОБ ФОРМИРОВАНИЯ ПЕРСОНАЛИЗИРОВАННОЙ МОДЕЛИ РАНЖИРОВАНИЯ, СПОСОБ ФОРМИРОВАНИЯ МОДЕЛИ РАНЖИРОВАНИЯ, ЭЛЕКТРОННОЕ УСТРОЙСТВО И СЕРВЕР
https://yandex.ru/patents/doc/RU2580516C2_20160410

ℹ️ Патенты яндекса для борьбы с накруткой ПФ:

СПОСОБ И СИСТЕМА ДЛЯ ВЫЯВЛЕНИЯ АНОМАЛЬНОГО РЕЙТИНГОВАНИЯ
https://yandex.ru/patents/doc/RU2776034C2_20220712

СПОСОБ И СИСТЕМА ДЛЯ ОПРЕДЕЛЕНИЯ АНОМАЛЬНЫХ ПОСЕЩЕНИЙ ВЕБ-САЙТОВ
https://yandex.ru/patents/doc/RU2775824C2_20220711

Вам не нужен Python!🚫🐍

Orange может решить множество сеошных задач, включая подсчет слов в датасете ключевых фраз, семантическое SEO и кластеризацию.

Что такое Orange?

🍊Orange — это бесплатный пакет программного обеспечения для визуального программирования на основе компонентов, предназначенных для визуализации данных, машинного обучения, интеллектуального анализа и анализа данных. Работает на различных платформах, таких как Windows, Mac и Linux.

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

Как начать пользоваться Orange?

🔸 Установить: https://orangedatamining.com/download/
🔸 Плейлист «Getting Started»: https://www.youtube.com/watch?v=HXjnDIgGDuI&list=PLmNPvQr9Tf-ZSDLwOzxpvY-HrE0yv-8Fy.

Какой add-on самый SEOшный?

Это Orange3 Text. Вот документация ко всем его виджетам: https://orange3-text.readthedocs.io/en/latest/

Пример решенной задачи

Одной из частей семантического SEO является связывание между собой семантически близких статей посредством ссылок. Для определения страниц-кандидатов для контекстных ссылок внутри статьи, в данном примере я использовал поиск ближайших соседей.

Для этого:

1️⃣ Просканировал сайт с помощью ScreamingFrog 🕷️
2️⃣ Выбрал столбцы URL и meta-title 📊
3️⃣ Предварительно обработал meta-title ✨
4️⃣ Перевел meta-title в векторное пространство embedding’ов с помощью SBERT 🔍
5️⃣ Нашёл 5 ближайших соседей выбранной мной страницы 🌐

Результат на скрине.

Похожий пример на Python был представлен недавно на SERP Conf.

P.S.
Если вас заинтересовала возможность использования данного программного обеспечения, рекомендую подписаться на мой канал, в дальнейшем планирую выкладывать .ows файлы с готовыми пайплайнами, чтобы вы могли сразу использовать их в Orange.