Super MODx SEO-strict +ускоряем фронтенд

Михаил задал вопрос про канонизацию урлов в MODx.
Писал ему ответ, но понял, что он слишком большой. Поэтому переписал в статью.

Поехали.
Вопрос канонизации урлов в MODx'е я изучал досконально.
I. MODx'овая система канонических урлов позволяет делать правильные автоматические редиректы на канонические урлы со всех возможных не канонических только в одном случае — это когда у ресурсов-контейнеров нету слеша на конце, а у ресурсов-неконтейнеров не установлено расширение, типа ".html".
Т.е. после всех манипуляций все урлы на сайте будут вида:

/help/5105

с начальным слешем, без ".html" и слеша на конце.

А действий не так много.
Идём в настройки и меняем следующее:
— Раздел «Дружественные URL»:
1. container_suffix «Суффикс контейнера» — делаем значение пустым;
2. friendly_urls «Использовать дружественные URL» — Да;
3. friendly_urls_strict «Строгий режим дружественных URL» — Да;
Автоматическая генерация, транслитерация, вложенные URL, дублирование во всех контекстах — устанавливаем по вкусу
— Раздел «Сайт»:
4. link_tag_scheme «Схема URL» — abs;
— Раздел «Шлюз»:
5. request_method_strict «Строгий метод запроса» — Да;

Потом идёт в «Сайт» => «Типы содержимого»:
6. HTML text/html — делаем значение пустым.

Вуаля. 6 шагов.

p.s. и удаляйте нахрен тег

<base href="blablabla">

, который modx засовывает в стандартный шаблон. Он вообще не нужен.
Зато минусов хватает — новички, не понимая основу основ, постоянно об него спотыкаются и задают вопросы в стиле «А почему у меня стили не грузятся?» тем самым забивая и без того забитое информационное пространство.
Да ещё якорные-ссылки из-за этого тега ломаются.
В общем, первым делом убирайте его из стандартного шаблона и в своих шаблонах не прописывайте.

II. Далее в каждом шаблоне внутри тега head пишем:

[[Canonical]]

Потом создаём сниппет под названием Canonical и вставляем в него следующее:

$resourceId = $modx->resource->get('id');
if (!$resourceId) { return ''; }

/** @var string|array $args */
$args = '';
if (!empty($scriptProperties['args'])) {
  $args = $scriptProperties['args'];
  if (strpos(ltrim($args), '{') === 0) {
    $args = $modx->fromJSON($args);
    $args = (is_array($args)) ? $args : '';

    foreach ($args as $k => $v) {
      if (is_string($k) && !trim($k) && is_string($v) && !trim($v)) {
        unset($args[$k]);
      }
    }
  }
}

$canonicalUrl = $modx->makeUrl($resourceId, '', $args, 'full');

return '<link rel="canonical" href="'. $canonicalUrl .'" />';

Этот сниппет может принимать один параметр args, в который можно передать строку запроса вида «qwe=asd&zxc=123» либо json-строку, пригодную для преобразования в массив и последующей его передачи в php-функцию http_build_query.

Всё, добили seo-strict канониклом.
Но и этого, в своё время мне показалось мало.

III. Конфиг для nginx'а.
Скажу сразу, что для тех, кто использует апач — мне предложить нечего, извините.
Сразу ссылка: gist.github.com/antixrist/cf12d6b49367979ef622
И сразу дисклеймер: в этом конфиге нужно заменить DOMAIN.TLD на ваш домен (в нижнем регистре, разумеется) и заменить your-backend. Кто настраивал — разберётся.

Так вот, давайте я вам расскажу что здесь и как.
Все преобразования урлов происходят с учётом nginx'ового феншуя и правильности с т.з. seo. В этом не сомневайтесь.

— Код.
Редиректим с www. домена на «без www.»

— Код.
Автоматически направляем все поддомены на основной домен. Не забудьте в dns добавить CNAME запись вида:

*	CNAME	domain.tld.

с точкой на конце.

— Код.
Прописываем индексные файлы.

— Код, код.
настраиваем обработку php-файлов.
p.s. о регулярке ^/(adminka|manager|connectors|connectors-[_A-Z-a-z-0-9]+|_build)/ будет дальше.

— Код.
Закрываем доступ к папке /core/ из вне. Я настроил так, чтобы при попытке обратиться к какому-либо файлу из этой директории, отдавалась 404, а не 403. Если вас это не устраивает, то вы можете раскомментировать вот эту строчку, закомментировав вот эту.

— Код.
Удаляем конечный index.html из урла.

— Код.
Удаляем конечный index.php из урла, отправляя его на php-обработку.

— Код.
Удаляем из урл двойные/тройные/etc слеши. Описание проблемы здесь.
Для того, чтобы это заработало, надо в секцию http добавить параметр

