- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Чего нету? Ты бы сначала определился с понятием "С этой статьей также смотрят". В этой теме уже дали два возможных варианта - related похожие; случайные записи. Если у тебя оно означает (переходы_с_статьи + кол_статей)/общее_число_мемберов * текущая_дата то это только под заказ.
случайные менее интересно, а вот по поводу релейтед дополню - для вордпресса есть два наиболее распространенных варианта релейтовости (во классное слово придумал )))
первое - делаем "похожесть" на основе категорий, ведь вполне логично что статьи из одной категории будут чем-то похожи...
второе - "похожесть" на основе тегов, причина аналогична
по поводу плагинов - есть дофига и еще немножко, но меня всегда поражала загадочная блоггерская душа, пытающаяся все делать через ж*, простите через плагины - где-то даже плагин для дат видел )))
вот решение на скорую руку, на базе тегов
десяток строк позволит обойтись без плагина, по категориям можно сделать аналогично... а вообще код предлагаю рассматривать как заготовку - например дополнительно можно показывать превьюшки или первые 20 слов
Выводим список этих самых «следующих записей» за весь период жизни сайта (записи).
в принципе в программировании не бывает ничего невозможного - зато существует нецелесообразное...
обьясню что имелось ввиду
1. нецелесообразно с точки зрения нагрузки
представьте что зашел на сайт Василий Пупкин и с интересом посмотрел материал, в котором девченка огрела табачника венком по роже... Айпишник Василия нужно уточнить, верно? а кроме того данный айпишник нужно где-то держать, тоже верно? Ну и соответственно где-то нужно держать данные о том что именно просматривал Василий, ведь другой айпи может просматривать что-то другое... а если он больше ничего не просмотрит?
Василий уходит, на сайт приходит Маня Пупкина - а перед тем как выдать ей материал, сервер должен будет лишний раз убедиться, что айпи Мани и Васи совпадают, лишний раз дернуть базу - что же там смотрел Василий... а после просмотра еще и сделать изменения в базе - ведь нужно же сохранить данные о том что просматривала Маня...
2. нецелесообразно с точки зрения СЕО
Напоминаю, что наш Василий смотрит статью про букет и про рожу - именно эти слова являются нашими ключами... если выводим related статьи из этой же категории или с этими же тегами, то общее кол-во ключей при грамотном подходе увеличится (а если релейтед пойдут с анонсами, т.е. ключи будут окутаны тематическим текстом как теплым одеялом - то вообще сказка)
Теперь представьте, что Вася П. которому до лампочки все слова из трех букв включая СЕО смотрит сразу же после данной статьи что-то про сиськи, или про футбол, или про марсиан...
другими словами - Маня Пупкина, которая откроет ту же самую статью видит, что вместе с этой статьей смотрят про сиськи и марсиан...
2.1 по той же самой причине нецелесообразно с точки зрения юзабилити/удержания посетителя на сайте
много букв получилось, но надеюсь что убедил не поступать нецелесообразно...
t3s, спасибо за подробный ответ.
Однако, давайте разберемся.
1. нецелесообразно с точки зрения нагрузки
Очень даже возможно.
Однако, наверняка есть способы нагрузку эту оптимизировать.
http://www.kakprosto.ru/kak-63906-kak-rasschitat-bolnichnyy-iz-mrot
Вряд ли там маленький траф, однако не тормозит...
2. нецелесообразно с точки зрения СЕО
Согласен.
Но при этом современное SEO - вещь в себе не сильно уступающая физике твердого тела, что для нее хорошо, а что плохо - скорее тема дискуссии, чем глава учебника...
нецелесообразно с точки зрения юзабилити/удержания посетителя на сайте
В вот тут спорно.
Заходя на сайт и/или в магазин, получить подсказку, чем еще интересовались люди, читающие то, что читаю я сейчас - как минимум не бесполезная информация.
Очень даже возможно.
Однако, наверняка есть способы нагрузку эту оптимизировать.
http://www.kakprosto.ru/kak-63906-kak-rasschitat-bolnichnyy-iz-mrot
я не говорил "невозможно", я говорил "нецелесообразно"
специально проверил ссылку - харьковский, польский и американский айпишники показали идентичные результаты в блоке "С этой статьей также смотрят", т.е. там реализация не на основе айпишника
если вернуться к примеру про Василия Пупкина - то как быть если таких Василиев 100? а если 1000? Для каждого ай пи хранить свой результат статей, которые читают?
по поводу СЕО - не спорю, тут скорее не физика а лирика, хотя мой опыт (несколько сотен сайтов на ВП) говорит о том что "похожие статьи", выводимые вместе с аносами и оформленые в стиле основного материала отлично работают, т.е. основной материал добавляется нужными ключами+качественная перелинковка
а вот по поводу юзабилити я возможно не так обьяснил...
смотрите, допустим имеется интернет-магазин, в котором пользователь просматривает телефон Nokia X8... Если мы сделаем "С этой статьей также смотрят" на основе тегов (вполне логично что теги будут вроде Nokia, Simbian, сенсорный и т.д.) - то пользователю будут выведены действительно похожие телефоны...
но если мы доверим это дело пользователю, и будем выводить лишь то что он посмотрел... представьте что сразу после телефона Вася П. посмотрел на стиральную машину, или утюг, или пылесос - соответственно следующий посетитель увидит что вместе с Nokia X8 смотрят про стиральные машины/утюги/пылесосы
с новостными или информационными сайтами аналогично - если статья про футбол то логично показывать как минимум спортивные статьи...
харьковский, польский и американский айпишники показали идентичные результаты в блоке "С этой статьей также смотрят"
А как он может быть разный, если блок показывает, что другие посетители читали вместе с этой статьей?
Это вообще не WP, а Drupal.
И если присмотреться повнимательней, то в этом блоке выводятся статьи из этой же категории. Так что можете спокойно использовать Related и называть свой блок как душе угодно, хоть "С этой статьей также смотрят".
Это вообще не WP, а Drupal.
И если присмотреться повнимательней, то в этом блоке выводятся статьи из этой же категории. Так что можете спокойно использовать Related и называть свой блок как душе угодно, хоть "С этой статьей также смотрят".
Так точно - Друпал и related_articles. Если ТС предполагает, что его посетители поголовно страдают стадным инстинктом, то блок даже можно назвать "Невероятно, но все кто прочитал статью X, еще читали следующие 5 записей: ..."
п.с. И вообще это мажорство - отдавать, практически, рандомные ссылки посетителю. Вы еще скажите, что в блоке "С этом товаром так же покупают" действительно показывают то, что так же покупают с этим товаром :)
Вы еще скажите, что в блоке "С этом товаром так же покупают" действительно показывают то, что так же покупают с этим товаром :)
В нормальных магазинах именно так, но для покупок это попроще, чем для просмотров, во первых в меру количества обрабатываемых данных, во вторых в меру реальности покупок.
Что касается задачи ТС, в принципе в этом есть определённый смысл, но если подсчитывать тупо кол-во просмотров, без коррекций... то его не много. По двум основным причинам. Первое - блок рано или поздно станет статичным, т.к. вместе с текущей статьей люди будут часто тыкать в статьи из блока и будет "самонакрутка". А с другой стороны блок до "самонакрутки" будет изрядно случайным, т.к. у посетителя нет возможности выбрать интересную статью на сайте "вот так сразу", он перетыкает несколько, пока не наткнется на интересную. Фактически задачу отображать "статьи которые интересны читателям этой статьи" он выполнять не будет в чистом виде.
p.s.: ТС, если задачу действительно нужно решить и не найдете вариантов, стучите в асю, решим. Но мы решаем задачи медленно и дорого:)
Очень даже возможно.
Однако, наверняка есть способы нагрузку эту оптимизировать.
Если там присмотреться видно, что найденные новости схожи с искомой. Все начинаются на "Как" а в некоторых есть и "рассчитать". Сделано там по другому принципу.
А как он может быть разный, если блок показывает, что другие посетители читали вместе с этой статьей?
Где показывает, что показывает? Вы всему верите что там написано? Откуда знаете какой там алгоритм вывода? Может это вообще все вручную проставлено. Я вот зашел в тему которой небыло в этом блоке, обновил страницу и.. там нечего не изменилось. Кэш наверное, зайду через неделю.
ТС, ставьте плагин похожие новости и не майтесь ерундой. С точки сео и пользы от этого будет гораздо больше толка. Вам верно говорят, что те кто искали розовые слоны вряд ли будут интересны голые титки семенович (небольшой контраст), и наоборот. А они будут отображаться в блоке если ктото серфил по сайту.
А как он может быть разный, если блок показывает, что другие посетители читали вместе с этой статьей?
ведь это ваша цитата, верно?
насколько я понял из данной фразы - вы хотите отталкиваться именно от айпи