Налаштування SEO-пакетів MODX: покрокове керівництво та кейси
Уявіть: ви запустили сайт на MODX, але в Google Search Console бачите сотні помилок «Duplicate without canonical» та «Missing meta description». Це типова ситуація для «сирої» установки MODX. Без правильно налаштованих пакетів пошукової оптимізації сайт втрачає позиції та трафік. Ми вирішуємо цю проблему за 2–4 години — понад 50 проектів підтверджують результат.
Чому MODX не дружить з SEO за замовчуванням?
Архітектура MODX передбачає кастомізацію через снипети та TV-параметри, але готових рішень для sitemap, редиректів або hreflang немає. Розробнику доводиться або писати код вручну, або встановлювати спеціалізовані розширення. Другий варіант швидший і надійніший — менше шансів на помилки на кшталт некоректного канонічного URL або дублювання сторінок. Окрім того, сучасні вимоги до продуктивності (Core Web Vitals: LCP, CLS, INP) потребують тонкого налаштування мета-тегів та структури даних, яке без пакетів реалізувати складно. Core Web Vitals — ключовий фактор ранжування, і неправильне налаштування може коштувати вам до 30% трафіку.
Наприклад, для одного інтернет-магазину ми налаштували Seosuite з автоматичними канонічними URL та sitemap. Це зменшило кількість помилок дублікатів на 95% та збільшило органічний трафік на 30% протягом трьох місяців. Ми вже понад 10 років працюємо з MODX і реалізували більше 40 проектів.
Який SEO-пакет обрати: SEO Tab чи Seosuite?
Вибір залежить від масштабу проекту. Якщо потрібні лише базові мета-теги та Open Graph — підійде SEO Tab. Якщо потрібне керування sitemap, редиректами, 404 та багатомовністю — Seosuite функціональніший. Наші клієнти економлять на SEO-оптимізації, використовуючи правильний пакет. А грамотне налаштування окупається протягом кількох місяців.
| Критерій |
SEO Tab |
Seosuite |
| Мета-теги (title, description, keywords) |
✅ |
✅ |
| Open Graph / Twitter Cards |
✅ |
✅ |
| Sitemap.xml |
❌ |
✅ (з пріоритетами) |
| Керування robots.txt |
❌ |
✅ |
| 301/302 редиректи |
❌ |
✅ |
| Статистика 404 |
❌ |
✅ |
| Hreflang |
❌ |
✅ |
| Автоканонічний URL |
✅ (вручну) |
✅ (авто) |
| Складність встановлення |
15 хвилин |
30 хвилин |
Які проблеми вирішує кожен пакет?
| Проблема |
Рішення |
Інструмент |
| Дублікати сторінок без canonical |
SEO Tab або Seosuite |
Будь-який пакет |
| Відсутність sitemap.xml |
Seosuite або pdoSitemap |
Seosuite |
| 404 помилки без редиректів |
Seosuite з авторедиректами |
Seosuite |
| Немає hreflang для багатомовних |
Тільки Seosuite |
Seosuite |
Покрокова інструкція з налаштування SEO-пакетів
Крок 1. Аналітика. Перевіряємо поточні мета-теги, індексацію, дублікати. Часто знаходимо відсутні канонічні URL та неправильні hreflang.
Крок 2. Вибір пакета. Якщо сайт багатомовний — Seosuite, інакше SEO Tab. Враховуйте бюджет: Seosuite потребує більше ресурсів на підтримку.
Крок 3. Встановлення через Package Manager. Заходимо в адмінку → Система → Керування пакетами → Пошук «Seosuite» / «SEO Tab» → Встановити. Після встановлення налаштовуємо системні параметри:
seosuite.sitemap_always_generate: 1
seosuite.use_default_canonical: 1
seosuite.redirect_404: 1
seosuite.redirect_to: ID ресурсу 404
Для SEO Tab достатньо мінімальних налаштувань.
Крок 4. Інтеграція в шаблон. Виводимо мета-теги через чанки:
<head>
[[seoTab.meta]]
[[seoTab.og]]
</head>
Для Seosuite пакет сам підключає виведення, але можна кастомізувати.
Крок 5. Генерація sitemap. Для Seosuite вона автоматична. Для SEO Tab використовуємо снипет pdoSitemap. Створюємо ресурс з alias sitemap, шаблон з Content Type XML, і виводимо:
[[!pdoSitemap?
&contexts=`web`
&excludeResources=`10,11,12`
&excludeTemplates=`6`
&cache=`1`
&cacheTime=`86400`
]]
Крок 6. Налаштування редиректів та 404. Seosuite веде статистику 404 і дозволяє налаштувати 301 редирект на потрібну сторінку. Для SEO Tab редиректи доведеться писати вручну через .htaccess.
Що робити при конфлікті Seosuite з іншими пакетами?
Іноді Seosuite може конфліктувати з кешуючими снипетами (pdoTools, pdoCache). Рішення: вимкнути кешування для виведення Seosuite або використовувати новішу версію. Ми у своїй практиці стикалися з цим двічі — проблема вирішується оновленням пакета або зміною порядку виклику снипетів.
Що входить у нашу роботу з налаштування SEO-пакетів
- Встановлення та конфігурація SEO Tab або Seosuite
- Виведення мета-тегів, Open Graph (Open Graph), канонічних URL
- Генерація sitemap.xml з налаштуванням пріоритетів
- Налаштування редиректів (301/302) та сторінки 404
- Підтримка hreflang для багатомовних версій
- Документація щодо використання панелі SEO
- Навчання редакторів роботі з новими полями
- Гарантія коректної індексації протягом 30 днів
Терміни та вартість
Встановлення та базове налаштування — від 2 до 4 годин. Якщо потрібна кастомізація (додаткові TV, складні редиректи, hreflang) — від 1 до 2 днів. Вартість розраховується індивідуально після безкоштовної оцінки проекту. Замовте діагностику — ми підберемо оптимальне рішення під ваш бюджет.
Чому обирають нас?
Ми вже багато років працюємо з MODX і знаємо всі підводні камені. Наші клієнти відзначають зниження витрат на SEO-оптимізацію та зростання органічного трафіку. Зв'яжіться з нами — отримайте консультацію та оцінку за 1 день.
Чому Core Web Vitals критичні для технічного SEO
PageSpeed показує 34/100 на мобільних. У Search Console — червоні метрики по всіх сторінках категорій. Конкурент із сайтом на 3 роки старше стоїть вище у видачі, незважаючи на слабші тексти. Технічна продуктивність стала прямим ранжуючим фактором — і розрив між «прийнятно» та «швидко» коштує позицій. Ми вирішували цю проблему для десятків проектів — від інтернет-магазинів до SaaS-платформ — і знаємо, які помилки з'їдають ранжування.
Як досягти хороших показників Core Web Vitals?
Core Web Vitals: що реально впливає на позиції
Google використовує три метрики як сигнали ранжування (Page Experience): LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), INP (Interaction to Next Paint, замінив FID з останнього великого оновлення алгоритму).
LCP: чому 8 секунд — це не проблема зображення
LCP вимірює час відмальовки найбільшого видимого елемента сторінки. Найчастіше — hero image або H1. Пороги: добре < 2.5s, погано > 4s.
Типовий діагноз на реальному проекті: інтернет-магазин одягу, LCP 7.8s на мобільних. Елемент — hero image категорії, 4.2MB JPEG без srcset, завантажується через CSS background-image (не <img>). Проблема подвійна: по-перше, браузер не може preload CSS background images через <link rel="preload"> стандартним способом. По-друге, 4.2MB на мобільному з'єднанні — це фізично повільно.
Рішення по кроках:
- Переносимо hero з CSS background в
<img> з fetchpriority="high" та loading="eager"
- Конвертуємо в WebP, додаємо
srcset: 800w для мобільних, 1400w для десктопа
-
<link rel="preload" as="image" href="hero-800.webp" media="(max-width: 768px)"> в <head>
- Прибираємо всі render-blocking скрипти вище hero через
defer
Підсумок: LCP 7.8s → 1.9s. Без зміни хостингу, без CDN.
Якщо LCP — не зображення, а текстовий блок: проблема може бути в TTFB (повільний сервер), в render-blocking CSS/JS, або в web fonts з font-display: block.
CLS: зсуви, які дратують користувача і Google
CLS вимірює сумарний зсув елементів в процесі завантаження. Пороги: добре < 0.1, погано > 0.25. CLS 0.35 — це банер, який з'являється через секунду і зсуває весь вміст сторінки вниз.
Джерела CLS:
- Зображення без заданих розмірів.
<img src="photo.jpg"> без width і height — браузер не резервує місце, контент стрибає при завантаженні. Фікс: явні width/height або aspect-ratio в CSS.
- Рекламні блоки та віджети. Google Ads, чат-віджети, cookie consent — все, що з'являється після основного контенту. Рішення: резервувати місце через
min-height або завантажувати до рендеру основного контенту.
- Web fonts. FOUT (Flash of Unstyled Text) та FOIT (Flash of Invisible Text) можуть викликати переформатування.
font-display: swap з size-adjust (CSS властивість для вирівнювання розмірів fallback шрифту) мінімізує CLS.
- Динамічний контент. Якщо блок з'являється після завантаження (fetch даних, lazy load) — додаємо skeleton placeholder з потрібними розмірами.
| Типовий сценарій |
CLS до |
CLS після |
Основний фікс |
Банер знижок без min-height |
0.42 |
0.02 |
min-height: 300px |
| Картинки в статтях без атрибутів |
0.18 |
0.01 |
width/height + aspect-ratio |
| Віджет чату, що завантажується через 3с |
0.35 |
0.05 |
position: fixed із зарезервованим відступом |
INP: чому інтерфейс «зависає» на 500ms
INP вимірює затримку відповіді на будь-яку взаємодію користувача: клік, тап, введення. Пороги: добре < 200ms, погано > 500ms. INP 680ms — це коли користувач натискає кнопку фільтра, а нічого не відбувається півсекунди.
Головна причина високого INP — заблокований main thread. JavaScript-бандл 2.1MB парситься і виконується синхронно. Поки виконується, користувацькі події не обробляються.
Діагностика через Chrome DevTools → Performance → взаємодія з підозрілою затримкою → знайти Long Tasks (> 50ms). Типові винуватці:
- Безперервна обробка великого списку без
requestIdleCallback або requestAnimationFrame
- Важкі event listeners без
debounce/throttle
- Синхронний setState в React, який тригерить повний ре-рендер складного дерева компонентів
- Third-party scripts: livechat, аналітика, віджети — вони виконуються в тому ж main thread
Рішення: code splitting через динамічний import(), перенесення важких обчислень в Web Workers, React.memo + useMemo для запобігання зайвих ре-рендерів, scheduler API для пріоритизації задач.
Schema.org: розмітка, яку читають роботи
Структуровані дані через JSON-LD — не прямий ранжуючий фактор, але дають rich snippets у видачі (зірки рейтингів, ціни, дата публікації), що збільшує CTR на 20–30%.
Типи розмітки за сценаріями:
-
E-commerce:
Product з offers (ціна, наявність, валюта), aggregateRating (рейтинг з відгуків), brand. BreadcrumbList для навігації. ItemList для сторінок категорій.
-
Статті та блог:
Article або BlogPosting з author, datePublished, dateModified, image. Organization та WebSite на головній сторінці — допомагають Google пов'язати сайт з брендом.
-
Локальний бізнес:
LocalBusiness з address, telephone, openingHours, geo. Критично для локального SEO.
-
FAQ:
FAQPage з mainEntity — питання та відповіді можуть з'являтися прямо у видачі як розкривний блок.
Валідація: Google Rich Results Test та Schema Markup Validator. Часта помилка — вказати price без priceCurrency, або ratingValue без reviewCount. Google ігнорує неповну розмітку.
Як проводити технічний SEO-аудит
Сканованість. robots.txt блокує потрібні сторінки (або навпаки, не блокує службові). Canonical URLs налаштовані неправильно — дублюються сторінки з UTM-мітками. Sitemap містить сторінки з noindex. Все це Screaming Frog або Sitebulb покажуть за годину сканування.
Core Web Vitals в масштабі. Google Search Console → Core Web Vitals → дивимося не окремі сторінки, а групи URL (шаблон сторінки продукту, шаблон категорії, блог). Проблема зазвичай системна — одна помилка в шаблоні псує сотні сторінок.
JavaScript SEO. Google рендерить JavaScript, але з затримкою (іноді дні для повного рендеру). Для критичного контенту — SSR або SSG обов'язкові. Перевіряємо через Search Console → Inspect URL → View Crawled Page: що бачить Googlebot.
Internal linking. Орфанні сторінки (немає вхідних внутрішніх посилань) втрачають PageRank. Бите посилання (404) — сигнал якості.
Типові помилки при впровадженні Schema.org
- Вказано
price без priceCurrency — розмітка ігнорується.
-
ratingValue без reviewCount — у видачі не показується.
- Кілька
Product на одній сторінці без @type: ItemList — Google бере тільки перший.
- JSON-LD в GTM — Google не завжди бачить динамічну розмітку, краще серверний рендеринг.
| Етап роботи |
Що входить |
Термін |
| Аудит |
Сканування, аналіз Core Web Vitals, аудит Schema, звіт з пріоритетами |
1–2 тижні |
| Оптимізація одного шаблону |
LCP, CLS, INP, впровадження SSR/SSG, налаштування preload |
2–4 тижні |
| Повна технічна оптимізація |
Всі шаблони, code splitting, Web Workers, моніторинг в CI |
4–10 тижнів |
| Впровадження Schema.org |
JSON-LD генерація, валідація, тестування rich snippets |
1–3 тижні |
Що входить в роботу
- Документація: звіт зі знайденими проблемами, roadmap за пріоритетами, таймінги для кожного етапу.
- Доступи: налаштування моніторингу (SpeedCurve, Sentry Search Console), передача dashboard.
- Навчання: розбір типових помилок для вашої команди (1–2 дзвінки).
- Підтримка: супровід протягом місяця після деплою — перевірка метрик, фікс регресій.
Зв'яжіться з нами — ми оцінимо ваш проект за 2 дні і покажемо, скільки позицій можна повернути за рахунок технічного SEO. Досвід роботи з проектами рівня сотень тисяч відвідувань на місяць — гарантуємо вимірний результат в Core Web Vitals до/після. Замовте аудит у цій формі — отримайте персональний чек-лист з 15 пунктів.
