SEO на MODX: возможности и настройка

MODX Revolution — редкая CMS, где SEO-специалист не борется с системой, а получает от неё ровно то, что попросит. Здесь нет навязанной разметки, нет «магии ядра», которая подставит в код неожиданный div, нет плагина, дописывающего в title лишний хвост. Шаблон — чистый HTML, который вы пишете сами, до последнего символа. Обратная сторона той же медали: MODX из коробки не делает ничего. Ни ЧПУ, ни sitemap, ни canonical, ни robots.txt — всё это придётся включить и настроить руками. В этой статье разбираем, как выжать из MODX максимум и не наступить на грабли, о которые спотыкается большинство проектов, а если задача горит — SEO-продвижение мы возьмём на себя целиком.

Почему MODX объективно удобен для SEO

Разговор о SEO на любой CMS сводится к одному вопросу: сколько усилий нужно, чтобы получить на выходе тот HTML, который вы задумали. На большинстве систем ответ неприятный. Движок отдаёт свою разметку, тема добавляет свою, плагины — свою, и SEO-специалист неделями воюет с чужим кодом, вычищая мусорные обёртки, лишние h1 и хлебные крошки, которые размечены не тем типом.

MODX устроен принципиально иначе. Шаблон в MODX — это просто HTML-документ, в который вы расставляете плейсхолдеры вида SEO на MODX: возможности и настройка или вызовы сниппетов . Всё, что не является плейсхолдером, отдаётся браузеру и роботу байт в байт. Нет темы, которая решает за вас. Нет ядра, которое подмешивает свои скрипты. Если в исходном коде страницы появился лишний тег — его туда положили вы, и вы знаете, где именно.

Практический смысл этого простой. Когда нужно вынести критический CSS в head, вы просто выносите его в head. Когда нужно, чтобы h1 был ровно один и стоял до навигации, вы так и верстаете. Когда нужна микроразметка Schema.org на карточке товара, вы пишете JSON-LD прямо в шаблоне и подставляете в него нужные поля — без плагина-прослойки, который умеет только пять предустановленных типов. Задачи внутренней оптимизации сайта, которые на других системах требуют переопределения шаблонов ядра, здесь решаются правкой одного файла в админке.

Вторая сильная сторона — модель данных. Любому ресурсу можно добавить произвольное количество TV-полей (Template Variables) любого типа: текст, textarea, чекбокс, список, изображение, набор изображений. Это значит, что структура данных проектируется под семантику, а не под ограничения CMS. Нужны отдельные поля под title, description, canonical, приоритет в sitemap, флаг noindex, региональная привязка — заводите шесть TV и получаете полный контроль.

ЧПУ: включение и типичные ошибки

Из коробки MODX отдаёт адреса вида site.ru/index.php?id=42. Такой URL индексируется, но не несёт ключей, не читается человеком и провоцирует дубли: одна и та же страница доступна и по id, и по алиасу. Как устроены нормальные адреса и почему они важны, подробно разобрано в материале про ЧПУ и человекопонятные URL; здесь — конкретика по MODX.

Три системные настройки, которые всё решают

ЧПУ в MODX включаются в разделе «Система → Настройки системы». Ключевых параметра три, и работают они только вместе.

Отдельная ловушка — use_alias_path. Если он выключен, все ресурсы живут в корне: /kupit-divan/ вместо /katalog/divany/kupit-divan/. Для маленького сайта это терпимо, для каталога — катастрофа, потому что URL перестаёт отражать структуру сайта, а поисковик теряет сигнал о вложенности разделов. Включать эту настройку на живом проекте с трафиком нельзя без подготовки: все адреса поменяются разом, и без карты 301-редиректов вы обнулите позиции. Порядок действий — сначала выгрузка текущих URL, потом карта соответствий, потом переключение и одновременная заливка 301-редиректов.

Транслитерация: обязательный дополнительный компонент

