SEO на WordPress: що налаштувати до запуску і чого не зробить жоден плагін

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

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

Чому WordPress не оптимізований із коробки

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

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

Адреси сторінок і постійні посилання

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

Кілька правил, які економлять проблеми пізніше:

слаг записує розробник або редактор, а не генерується автоматично з довгого заголовка; зайві слова й сполучники в ньому не потрібні;
для українських сайтів слаг зазвичай транслітерується латиницею, і важливо, щоб правило транслітерації було єдиним для всього проєкту;
кінцевий слеш або є скрізь, або відсутній скрізь, а другий варіант переадресовується на перший;
базу категорій (префікс на кшталт /category/) краще прибрати або замінити осмисленим, якщо це не ламає структуру;
для WooCommerce окремо перевіряється база товарів і категорій товарів: саме там часто лишаються вкладені шляхи, які створюють дублі.

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

Що має потрапляти в індекс, а що ні

Найчастіша помилка після запуску — забута галочка «Заборонити пошуковим системам індексувати сайт» у налаштуваннях читання. Її вмикають на стадії розробки, щоб тестовий сайт не потрапив у видачу, а після релізу про неї забувають. Сайт місяцями не з’являється в Google, а команда шукає причину в контенті. Перша перевірка після будь-якого запуску — подивитися meta robots у вихідному коді головної сторінки й перевірити файл robots.txt.

Далі йде робота з архівами. Сторінки тегів, авторів і дат у більшості корпоративних сайтів не мають власної цінності: вони повторюють анонси записів і віддають мало унікального тексту. Для них зазвичай ставлять noindex, залишаючи в індексі основні категорії, які мають структурну логіку й опис. Сторінки вкладень (окрема сторінка для кожного зображення) у нових версіях WordPress за замовчуванням вимкнені, але на старих сайтах вони часто лишаються, і їх варто перенаправляти на батьківський запис. Результати внутрішнього пошуку закриваються від індексації майже завжди: це нескінченна кількість адрес без цінності.

Важливий нюанс: директива noindex працює лише тоді, коли робот може відкрити сторінку й прочитати її. Якщо одночасно заборонити адресу в robots.txt, пошуковик не побачить noindex, а сама адреса може лишитися у видачі без опису. Тому закривати від індексації й закривати від сканування потрібно свідомо, а не «на всяк випадок» обома способами.

Окремо стоять параметри адрес: мітки utm, сортування, пагінація. Для них потрібні канонічні посилання, що вказують на основну версію сторінки, і чіткі правила для пагінації. Атрибути rel=prev і rel=next Google давно не використовує, тому кожна сторінка списку має бути доступною через звичайні посилання й мати власну канонічну адресу.

Заголовки, шаблони й конструктори сторінок

Тема WordPress і конструктор на кшталт Elementor або Divi визначають, що опиняється в HTML. Саме там з’являються типові проблеми: два чи три заголовки першого рівня на сторінці, заголовки, використані лише заради розміру шрифту, порожні теги, вкладені на десять рівнів блоки. Пошуковий робот читає не візуальний макет, а код, тому перевіряти потрібно саме його: що показує «переглянути код сторінки», а не те, що виглядає правильно в редакторі.

У шаблоні мають бути закладені речі, які редактор не повинен налаштовувати вручну: підтримка тегу title, єдиний H1 на сторінці, хлібні крихти, коректні посилання в меню (елементи з href, а не кнопки, що працюють лише через JavaScript). Контент, схований у вкладках і акордеонах, індексується, якщо він присутній у коді відразу, але якщо він підвантажується лише після кліку, робот може його не побачити.

Швидкість: де WordPress втрачає секунди

Швидкість завантаження — та частина SEO, де відповідальність найбільше лежить на розробникові. Google оцінює сторінки за показниками Core Web Vitals: LCP (час появи головного елемента, добрим вважається результат до 2,5 секунди), INP (відгук на дії користувача, до 200 мілісекунд) і CLS (візуальна стабільність, не більше 0,1). Скільки саме це впливає на позиції і які правки дають найбільший ефект, докладно розібрано в матеріалі про швидкість сайту і Core Web Vitals. Тут важливо розуміти, які речі на WordPress впливають на ці показники найчастіше.

