Скрипт Lasto's Abductor и решаемые им задачи. Партнёр none

Lasto's Abductor, Похититель буковок Lasto's Abductor, Похититель буковок

"Букв похититель" от рутины,
Едва ли полностью спасет.
Но из глобальной Паутины
Контент и трафик принесет :)

Он по-стахановски, сверх плана,
Пока web-мастер крепко спит,
Без АГС-ов или бана,
Бабла немало отслюнит :)
Мастер Горди.

Интрадакшен:

Как следует из публичного содержимого данного сайта, коллекционирующего в своих разделах актуальную информацию главным образом на тему парсинга, в этих самых парсерах нет никакого недостатка. И не существует ни единой проблемы в получении контента из любых мест: с конкретных сайтов или загодя заготовленного списка URL-ов, через запрос к поисковым системам по списку ключевых слов, а также посредством творческой работы с фидами.

Чаще всего подобные парсеры десктопные, что предполагает дальнейшую выгрузку контента в ту или иную CMS, список которых не бесконечен.

Всё это замечательно, когда требуется тупо сгенерировать контент для того типа сайтов, что сильно радуют "чёрного" SEO-шника. Однако для проектов, тяготеющих к "белой" стороне, такой инструментарий не сильно подходит.

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

Каковы реальные потребности вебмастера?

  1. Сразу понятно, что необходим скрипт в серверном исполнении.

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

  2. Лучше и проще всего совместить скрипт с CMS. Чтобы задачи экспорта-импорта контента даже не возникало. А также и всей сопутствующей проблематики по конвертации контента между разными форматами его представления. Родившийся в скрипте контент должен использоваться далее без всей этой промежуточной (и никому не нужной) нервотрёпки.

  3. Имеет смысл саму CMS сделать без базы данных. Даже не потому, что такие движки быстры, нетребовательны к серверу, и никогда в жизни не покажут вместо сайта промпт ошибки соединения с MySQL (мучая этим миллионы людей). CMS на файлах элементарно удобнее.

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

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

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

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

  5. Вопрос, откуда брать контент, должен решаться комплексно:

    1. По списку ключевых слов с любых поисковых систем.

      Глубину просмотра поисковой системы при этом нужно уметь задавать.
      Быть может, для наших целей более пригодны ресурсы, начиная где-нибудь с 20 страницы выдачи поисковой системы - c ними не нужно будет конкурировать :)

      Свежую информацию о достойных внимания статьях в рамках тематики своего сайта можно найти только через поисковик. Желательно за определённый интервал (последние: день, неделя, месяц, год) - Гугл это умеет.

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

    2. С любого сайта, имеющего сниппетовую структуру.

      Это когда на сайте имеется список публикаций, либо оглавление разделов. Если для такого участка HTML кода страниц сайта можно написать регулярку, этого вполне достаточно.

      Данный способ добычи контента ничем не отличается от парсинга сниппетов поисковика, и вытягивания из них URL-ов статей. Применяется, когда донорский сайт не предоставляет RSS ленту, и больше контент никак оттуда напрямую не взять.

    3. С RSS ленты (фида).

      Когда тематика нашего сайта достаточно узка, и круг ресурсов, могущих публиковать интересующий нас контент, предопределён, проще всего отслеживать этот контент наиболее естественным способом. Через фиды.

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

    4. Со списка URL-ов.

      Можно не заставлять скрипт искать контент самостоятельно, а дать ему уже готовые ссылки на статьи, ежели таковые известны.

    Понятно, что все эти варианты поиска контента функционируют независимо друг от друга, и при этом параллельно. Для всякой категории мы можем активировать любой способ, причём со своими настройками.

    Также очевидно, что один способ подбора контента может замещать собой другой. Так, мы можем взять сведения о новом контенте с конкретного сайта через его фид (c), либо спарсить его с сайта напрямую (b), либо найти через Гугл (a), задав областью поиска документы только нужного сайта (возможно, оговорив ещё и кейворды, а также тип индекса поисковика - основной или дополнительный).

  6. Парсер контента должен уметь брать текст статьи с любого источника.

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

  7. Скрипт обязан прозрачно проходить сквозь редирект.

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

  8. Очистка кода импортируемой статьи.

    Нам не нужны чужие баннеры, джава-скрипты, счётчики, и блоки контекстной рекламы. Всё это зачастую встречается прямо в коде статей, и должно быть изъято оттуда.

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

  9. Синонимайз импортированной статьи.

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

    Базы синонимов можно добавлять свои.
    Управление выбором имеющихся баз простое, через админку.
    Последовательный проход по нескольким базам также поддерживается.
    Всё максимально удобно и крайне незамысловато в использовании.

  10. Импорт рисунков на собственный сайт.

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

    Естественно, добавление своих рисунков через админку также есть.

  11. Весьма пригодится функционал по отмывке трафика.

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

  12. Ну и так как любой сайт, даже автонаполняемый, не может обойтись без "особых" страниц, добавляемых вебмастером, не лишней будет возможность встроенной CMS с произвольной структурой файлов.

    К примеру, данный Мануал со всей его иерархией документов как раз выполнен с использованием встроенной CMS.

Ограничения скрипта Abductor:

  1. Область применения - работа со статьями.

    Если парсер контента обучен распознаванию текстов, то и работать он сможет только с текстами. Никакой подборки видео с Ютуба, или коллекции картинок голой Анфисы Чеховой на основе текстового парсера контента мы соорудить не сможем.

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

  2. Поддерживается только русский язык создаваемых сайтов.
    Может быть, ещё и украинский.
    Они очень близки.
    Скармливайте демо версии админки URL-ы документов на украинском языке, и проверяйте, так ли это.

    Никаким другим языкам парсер не обучен.
    И работать с ними не будет.

  3. Скрипт серверный, и не является браузером.

    В силу этих чисто физических ограничений он не может пройти антипарсинговую защиту некоторых ресурсов, тестирующих внешние подключения смесью кук, редиректов, и исполняемого JavaScript кода. Или выставляющих защитную капчу.

Таким образом, по замыслу автора скрипта, с его помощью можно выращивать ресурсы, максимально похожие на "белые" сайты, так называемые СДЛ. Которым положено жить долго, и монетизироваться через биржи ссылок, принося постоянный пассивный доход. Причём, в зависимости от тематики и совокупного трафика, тут отнюдь не исключены партнёрские программы и контекстная реклама. А так же всё, что покажется уместным.