Русские заголовки MODX по умолчанию превращает в алиасы с кириллицей или обрезает их. Нужен компонент транслитерации — в экосистеме это translit (плагин, ставится из репозитория) либо встроенные средства современных сборок. После установки в настройке friendly_alias_translit выбирается схема транслитерации (для русского — russian). Проверка простая: создайте ресурс «Купить диван в Москве» и убедитесь, что алиас стал kupit-divan-v-moskve, а не набором процентов от URL-кодирования кириллицы.

Правила в .htaccess

Одних настроек мало: веб-сервер должен понимать, что запрос к /uslugi/seo/ нужно передать в index.php. В корне MODX лежит файл ht.access — его переименовывают в .htaccess. Внутри раскомментируйте RewriteBase (если сайт в подпапке), задайте канонический хост — с www или без — и принудительный HTTPS. Именно здесь склеивается зеркало: правило должно быть одно, отдавать 301 и вести на выбранную версию хоста и протокола. Как не потерять позиции при переходе на защищённый протокол — в разборе HTTPS и SEO.

Метатеги: TV-поля вместо SEO-модуля

Здесь MODX расходится с логикой WordPress и Битрикса. Не нужно искать «тот самый SEO-плагин» — правильнее спроектировать поля самому. Стандартная схема, которую мы разворачиваем на проектах.

Набор TV-полей

• seo_title (text) — title страницы. Отдельно от pagetitle, потому что H1 и title решают разные задачи и почти никогда не должны совпадать дословно.
• seo_description (textarea) — description для сниппета.
• canonical_url (text) — принудительный canonical для страниц фильтров и пагинации.
• noindex (checkbox) — флаг закрытия страницы от индексации.
• h1 (text) — заголовок первого уровня, если он отличается от pagetitle в меню.

Ключевая механика — фолбэк через фильтры вывода. Заполнять seo_title на тысяче карточек вручную никто не будет, поэтому в шаблоне пишется конструкция с подстановкой значения по умолчанию: если TV пустое, берётся pagetitle плюс шаблонный хвост с названием компании и городом. В синтаксисе MODX это модификатор :default= или :is=. Так вы получаете гарантированно непустой уникальный title на каждой странице, а руками правите только приоритетные посадочные. Как формулировать сами теги, чтобы они собирали клики, — в статье про title и description.

Что даёт pdoTools

pdoTools — не «плагин для SEO», а набор сниппетов, заменяющих штатные getResources, Wayfinder и Breadcrumbs, работающих в разы быстрее за счёт прямых запросов через xPDO вместо перебора объектов. Для SEO важны конкретные компоненты пакета:

Отдельно стоит pdoPage — пагинация. Он умеет отдавать корректные ссылки постраничной навигации и параметр страницы в URL, что критично для правильной обработки листингов роботом. Механика настройки пагинации без потери индексации разобрана в материале про пагинацию и SEO.

Sitemap.xml на MODX без костылей

Карта сайта в MODX делается за пять минут и почти никогда не делается правильно. Схема такая: создаётся новый ресурс с алиасом sitemap.xml, тип содержимого переключается на XML, шаблон — пустой, галка «Использовать HTML-редактор» снимается, «Показывать в меню» снимается. В поле содержимого — вызов pdoSitemap с параметрами.

Важный нюанс с lastmod. pdoSitemap по умолчанию берёт дату editedon ресурса. Если у вас работает автоматическая правка ресурсов скриптом (пересчёт остатков, импорт цен), lastmod будет обновляться на всём сайте каждую ночь. Робот быстро перестанет доверять этому сигналу. Решение — либо отключить вывод lastmod, либо привязать его к отдельному TV, которое меняется только при реальной правке контента. Общие принципы — в руководстве по sitemap.xml, а настройка директив — в инструкции по robots.txt. Кстати, robots.txt в MODX тоже удобно делать ресурсом с типом содержимого text/plain — тогда его правят контент-менеджеры из админки, а не по FTP.

Кэш и скорость: где MODX теряет секунды

MODX быстр, пока вы не сломали ему кэш. И ломают его почти все. Разберём механику.

Два уровня кэширования

