О сайтах и не о сайтах

Концепт доргена

Дорвеи делать я перестал еще давно, т. к. сливать трафик на "серые" платники совесть не позволяет, а из "белых" решений ничего особо прибыльного и нет по сути. Но перестав делать дорвеи, само дорвеестроительство как таковое я не забросил и вообще имел на этот счет большие планы. Собирался провести ряд экспериментов по внутренней оптимизации сайтов, ну и главное - наконец-то начать писать свой мега дорген, причем сделав его публичным.

Однако несколько недель назад ко мне стукнулся один человек и предложил позаниматься в партнерстве не совсем белыми вещами. На мой решительный отказ, достаточно точно подметил, что "карма и доры - это как-то даже интересно". Собственно, нельзя не согласиться. Идя в сторону СДЛ и параллельно заниматься написанием комбайна для поискового спама и вправду как-то странно. Поэтому я решил полностью уйти из дорвеестроительства. Рубрику "Дорвеи" на блоге уже удалил (посты не пропали, раскидал по другим категориям).

Идей же по доргену было много, поэтому решил поделиться. Мало ли, может кому-то пригодится.

Концепция

Сам дорген делается изначально на английском языке, название - iDorgen, "первый интеллектуальный". Домен под проект планировался соответственно idorgen.com (на данный момент свободен).

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

Техническая реализация

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

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

Сам дорвей строится таким образом - на конечный сайт (по домену которого должен будет отображаться дорвей) заливается как минимум один файл примерно такого содержания:

echo file_get_contents( 'http://domain.com/query.php?host='.$_SERVER['SERVER_NAME'].'&q='.$_GET['q']; );

где domain.com - домен, где установлена наша система. Т. е. страница дора собирается на сервере domain.com скриптом query.php и выводится уже на любом домене. Фактически проксирование. Плюс в том, что представленный выше исходник будет одинаковым для всех дорвеев. Все что нужно сделать - это сгенерировать дорвей в админке и закинуть один index.php файл на домен, по которому должен отображаться дорвей.

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

Из этой ситуации я вышел просто - помимо index.php на сервер с дорвеем заливал еще и файл img.php (тоже одинаковый для всех дорвеев), который и выдавал нужную картинку (т. е. при запросе img.php?id=xxx картинка на самом деле грузилась все с того же domain.com, но т. к. делается это на стороне сервера, узнать это извне нельзя). Картинки хранил в базе, тип mediumblob, минус этого решения в том, что если картинок много, то и БД сильно раздувается и становится неповоротливой, в принципе скорее всего более правильным было бы хранение картинок все-таки в виде файлов.

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

Модульность

Сама система предполагалась максимально абстрактной и модульной. Есть ядро и есть модули расширений. Фактически можно собрать свой персональный дорген, заточенный под генерацию галерей, блогов, новостников, форумов и т. д. Соответственно должны быть и модули для "добычи" контента (всякие парсеры либ.ру, ютуба, гугл картинок и т. д.).

Из "вкусных" модулей на память приходят две идеи. Умное формирование облака тегов (тайтл страницы разбивается на слова, слова пробиваются на частоту и инфинитив самого частотного слова становится тегом к этой записи) и генерирование дополнительных страниц в зависимости от ботов ПС. Касательно последнего - предположим, у нас есть дорвей по тематике "дейтинг", на этом дорвее есть страничка с тайтлом "Знакомства Москва". И на эту страничку кто-то заходит с Яндекса по запросу "знакомства москва область". Скриптами автоматически проверяется соответствие тайтла страницы, на которую зашли, с кеем, по которому зашли. Если они не совпадают, то по всему дору ищется страница со 100% совпадением тайтла ключу, если находится - то на эту страницу ставится ссылка со страницы, на которую зашли, в качестве анкора используется нужный ключ. Если такая страница не найдена (что будет скорее всего), то она создается автоматически (перелинковка аналогична). Т. е. получается, что чем больше на дор идет поискового трафика, тем больше на дорвее становится страниц, каждая из которых не только на 100% соответствует некоему НЧ, но на которую стоит ссылка с уже проиндексированной страницы с релевантным анкором.

Монетизация

Продавать сам дорген не имеет смысла. Занулят. Сделать дорген бесплатным и продавать к нему модули тоже бессмысленно по все той же причине.

Я остановится на таком решении - некоторые полезные фичи (как например генератор уникальных читабельных комментариев) реализовывать на сервере самого проекта, и предоставлять доступ к ним по платному API.

Т. е. при запросе, скажем

api.php?type=comments&number=10&uin=xxxxx

если uin=xxxxx зарегистрирован и проплачена конкретно генерация комментариев, то выдается xml c 10-ю сгенерированными комментариями, в противном случае ошибка "доступ запрещен". Конечно, писать запросы вручную не надо - поддержка платного API будет встроена уже в дистрибутив доргена. Заходишь в специальный раздел, ставишь галочку "Использовать платное API", проплачиваешь доступ и можешь генерировать дорвеи с дополнительной функциональностью. Ту же вставку ютуб роликов можно вынести из базовой поставки к доргену в платное API с платой за доступ в ~$0.3/месяц. Покупать можно будет как неограниченный доступ ко всему API, так и только к определенному функционалу (например, как в примере выше - к генерации комментариев и вставки валидных ютуб роликов).

Комментарии

Прям как Sed.
Чувак у тебя идею спиздили.
Пишу сейчас дорген. Интересная идея с облаком и перелинковкой.
На счет облака: "тайтл страницы разбивается на слова, слова пробиваются на частоту и инфинитив самого частотного слова становится тегом к этой записи" не фига не понял. Почему инфинитив? Плохо, что нужно обращаться с вордстату.

Да я только за, если кто-то реализует идеи из поста :)

Инфинитив, т. к. если у нас есть, к примеру, три тайтла "Знакомства в Москве", "Лучшие знакомства Москвы" и "Московские знакомства", и мы хотим назначить тег по городу автоматом, то тег должен быть по логике "Москва", т. е. инфинитив.

Как вариант, просто искать "похожие" слова каким-нибудь similar_text(), и в тег ставить самое первое найденное вхождение (Москве), но облако тегов тогда глаз резать будет, когда все слова в случайных склонениях, некоторые из которых не имеют смысла без предлогов. Так что лучше инфинитив.

Ну и ИМХО лезть в вордстат не лучшая затея, проще распарсить какой-нибудь словарь Ожегова и создать табличку инфинитивов. Потом прогнать по этой табличке с сотню книг, просчитав для каждого слова частотность. Как вариант, просто воспользоваться готовой табличкой (http://en.wiktionary.org/wiki/Wiktionary:Frequency_lists#Russian). Оно и быстрей и надежней по факту будет.

Добавить комментарий

Содержимое данного поля является приватным и не предназначено для показа.