Формирование структуры URL адреса задача в некотором плане больше творческая, нежели техническая. Но даже если и так, то все равно - на первое место надо ставить логику, а не свою бурную фантазию. Ниже мое общее представление о том, какая же структура адресов является правильной.

Кстати, насчет терминов. В рунете принято название "ЧПУ", человекопонятный урл. Весьма забавно получилось - термин, который должен описывать процедуру грамотного составления URL, сам по себе является тем еще режущим глаз жаргонизмом. В остальном же интернете общепринятое название это SEF, search engine friendly. Т. е. о людях (или о все тех же человеках) ни слова. Главное, чтобы фрэндли для поисковых систем.

Ну и раз разговор уже зашел о поисковых системах, то...

То поисковым системам совершенно без разницы на URL адрес (в том числе и на вхождение ключа в домен). Ну не совсем, конечно, без разницы (в Яндексе год-два назад одно вхождение слова в адрес страницы приравнивалось по весу к одному вхождению этого же слова в тело документа), но влияние околонулевое. Т. е. производить какие-либо манипуляции с url адресами только в угоду поисковикам как минимум бессмысленно. За сим с SEO аспектом можно закончить. И перейти к человеко-аспекту. Или к юзабилити, если другими словами.

Что требуется от урла? Краткость, понятность. Ну и эстетическая красота, куда ж без этого.

По поводу краткости. Чем короче урл, тем лучше. Идеальный сферический адрес в вакууме - это адрес вида site.com/xxxx (где xxxx некая буквенно-циферная комбинация). Все бы так, если бы требовалась одна только краткость. Но помимо краткости остается еще и понятность (ну или очевидность).

Фактически, любая дальнейшая манипуляция с url адресом - по сути жертвование минимализмом. И крайне желательно, чтобы это жертвование было обоснованным.

В первую очередь, конечно же, url должен быть стандартизирован и состоять из набора символов a-z, 0-9, а из спец. символов использоваться только "-" и "/". Никаких прописных букв, знака подчеркивания, скобок и т. д.

К слову, отдельно нужно упомянуть транслитерацию. Транслитерированный URL - это длинно, непонятно и просто не комильфо, мягко говоря. Надо использовать либо русские буквы (как на википедии, хотя для большинства случаев это явный перегиб), либо перевод на английский, либо цифры (site.com/article/123). Только что прошелся по нескольким популярным рунетовским порталам (за которыми стоят грамотные люди, мнению которых можно довериться) - нигде не используется транслитерация. Откуда это повальное увлечение адресами вида "nazvanie-publikacii-ili-kategorii" - непонятно. Но так делать нельзя.

Что по очевидности адреса - адрес должен быть предсказуемым. Из адреса должно быть понятно, где я сейчас нахожусь или куда я попаду, перейдя по ссылке. В общем, эту самую "предсказуемость" можно весьма условно разделить на общую и внутрисайтовую.

По "общей" очевидности url'а, это формирование адресов исходя из ожиданий пользователей. Т. е. страница контактов должна иметь адрес site.com/contact, страница архивов site.com/archives и т. д. Это уже устоявшиеся общепринятые адреса и отказываться от них глупо. То же самое по категориям, site.com/news и прочим. Или еще как пример - из ссылки "site.com/123" совершенно не ясно, куда она ведет, а вот по "site.com/news/123" уже понятно, что по ссылке находится страница с определенной новостью.

По внутрисайтовой иерархии урлов - если сайт имеет довольно сложную структуру, то не грех пренебречь минимализмом и целиком и полностью расписать путь (site.com/category/sub-category/smt-else/title, etc.). Но не стоит этим злоупотреблять, только если без этого действительно не обойтись, в противном случае подробную роспись адреса лучше опустить, сократив его до приемлемого минимума.

На фоне всего вышесказанного, можно встретить много примеров, как элегантной структуры адресов, так и противоречивой. Пожалуй, стоит даже привести несколько примеров.

drupal.org
drupal.org/project/modules - страница модулей, из адреса полностью понятна структура сайта и где мы находимся.
drupal.org/project/cck - конкретная страница определенного модуля, как видно, "modules" в адресе опускается, за счет чего уровень вложенности и длина адреса значительно сокращается.

