- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
А разве это решит проблему обозначенную коллегами?
Допустим у меня выборка по словам "скачать" и "установить"
У меня все ключи будут содержать эти слова. Либо первое либо второе.
Потом алгоритм описанный выше будет находить либо по 1му либо по 2му слову совершенно нерелевантные слова.
Например ключ "скачать фотошоп бесплатно"
по этому алгоритму найдет :
по 1му слову: скачать все подряд - все ключи похожие
по 2му слову: все про фотошоп - уже лучше
по 3му слову: дофига нерел. ключей по слову бесплатно
И в итоге будет у нас 1 список где важное слово было всего 1 + куча шлака.
Не?
Ну с другой стороны переспама по 1 отдельно взятому ключу уже не будет.
тогда можно взять и разделить ключ не по 1 слову, а по 2 например, тогда будет более похоже.
Может не учитывать при поиске слова, которые встречаются чаще 10% от всего списка?
То есть убрать из рассмотрения слово "скачать, видео, п0рн0" если они попадаются в каждом 10 ключей или чаще.
Оставшиеся слова - это именно те, что имеют значение при поиске похожих. Не лучше ли так будет?
Подправил тот пост, теперь там можно найти «очень похожие» ключи по двум словам. Идеала все равно не будет, ведь все-равно попадутся ключи со «скачать бесплатно», но без «фотошоп». Это дор, такая погрешность допустима.
Для идеала нам надо научить дорген выделять в ключе самые значимые слова. Это уже надо очень придирчивым. Но если уже начали, то алгоритм такой:
Или вариант попроще: указать в настройках доргена список стоп-слов (stop-SIMILARKEY.txt), которые игнорируются при формировании похожих ключей:
А дорвейщик уже сам сможет выделить их из списка ключей для нужной тематики. тот же KeyCollector через "анализ групп" покажет наиболее часто встречаемые слова. Необязательно весь массив пересмтаривать, хватит рандомно 10К кеев взять.
Или вариант попроще: указать в настройках доргена список стоп-слов (stop-SIMILARKEY.txt), которые игнорируются при формировании похожих ключей:
Дык а не удобнее ли будет если программа динамически сформирует этот список стопов? Просто собираем статистику слов по каждому ключу и те что набрали больше 10%(настраивается в тюнинг файле) - считаем стоп словами и их тупо не рассматриваем.
Плюс нужен настраиваемый баланс между скоростью и степенью похожести.
Дык а не удобнее ли будет если программа динамически сформирует этот список стопов? Просто собираем статистику слов по каждому ключу и те что набрали больше 10%(настраивается в тюнинг файле) - считаем стоп словами и их тупо не рассматриваем.
Удобнее конечно будет, наверно так и надо делать.)
Дык а не удобнее ли будет если программа динамически сформирует этот список стопов? Просто собираем статистику слов по каждому ключу и те что набрали больше 10%(настраивается в тюнинг файле) - считаем стоп словами и их тупо не рассматриваем.
Плюс нужен настраиваемый баланс между скоростью и степенью похожести.
Просто сейчас очень быстро посты все штамповали, и я свой предыдущий пост писал, не читая еще твоего. Все ок, сойдет любой вариант.
UPD
Еще нужен обязательно:
{PUNIQSIMILARKEY}…{/PUNIQSIMILARKEY} – аналогичен {SIMILARKEY}, но уникален в пределах страницы.Чтобы на тех же тубах можно было его выводить типа так:
{REPEAT-5-15}{PUNIQSIMILARKEY}…{/PUNIQSIMILARKEY}{REPEAT}
{PUNIQSIMILARKEY}…{/PUNIQSIMILARKEY}
Обычный {SIMILARKEY} уже и так уникален в пределах страницы, иначе смысла бы не было :)
Только приступаю к изучению Пандоры, прошу сильно не пинать...
Вопрос такой, можно ли в пандоре реализовать такую схему:
У нас есть категории, ключевики, тексты и картинки
Скажем есть 5 категорий
Для них есть 5 фалов с ключами
5 файлов (папок с текстами)
5 папок с картинками
Реально ли сделать так, что бы для категории 1, взялся файл с ключами 1, файл с текстами 1, папка с картинками 1
аналогично для категорий 2-5
Если это реально - может кто нибудь подсказать как это реализовать?
Только приступаю к изучению Пандоры, прошу сильно не пинать...
Вопрос такой, можно ли в пандоре реализовать такую схему:
У нас есть категории, ключевики, тексты и картинки
Скажем есть 5 категорий
Для них есть 5 фалов с ключами
5 файлов (папок с текстами)
5 папок с картинками
Реально ли сделать так, что бы для категории 1, взялся файл с ключами 1, файл с текстами 1, папка с картинками 1
аналогично для категорий 2-5
Если это реально - может кто нибудь подсказать как это реализовать?
readme.doc
вторая страница (30 стр.)