- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Если я правильно понял, то Nun говорит о
Метод группирования статей по характеру их содержания. (Не по их расположению в навигационной структуре).
Это цитат из описания движка textpattern. Подробнее можно почитать в статье Семантика Textpattern
Тут скорее стоит улучшать алгоритм обычного поиска. Либо использовать данные теги, чтобы повысить релевантность документа в результатах.
Нет. Речь шла о другом механизме, действительно нужном для больших проектов.
Рубрики и категории не всегда спасают. Особенно когда много документов. Проще провести локальный поиск по документам, содержащим определенное слово или словосочетание и потом, выбрать из них десяток наиболее интересных. Вот их и надо показать как "еще материалы по теме".
В этом методе есть один но существенный недостаток:
статьи по теме, как правило, показываются только более старые, т.к. при добавлении новой статьи надо проходить другие статьи и добавлять туда новую, что не очень эффективно с точки зрения трудозатрат.
Более универсальный механизм - группы.
Для каждого словосочетания создается своя группа, к примеру -"ежеудавная проволока". Первичное заполнение группы происходит по вышеописанному механизму, с небольшими усложнениями речь о которых пойдет ниже. В дальнейшем група пополняатся прямо из создаваемой статьи. Т.е. в каждой статье есть поля - группа статей по теме ( или основная группа ), и дополнительные группы, в которые входит данная статья. При соханении документа группы, затрагиваемые данной статьей, перестраиваются. При выводе на WEB под заголовком статьи по теме выводится список статей основной группы данной статьи.
Не забудьте при реализации отработать удаление статьи и удаление группы из статьи :)
можно добавить фичу - выдачу карты сайта в XML (в формате Google Sitemap)
Для каждого словосочетания создается своя группа, к примеру -"ежеудавная проволока". Первичное заполнение группы происходит по вышеописанному механизму, с небольшими усложнениями речь о которых пойдет ниже. В дальнейшем група пополняатся прямо из создаваемой статьи. Т.е. в каждой статье есть поля - группа статей по теме ( или основная группа ), и дополнительные группы, в которые входит данная статья. При соханении документа группы, затрагиваемые данной статьей, перестраиваются. При выводе на WEB под заголовком статьи по теме выводится список статей основной группы данной статьи.
Непонятно.
"Каждому словосочетанию" ставится в соответствие "группа", одна или несколько? Как отбираются эти "каждые"?
"Группа пополняется из создаваемой статьи", в CMS должна быть батарея чекбоксов по всем группам? Как слово из текста поля ставится в соответствие определенной группе?
Правильно ли понял, что список рекомендуемых ссылок по группе периодически обновляются, что приводит к динамике по внутреннему ссылочному на внутренних страницах? :)
И вообще какой [количественный] эффект от такого гиморройного механизма? :)
Нет. Речь шла о другом механизме, действительно нужном для больших проектов.
Кому нужно, тот всегда найдёт. ;)
Кстати, технорати на этом алгоритме и работает.
"Каждому словосочетанию" ставится в соответствие "группа", одна или несколько? Как отбираются эти "каждые"?
Естественно одна. и делается это по мере необходимости.
Группа содержит статьи по данному словосочетанию.
Каталог самих групп, для удобства, можно делать в иерархическим.
"Группа пополняется из создаваемой статьи", в CMS должна быть батарея чекбоксов по всем группам? Как слово из текста поля ставится в соответствие определенной группе?
Нет, просто кнопка "Статья отностися к группе". При нажатии можно делать множественный выбор групп, к которым отностися данная статья.
Как это реализовать для конкретной CMS - не знаю, пытайте системного аналитика и программера. Скорее всего созданием связывающих таблиц, я от реляционных систем ушел лет 10 назад, а на лотусе - как 2 пальца об асфальт.
Правильно ли понял, что список рекомендуемых ссылок по группе периодически обновляются, что приводит к динамике по внутреннему ссылочному на внутренних страницах?
Правильно. Можно обновлять а можно пополнять.... тут уж кому что надо :)
И вообще какой [количественный] эффект от такого гиморройного механизма?
Как сказать... удобство пользователю и оператору. Повышение качества контента и соотношения хост/хит :)
У себя сделал словарь внутренних ссылок для автоматической перелинковки текста. По низкочастотным запросам хорошо отрабатывается.
Мэкс, извиняюсь, конечно, но непонятно. :)
Статья ставится в соответствие нескольким группам при её вводе на сайт. При выдаче этой статьи посетителю выводится список подсказок-ссылок. Как формируется этот список-подсказок, если статья в нескольких группах? И зачем необходимы ключевые слова в группах?
pro-maker, Есть 2 поля. Первое содержит имя основной группы, только одно значение, а второе ( в принципе оно необязательно, но связи удобнее строить) содержит список других групп.
При выдаче статьи в "еще ссылки по теме" - выводятся все ссылки из группы в первом поле (естественно кроме ссылки на себя).
А вот данная статья выводится в "еще ссылки по теме" в тех статьях, в первом поле которых стоит одна из групп из второго поля данной статьи.
Короче, на рисунке док. 1 содержит в поле 1 группу А, при этом относясь к группе В и С, док. 2 содержит только группу С.
Что имеем при выводе:
Док. 1 - "есть еще" док.2
Док. 2 - ничего дополнительно нет.
Есть более сложные механизмы, поддерживающие версии. Но это уже для хранилищ документов.
pro-maker, Есть 2 поля.
Вооо.. теперь и до меня дошло. :) Идея интересная, но не будет ли в процессе развития сайта дико расширятся количество групп?