nytimes.com
nytimes.com/2011/06/25/science/25trust.html?partner=rss&emc=rss - в адрес вшита дата, что и понятно, издание все-таки периодическое. Далее идет раздел и сокращенное название статьи. Все достаточно логично. Немного напрягает в конце ряд параметров (говорящих о том, что я перешел на статью из rss ридера), как на мой взгляд, это не лучший способ отслеживания потоков трафика.

boingboing.net
boingboing.net/2011/06/26/snappy-answers-to-fr.html - весьма спорное формирование адреса. Дата зашита в урле, хотя редко какие из публикуемых постов привязаны к дате. Возможно, дань происхождению - БоингБоинг начинал именно как бумажное периодическое издание, и только потом стал коллективным блогом. Интересен также и способ формирования остального адреса - берется тайтл страницы, переводится в урл и обрезается до 20 символов (в примере выше полное название поста "Snappy answers to freaky job-interview questions"). Хоть такие адреса и выглядят немного кривовато, но шаг вполне оправданный - редакторов нет, блог коллективный, заниматься составлением красивого адреса никто не будет. Пусть уж будет так, чем адрес плавающей длины (если в качестве адреса использовать весь тайтл).

mattcutts.com
mattcutts.com/blog/search-engineering-at-google/ - тут все понятно, адрес берется из тайтла. Характерно другое - в адресах конечных материалов в личных блогах очень редко можно увидеть указание категории, т. е. используется форма site.com/post-title, а не site.com/category/post-title. Оно и понятно почему - на личном блоге не так уж и много материалов, чтобы в них можно было бы запутаться. Плюс если кто-то и читает блог, то обычно читает все публикации, а не принадлежащие какому-то определенному разделу, поэтому использование адреса категории в адресе материала хоть и отображает логическую вложенность, но является по сути бессмысленным, поэтому и опускается.

Обычной практикой является и абстрагирование от внутренней древовидной структуры сайта (бывает полезным в том числе и тогда, когда материал может принадлежать сразу к нескольким рубрикам, что затрудняет использование вложенного урла виде site.com/category/page-title), например:
imdb.com/title/tt0172493/ - конечная страница с описанием фильма.
youtube.com/watch?v=lCDxvVRGias - конечная страница с видео.
armorgames.com/play/6137 - конечная страница с игрой.

В целом, каждая часть url адреса должна быть обоснована. Если от какой-то части адреса можно безболезненно отказаться - от нее нужно отказаться. И естественно, в любых правилах есть исключения, так или иначе оправданные.

Чисто технически - www.site.com и site.com являются совершенно разными доменами/сайтами. Как и forum.site.com и site.com. Сам префикс "wwww" пошел еще с тех времен, когда интернет хосты было принято именовать по функциям, ими выполняемыми, как то www.site.com, ftp.site.com, nntp.site.com и т. д.

Сейчас же домены www.site.com и site.com общепринято делать зеркалами. Вопрос в том, какой домен сделать главным зеркалом, а на какой поставить 301-ый редирект? Или же сделать оба домена одинаково доступными?

Прежде всего я решил проверить, как обстоят с этим дела у популярных ресурсов, где выбор главного зеркала явно был обоснованным, а не случайным. Собрал список из 50-ти первых пришедших в голову сайтов, и проверил у каждого из них ответ сервера с префиксом www и без.

Результаты оказались весьма и весьма неоднозначными.

#	URL	Ответ сервера с www	Ответ сервера без www
1	youtube.com	200	301
2	wikipedia.org	200	301
3	twitter.com	301	200
4	microsoft.com	200	301
5	samsung.com	301	200
6	nokia.com	200	301
7	adobe.com	200	301
8	ebay.com	200	301
9	amazon.com	200	301
10	bbc.co.uk	200	301
11	comedycentral.com	200	301
12	cartoonnetwork.com	200	301
13	mtv.com	200	301
14	opera.com	200	301
15	thepiratebay.org	301	200
16	imdb.com	200	301
17	jquery.com	301	200
18	prototypejs.org	200	200
19	drupal.org	301	200
20	joomla.org	200	301
21	wordpress.org	301	200
22	alexa.com	200	301
23	php.net	200	200
24	mysql.com	200	200
25	apache.org	200	200
26	ubuntu.com	200	301
27	linux.com	200	301
28	quakelive.com	200	301
29	nytimes.com	200	301
30	timeout.com	200	301
31	newsweek.com	200	301
32	digg.com	301	200
33	boingboing.net	200	200
34	slashdot.org	301	200
35	techcrunch.com	301	200
36	tutsplus.com	301	200
37	mashable.com	301	200
38	xkcd.com	200	200
39	explosm.net	200	200
40	buytaert.net	301	200
41	mattcutts.com	200	200
42	dailyblogtips.com	200	301
43	copyblogger.com	200	301
44	johnchow.com	200	301
45	problogger.net	200	301
46	shoemoney.com	200	301
47	clickbooth.com	200	200
48	copeac.com	200	200
49	affbuzz.com	200	200
50	freelancer.com	200	301
#	Всего	38	23

