Налаштування SEO-пакетів MODX: покрокове керівництво та кейси

Налаштування SEO-пакетів MODX: де ламається виведення мета-даних

Мета-дані на MODX збираються з трьох незалежних джерел: полів самого ресурсу, TV-параметрів і значень за замовчуванням у шаблоні.

Варто одній ланці не спрацювати — і у вихідному коді title підставляється з назви сайту, description залишається порожнім, а пошукова система бачить зовсім не те, що відвідувач.

Найчастіше виведення ламається в чотирьох місцях. Успадкування за деревом: у дочірніх сторінок поля не перевизначені, і вони дослівно повторюють заголовок і опис батьківської. Шаблони з жорстко прописаним заголовком у чанку — правки в адмінці до виведення просто не доходять.

Кеш, що віддає стару розмітку після збереження. І сторінки пагінації з фільтрами, де дублі title і description з’являються самі собою, без чиєїсь участі.

Окремий шар — адреси й карта сайту. Якщо canonical не виставлений, а фільтри генерують десятки майже однакових URL, в індекс потрапляють обидва варіанти.

Карта сайту при цьому включає службові розділи, а robots.txt їх не закриває — помилки SEO-розмітки на сайті накопичуються тихо, без жодного запису в логах.

Наслідки передбачувані: порожні описи сторінок змушують пошукову систему збирати сніпет з випадкового фрагмента тексту, дублі розмивають вагу між адресами, а картка у видачі перестає відображати реальну пропозицію.

Нижче розбираємо, як це закривається — від аудиту шаблонів і параметрів до правил генерації мета-даних і карти сайту.

Що змінюється після впровадження: ефекти в термінах і охопленні

Ефект від налаштування видно у вимірюваних показниках, а не у відчуттях.

Частка сторінок з коректно заповненими заголовком, описом і канонічною адресою перестає залежати від акуратності автора: значення підставляються за шаблонами, тому розмітка є в усіх опублікованих матеріалів — карток, категорій, сторінок добірок.

Зникає цілий клас помилок, пов’язаний із дублями розмітки. Пагінація, сортування, адреси з мітками кампаній і дзеркала отримують однозначні канонічні посилання та директиви обходу, тому з індексу вичищаються копії з однаковим вмістом.

Частка проіндексованих сторінок зростає, а вага сайту більше не розмивається між версіями одного й того самого матеріалу.

Час на правки мета-даних скорочується з годин до хвилин. Заголовок і опис для окремої сторінки змінюються в панелі керування MODX, а не в шаблонах із повторним вивантаженням; для десятків однотипних адрес достатньо одного правила підстановки. Масове оновлення по цілому розділу перестає бути окремою задачею для розробника.

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

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

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

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

Що враховуємо під час вибору

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

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

Роботи йдуть у фіксованому порядку: спочатку фіксуємо поточний стан, потім проєктуємо цільову схему і лише після цього правимо налаштування. Так кожна зміна прив’язана до конкретної проблеми, а не виглядає як «переробили все одразу».

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

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

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

Комплект збирається так, щоб контур розмітки можна було підняти й розвивати без автора налаштувань. Кожен артефакт закриває свою зону: один відповідає за поведінку полів, другий — за те, хто і що має право змінювати, третій — за порядок дій після релізу. Нижче — що саме залишається в замовника в репозиторії та у внутрішній базі знань.

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

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

Після цього правки розмітки перестають вимагати зовнішнього підрядника, а оновлення проходять без просідання індексації.

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

Портал із сотнями розділів: сторінки генеруються шаблонами, а мета-розмітка успадковується від батьківської. У звітах з індексації це виглядало так — десятки адрес з однаковим заголовком і описом, цілі гілки каталогу, що випали з пошуку, порожні значення на сторінках фільтрів.

Річ не в MODX, а в тому, що SEO-пакети стояли «за замовчуванням»: правила виведення не враховували рівень вкладеності та тип розділу.

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

Що зробили

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

Правила застосовуються за гілкою дерева: невдалий варіант відкочується точково, без правки шаблонів і повторної індексації всього порталу.

Що робити, якщо модулі вже встановлені й заважають один одному?

Конфлікт розширень майже ніколи не виглядає як помилка — він виглядає як «мета-теги самі змінюються». Два пакети підписуються на одні й ті самі події та обидва вважають себе господарем заголовка сторінки.

Хто переможе, залежить від порядку реєстрації та пріоритету, а він на різних збірках різний — тому поведінка здається випадковою.

Порядок обробки подій у MODX задається числовим пріоритетом: плагін з меншим значенням спрацьовує раніше й може переписати те, що поклав попередній. Якщо один пакет будує заголовок із шаблону, а другий — з поля ресурсу, у видачу йде результат того, що спрацював останнім.

Налагодження починаємо з трасування: вмикаємо журнал подій, дивимося ланцюжок викликів і лише потім щось змінюємо.

Друге джерело розходжень — успадкування налаштувань. Значення поля береться в ресурсу, якщо порожнє — у батьківського, далі — з налаштувань контексту й системи.

Розширення читають ці рівні по-різному: одне підставляє системну величину, інше отримує параметр, жорстко прописаний у виклику сніпета. Зовні однакові сторінки отримують різні дані, і правка в одному місці не доходить до половини розділів.

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

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

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

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

Що робити з конфліктами розширень?

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

Як перевіряються редиректи?

Будуємо таблицю «стара адреса → нова» і проганяємо її повністю: не більше одного переходу, без петель, код 301. Звіряємо за журналами сервера й картою адрес шаблонів, а не вибірково за кількома сторінками.

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

Адреси не змінюємо, розмітку оновлюємо хвилями. Після кожної хвилі звіряємо ключові розділи з даними пошукових систем — якщо сторінка просла, правило відкочуємо точково, не зачіпаючи решту сайту.

Обговоримо задачу: з чого почнемо і що потрібно від вашої команди

Щоб обговорити задачу предметно, а не за загальними міркуваннями, нам потрібен зріз поточного стану проєкту: як зараз влаштоване виведення мета-тегів, які пакети вже стоять і що з цього працює не так, як очікувалося.

Чим повніші вихідні дані від замовника, тим точніша оцінка обсягу робіт — за досвідом, відсутність доступу до стенда або списку кастомних правок зсуває розбір сильніше, ніж обсяг самого каталогу.

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

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