Настройка SEO-пакетов MODX: пошаговое руководство и кейсы

Настройка SEO-пакетов MODX: где ломается вывод мета-данных

Мета-данные на MODX собираются из трёх независимых источников: полей самого ресурса, TV-параметров и значений по умолчанию в шаблоне. Стоит одному звену не сработать — и в исходном коде title подставляется из имени сайта, description остаётся пустым, а поисковик видит совсем не то, что посетитель.

Чаще всего вывод ломается в четырёх местах. Наследование по дереву: у дочерних страниц поля не переопределены, и они дословно повторяют заголовок и описание родителя. Шаблоны с жёстко прописанным заголовком в чанке — правки в админке до выдачи просто не доходят. Кэш, отдающий старую разметку после сохранения. И страницы пагинации с фильтрами, где дубли title и description появляются сами собой, без чьего-либо участия.

Отдельный слой — адреса и карта сайта. Если canonical не выставлен, а фильтры генерируют десятки почти одинаковых URL, в индекс уходят оба варианта. Карта сайта при этом включает служебные разделы, а robots.txt их не закрывает — ошибки SEO-разметки на сайте накапливаются тихо, без единой записи в логах.

Цена предсказуема: пустые описания страниц заставляют поисковик собирать сниппет из случайного фрагмента текста, дубли размывают вес между адресами, а карточка в выдаче перестаёт отражать реальное предложение. Ниже разбираем, как это закрывается — от аудита шаблонов и параметров до правил генерации мета-данных и карты сайта.

Что меняется после внедрения: эффекты в сроках и охвате

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

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

Время на правки мета-данных сокращается с часов до минут. Заголовок и описание для отдельной страницы меняются в панели управления MODX, а не в шаблонах с повторной выгрузкой; для десятков однотипных адресов достаточно одного правила подстановки. Массовое обновление по целому разделу перестаёт быть отдельной задачей для разработчика.

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

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

Способы подключения модулей на MODX: сравнение вариантов

Способ подключения определяет не только набор полей в админке, но и то, насколько предсказуемо ведут себя мета-теги на тысячах страниц. Разбираем четыре альтернативы, между которыми выбирают на проектах под MODX.

Что учитываем при выборе

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

Порядок работ: от аудита шаблонов до передачи регламентов

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

1. Аудит SEO-настроек сайта. Снимаем карту шаблонов и полей: сколько шаблонов реально используется, где мета-теги собираются из чанка, а где зашиты в разметку, на каких страницах выводятся пустые или дублирующиеся значения.
2. Чистка и инвентаризация. Убираем неиспользуемые шаблоны и поля — лишние элементы путают редакторов и ломают вывод при копировании страницы.
3. Проектирование схемы разметки страниц. Для каждого типа контента задаём свой набор полей и правила наследования: что заполняется на уровне раздела, что переопределяется на отдельной странице.
4. Настройка ЧПУ и редиректов. Определяем правила генерации адресов — слеши, регистр, транслитерация; старые адреса закрываем постоянными редиректами, чтобы не терять накопленный вес.
5. Проверка вывода мета-тегов. Прогоняем контрольную выборку: главная, разделы, карточки, пагинация, страницы фильтров. Заголовок, описание и канонический адрес должны собираться по одной логике.
6. Карта сайта и robots. Собираем карту из тех же данных, что идут в разметку, — она не расходится с фактическими адресами.
7. Передача регламентов команде. Отдаём документ с описанием полей, правил и типовых ошибок, чтобы новые страницы добавлялись без правок в шаблонах.

Правки выкатываем сначала на контрольной выборке до 40 страниц, сверяем результат и только потом применяем ко всему сайту.

Комплект передачи: конфигурации, шаблоны и регламенты обновлений

Комплект собирается так, чтобы контур разметки можно было поднять и развивать без автора настроек. Каждый артефакт закрывает свою зону: один отвечает за поведение полей, второй — за то, кто и что имеет право менять, третий — за порядок действий после релиза. Ниже — что именно остаётся у заказчика в репозитории и во внутренней базе знаний.