Как видно, единой картины нет. Хотя сайтов с использованием префикса www все-таки значительно больше. Возможно, просто сила привычки, т. к. исходя из опросов на популярных форумах, большинство вебмастеров высказываются за отказ от использования записи www.site.com как от атавизма.

Аргументов "за" и "против" использования www можно привести много. Но все равно единого мнения не существует (что и видно по таблице выше).

Лично я уже давно отказался от www, настроив на всех своих сайтах 301-ый редирект с www.site.com на site.com.

К слову, делается это просто. Достаточно только в файле .htaccess прописать

если главным зеркалом надо сделать сайт с www и

если без. Вместо example.com естественно нужно подставить свой домен.

Свой выбор я сделал не то чтобы осознанно, скорее интуитивно. Ну не вижу я особого смысла в использовании www. А если смысла нет, то и усложнять незачем. Чем проще - тем лучше. Плюс ко всему, сайты я делаю в основном на Drupal'e, а у проекта drupal.org главным зеркалом является сайт как раз без www. Что и развеяло у меня последние сомнения относительно правильности сделанного выбора.

С точки зрения оптимизаторов, наиболее целесообразно покупать ссылки, размещенные в одном блоке с контентом, до или после текста (если не брать в расчет контекстные ссылки).

Вебмастера же чаще выносят сапоссылки в отдельный блок, не желая портить внешний вид своего сайта, помещая нетематические линки (часто с бредовыми анкорами) в поле зрения посетителей.

Так или иначе, но к консенсусу интересов вебмастеров и оптимизаторов надо прийти. Я последнее время руководствуюсь следующими правилами размещения сапоссылок на своих сайтах.

Во-первых, никакого разбиения ссылок на несколько блоков, хотя ранее я был другого мнения (пост «Разносим ссылки в сапе»), но с тех пор многое изменилось. Яндекс стал умнее, обмануть его не получится, поэтому любые попытки замаскировать продажные ссылки бессмысленны. Плюс ко всему, последнее время продавать более чем по 3-4 ссылки со страницы стало неликвидно, в идеале, конечно, размещать максимум по 1-2 ссылки и не со всех страниц, доступных по уровню вложенности для продажи. Слишком велика вероятность того, что даже СДЛ вылетит из индекса с очередным АГС-ом. Да и если «прогнозируемое число внешних ссылок» на сайте слишком большое, то попасть под фильтры оптимизаторов и сеопульта будет трудно, придется демпинговать. Ну а если мы размещаем мало ссылок, то и разносить получается нечего.

Абстрагируемся от того факта, что сапоссылки – это по сути спам. Будем считать их «рекламными материалами». А реклама всяко не может размещаться в футере и сливаться с фоном. Следовательно, размещение ссылок в подвале – зло.

Где же тогда размещать сапоссылки? Обратимся к нормальным СДЛ, которые размещают текстовые ссылки не через биржи, а вручную, правда, чаще для обмена трафиком, чем для сео. А ссылки они размещают в сайдбарах, где и меню, причем по оформлению эта реклама мало чем отличается от блоков навигации (пример для блогов – блогролл).

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

К чему это я. Ссылки-то многие размещают в блоках в сайдбарах, но выводят их одним сплошным текстовым месивом, руша основную затею – преподнести сапоссылки не как спам, а как рекламу. В лучшем случае разделяют ссылки знаком «|» и другими, но от этого не легче.

