Зачем? Яндекс лучше индексит. Как бы там кто не говорил что яндекс отлично индексит скрипты, все же у него есть некая иерархия. Т.е. возьмем в пример 3 адреса

1) http://www.site.ru/news/last/best/1.html
2) http://www.site.ru/news/1.html
3) http://www.site.ru/?modelu=news&id=1

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

Все это лишь догадки, но основанные на практике. ЧПУ создается для поситителей сайта. Это действительно удобно. Возмем 2 примера:

1) ЧПУ форума античата - http://forum.antichat.ru/threadnav9049-2-10.html
2) ЧПУ старого сайта hp - http://www.hp.ru/printer/laserjet/1000/

Первое ЧПУ не несет никакой помощь пользователю, второе, как мы видим, может играть роль новигационного меню. Т.е. зная тип и модель принтера можно легко попасть сразу на нужную страницу, да и потом если ты кладешь эту страницу в звкладки ты сразу понимаешь что на ней, когда листаешь закладки через пол года да и в конце концов такой адрес легко запомнить.

Т.е. лино я всеми руками ЗА ЧПУ но за грамотное ЧПУ!
Но с другой стороны я против ЧПУ. Рассмотрим конкретный пример. С чем я столкнулся:

http://newz.nnm.ru/windows_vista/29....windows_vista/

Разбираем адрес. newz.nnm.ru - раздел новостей на NoNaMe, затем имя дока (windows_vista), потом дата и название новости (xbox_360_i_windows_vista). С одной стророны пользователю удобно, он может убрать лишнее и попасть в док windows_vista сразу, минуя всякие клики по сайту, т.е. на http://newz.nnm.ru/windows_vista/. Но с точки зрения организации БД это плохо. Как мы видим инициализация новости идет по ключу "xbox_360_i_windows_vista", т.е. это строковая переменная. Что это значит? Это значит что я не могу повесить на нее кластерный индекс по нескольким причинам:

1) Заголовок может достигать 255 символов (в MySQL и 8к в MSSQL) а значит ветка кластерного индекса будет весить совсем не слабо и суть кластерного индекса проподает, так как обрабатываться он будет так же долго.
2) При связка с другими таблицами (комменты, рейтинг итп) придется использовать опять же не уникальный номер, а заголовок, т.е. опять символьный тип данных. А мы знаем что под сравнение данных выделяется столько же места в ячейке памяти, сколько могут занимать эти данные. Т.е. в нашем случае 255 байт (исключением является сравнения типа IS NULL, под них выделяется 1 бит в памяти).
3) Для мнимой оптимизации опять же этот инекс нужно кластеризовать, но это приведет лишь к существенному увеличению объема индекса

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

Т.е. мы пришли к выводу что использование правильного ЧПУ приводит к торможению сервера, а использование неправильного ЧПУ уже не ЧПУ, т.е. не ЧеловеческиПонятныйУрл. http://forum.antichat.ru/threadnav9049-2-10.html, это не ЧПУ, хоть убейте, он мне не понятен =))) Вот такие пироги...