Первый уровень — кэш ресурса. При первом запросе MODX собирает страницу и кладёт готовый HTML в файловый кэш. Все последующие запросы отдаются из файла почти без обращений к базе. Второй уровень — кэш вызовов. Каждый тег в шаблоне может быть кэшируемым или нет. Разница в одном символе: кэшируется и попадает в готовый HTML страницы, с восклицательным знаком выполняется при каждом запросе заново.

Восклицательный знак — самый дорогой символ в MODX. Один некэшируемый pdoResources с выборкой на 500 товаров превращает страницу, отдававшуюся за 40 мс из кэша, в страницу с 300 мс на запросы к базе. Достаточно поставить его на меню в общем шаблоне — и весь сайт разом теряет кэш ресурса, потому что страница с некэшируемыми вызовами всё равно требует прохода через парсер.

Правило: некэшируемым делается только то, что физически зависит от пользователя или запроса. Всё остальное — кэшируется. Если персональный блок в общем шаблоне один (корзина в шапке), правильное решение — вынести его в отдельный AJAX-запрос и оставить весь шаблон кэшируемым. Разница на живых проектах — кратная, и она напрямую отражается на Core Web Vitals, в первую очередь на TTFB и LCP.

Дополнительные рычаги производительности

• Отключить cache_disabled в проде. Настройка cache_disabled должна быть в «Нет». Звучит очевидно, но на половине аудитов мы находим сайты, где кэш выключили при отладке и забыли включить.
• Сжатие ресурсов. Настройки compress_css и compress_js объединяют и минифицируют файлы, подключённые через регистрацию скриптов. Работает только для того, что подключено штатно, а не хардкодом в шаблоне.
• Кэш парсера. Настройка cache_scripts кэширует скомпилированные сниппеты — включать обязательно.
• Chunk вместо файла. Каждый вызов сниппета — это подключение файла. На странице с полусотней мелких вызовов накладные расходы заметны; выносите повторяющуюся статику в чанки.
• Изображения. MODX не оптимизирует картинки сам. Нужен pThumb или ImagePlus для ресайза и WebP на лету — механика описана в разборе оптимизации изображений.

Отдельно про хостинг. MODX чувствителен к версии PHP и к дисковой подсистеме, потому что кэш файловый. На дешёвом shared-хостинге с медленным диском вы не увидите обещанной скорости даже при идеальном кэше. Связь сервера с позициями разобрана в материале про хостинг и SEO, а общие рычаги ускорения — в статье про скорость загрузки сайта.

Дубли и canonical: где MODX плодит копии

Гибкость MODX имеет цену: система разрешает открыть один ресурс десятком способов и не запрещает это по умолчанию. Типовые источники дублей на MODX-проекте:

• Доступность по id. При включённых ЧПУ страница часто остаётся доступна и по index.php?id=42. Лечится настройкой friendly_urls_strict и правилом в .htaccess.
• Главная по двум адресам. site.ru/ и site.ru/index.php — классика. Закрывается 301-редиректом в .htaccess.
• Слеш и его отсутствие. Определитесь с container_suffix и приведите всё к одному виду редиректом. Смешение /uslugi и /uslugi/ — гарантированные дубли.
• Регистр. /Uslugi/ и /uslugi/ на Linux-сервере — две разные страницы. friendly_urls_strict отдаёт на второй вариант 404 вместо копии.
• Фильтры и сортировки. Параметры GET порождают бесконечные комбинации URL. Каждая такая страница должна иметь canonical на базовую категорию — либо, если фильтр коммерчески значим, становиться полноценной посадочной с уникальным title.
• Пагинация. Страницы 2, 3, 4 не должны быть копиями первой ни по title, ни по canonical.

Canonical в MODX прописывается в шаблоне head одной строкой: берётся TV canonical_url, а при его пустоте фолбэком подставляется полный URL текущего ресурса через https://seo-masters.ru/blog/seo-na-modx. Это даёт корректный canonical на каждой странице без единого плагина. Полная механика — в разборе canonical и дублей страниц, а специфика фильтров каталога — в материале про фасетную навигацию.