Как выводится меню в блоках? Последние комментарии? Популярные материалы? Блогролл? Списком! Поэтому и сапоссылки надо выводить только и только списком. А об этом забывают если не все, то почти все.

Небольшая инструкция, как реализовать вывод ссылок sape списком. Идем в настройку нашей площадки в сапе и указываем в качестве разделителя </li><li>. Теперь вроде бы осталось только обрамить предлагаемый сапой код тегами <ul><li>код сапы</li></ul>. Но это решение «в лоб» имеет один недостаток. Если на странице, на которой установлен код сапы, еще не купили ни одной ссылки, то код <ul><li></li></ul> все равно будет выводиться. Например, если в Drupal создать блок с php кодом, то он будет отображаться только если есть хоть какая-то информация для вывода. При таком решении этой информацией будут теги открытия и закрытия списка, поэтому на всех страницах будет красоваться пустой блок «реклама» или «партнеры сайта», что, естественно, нежелательно. То же касается и WP, если мы не пользуемся плагином для сапы, а создаем блок вручную. Да и вообще, не зависимо от движка, выводить что-либо имеет смысл только тогда, когда есть что выводить, автоматической вставки в код страницы ненужного мусора, в независимости есть ли ссылки для вывода или нет, лучше избежать.

Модифицируем немного код sape:

На этом блоге у меня стоит такой код, чуток изменил, чтобы нормально работал в Drupal:

Теперь все отображается идеально, и сапоссылки более не выглядят как поисковый спам. А если еще и одобрять только тематические ссылки – то и придраться будет не к чему. Конечно, когда сайт только добавлен в сапу, то цель стоит распродать все места, но когда все места заняты, то почему бы изредка и не проводить чистку на явный мусор и нетематику, а на освободившиеся места одобрять только уже подходящие ссылки.

Стандартная форма комментирования в CMS Drupal настолько далека от идеала, что без некоторых доработок ее использование крайне нецелесообразно. Ниже распишу по пунктам, как с помощью дополнительных модулей и небольших изменений в коде привести ее в человеческий вид. Актуально для Drupal 6.x /в 5.x свои грабли, а 7.x стабильной версии пока еще нет/.

1. Разрешаем комментировать анонимным пользователям.
Управление пользователями/Разрешения/модуль comment
Здесь настраиваем права доступа для анонимусов.

2. По дефолту в форме комментирования есть всего два поля – тема комментария и сам комментарий. Добавляем поля имя, e-mail, url и убираем поле «тема»
Содержание/Типы материалов
Нажимаем «изменить» у интересующего нас типа и переходим на «Установки комментариев», где выставляем нужные опции.
Я обычно ставлю:
- Режим показа по умолчанию:
Плоский список – развёрнутый
- Порядок сортировки по умолчанию:
По дате - сначала старые
-Управление комментариями:
Не показывать
-Анонимные комментарии:
Анонимные пользователи должны указывать контактную информацию
-Поле темы комментария:
Отключено
-Просмотр комментария перед отправкой:
Необязательно
-Расположение формы отправки комментария:
Показывать ниже сообщения или комментариев

3. Капча
Встроенной капчи нет, поэтому устанавливаем модуль. Я предпочитаю математическую капчу, за нее отвечает модуль captcha. Качаем, ставим, настраиваем, переводим интерфейс/все делается в админке/.

4. Кнопка «ответить» в комментариях
Какой бы вид отображения мы бы не выбрали, плоский или древовидный, под каждым комментарием будет оставаться кнопка ответить. Чтобы ее убрать, качаем модуль flatcomments. После установки идем в Содержание/Типы материалов, переходим по «изменить» напротив интересующего нас типа материала и ставим галку напротив Do not show a reply link on comments.

5. Возвращаемся к полю «тема комментария». Хоть мы и убрали это поле, при публикации коммента она будет отображаться в виде первых слов комментария. Чтобы это исправить, открываем файл comment.tpl.php в папке с нашей темой и удаляем или закомментируем следующие строки:
<?php if ($title) echo $title; ?>