merge_slashes off;

Вот код.
Секция http {} находится в файле nginx.conf.

Разбираясь в проблеме, стало понятно, что nginx по умолчанию обрабатывает несколько подряд идущих слешей как один. На вход в конфиг отдельно взятого сайта nginx отдавал урл таким, как будто никаких много-слешей там и не было. Происходит это потому, что «мержит» он их уровнем выше, в секции http, в котором и находится та самая настройка merge_slashes. Поэтому и регулярки на вычленение много-слешей не отрабатывали. Выключив эту настройку — всё заработало.

— Код.
Закрываем от внешнего доступа все .htaccess/.htpasswd и им подобные файлы. Опять же, я предпочитаю вообще не показывать, что такие файлы существуют (отдавая 404), нежели подогревать интерес у всяких умников, которые видят, что файл есть, а доступа к нему нет (отдавая 403).

— Код.
Создаём в корне сайта файлы 403.html, 404.html, 50x.html и дизайним их как душе угодно. Эти файлы из браузера открыть не получится (так настроено), но при соответствующих ошибках nginx будет отдавать именно эти страницы.

Ускоряем фронтенд.
— Код.
Подключаем конфиги кеширования и прочего, ускоряющего фронтенд, из комплекта html5boilerplate.
Их я немного подправлял, поэтому выкладываю свою версию: тыц. Просто закиньте эту папку в корень вашей nginx-установки

— Код.
На эту тему написано много, не буду вдаваться в подробности. Смысл в том, что у меня на каждом сайте все изображения, имеющие отношение к оформлению, лежат в папке "i", а все скрипты, я по максимуму переношу в папку "js".
Так вот, чтобы не было блокирующей загрузки файлов фронтенда и, чтобы браузер смог распараллелить загрузку изображений, скриптов и стилей, создаём поддомены i.domain.tld и js.domain.tld, которые являются алиасами соответствующих папок основного домена (вы не забыли в dns прописать cname для всех поддоменов?).
Соответственно, в своих шаблонах пишем что-то вроде такого:

<script src="http://js.my-site.ru/scripts.js"></script>

А файл scripts.js физически у вас должен лежать в /js/scripts.js в корне сайта.
К слову сказать, с css-файлами такого делать не нужно. Их надо подключать классическим способом.

С картинками сложнее, ибо постоянно ручками прописывать в css-файлах урлы вида "i.my-site.ru/design-image.png" геморройно. Но не невозможно.
Лично у меня этим занимается gulp с compass'ом, поэтому над урлами к оформительским изображениям в css'е я не заморачиваюсь.

Ну вот вроде бы и всё.

Кстати, о регулярке ^/(adminka|manager|connectors|connectors-[_A-Z-a-z-0-9]+|_build)/.
Есть замечательная статья Правильный хостинг для MODX Revolution 2, где Василий рассказывает как настроить свой собственный хостинг. В этой статье он делится bash-скриптами для автоустановки/обновления/удаления modx-сайтов для такого вот сервера.
Так вот. Эти скрипты я тоже дописал :)

Теперь у меня при установке:
— папка core выносится за пределы папки www (так что доступ из вне физически невозможен, к тому же в админке в диспетчере и источниках файлов папку core не видно вообще, что тоже накладывает определённую степень безопасности);
— папка manager переименовывается в adminka;
— папка connectors переименовывается в connectors-blablabla-random-key;
— всё это заносится в modx-конфиг и нигде ничего не ломается.

Всё это для пущей безопасности. + для каждого сайта автоматически устанавливается вот этот вот самый nginx-конфиг, который дополнительно настраивать не нужно.
Вот скрипты:
addplace.sh, addsite.sh, remove.sh, update.sh. Не забудьте прописать свой mysql-rool-пароль в каждый из скриптов и сделать их исполняемыми:

filename.sh chmod -x

(вроде так, поправьте, пожалуйста, если я в команде ошибся).

Вот с такими вот настройками я вообще не парюсь по поводу seo-strict урлов — ибо всё отточено. Плюс конфиг ускоряющий фронтенд — делает своё дело. Фронтенд я собираю gulp'ом, конфиг к которому я тоже долго обкатывал и оттачивал. Gulp кукожит и склеивает всё, что только может — скрипты, стили, картинки, генерирует critical-css и автоматически инжектит их в шаблоны (такого практически нигде нет).
По итогу, один из моих сайтов имеет 95 баллов по Google PageSpeed (на один меньше, чем у яндекса)). Остальные в районе 90 (±10) баллов.

И раз уж тема изначально зашла про seo, то стоит добавить, что скорость загрузки фронтенда — тоже такой неплохой фактор ранжирования.