На MODX не бывает «неожиданных» дублей. Каждый дубль на MODX-сайте — это строчка, которую кто-то не написал в .htaccess или в шаблоне. Хорошая новость: значит, каждый из них закрывается за один вечер.

Мультирегиональность: контексты против папок

MODX — одна из немногих CMS, где мультирегиональность решается архитектурно, а не костылём. Инструмент называется контексты. Контекст — это изолированное пространство со своим деревом ресурсов и, что важнее, со своим набором системных настроек: base_url, site_url, site_start, cultureKey. Фактически один экземпляр MODX обслуживает несколько независимых сайтов из одной админки.

Схема с поддоменами на контекстах

Классика для регионального продвижения: msk.site.ru, spb.site.ru, ekb.site.ru. Каждый поддомен — отдельный контекст со своим site_url и своим деревом. Роутинг настраивается через сниппет-обработчик в правилах контекста, который смотрит на HTTP_HOST и переключает контекст. Плюсы очевидны: полная изоляция контента, свои цены и телефоны, независимая привязка региона в Яндекс Вебмастере, отдельная внутренняя перелинковка. Минус — контент нужно наполнять для каждого региона, а на десяти поддоменах с одинаковыми текстами вы получите не рост, а региональные дубли.

Схема с папками

Альтернатива — /msk/, /spb/ внутри одного домена. Проще в реализации (обычные контейнеры в дереве), весь ссылочный вес копится на одном хосте, не нужно возиться с SSL для поддоменов. Минус — привязка региона в Вебмастере на уровне папок работает хуже, чем на уровне поддомена. Что выбрать под конкретный бизнес — подробно в материале про региональное SEO.

Для многоязычных проектов контексты дают ещё один бонус: в каждом задаётся cultureKey, а hreflang собирается в шаблоне перебором контекстов. Правило неизменно: hreflang должен быть взаимным (каждая версия ссылается на все остальные и на себя) и содержать x-default.

Чек-лист настройки MODX под SEO

Последовательность, по которой мы принимаем MODX-проект в работу. Порядок не случаен: каждый следующий пункт опирается на предыдущий.

Минусы MODX, о которых честно

Было бы нечестно закончить на комплиментах. У MODX есть реальные ограничения, и их нужно знать до выбора платформы.

Порог входа. На MODX нельзя посадить контент-менеджера без обучения и надеяться, что он не сломает шаблон. Здесь нет визуального конструктора страниц уровня Tilda — и это осознанный компромисс, о котором мы пишем в сравнении SEO на Tilda. Проекту на MODX постоянно нужен разработчик, который понимает синтаксис тегов и логику кэша.

Экосистема меньше. Компонентов в разы меньше, чем плагинов у WordPress. Часть популярных решений поддерживается силами энтузиастов и обновляется нерегулярно. Если нужен модуль под редкую задачу, скорее всего, его придётся писать. Сравнение подходов — в материалах про SEO на WordPress и SEO на 1С-Битрикс.

Всё нужно делать руками. То, что на других CMS ставится галочкой, здесь пишется в шаблоне. Это плюс для качества и минус для сроков. Стартовые сроки настройки MODX-проекта выше, зато техдолга на выходе меньше.

Кэш требует дисциплины. Один неаккуратный восклицательный знак разработчика — и производительность падает без единой ошибки в логах. Проблема не диагностируется сама: сайт просто медленный.

Вывод простой. MODX — отличный выбор для корпоративных сайтов, каталогов услуг, проектов с нестандартной структурой данных и для тех, кто готов вкладываться в качество технической базы. Он плохой выбор для проекта без бюджета на разработку, потому что MODX не прощает «сделаем как-нибудь, потом поправим». Если сайт только проектируется, обсудите платформу на этапе создания сайта: правильно выбранная CMS экономит месяцы. Примеры MODX-проектов, которые мы вывели в ТОП, есть в портфолио, а пока техническая база настраивается и сайт ждёт переиндексации, трафик разумно подстраховать контекстной рекламой.

Частые вопросы