6. Для анонимусов под формой комментария будет дан выбор, какой фильтр ввода использовать, и приведена ссылка «Подробнее о форматировании».
Если первое решается через ограничение прав доступа анонимусов к изменению форматов ввода, то чтобы убрать ссылку на ф.а.к. по форматированию, придется лезть в код.
Открываем файл template.php в корне нашей темы и добавляем внизу пару строк:

7. После публикации комментария сразу за именем анонимуса всегда пишется (не проверено), даже если премодерация отключена. Чтобы эту надпись убрать, снова открываем template.php и вниз кода вставляем следующее:

8. Теперь вид информации о комментирующем приобрел такой вид «Опубликовано Гость в Вс, 2009-07-12 21:48». Красиво конечно, но хочется «Гость - 12/07/2009 в 21:48».

Для этого сначала открываем файл comment.tpl.php и заменяем <?php echo $submitted; ?> на <?php echo "$author - $date"; ?>.
Потом идем в Настройка сайта/Дата и время, выбираем Средний формат даты: Пользовательский формат и прописываем шаблон даты d/m/Y в H:i.

Вот и все. Теперь у нас человеческая форма комментирования.

PS
1. У шестого друпала очень агрессивное кэширование, поэтому чаще всего сделанные изменения вы не увидите без чистки кэша - Настройка сайта/Производительность/Очистить кеш данных.

2. Иногда вместо имени функции «phptemplate» надо вставить название шаблона/имя папки с шаблоном/. Так что если после вставки кода сайт не открывается или код не работает – заменяем phptemplate на название нашего шаблона.

3. Описанная реализация наиболее правильная, т.к. не приходится редактировать ядро и все изменения проводятся только в файлах шаблона.

При написании предыдущего поста мне понадобилась функция подсветки синтаксиса php кода, по дефолту этого нет, поэтому пришлось немного покопаться.

Ниже приведена инструкция по прикрутке подсветки синтаксиса кода в Drupal /в Друпале чаще всего все можно реализовать несколькими способами, так что описанный ниже вариант далеко не единственный для решения поставленной задачи/.

1. Качаем модуль GeSHi Filter, распаковываем, заливаем на сайт в директорию modules/, в админке сайта идем в Управление сайтом/Конструкция/Модули, ставим галку напротив GeSHi Filter, сохраняем. Активировать GeSHi node не обязательно – он создает дополнительный тип нодов исключительно для кода, что нам не требуется.

2. Теперь надо скачать библиотеки. Идем по ссылке, переходим в раздел Downloads, качаем geshi последней версии. Почему-то вчера был запрещен доступ по российский ip, в таком случае можно воспользоваться анонимайзером, что я и сделал. Далее разархивируем и заливаем папку geshi на сервер в корневую директорию установленного ранее модуля modules/geshifilter/.

3. Все установлено, можно переходить к настройке. Первым делом разрешим применение фильтров к вводимому тексту, для этого идем в раздел Управление сайтом/Настройка/Форматы ввода и жмем «настроить» напротив Full HTML где и разрешаем применение GeSHi filter.

Затем идем в настройки модуля GeSHi Filter Управление сайтом/Настройка/GeSHi Filter и, собственно, настраиваем. Поиграться здесь есть с чем, к примеру задать индивидуальные теги для применение разных стилей оформления в зависимости от того, на каком языке написаны исходники. Ниже приведу те настройки, которые сделал я.

- Снял все галки, установленный по дефолту.

- В качестве “Default highlighting mode” выбрал стиль C++, он используется для подсветки php кода на большинстве сайтов, поэтому будет попривычней, чем php-стиль.

- Значение “Default line numbering” установил в позицию “normal line numbers”, таким образом слева от кода идет нумерация строчек, можно еще выбрать, чтобы каждое 5, 10 или 20 число выделялось жирным, но это актуально лишь при цитировании больших исходников.

- Для “CSS mode for syntax highlighting” установил значение “Inline CSS style attributes”, для “Code container” значение “Use no container”. При выборе других пунктов отображение нумерации строк работать не будет.

Вот и все. Теперь при создании заметки с выбором формата ввода Full HTML весь код, заключенный в тег <code>, будет подсвечен.

PS
Также советую установить BUEditor - простой редактор текста, хорош тем, что можно самому программировать и добавлять нужные кнопки.

