Вы ссылки изучали?
Как минимум три из перечисленных - mnogosearch, dataparksearch, nutch - имеют собственные краулеры. Первые два дружат с русской морфологией.
Еще из вариантов: Яндекс.Server - http://company.yandex.ru/technology/server/ - насколько я помню, в бесплатную версию теперь входит возможность индексирования разных сайтов.
тема всплывает с завидной регулярностью:
/ru/forum/comment/2467762
Понятно, что для каждой задачи свое решение. Для кого-то очистка кеша раз в неделю является приемлимым решением. Т.е. тут предложили разные варианты, каждый выберет для своих задач нужное... На практике все равно приходится комбинировать разные подходы...
Внесу и свою лепту чуток :)
Есть еще такой подход: обновлять кеш именно тогда, когда
это необходимо.
Кладете в кеш часто запрашиваемые страницы/части страниц/результаты выборок (т.е. не важно, что именно - работает для всего), устанавливая для каждого кешируемого элемента набор тегов-маркеров, отвечающих за обновление.
Например, на сайте есть раздел "новости", "форум", "каталог товаров". На главной странице показывается лента новостей, рубрикатор товаров и статический (неизменяемый) контент, а по всему сайту сквозняком блоки "новости", "свежие темы с форумов".
Тогда при кешировании страниц сайта вводим следующие соответствия (страница - теги):
Главная страница - news, rubrics
Страницы рубрикатора товаров - news, rubrics, forum
Страница конкретного товара (id: 234) - news, forum, tovar234
Задача по управлению кешированием заключается в реализации алгоритма: при добавлении новости очистить кеш от всех страниц с тегом news, при изменении рубрикатора - страницы с тегом rubrics, при изменениях информации о товаре id: 234 - tovar234
Это в теории :)
На практике все это выливается в многомерную структуру кеша и сложность реализации, изложенного алгоритма: зашивать управление кешем в каждый модуль (новости, форум, каталог товаров) недальновидно с т.з. гибкости архитектуры, т.е., если хотим получить универсальное решение, надо выносить управление кешем на уровень "обертки". Работаю с j2ee - здесь данный подход реализуется навешиванием кеширующего фильтра и фильтра, управляющего кешем на основе заданных правил (что тоже не всегда просто), либо с помощью АОП. Как это сделать на других платформах, не знаю.
Из плюсов: пользователь всегда видит "свежий" контент, т.е. применение алгоритма оправдано тогда, когда "кровь из носа" нужно отдавать актуальную информацию.
Аналогичные траблы, но как-то непонятно: часть сайтов с IMS индексируется без проблем, часть периодически "вылетает" из индекса - грешим на контент (доски объявлений, но не говнодоски, а тщательно модерируемые), но, возможно, дело не в этом...
А вот тут поподробней, если можно. Какого рода проблемы, и на чем основано это утверждение? Просто используем данный подход на ряде сайтов, с некоторыми из них есть определенные траблы, но как-то не связывали с обработкой IMS.
Ну, тоже не совсем верно :) Согласно RFC, клиент (браузер, прокси, поисковый робот, etc) пошлет запрос IMS (If-Modified-Since) только в том случае, если при предыдущем обращении к странице сервер возвращал заголовок LM (Last-Modified). Так что на LM поисковикам совсем не "насрать".
Если поступил запрос IMS от клиента, и страница с тех пор не менялась, сервер должен вернуть ответ 304 Not Modified (а не 301 - ошиблись малость).
Автору:
Как вариант решения проблемы, в обработчике IMS на сервере проверять, авторизован ли пользователь, если да, то отдавать страницу, а не ответ 304.
Но опять же это не всегда сработает - многое зависит от настроек прокси по пути от сервера к клиенту - некоторые могут кешировать намертво опираясь только на значения Last-Modified, и чихая на остальные заголовки и рекомендации RFC. Как-то на одном из виртуальных хостингов столкнулись с вариантом, когда front-end кешировал страницы, выставляя Expires, основываясь на промежутке времени между запросом к странице и ее Last-Modified - они так снижали нагрузку на бекэнде, а клиенты матом ругались от того, что все железно кешировалось, не смотря на Cache-Control и т.п.
Или вообще, разделить (если возможно), части сайта для "общего пользования" (с соответствующими установками LM, обработкой IMS) и "авторизованного пользования" - c полным запретом на кеширование.
По кешированию почитай rfc, и неплохая статья на русском:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13
http://xmlhack.ru/texts/06/doing-http-caching-right/doing-http-caching-right.html
Кстати, а история сохраняется только в текущем сеансе? Зашел сейчас снова - история пустая. Неплохо было бы иметь возможность сохранять историю и между сеансами. Настраивать кол-во результатов на страницу можно во всех больших SE, а у вас - нет. Вобщем, Ваш путь, насколько я понял, в предоставлении пользователям всяких "вкусняшечек" - так что дерзайте, тут есть еще чего подсмотреть/скопировать/напридумывать :)
История поисковых запросов дублирует один у тот же запрос, если кликать по закладкам или следующим "страницам" поиска. Логичнее сохранять уникальные запросы, а при повторе запроса через какое-то время просто перемещать его в начало списка.
Не совсем понравилось отсутствие привычного постраничного бара.
А так вполне приятственное впечатление, удачи.
В блоге Гугла речь идет о meta-тегах, отвечающих за индексацию:
<META NAME="ROBOTS" CONTENT="NOFOLLOW">
<META NAME="ROBOTS" CONTENT="NOINDEX">
Здесь же речь о теге <noindex>, "понятном" Яндексу и Рамблеру, но "непонятном" Гуглу.