Хостинг і час відповіді сервера. Якщо сервер повільно віддає першу відповідь, ніякі оптимізації на фронтенді цього не компенсують. Серверне кешування сторінок дає на WordPress найбільший виграш і дешевше, ніж переписування теми.
Зображення. Сучасні формати (WebP, AVIF), відповідні розміри для різних екранів і явно вказані ширина та висота. Головне зображення першого екрана не можна відкладати при завантаженні: саме воно найчастіше й виявляється LCP-елементом.
Кількість плагінів і скриптів. Кожен плагін додає власні стилі й скрипти, часто на всі сторінки, навіть там, де вони не потрібні. Слайдери, віджети чатів, пікселі аналітики й шрифти з зовнішніх джерел сукупно дають найбільше навантаження на INP.
Шрифти й банери. Підвантаження шрифтів без запасного варіанта й банери, що з’являються з затримкою й зсувають контент, — головні причини поганого CLS.

Замір варто робити не лише в лабораторних інструментах, а й за реальними даними користувачів у звіті Core Web Vitals у Search Console: розрив між ними буває суттєвим, особливо для мобільних пристроїв.

Структуровані дані й сніпети

Розмітку Schema.org на WordPress зазвичай додає SEO-плагін або окреме розширення. Базовий мінімум: Organization або LocalBusiness для компанії, Article для матеріалів блога, BreadcrumbList для хлібних крихт і Product для карток товарів у WooCommerce. Розмітка має відповідати тому, що користувач бачить на сторінці: ціни, наявність і відгуки, яких немає в інтерфейсі, потрапляють у розмітку лише на шкоду сайту.

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

Редиректи, 404 і міграції

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

Окремо стежать за ланцюжками переадресацій (коли адреса А веде на Б, а Б на В): кожна ланка уповільнює завантаження і розпорошує сигнали. Видалені сторінки без заміни мають віддавати відповідь 404 або 410, а не «м’яку» помилку, коли сторінка з повідомленням про відсутність контенту повертає код 200. Помилки такого типу видно у звіті про індексацію в Search Console, і їх варто переглядати регулярно, а не лише після міграцій.

Один SEO-плагін замість трьох

На одному сайті має працювати один SEO-плагін. Два одночасно створюють дублікати тегів title, конфліктні канонічні адреси й подвійну розмітку Schema.org. До того ж WordPress із версії 5.5 має власну карту сайту, і якщо плагін генерує свою, потрібно вимкнути одну з двох, щоб у пошуковиків не було двох різних списків адрес.

Налаштування, які справді мають значення: шаблони для title і description за типами контенту, правила noindex для архівів, налаштування карти сайту, хлібні крихти й керування переадресаціями. Усе інше, наприклад «SEO-оцінки» з індикаторами різних кольорів, не відображає того, як сторінку ранжуватиме Google: це лише підказки до редагування тексту. Жоден плагін не створить корисного контенту, не побудує структуру сайту і не усуне проблеми швидкості, що виникли через важку тему.

Контент і внутрішні посилання

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

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

Що перевірити після релізу

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

meta robots і robots.txt не забороняють індексацію, галочка в налаштуваннях читання вимкнена;
на кожній сторінці один H1, title і description унікальні, канонічна адреса вказує на саму сторінку;
карта сайту одна, додана в Search Console й не містить закритих або переадресованих адрес;
старі адреси переадресовуються на нові без ланцюжків, а видалені сторінки віддають коректну помилку;
архіви, вкладення й внутрішній пошук закриті від індексації за потреби, а основні категорії відкриті;
Core Web Vitals у польових даних у межах норми для мобільних пристроїв;
розмітка проходить перевірку, а дані в ній збігаються з тим, що бачить користувач;
налаштована аналітика й подія для основних цілей, щоб було видно, які сторінки приносять заявки.

Висновок

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

2026-11-14