Пусть редко, но так или иначе все мы сталкиваемся с необходимостью создания уникального фавикона. Большинство, и я не исключение, сначала идет искать сервисы on-line создания иконок, потом, убедившись в их убогости, начинает выкачивать все подряд по запросу «редактор favicon.ico скачать». Половина скачанных программ, естественно, не работает, половина глючит. Убив на все про все часа полтора, все-таки получается нарисовать некое подобие иконки, но о том, чтобы создавать уникальные фавиконы не только для сдл, но и для всех сателлитов не может быть и речи – еще бы, столько времени тратить.

Однако практически у каждого стоит фотошоп, так почему бы не использовать его для решения этой весьма обыденной задачи? А использовать фотошоп вообще-то не только можно, но и нужно. До меня это, правда, дошло совсем недавно, но лучше поздно, чем никогда.

Ниже представлен мини F.A.Q. по созданию иконок favicon.ico средствами фотошопа.

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

1) Рисовать с нуля? Нет уж, увольте. Ищем исходник, к примеру в поиске гугла по картинкам. Имеет смысл поставить фильтр на поиск «искать в клип-артах», тогда картинки будут выдаваться достаточно хорошего качества и уже обработанные.

2) Копируем в фотошоп понравившуюся картинку. Точнее не понравившуюся, а наиболее подходящую для создание иконки. Не забываем, что разрешение фавикона – 16*16, поэтому чем проще и четче будет картинка, тем лучше. Скопировав в фотошоп, обрабатываем изображение, удаляем лишнее, делаем картинку более контрастной. В данном случае это не требуется, т.к. изображение изначально уже обработанное. Выделяем ту часть картинки, которая будет являться фавиконом, и копируем в буфер обмена (при работе со слоями, не забудьте их объединить перед копированием).

3) Создаем новый документ Файл-Новый. В параметрах создания ставим ширину и высоту по 16 пикселей. Инструментом «Лупа» увеличиваем созданный документ до максимальных размеров (1600%), чтобы было легче работать. Далее вставляем скопированную ранее часть картинки (Редактировать-Вставить). Скорее всего, после этого действия на новосозданном документе вы ничего не увидите. Оно и понятно – документ у нас 16*16 пикселей, а вставляемая картинка намного больше. Поэтому идем в Редактирование-Произвольная Трансформация. После этого действия вы увидите рамку, посредством которой надо будет загнать вставленное изображение в созданный документ размером 16*16 пикселей. Затем подтверждаем применение трансформации и занимаемся редактированием полученного изображения. Дорисовываем потерянные пиксели, где-то удаляем явно лишнее, можно подправить яркость, контраст и прочее. В итоге у нас должно получится нечто похожее на картинку внизу.

4) Теперь сохраняем полученный результат. Файл-Сохранить как, вписываем название файла favicon, а расширение выбираем png. Так как расширение иконок .ico, то полученный в фотошопе .png надо конвертировать. Делается это достаточно просто. Идем в проводник, сервис, свойства папки, вид, снимаем галку напротив «скрывать расширение для зарегистрированных типов файлов»/путь написал для XP, в висте там по-другому, на память не вспомнить, но вроде как интуитивно понятно/. Ну а дальше вручную меняем расширение у нашего файла с png на ico. На вопрос винды, действительно ли вы хотите поменять расширение, отвечаем утвердительно.

5) Наш favicon.ico готов. На все ушло не больше пяти минут.

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

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

Увеличение количества страниц второго уровня чаще всего является одним из самых простых способов повышения прибыльности сайта. Но не всегда получается оптимально организовать навигацию “под сапу” без ущерба конечного пользователя. Речь идет, конечно, не о ГС, где можно хоть карту сайта расположить на главной. И не о перспективных контент проектах и разнообразных сервисах – думаю, проблема, как продать побольше ссылочек для них далеко не самая приоритетная. Вопрос о грамотном увеличении количества страниц второго уровня встает тогда, когда делается сайт для людей, источником дохода которого в основном будет продажа ссылок. Такая ситуация возникает часто. Например, когда тематика достаточно узкая, и собрать больше 100 уников в день не особо представляется возможным. Или же не конкурентная, такая как искусство/хобби, где монетизация трафика не принесет больших доходов. Может быть и обратный вариант, когда тематика выбрана конкурентная, но затраты на получение трафика в таком случае часто просто могут не окупиться.

