Хе-хе-хе. Эко Вас пробрало....
А вот и не угадали! Я их и не путал.
Было сказано именно то, что имелось в виду.
Стыдно, батенька! Опускаетесь до простого, извиняюсь, оскорбления. А представителю солидной компании в отличие от, скажем, среднестатистического посетителя форума, не положено (впрочем, им не положено тоже). Ну, как известно: "Все, что Вы скажете, может быть использовано против Вас".
Цитата из известного анекдота про астронавтов, которые приземлились в глухой сибирской тайге, 3 дня по ней бродили, голодные, изодhанные (один раз чуть медведь не съел), и вот видят они в тайге костер, а возле него мужика в валенках, ушанке и ватнике: "-Please Help Us! Do you speak English??!! - Yes. Of course. Certainly do. But фигли толку?"
Я же не говорил, что у Rambler нет морфологии. А говорил, что это преимущество Yandex.
На сем предлагаю обмен мнениями перевести в более конструктивное русло.
Замечания о Дополнения:
1. http://www.be1.ru/articles/manual/technology.html - ой не все там правильно написано, ой не все. Даже очень многое неправильно, я бы сказал.
2. В отличие от передачи параметров любым способом, как через ?, так и через /, обработчик 404 имеет множество преимуществ, причем только одно из них описано в предыдущем постинге, внимательное изучение показывает, что пользы можно извлечь и больше.
3. Приведенный пример написан для PHP, причем рекомендуется использовать PHP 4.x - там корректнее работа с длинными строками, чем в PHP 3.x. Используемый web-сервер - Apache.
4. Лично я подсмотрел подобную идею на http://detail.phpclub.net Отличный сайт, регулярно его просматриваю, чего и всем советую.
5. БОльшей производительности сервера можно достичь, используя mod_rewrite, но использование скриптового обработчика естественно, более гибкий и мощный инструмент. Хотя и отъедающий ресурсы (и забивающий логи ошибками).
6. Буду чрезвычайно благодарен (как, видимо, и многие участники и посетители форума) за замечания, и особенно за рассказ о собственных технических приемах
2 Professor насчет POST:
1. Вызывается /form.html
2. Вызов обрабатывается /missing.html, который рисует форму
3. Посетитель заполняет поля формы, давит батон, и происходит вызов /form_action.html, в который параметры передаются POST
4. А на самом деле вызывается /missing.html, к которому и попадают все POST-параметры
5. /missing.html стряпает URL к реальному обработчику формы с добавлением полученных им POST параметров в строку URL реального обработчика форм /handle_all_site_forms.html?var1=value1&var2=value2
6. Этот URL никто и никогда не видит, ни посетитель, ни робот
7. Результаты работы вызванного обработчика печатаем в стандарнтый вывод
8. Посетитель видит в адресной строке /form_action.html
9. А на экране результаты комбинированной работы /missing.html, который печатал что-то свое + использовал результаты работы /handle_all_site_forms.html?var1=value1&var2=value2
Впрочем, такой URL, как /form_action.html, нам индексировать и не надо. Зачем? Лучше вообще прописать в robots.txt строки:
==========================
User-Agent: *
Disallow: form_action.html
Реально полезное применение обработки 404 через /missing.html несколько другое ... Вот Вам пример: есть большой сайт, контент которого удобно делать в Dreamweaver. А еще (будьте внимательны!) хочется сделать страницы сайта высокорелевантными. Страничек у нас много, тематика обширная, поэтому охота для каждой страницы иметь свои META, и в текст добавить еще ключевых слов (в теги h, b, strong и т.п.).
Возможный вариант следующий:
1. Делаем сайт в Dreamweaver, всем файлам даем расширение .htm
2. index.html в корень сайта либо не кладем, либо он и есть обработчик
3. Договоримся на том, что /index.html нет, а обработчик называется /missing.html
4. Получаем в /missing.html $REQUEST_URI
5. Отрезаем от нее последний символ. $raw_content_file = substr($REQUEST_URI,0,-1)
6. Берем с помощью join('',file()) содержимое реально существующего файла контента: $raw_content = join('',file($raw_content_file))
7. Мы получили в строке содержимое реально лежащего на сервере файла с контентом.
8. Для начала, чтобы наша схема наверняка хорошо работала, заменим ВНУТРИ этой строки все .htm на .html $raw_content = str_replace('.htm','.html',$raw_content); ПРИМЕЧАНИЕ: все возможные пути обхода глюков из-за того, что .htm встречается в самом тексте (не внутри кода) позвольте мне здесь не рассматривать. Проблема - решаемая.
9. Теперь у нас имеется строка с контентом, в которой все ссылки заменены с .htm на .html
10. Оппаньки!!! А ведь на самом деле с этой строкой можно делать что попало, прежде чем передать пользователю!
11. $s = make_relevant_title($raw_content);
12. $s = make_relevant_description($s);
13. $s = optimize_keyword_set($s);
14. $s = optimize_content($);
15. $s = make_this_page_even_MORE_relevant($s);
16.
==================
Header("HTTP/1.0 200 OK");
Header("Last-Modified: ".gmdate("D, M d Y H:i:s",filemtime('missing.html')." GMT");
17. print $s;
18. Уфффф..... упарились... а если серьезно, то такой процессинг файла перед выводом занимает не так уж и много времени в смысле ресурсов сервера
19. Я честная статическая страница!!!!! Ну немножко релевантность повышена, ну и что? Это случайно!!!! Я же не скрипт!! (web-страница /page.html)
20. Расширить и дополнить методику по вкусу. You've got the idea
Yandex в последнее время постоянно "колбасит", потому что вес ссылочного ранжирования "прыгает". Видимо, товарищи подбирают параметры (весовые коэффициенты). И я так понимаю, что они их в конце концов таки подберут. Перед Rambler у них есть 3 огромных преимущества:
1. Скорость переиндексации. Пока Вы, уважаемый Rambler, будете по полгоду и более переиндексировать сайты, релевантности у Вас не будет все равно.
2. Морфология русского языка. Без комментариев.
3. Yandex все время что-то делает в отношении улучшения поиска. Им можно простить по большому счету "дерганья" алгоритма ранжирования, потому что если взять какую-либо тематическую категорию, и посмотреть интегральную статистику переходов, то в итоге все довольно быстро (2-4 недели) усредняется. А еще можно немножко подумать головой и сделать свой сайт таким, чтобы он хорошо себя чувствовал и при малом весе ссылок, и при большом.
А поиск Ramblerа ... как был поиском Ramblerа , так и остался. В силу низкой динамики обновляемости базы подвержен "исследованиям" и "оптимизации" страниц индексируемых сайтов.
То есть если найдена какая-либо слабинка в ранжировании, то можно спокойно, не торопясь, сделать страниц 50-100 с ... эээ ... "требуемыми особенностями" (даже не спамом, что самое смешное). Через 2-3 месяца оно проиндексируется, а потом можно еще полгода пожинать плоды.
На фоне того факта, что через Rambler идет много "коммерческих" запросов (люди ищут товар, за который готовы заплатить деньги), даже больше, чем через Yandex, сохранение текущей ситуации представляется еще более странным. Мягко говоря.
P.S. Кстати о птицах. Вот, скажем, если бы я подбирал весовые коэффициенты ссылочного ранжирования и обычного. И, допустим, я бы их подобрал. Оптимальные. Даже после этого все равно хорошо ... эээ ... немного их "трясти". Примерно раз в неделю, просто чтобы дезориентировать людей, анализирующих результаты поиска.
Обработка ошибки 404 - именно для приведения URL к "нормальному" (без знаков ?) виду, и для прописывания даты в заголовке HTTP.
Как показывает практика, такие тонкие признаки динамической страницы, как заголовки HTTP X-Powered-By, отсутствие поля Content-Length, не влияют на поисковики абсолютно. Точно так же, как и строка Server (которая вообще одинакова для всех документов, берущихся с сервера). В общем, их (поисковые системы) можно понять.
Допустим, на каком-либо большом сервере целиком, указано, что .html и .htm - парсятся PHP. Тогда нет вообще никакой возможности извне отличить страницы со вставками PHP от просто статических страниц. Которые при этом тоже проходят через парсер, но результат работы парсера совпадает с исходным скриптом.
То есть идея очень проста - поисковики не обращают внимания на эти поля и, скорее всего, не будут обращать, потому что они не являются достоверным признаком того, статическая это страница или динамическая.
Во внимание принимаются только явные ("ярко выраженные") признаки: наличие "?" в URL и поле Last-Modified в заголовке HTTP.
Кроме того, есть предположение (но это уже действительно просто предположение), что никакого влияния не имеет и расширение файла тоже.
Таким образом, если (на всякий случай ) сделать у документов сайта расширение .html, и обрабатывать ошибку 404, прописывая при этом код возврата "HTTP/1.1 200 ОК", и правильную дату Last-Modified, то поисковики должны индексировать такой сайт безо всякой "дискриминации". Что, в общем замечательно подтверждается на практике.
Что же касается POST-переменных, то они действительно "теряются" ... если не принять мер. Дело в том, что POST-переменные передаются в обработчик 404 ошибки, и их просто нужно самостоятельно передать "далее по цепочке". В качестве простейшей (применяемой мной) меры служит кусок кода, который работает внутри обработкика 404 ошибки, и просматривает содержимое HTTP_POST_VARS[], после чего просто добавляет их значения в виде GET-переменных в URL вызываемого скрипта, предварительно пройдясь по ним функцией rawurlencode().
Сынкс. Доброе слово и кошке приятно
Угу. Только с небольшими дополнениями и изменениями - "новый" Rambler alt учитывает. И в результатах поиска показывает.
Что характерно, эти пропорции очень хорошо соответствуют числу переходов по ссылкам из поисковых систем на "средний коммерческий сайт". IMHO
Я тот факт, что пропорция именно такая, подозревал и раньше, но дополнительное подтверждение увидеть все равно приятно!
P.S. Понятие "средний коммерческий сайт" - аналогично понятию "средний американец"
Как не индексируются? Если сделать у страницы Plain URL, то есть без знаков вопроса, и с расширением, для верности, .html, и прописать поле Last-Modified в заголовке HTTP, то куда он денется? Такая страница для внешнего мира будет неотличима от статического .html-документа... ну почти неотличима.
Кстати, был такой топик: про индексацию динамических страниц. Там и код записи Last-Modified есть
Проще всего перевести хостинг сайта к провайдеру, у которого сервис локальной искалки Yandex входит в комплект. Zenon, например. http://www.aha.ru
P.S. Это не реклама Зенона. Просто одна из компаний, для которой делал и сейчас поддерживаю сайт, упорно держит его на своем сервере и не хочет переходить к нормальному хостеру. А сайт у нее (компании) здоровенный, и без хорошей локальной искалки просто абзац. Сейчас вместо поиска стоит примитивнейший PHP-скрипт общим размером 5454 байта (включая все пробелы). Такая вот, извиняюсь, фигня. Он правда, даже "поисковую базу" делает, но, в общем, сами понимаете, уважаемые... Свой более умный скрипт писать не буду принципиально.
