Ingref вообще странно получается, сейчас в выдаче по этому запросу у серча выводится PDA-версия. В rel canonical указывается версия для десктопов. Получается, с учетом недавних изменений Яндекс или считает версию для PDA более качественной (за счет mobile friendly), или только пробует оба варианта и собирает стату. Ссылки на сохраненку кстати у меня не выводятся в веб-выдаче, но можно взять их из Yandex.XML
Да, интересное наблюдение. Сейчас уже 3 результата, но выводится что найдено 19. Скорее всего это говорит о том, что они не считают их, а используют какую-то вероятностную структуру данных и оценивают число документов, которые содержат слова или даже n-граммы из запроса. Может быть что-то реализованное на базе хэш-функций, например HyperLogLog.
Есть предположение, что будут проблемы с индексацией такого контента - Яндекс посчитает за бредотекст и выкинет такие страницы из индекса.
Кстати, у первоначального эксперимента с keywords интересное продолжение:
Как видно, Яндекс нашел документ не по вхождению в анкор, а по вхождению в href. И в сниппете выводит вместо анкора урл в скобках. О чем это говорит?
1. Возможно, что href является расширением текста документа и трансформируется при индексировании в "анкор (href)"
2. Возможно, работает какой-то переколдунщик чисто для ссылок на выдачу Яндекса, извлекает оттуда поисковую фразу
3. Возможно что серч отдает роботу какую-то другую версию страницы, где действительно следом за анкором указывается урл в скобках, что было бы странно. Простой тест с подменой User-Agent такую гипотезу не подтверждает, но это не единственный способ делать клоакинг - еще можно по IP-адресу робота, который никак не подделать.
Вообщем, можно еще эксперимент ставить по индексированию слов, которые присутствуют только в href 😂
P.S. Забавно что целью такого изврата с оставлением ссылки на выдачу было как раз избежание индексирования страницы с этой темой по этому запросу. Но Яндекс перехитрил и проиндексировал вхождение из урла на выдачу.
Цель описанного мной эксперимента - проверить гипотезу о том, что в формуле ранжирования Яндекс (в отсутствие или при прочих равных других факторах) вес страницы с дополнительным включением поисковой фразы в meta keywords будет выше, чем только с вхождением в текст. Он должен дать ответ на вопрос - а есть ли смысл заполнять keywords, или достаточно упоминания в тексте.
В результате эксперимента может быть три исхода:
1. Оптимистичный сценарий - все или большая часть страниц в экспериментальной выборке запросов отранжируются таким образом, что будет отдано предпочтение страницам с дополнительным вхождением ключа в meta keywords. Если даже предположить, что какие-то факторы мы не учли, то при возникновении данного исхода получается, что вхождение в keywords их перевесило. Это будет доводом к тому, чтобы заполнять keywords - если можно на что-то влиять в плюс, лучше это делать, чем не делать.
2. Худший сценарий - страницы будут выводиться в выдаче вразнобой, прямой зависимости с наличием доп. вхождения в keywords не будет. Это позволит считать эксперимент несостоявшимся, т.к. из результата может следовать что угодно - либо какие-то иные факторы добавили шум, либо в поисковике реально нет фактора, который бы суммировал факт наличия вхождений как в тексте, так и в keywords. Хотя некоторые могут посчитать это доводом в пользу того, чтобы не заполнять keywords.
3. Невероятный сценарий - если вхождение в keywords наоборот добавит штраф к релевантности и страницы, содержащие его, будут ниже. Это будет аргументом к тому, чтобы наоборот избавляться от keywords.
Насчет воспроизводимости эксперимента - в принципе она есть - только придется сгенерить новые уникальные термины, написать новые тексты и сделать под них новые сайты - т.к. проверяется не ранжируемость по конкретному запросу, а по неограниченному количеству запросов, попадающих под условия:
Понятное дело, что даже в случае оптимистичного сценария результаты этого эксперимента имеют ограниченную применимость на практике - большинство реальных запросов для продвижения имеют конкурентов и у поисковика есть какая-то статистика по словам тематики, которая влияет на значимость вхождения конкретных слов, отсутствующих в запросе. Для абсолютно новых слов, по которым задуман этот эксперимент, такой статистики нет и можно посмотреть как работает чистое ранжирование по вхождениям слова.
Да, с этим есть технические проблемы - загнать в индекс много разных сайтов с одинаковым текстом может оказаться невозможным, но в принципе за счет выборки можно использовать уникальные тексты, если выполняется требование новизны слова для поисковика. Хотя, если брать во внимание изменения с момента релиза алгоритма "Королёв", то из этой статьи становится ясно, что взаимосвязь у них есть не только по отдельным словам, но и даже буквенным триграммам. Но модель все равно обучается на корпусе популярных слов, и для неизвестного просто обязана выдать рандомный результат, который будет просто шумом, скомпенсированным выборкой.
Можно еще пробовать такой эксперимент в динамике - сначала загнать в индекс с одним текстом, потом поменять его, дождаться переиндексации и снова посмотреть на результат.
keywords используется яндексом, проверил экспериментально. Суть эксперимента - придумываем какой-нибудь заведомо несуществующий термин, делаем страницу где он упоминается только в meta keywords и загоняем в индекс. А затем пробиваем выдачу
Т.е. как минимум для определения релевантности они как-то используются, в отсутствие более подходящих страниц с вхождениями термина в текст.
Можно также попробовать оценить влияние вхождения в keywords на ранжирование, только для этого понадобится сделать достаточно много таких примеров, дабы скомпенсировать независящие от контента факторы. Как вариант, придумываем термин, делаем под него 10 страниц с одинаковым текстом, 5 из них с вхождением в keywords, другие 5 без вхождения, загоняем в индекс и смотрим долю страниц в топ-5 в которых есть вхождение в keywords. Если она будет высокая - значит поисковик при прочих равных отдает предпочтение страницам с вхождениями keywords.
Можно в similarweb смотреть топ-5 стран по трафику, бесплатно и даже без регистрации. На моей выборке в 500к доменов разрыв между первым и вторым местом в среднем составляет 60 процентных пунктов. Между вторым и третьим - уже 7 п.п. Так что этого топ-5 должно хватить для большинства случаев.
Что именно не понятно? 🤪
В меню выбираете Configuration -> Include и указываете регулярку .*chekhly-na-sidenya.*
Ну это подходит только в случае, если нужные урлы лежат в одной папке, например, если надо отсканить всё, что лежит в /articles/, /news/, /categories/covers/ и т.п - при правильном ЧПУ на сайте так и должно быть. Для случаев, когда нужно вхождение в любом месте урла, надо использовать Include-правила на основе регулярных выражений.
Потому что спецификацией формата robots.txt не определен приоритет allow/disallow в случае использования подстановочных знаков, например звездочки: https://developers.google.com/search/reference/robots_txt
По правильному, это надо делать не через robots, а штатными средствами софта, например фильтром Configuration -> Include: https://www.screamingfrog.co.uk/seo-spider/user-guide/configuration/
Как говорил классик, любая сложная проблема имеет простое и неправильное решение.
Поскольку ТС даже не уточнил формат входных данных, стоит рассмотреть все случаи.
Ссылка - это не всегда только урл акцептора, информация о ней чаще всего включает в себя еще и анкор + урл донора. Форматов представления может быть много, но чаще это либо таблица в xls/csv, либо полностью html-тег, либо спец. разметка, навроде той что есть у сапы.
Теперь рассмотрим тривиальный случай, когда обрабатываются только урлы акцепторов. Очевидно, что задача уникализации этих урлов не может быть корректно решена простой текстовой сортировкой и последующим фильтром дубликатов. Нужно, как минимум, нормализовать урлы - удалить #фрагменты, привести к одному регистру все, кроме пути и query_string, раскодировать пуникодные и percent-encoded урлы, в каких-то случаях даже объединить зеркала.
Если добавить к урлу акцептора такие данные, как урл донора, анкор и набор атрибутов, то появляется еще больше неоднозначностей, которые нужно описать в требованиях. Например, нужно ли считать дублями ссылки на одинаковый акцептор, но взятые с разных доноров, или если они имеют разные анкоры. Или если они отличаются только атрибутами навроде nofollow.
Рекомендовал бы ТСу все-таки начать с анализа, какая действительно проблема решается такой уникализацией, и искать полноценное решение под ваш use case.
Если образ mysql официальный от разработчиков Docker, можно переопределить имя базы через переменную MYSQL_DATABASE при создании контейнера. Если не переопределить, созданная база так и называется - mysql
А зачем вы парсите HTML регулярками, когда можно использовать, например, XPath или CSS-селекторы?