• Конфигурация SEO пакетов — рабочие значения полей, приоритеты шаблонов и системные настройки, выгруженные в файлы, а не запертые в админке: настройки разворачиваются на тестовом контуре одной командой.
• Схема шаблонов и полей — карта соответствия: какой шаблон выводит какие поля разметки, где значения дублируются, откуда берётся заголовок и описание для каждого типа страниц.
• Правила доступа редакторов — роли и границы: что контент-менеджер правит сам, что уходит разработчику, почему шаблоны закрыты от правки из панели управления.
• Документация по разметке — обязательные поля, ограничения по длине, требования к вложенности заголовков, примеры корректных и битых значений.
• Регламент обновлений — последовательность обновления ядра и пакетов, проверка разметки после релиза, порядок отката при расхождении шаблонов.
• Чек-лист приёмки релиза — контрольные точки: доступность страниц, корректность канонических адресов, отсутствие дублей, целостность карты сайта.
• Карта зависимостей — какие настройки завязаны на шаблоны и плагины, что именно ломается при их смене.

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

Кейс: убрали дубли мета-тегов на портале с сотнями разделов

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

Замеры сняли по каждому типу страниц до правок и зафиксировали как базу — иначе не доказать, что результат дала именно настройка SEO пакетов, а не общая переиндексация. Сравнение шло по одним и тем же адресам:

Что сделали

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

Что делать, если модули уже установлены и мешают друг другу?

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

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

Второй источник расхождений — наследование настроек. Значение поля берётся у ресурса, при пустом — у родителя, дальше — из настроек контекста и системы. Расширения читают эти уровни по-разному: одно подставляет системную величину, другое получает параметр, жёстко прописанный в вызове сниппета. Внешне одинаковые страницы получают разные данные, и правка в одном месте не доходит до половины разделов.

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

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

Технические сомнения перед стартом: частые вопросы инженеров

Сомнения перед стартом обычно не про сам пакет, а про то, как он уживётся с уже работающим сайтом: шаблонами, сниппетами, правилами в файле конфигурации сервера и мета-тегами, которые редакторы проставляли руками. Ниже — четыре вопроса, которые всплывают чаще всего при настройке SEO пакетов.

Что делать с конфликтами расширений?

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

Как проверяются редиректы?

Строим таблицу «старый адрес → новый» и прогоняем её целиком: не больше одного перехода, без петель, код 301. Сверяем по журналам сервера и карте адресов шаблонов, а не выборочно по нескольким страницам.

Уже проиндексированные страницы пострадают?

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

Обсудим задачу: с чего начнём и что нужно от вашей команды

Чтобы обсудить задачу предметно, а не по общим соображениям, нам нужен срез текущего состояния проекта: как сейчас устроена выдача мета-тегов, какие пакеты уже стоят и что из этого работает не так, как ожидалось. Чем полнее исходные данные от заказчика, тем точнее оценка объёма работ — по опыту, отсутствие доступа к стенду или списка кастомных правок сдвигает разбор сильнее, чем объём самого каталога.

• Список доменов и поддоменов с картой разделов: какие ЧПУ-правила используются, где есть дубли адресов и старые структуры.
• Доступы: административная часть системы, панель хостинга, панели вебмастера, доступ к серверному кэшу и планировщику.
• Перечень установленных пакетов и сниппетов, отвечающих за мета-теги, карту сайта, редиректы и микроразметку — со скриншотами текущих настроек.
• Шаблоны и чанки, где формируются заголовки и описания: покажите, что генерируется автоматически, а что проставлено руками.
• Выгрузка индексируемых адресов и карта редиректов, включая историю переездов и смены структуры каталога.
• Список приоритетных разделов и целевых запросов, требования к микроразметке и языковым версиям.
• Тестовый контур, где можно прогонять миграции и проверять вывод разметки без риска для рабочего сайта.
• Известные ограничения: лимиты хостинга, особенности кэширования, ошибки в журналах, которые мешают сборке страниц.

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