Помогите выбрать структуру URL для сайта

Мучаюсь выбором формата URL для сайта.

Сайт имеет структуру тематических блогов (как на хабрахабре) - есть блоги, в них посты.

Итак, есть блог, к примеру Новости (news). В нем есть пост у которого помимо текста есть заголовок, теги и дата, которые можно использовать как часть URL. Это рождает массу возможных вариантов и я в них запутался.. Постараюсь описать все разумные варианты, а вы, пожалуйста, помогите определиться.

Пост, к примеру, такой: "Apple обновила iMac", к нему, соответственно, прописаны теги "Apple" и "iMac". Пост получает ID=700 в базе данных.

Вариант 1. Логичный.

http://example.com/blog/news/700/

Плюсы: Сразу видно, куда ведет адрес. URL можно еще сократить, выкинув "blog".

Минусы: Не вижу.

Вариант 2. Простой.

http://example.com/post/700/

Плюсы: Простота. Теоретический прирост производительности, особенно на самописных движках (не нужен лишний запрос к базе данных, чтобы проверить пермалинк к блогу)

Минусы: Непонятно, на какую тему окажется пост. Парсеры контента будут счастливы от таких урлов.

Вариант 3. Компактный.

http://example.com/2BC/

Здесь ID поста закодирован в шестнадцатеричной системе. Можно кодировать его, используя все буквы латинского алфавита. Это приведет к тому, что даже пост с ID 1000000 будет закодирован всего 4-5 символами (как в сокращалках URL).

Плюсы: Хорошо для твиттера. Всё :)

Минусы: Непонятный, нелогичный. Слишком короткий урл занимает меньше места на экране и, как следствие, теоретически, слишком короткий URL менее заметен и кликабелен.

Вариант 4. SEOшный, классический.

http://example.com/blog/news/apple-obnovila-imac/

Плюсы: По URL в точности понятно, куда ты попадешь.

Минусы: Транслит выглядит отвратительно. Отвратительно! Здесь еще короткий, удачный заголовок. Большинство заголовков будет длиннее, со знаками препинания. Все это ужасно транслитерируется и выглядит кошмарно.. Смотришь в логи веб-сервера, а там все засрано этим транслитом :)

Вариант 4. В меру SEOшный.

http://example.com/blog/news/700-apple-imac/

Здесь мы игнорируем кириллицу в заголовке. А чтобы обеспечить уникальность URL дабавляем ID поста.

Есть еще один вариант, который мне оень нравится — брать текстовую часть не из заголовка, а из тегов к посту. Во многих случаях это будет выгоднее - по URL всегда будет видно этакий конспектик, о чем конкретно будет пост. Ведь заголок может быть без ключевых слов, например для этого поста он мог быть таким: «Джобс показал новый компьютер». Используя же теги поста, как часть URL мы всегда получаем несколько ключевых слов в адресе.

Плюсы: По URL в точности понятно, куда ты попадешь.

Минусы: Все это чуточку неявно.

Вариант 5. SEOшный, ручной.

http://example.com/blog/news/new-apple-imac/

Здесь при написании поста автор сам пишет пермалинк. Вариант идеален для авторских блогов и очень хорош для всех сайтов, где контент пишется профессионально, редакторами.

Плюсы: URL прекрасен. Он идеален :)

Минусы: Неподходит для user-generated content. Неподходит мне :(

Вариант 6. SEOшный, патриотический.

http://example.com/blog/news/Apple обновила iMac/

Зажмуриваемся и пробуем использовать кириллицу в адресе.

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

Минусы: С таким адресом мы постоянно будем огребать кучу проблем. Начиная от того, что где-то это просто может не работать и заканчивая тем, что при вставке ссылок куда-нибудь в ЖЖ, такой URL может не распознаться парсером.

Вариант 7. Все в корне.

http://example.com/apple-obnovila-imac/

Время от времени возникают предположения, что ПС людят страницы, расположенные ближе к корню сайта чуть больше, чем задвинутые на дальние уровни (3-5 слэшей)

Плюсы: URL в меру красив. Ничего лишнего.

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

Вариант 8. С датой.

http://example.com/2010/07/28/apple-obnovila-imac/

Очень популярный вариант. Особенно раньше и особенно в блогах - почти везде были такие УРЛы.. Почему - пойди пойми.

Плюсы: Не вижу плюсов. Разве что легко можно ввести любую дату и увидеть все посты за этот день/месяц/год.. Но кому это надо?..

Минусы: Блок с цифрами в УРЛе выглядит инородно, он визуально разделяет домен от заголовка - фи.. Ну и плюс, люди любят все новое. А увидев в серпе URL с датой, скажем годичной давности, могут пройти мимо.