Ну а теперь конкретика.
Способы увеличения количества страниц второго уровня:

- Делать расширенную подробную навигацию. Т.е. фактически то, что логично было бы сделать третьим уровнем, выносить на второй.

Например, если на региональном сайтике будет присутствовать такие разделы:
-Информация
-Фото
-Известные люди
то целесообразней организовать меню так
|Информация
-История
-Современность
-Статистика
|Фото
-Город
-Природа
-Достопримечательности
|Известные люди
-Литература
-Живопись
-Политика

Способ самый простой, но и наиболее непродуктивный и нежелательный в плане юзабилити. Количество страниц второго уровня таким образом можно нарастить до 40-50, больше уже трудно, меню будет занимать больше трети экрана и разобраться что где пользователю будет нелегко.

- При блоговом представлении материала делать внизу список страниц. Не только предыдущие/следующие, как стоит по дефолту на том же вордпрессе, а 1|2|3|4|5 и т.д. Ну и настроить так, чтобы показывались ссылки на все страницы, а не только первые и последние /1|2|3…100|101|102/. Плюс, если материала мало, то выводить можно не по 10 постов, а, к примеру, по пять.

- Теги. Очень удобная вещь в плане увеличения количества страниц. Можно сделать навигацию по сайту полностью теговой, или использовать как дополнение к основной. +30-100 страниц второго уровня с этого можно получить.

-Разнообразные модули – популярные записи, последние записи и т.д. Оптимально использовать те, в которых формируются статические ссылки, не изменяемые во времени /архив материалов, календарь/.

Соответственно, все вышеперечисленное нужно использовать в комплексе и исходя из целесообразности. Не стоит перегружать страницу ради пары десятков лишних страниц под продажу ссылок. Делайте изначально так, чтобы и навигация по ресурсу оставалась удобной, и потенциал заработка сайта был высоким. На первых сайтах в погоне за количеством страниц я перегружал меню, сейчас же стараюсь подходить к решению проблемы с умом. На последнем своем сайте организовал навигацию так – 5 основных ссылок на разделы, 21 ссылка на подразделы, постраничная навигация 1|2|3| внизу страницы, облако тегов, пару модулей “наиболее читаемое”… Итого ~100 страниц второго уровня без перегруженности навигации, более того, все выглядит естественно и крайне удобно для пользователя.

Поговорим о капчах. Естественно, предназначение капчи – это защита от ботов, которые становятся со временем все умней и умней. Но не стоит забывать и о посетителях. Поэтому приходится искать консенсус между стопроцентной непробиваемостью ботами и минимумом неудобств для юзверя.

Стандартные капчи популярных движков идут лесом – оллсабмиттер и прочий софт их ломает на лету.

Капчи в виде картинки с искаженными буквами не лучший вариант – и сломать их проще, ну а если пытаться сделать картинку нечитаемой для бота – то и человеку трудно будет ее воспринимать. Да и переключаться на английскую раскладку, для того чтобы ввести правильный ответ, не всем хочется.

Капчи вида “введите нижние символы с картинки” тоже не идеал –во-первых, в большинстве случаев юзверь сначала вводит все подряд, потом, когда вылезает ошибка, уже читает и вводит правильно. Да и опять таки приходится переключаться на англ раскладку. Хотя видел такого рода капчи, где нижними символами были цифрами, что значительно лучше.

Многие делают нестандартные капчи, например “введите буквы, которые вы видите, в обратном порядке”, что тоже не есть гуд. Или “напишите словом то, что видите на картинке”, ну и иногда варианты предлагают, типа “слон, дом, цветок”. Проще надо быть, проще.

Итак, подходя к концу, хотел бы сказать, какие капчи на мой взгляд являются на данный момент идеальными.

Во-первых, эта математическая капча с простым арифметическим вопросом, например 2+3=?. Как показывает опыт, боты через такие капчи не пробиваются. Плюсом также является и то, что юзверю не надо думать, что делать – все предельно ясно. И к тому же не надо переключаться на другую раскладку.

Ну и во-вторых, это ставить галочку в графу “Я не робот”, многие наверно видели эту капчу, она вроде только под вордпресс, что несомненно является минусом, хотя могу и ошибаться.