Технічне SEO для WordPress — це не «поставити Rank Math і забути». Це система, яка робить так, щоб Google і AI-системи стабільно знаходили, сканували, розуміли й індексували комерційні URL: послуги, категорії, картки, лендінги, блог. Без технічного фундаменту контент і лінки дають слабший ROI: crawl budget згорає на параметрах і дублях, Core Web Vitals ріжуть конверсію, міграції обнулюють позиції.
Цей гайд — робоча карта для власників WordPress-сайтів, in-house маркетингу й CMO: що перевіряти, у якому порядку, які шаблони ламаються найчастіше, і як зібрати аудит на 10 робочих днів із пріоритетами P0/P1/P2. Оновлено з урахуванням практики 2025–2026: GSC Coverage/Pages, CrUX field data, LiteSpeed/Nginx-кеш, page builders, WPML/Polylang, JS-рендеринг.
Якщо потрібен повний технічний аудит під ключ — дивіться послугу SEO-просування. Нижче — фреймворк, яким ми реально ведемо WordPress-проєкти в SEO-Studio.
Навіщо бізнесу технічне SEO на WordPress
WordPress закриває більшість бізнес-сайтів в Україні: корпоратив, послуги, блог, WooCommerce. Саме тому технічні помилки тут масштабуються швидко: один кривий шаблон категорії або кеш із noindex множиться на сотні URL.
Ціна технічного боргу
Типові симптоми, які власник бачить як «SEO не працює»:
- трафік просів після редизайну або зміни пермалінків;
- у GSC росте «Виявлено — наразі не проіндексовано» / Soft 404;
- PageSpeed «зелений» на головній, але форми на money-URL гальмують INP;
- staging або параметри фільтрів потрапили в індекс;
- після міграції залишилися ланцюги 302 і биті внутрішні лінки.
Технічне SEO повертає контроль: спочатку бот має коректно дійти до money-URL і віддати зрозумілий HTML, потім уже працюють контент, лінки й бренд.
Для кого цей гайд
- власник / CMO, якому потрібен фреймворк пріоритетів, а не глосарій;
- маркетолог, який ставить ТЗ розробнику;
- in-house SEO, який будує backlog на квартал;
- агентство/підрядник, якому потрібна єдина мова з клієнтом.
Карта робіт: від індексації до швидкості
Працюємо шарами. Спочатку доступність для бота, потім якість відповіді сервера й HTML, далі шаблони WordPress, і лише потім тонкі оптимізації CWV.
- Discoverability — robots, sitemap, канонікали, noindex, пагінація.
- Crawl efficiency — параметри, фільтри, редиректи, orphan, логи.
- Render & HTML — критичний контент у першому HTML, не лише в JS.
- Performance — TTFB, LCP, INP, CLS на шаблонах money-URL.
- Release hygiene — staging, деплой, моніторинг 5xx, регресії.
Нижче — карта теми: від індексації й crawl до CWV, релізів і моніторингу. У міру появи окремих глибоких гайдів по кожному шару посилання на них зʼявляться в змісті цього матеріалу.
| Шар | Що ламається на WP | Сигнал «готово» |
|---|---|---|
| Discoverability | noindex на проді, кривий sitemap, дубль canonical | Money-URL у індексі, sitemap = 200 без редіректів |
| Crawl | фасети, ?utm у індексі, ланцюги 301 | Бот ходить на пріоритетні шаблони (логи/crawl stats) |
| Render | контент лише після JS, порожній DOM у білдера | URL Inspection: контент у rendered HTML |
| Performance | важкий hero, GTM/чати, CLS шрифтів | Field CrUX money-path у «Good» або стабільний тренд |
| Release | staging open, 5xx у прайм-тайм | Чеклист релізу + алерти 24–48 год |
Індексація і контроль у Search Console
Починайте з факту: які URL Google вважає проіндексованими Покрокова перевірка — у гайді як перевірити індексацію в Google. , а які — виключеними. GSC → «Сторінки» дає причини (redirect, duplicate, soft 404, robots, 404). Для WordPress типові пастки:
- архіви автора/дата/теги відкриті без потреби;
- пагінація з слабким канонікалом;
- faceted URL каталогу в індексі;
- staging або query-параметри з UTM у канонікалах;
- два SEO-плагіни з різними canonical/title.
Практичний ритм GSC
- раз на тиждень — Coverage/Pages delta і нові причини виключень;
- після релізу — URL Inspection на 10 money-URL;
- раз на місяць — звірка sitemap vs indexed;
- після міграції — щоденний моніторинг 404 і «redirect error» 2–4 тижні.
URL Inspection як Definition of Done
Не вірте лише Screaming Frog. Для ключових шаблонів перевірте: чи Google бачить H1 і основний текст, який canonical обрано, чи немає «crawled / currently not indexed» без пояснюваної причини. Якщо rendered HTML порожній — це вже задача render/JS, а не «мало тексту».
Гігієна XML sitemap
Sitemap має містити лише індексовані 200 OK URL без ланцюгів редіректів і без noindex. На WordPress перевіряйте, що SEO-плагін не тягне вкладення, службові CPT і thin archives. Окремий гайд розбере структуру XML-карти детальніше. Практичний розбір — у гайді про XML-sitemap.
Crawl budget і «сміттєві» URL
На сайтах до ~500 URL crawl budget рідко проблема. Детальніше — у матеріалі Crawl budget: що це і коли на нього впливають. На каталогах, мультисайтах і контент-хабах — так. Логи nginx/CDN показують, куди реально ходить Googlebot: фільтри, внутрішній пошук, ланцюги 301, календарі.
Правило пріоритезації
Спочатку приберіть hits на URL без попиту (noindex / параметри / robots), потім прискорте money-URL (кеш, TTFB), лише потім розширюйте sitemap новими розділами. Інакше бот «пережовує» сміття замість комерції.
Типове сміття WordPress
?replytocom=, трекбеки, preview-параметри;- фільтри WooCommerce й Ajax-фасети без allowlist;
- пошук сайту
?s=в індексі; - календарі/архіви дат;
- дублі www/non-www і http/https у внутрішніх лінках;
- пагінація з session-id або сортуванням.
Коли потрібен log analysis
Якщо GSC показує «багато виявлено, мало проіндексовано», а краул бачить тисячі параметрів — зніміть 7–14 днів логів і побудуйте топ шляхів Googlebot. Це швидше пояснює пріоритети, ніж ще один «аудит на 80 сторінок».
robots.txt, canonical, noindex, пагінація
Чотири інструменти вирішують різні задачі. Підміна одного іншим — класична помилка.
robots.txt
Блокує crawl, але не гарантує зняття з індексу, якщо URL уже мають зовнішні лінки. Не Disallow-те CSS/JS, потрібні для рендеру. На проді не лишайте staging-правила. Типові помилки robots.txt розбираємо в окремому гайді. Почніть з типових помилок robots.txt.
noindex
Прибирає з видачі, але URL можуть далі витрачати crawl. Використовуйте для thank-you, внутрішнього пошуку, тонких фасетів, службових лендінгів Ads. Не ставте noindex на весь /blog/ «тимчасово».
canonical
Сигнал переваги, не команда. На WordPress стежте, щоб тема, білдер і SEO-плагін не видавали три різні canonical. Self-canonical на money-URL — норма; canonical на пагінації має бути узгоджений із політикою індексації сторінок 2+.
Пагінація
Для блогу й каталогу оберіть одну політику: індексувати page/2 з унікальним title або зводити сигнал на першу сторінку. Головне — не змішувати підходи між шаблонами й не плодити сортування в індексі.
Core Web Vitals на шаблонах WordPress
CWV міряємо не «головною в лабораторії», а шаблонами: послуга, категорія блогу, картка кейсу, лендінг з формою, категорія Woo. LCP часто ламає hero без розмірів і late CSS; INP — важкі скрипти чатів/GTM; CLS — шрифти й банери.
Стек, який перевіряємо
- тема + page builder (Elementor/WPBakery тощо);
- кеш (LiteSpeed / Nginx FastCGI / плагін page cache);
- CDN і зображення (WebP/AVIF, srcset, sizes);
- відкладення сторонніх скриптів без поломки форм;
- критичний CSS без стрибків layout.
Field vs lab
PageSpeed Insights — діагностика. Рішення приймайте за CrUX/Search Console по origin і ключових path. Якщо lab зелений, а field червоний — дивіться TTFB з регіону користувачів, треті сторони й персоналізацію кешу.
Пріоритет money-URL
Не оптимізуйте всі архіви одночасно. Візьміть топ-10–20 URL за лідами/виручкою й закрийте LCP/INP там. Глибші розбори CWV і WordPress Web Vitals — в окремих практичних гайдах. Дивіться Core Web Vitals для SEO та практичні кроки для WordPress.
Плагіни, білдери й технічний ризик
Більшість технічних регресій на клієнтських WordPress ми бачимо не в «чистому» ядрі, а на перетині page builder + SEO-плагін + кеш + переклад.
Питання перед встановленням плагіна
- Який SEO- або CWV-ризик він додає?
- Чи дублює canonical/title/schema з уже встановленим SEO-плагіном?
- Чи віддає контент у першому HTML, чи лише після JS?
- Чи вміє коректно працювати з page cache / object cache?
- Хто owner і коли останнє оновлення?
Антипатерни
- два SEO-плагіни одночасно;
- білдер із порожнім HTML для бота;
- кеш, що віддає noindex-версію або навпаки персоналізований HTML усім;
- WPML/Polylang із розʼїханими hreflang після імпорту;
- security-плагіни з 403 на Googlebot для /wp-json/ чи критичних assets;
- мертві плагіни як attack surface і зайве PHP на TTFB.
Раз на квартал робіть inventory: last update, чи потрібен, хто owner. Це частина технічного SEO, не лише «безпеки».
Міграції, редиректи, мультимовність
Чекліст — у міграції сайту з 301 і GSC. Найдорожчі технічні помилки трапляються під час редизайну й зміни CMS/пермалінків.
Мінімум для міграції
- карта 1:1 старих URL → нових для всього органічного трафіку;
- 301 (не 302) без довгих ланцюгів;
- оновлення внутрішніх лінків, не лише «редирект зверху»;
- чистий sitemap і перевірка в GSC;
- моніторинг 404/позицій/лідов 2–4 тижні;
- окремий реліз URL-структури від великого контент-батчу.
hreflang на WPML/Polylang
Для UK/RU критичні узгоджені канонікали й x-default. Помилка «всі мови на один canonical» зʼїдає міжнародну видимість. Глибокий розбір — у хабі міжнародного SEO; старт діагностики — тут: вибіркова перевірка пари URL у GSC і в HTML head.
Фреймворк аудиту на 10 робочих днів
Результат аудиту — не PDF на 80 сторінок без пріоритетів, а таблиця задач із очікуваним впливом на індексацію/швидкість/трафік.
Дні 1–2: доступність
GSC, robots, sitemap, canonical, індексація money-URL, staging, базова аналітика.
Дні 3–4: crawl
Screaming Frog / Sitebulb + вибірка логів. Карта сміттєвих шаблонів і orphan.
Дні 5–6: CWV і TTFB
Польові метрики + лабораторія на шаблонах. Список P0 по LCP/INP/CLS.
Дні 7–8: дублікати й архітектура
Пагінація, фасети, архіви, schema-конфлікти, внутрішні лінки на money-URL.
День 9: редиректи й broken
Ланцюги, 404 з трафіком, змішаний контент, hreflang-вибірка.
День 10: backlog
P0/P1/P2 з owner, Definition of Done, оцінка впливу. Саме так ми ведемо технічне SEO в агентстві.
Чекліст перед релізом на WordPress
Перед викаткою теми, плагінів або зміни пермалінків прогоніть короткий технічний гейт (20–40 хвилин).
- Перевірте
robots.txtна production (не staging-правила). - Відкрийте 5 money-URL інкогніто й під Googlebot UA — HTML має містити H1 і основний текст без критичної залежності від JS.
- Звірте XML sitemap: лише 200 OK, без noindex і редиректів.
- Прогоніть вибірку редиректів зі старої карти URL (мінімум топ-50 трафіку).
- Подивіться TTFB money-шаблонів до/після кешу.
- Увімкніть моніторинг 5xx на 24–48 годин після деплою.
- У GSC зробіть URL Inspection для головної, ключової послуги й 1–2 важливих посадкових.
Якщо реліз чіпає URL-структуру — не змішуйте його з великим контент-батчем. Спочатку стабілізуйте маршрутизацію й редиректи, потім нарощуйте контент.
Моніторинг після впровадження
Технічне SEO без моніторингу швидко деградує.
- Щоденні uptime/5xx алерти.
- Щотижневий GSC: нові виключення, ріст 404.
- Щомісячний краул вибірки шаблонів.
- Щоквартальний CWV field (CrUX) по origin і ключових path.
Для команд із кількома розробниками заведіть SEO regression checklist у CI або хоча б у Pull Request template: «чи змінювались URL / robots / headers / шаблон head?».
KPI технічного шару
- частка money-URL в індексі;
- час до індексації нових послуг/категорій;
- TTFB і LCP на топ-шаблонах;
- органічні ліди/виручка з money-landing (не лише sessions блогу);
- кількість 404 із хітами після релізу.
Процес впровадження: від аудиту до стабілізації
1. Фіксація baseline
Зніміть індексацію money-URL, TTFB шаблонів, частку брендового трафіку, кількість органічних лідів. Без baseline складно довести ефект.
2. P0 за 1–2 тижні
Закрийте те, що блокує індекс або ламає рендер: noindex на проді, відкритий staging, критичні 5xx, порожній HTML money-URL.
3. P1 за місяць
Crawl hygiene, canonical/pagination policy, CWV на топ-шаблонах, чистий sitemap.
4. P2 і система
Плагін inventory, моніторинг, регламент релізів, внутрішня перелінковка money-URL, документація для розробників.
5. Повторний замір 14/28 днів
Ті самі метрики, що в baseline. Інакше технічні правки «розчиняються» в інших змінах маркетингу.
Типові помилки
- Ставити noindex на весь /blog/ «тимчасово» і забути.
- Тримати staging відкритим для індексації.
- Кешувати HTML з set-cookie / персоналізацією без варіантів.
- Ламати layout відкладеним CSS (CLS/FOUC) заради PageSpeed.
- Ігнорувати 5xx під час деплою в прайм-тайм crawl.
- Плодити теги/архіви як SEO-розділи без попиту.
- Міняти пермалінки без карти 301.
- Оптимізувати CWV лише на головній.
- Вважати зелений PageSpeed = SEO зроблено.
Специфіка WordPress: що відрізняє його від «абстрактного» техSEO
Універсальні чеклісти crawl/index/CWV працюють скрізь. На WordPress додається шар CMS-реалій: пермалінки, CPT, таксономії, REST API, cron, object cache, мультисайт, велика кількість плагінів із різною якістю коду.
Пермалінки і історія URL
Зміна структури постійних посилань без карти 301 — одна з найдорожчих помилок. Навіть «красивіший» slug не окупає втрату накопиченої історії. Якщо змінюєте — робіть це як міграцію: карта, 301, оновлення внутрішніх лінків, контроль GSC.
CPT і таксономії
Послуги, кейси, міста, продукти — зручні як CPT, але кожен публічний тип потребує політики: чи в sitemap, який шаблон, який canonical, чи потрібні архіви. Порожні архіви CPT часто стають soft 404.
REST API і безпека crawl
Не блокуйте все підряд заради «безпеки». Закрийте те, що не має індексуватися, але залиште шлях до ресурсів, без яких ламається CSS/JS рендер. Перевіряйте 403 для Googlebot після встановлення security-плагінів.
WP-Cron, кеш і «привиди» контенту
Застарілий page cache може віддавати старі title/canonical після міграції. Object cache й CDN іноді тримають HTML довше, ніж очікує маркетинг. Після критичних SEO-змін робіть точковий purge money-URL і перевіряйте очима + URL Inspection.
Внутрішня перелінковка як технічний важіль
На WordPress внутрішні лінки часто «випадкові»: меню, related posts плагін, футер. Для технічного шару важливо, щоб money-URL отримували стабільні лінки з шаблонів і хабів, а не лише з разових згадок у блозі.
Orphan і глибина кліку
Сторінки послуг, які існують лише в sitemap і рекламі, індексуються гірше. Перевіряйте orphan у краулері. Ціль — 2–3 кліки від головної до ключових послуг.
Карта теми замість десяти однакових лонгрідів
Цей гайд тримає загальну карту технічного SEO на WordPress. Глибші розбори CWV, crawl budget, robots, міграцій і індексації виносяться в окремі статті — так легше оновлювати практику й не плодити дублі.
Хостинг, TTFB і кеш-шар
TTFB — частина технічного SEO, бо впливає на LCP і на те, як часто бот готовий повертатися. На WordPress TTFB псують: холодний PHP без page cache, важкі запити до БД, синхронні HTTP-виклики плагінів, географічно далекий origin без CDN.
Міні-чекліст TTFB
- page cache для анонімів на money-шаблонах;
- object cache (Redis/Memcached) для повторюваних запитів;
- очищення revisions/transients (окремо варто розібрати database bloat);
- CDN для статики; HTML — лише якщо розумієте варіанти кешу;
- не ганяти важку логіку в
wp_headна кожен запит.
Вибір хостингу під SEO
«Найдешевший shared» може бути прийнятним для візитки, але провалюється на каталозі чи builder-сторінках. Для комерції важливі: PHP 8.x, HTTP/2/3, можливість серверного кешу, доступ до логів, адекватний CPU під пікові краули.
Schema і технічна розмітка без спаму
Розмітка допомагає розуміти тип сторінки, але не лікує індексацію. На WordPress небезпека — дублі Organization/WebSite/Article від теми + SEO-плагіна + окремих модулів.
Правила
- один відповідальний джерело schema (зазвичай SEO-плагін);
- тип розмітки має відповідати шаблону (послуга ≠ Product без товару);
- FAQ schema — лише якщо FAQ видимий у HTML;
- після змін — перевірка Rich Results / Schema validator на вибірці.
Безпека, яка впливає на SEO
Хаки й malware часто додають spam-URL, приховані редіректи й doorways. Технічне SEO включає контроль: підозрілі нові публікації, неочікувані users, скачки crawl на сміттєві шляхи, зміна home URL.
- оновлення ядра/тем/плагінів за регламентом;
- обмеження прав і 2FA;
- моніторинг file integrity;
- швидкий rollback, якщо після оновлення впав HTML або зʼявився noindex.
Практичні орієнтири з проєктів
На WordPress-проєктах агентства ми фіксуємо baseline до змін: індексація money-URL, TTFB шаблонів, частка брендового трафіку, кількість органічних лідів. Після хвилі P0 порівнюємо ті самі метрики через 14 і 28 днів — інакше складно довести ефект технічних і стратегічних правок.
Внутрішні посилання між цим гайдом і суміжними статтями тримають тему зібраною: читач бачить наступний крок, а не набір розрізнених постів.
Якщо ви масштабуєте команду, заведіть Definition of Done для SEO-задач: критерій приймання в GSC/GA4, скрін до/після, власник URL. Це зменшує сценарій «зробили правку, але ніхто не перевірив індексацію».
Глибока діагностика індексації на WordPress
Індексація — це не бінарна кнопка «в індексі / не в індексі». У Search Console ви бачите спектр станів: проіндексовано, проскановано але не проіндексовано, виявлено але не проскановано, виключено через noindex, дубль без user-selected canonical, soft 404, редірект, 404. Для WordPress кожен стан має типові причини в темі, плагінах або політиці URL.
Crawled — currently not indexed
Часто означає, що Google бачив URL, але не вважає його достатньо цінним або унікальним. На блогах із тонким шаблоном тегів і «порожніми» CPT-архівами це нормальна реакція системи якості. Лікування — не «просити індексацію» сотнями URL, а підвищити якість шаблону, внутрішні лінки й унікальність, або свідомо noindex-нути сміття.
Discovered — currently not crawled
Сигнал черги й пріоритетів. Якщо money-URL довго висять у цьому статусі, перевірте: чи є на них внутрішні лінки, чи не заблоковані в robots, чи не перевантажений сайт параметрами, чи адекватний TTFB. Іноді допомагає посилення внутрішніх лінків і чистий sitemap; рідко допомагає лише кнопка Inspection.
Soft 404 на WordPress
Сторінка віддає 200, але виглядає порожньою: «нічого не знайдено», порожній архів, категорія без товарів, лендінг білдера без контенту в HTML. Google може трактувати це як soft 404. Рішення: реальний 404/410 для мертвих сутностей, редірект на батьківський розділ, або нормальний контент і статус 200 лише там, де сторінка справді корисна.
Duplicate, Google chose different canonical
Типово для www/non-www, http/https, параметрів сортування, print-версій, пагінації, локалізованих дублів. Зведіть внутрішні лінки й sitemap до одного канонічного хоста. Усуньте конфлікт SEO-плагінів. Не чекайте, що canonical «сам усе виправить», якщо сайт активно лінкує на дублі.
Render, JavaScript і page builders
Google вміє рендерити JS, але це дорожче й менш передбачувано, ніж віддати контент у першому HTML. На WordPress page builders інколи відкладають текст у клієнтський рендер або ламають критичні блоки при відкладенні скриптів.
Як перевірити
- View-source / curl без JS — чи є H1 і абзаци?
- URL Inspection → rendered HTML — чи збігається з тим, що бачить користувач?
- Мобільний емulator + повільний CPU — чи не зникає контент після «оптимізації» скриптів?
- Порівняйте шаблон послуги з шаблоном блогу: інколи блог у темі статичний, а лендінги — лише в білдері.
Що робити
- тримати ключовий текст у HTML, а не в вкладках, які підвантажуються окремим XHR без SSR;
- не агресивно delay-ити скрипти білдера на money-URL без регресійного тесту;
- прибрати зайві анімації й віджети, які тягнуть кілобайти JS ради декора;
- для критичних лендінгів розглянути легший шаблон теми замість універсального «все на Elementor».
WooCommerce і технічне SEO каталогу
Якщо WordPress використовується як магазин, технічний шар розширюється: фасети, варіації, out-of-stock, product schema, фіди. Детальна e-com стратегія живе в окремому хабі SEO інтернет-магазину; тут — точки дотику з технічним фундаментом.
Фасети й параметри
Allowlist індексованих комбінацій, решта — noindex або нелінковані. Не віддавайте в sitemap усі комбінації фільтрів. Стежте, щоб Ajax-фільтри не створювали тисячі crawlable URL без попиту.
Продуктивність лістингів
Категорії з важкими зображеннями, lazy-load без розмірів і сторонні віджети швидко вбивають LCP. Оптимізуйте шаблон категорії так само серйозно, як картку товару.
Аналітика для технічного SEO
Без вимірювання технічні правки перетворюються на «здається, стало краще». Мінімальний набір:
- GSC API або регулярні експорти Pages / Performance по money-path;
- GA4: органічні сесії й конверсії по шаблонах (content group / path regex);
- uptime і 5xx з розбиттям по URL;
- CrUX History або GSC CWV report;
- лог-семпли Googlebot після великих релізів.
Пастки
Не змішуйте ефект техніки з одночасним запуском Ads або масовим контентом. Фіксуйте дату релізу й дивіться cohort URL. Для міграцій тримайте окремий dashboard: 404 hits, redirect chains, indexed pages, organic leads.
Як організувати роботу команди
Технічне SEO провалюється, коли SEO пише «потрібно прискорити сайт», а розробка чує «зменшити розмір картинок». Потрібна спільна мова задач.
Формат тікета
- URL / шаблон;
- проблема й доказ (GSC, CrUX, crawl, скрін);
- очікуваний результат і метрика;
- ризики (кеш, персоналізація, A/B);
- план перевірки після релізу.
Ролі
SEO формулює пріоритет і DoD, розробник реалізує, маркетинг підтверджує бізнес-URL, DevOps/хостинг закриває кеш і алерти. Без owner задача «повисає в Slack».
Каденс
Щотижневий tech SEO sync на 30 хвилин: нові GSC-аномалії, статус P0, найближчі релізи. Щомісяця — перегляд backlog і відмова від задач без впливу.
Бюджет, терміни й очікування ROI
Технічне SEO рідко дає «вибух завтра», але швидко знімає стелю: індексація money-URL, стабільність після релізів, краща конверсія завдяки швидкості. Орієнтири для бізнесу:
| Обсяг сайту | Аудит | P0 | Перші стабільні сигнали |
|---|---|---|---|
| До 100 URL | 3–7 днів | 1–2 тижні | 2–4 тижні |
| 100–2 000 URL | 1–2 тижні | 2–4 тижні | 4–8 тижнів |
| Великий каталог | 2–4 тижні | ітерації | залежить від crawl і релізів |
ROI рахуйте через ліди/виручку з органіки money-landing і зниження вартості залучення, а не через позицію одного інформаційного запиту.
Квартальний технічний чекліст
- Inventory плагінів і вимкнення мертвих.
- Перевірка staging/noindex/robots на проді.
- Вибірка money-URL у Inspection.
- Оновлення карти редиректів після контент-чисткі.
- CWV field по ключових path.
- Бекап і тест відновлення (техборг безпеки = SEO-ризик).
- Ревʼю прав користувачів WP і підозрілого контенту.
- Оновлення документації шаблонів для нової людини в команді.
Інструменти: достатній мінімум
- Google Search Console + CrUX/PSI;
- краулер (Screaming Frog / Sitebulb);
- доступ до логів або CDN analytics;
- Query Monitor / New Relic на стейджі для важких запитів;
- галерея скрінів до/після для стейкхолдерів.
Не збирайте зоопарк із десяти «all-in-one SEO suites», якщо команда не читає звіти. Краще три інструменти в процесі, ніж двадцять у підписці.
Патерни з практики (без казки «+400% за тиждень»)
Найчастіші виграші технічного шару на WordPress, які ми бачимо повторювано:
- закриття сміттєвих фасетів → зростання crawl money-категорій;
- відновлення індексації послуг після випадкового noindex в SEO-плагіні;
- скорочення LCP hero на лендінгу з формою → ріст конверсії з органіки;
- карта 301 під редизайн → збереження 70–90%+ запитів на ключових URL замість «обнулення»;
- прибирання дубля schema/плагінів → чистіші снипети й менше конфліктів у GSC.
Цифри завжди залежать від ніші й конкуренції; обіцянка «гарантованих позицій» — червоний прапор. Чесний контракт: прозорі метрики, пріоритети, ітерації.
Staging, preview і середовища
Окреме середовище розробки рятує прод від чернеток, але стає SEO-бомбою, якщо його відкрити для індексації або якщо віджети аналітики/чату на staging починають слати події в бойові лічильники.
Правила staging
- HTTP auth або IP allowlist +
noindex, nofollow+ Disallow у robots staging; - окремі ключі GTM/GA4 або взагалі вимкнена аналітика;
- нелінкованість зі зовнішніх майданчиків;
- після клонування з прода — негайна перевірка, що home/siteurl не вказують на staging і навпаки;
- у SEO-плагіні на staging увімкнути «discourage search engines», але не покладатися лише на це.
Preview і draft URL
Посилання превʼю з токенами не повинні потрапляти в sitemap чи внутрішню перелінковку. Якщо редактор ділиться draft-лінком у Slack — ок; якщо той самий URL випадково опиняється в меню — вже інцидент.
HTTP-заголовки, CDN і краулінг
Кеш-заголовки, compression, HTTP/2, коректний Content-Type і відсутність випадкового X-Robots-Tag: noindex на CDN — частина технічного SEO. Ми неодноразово бачили, як правило CDN для «всього /wp-admin» випадково чіпало публічні шляхи або віддавало stale HTML після міграції.
CDN-чекліст
- HTML money-URL: зрозуміла політика cache (часто bypass або короткий TTL з purge API);
- статика: довгий TTL + fingerprint імен файлів;
- гео: PoP ближче до аудиторії UA/EU;
- після purge — контроль HTML canonical/title на 3–5 URL;
- логи CDN інколи зручніші за origin для аналізу ботів.
Доступність і SEO: перетин, не підміна
a11y не дорівнює SEO, але перетинається: коректні заголовки, alt, контраст, фокус на формах впливають на UX і опосередковано на конверсію з органіки. Для технічного шару важливо не ламати семантику HTML білдером (дивні рівні заголовків, кнопки як div, контент лише в canvas).
Міжнародність: короткий техмінімум
Повний міжнародний хаб — окремо. Техмінімум на WordPress: один канонічний URL на мовну версію, узгоджені hreflang, відсутність авторедіректу лише за IP без можливості дійти до потрібної мови, окремі sitemaps або зрозумілі секції. Не змішуйте переклад меню з індексацією чорнових мов.
Межа між технічним і контентним SEO
Техніка створює можливість бути знайденим і прочитаним. Контент закриває інтент. Стратегія обирає, які money-теми масштабувати. Якщо технічний борг червоний, спочатку приберіть блокери індексації й рендеру — інакше новий контент ляже в «discovered not crawled». Якщо техніка зелена, а сторінки тонкі — вже зона контенту й brief, не ще один плагін кешу.
Практичне правило пріоритизації: якщо money-URL відсутні в індексі або віддають порожній HTML — це P0 техніки. Якщо вони в індексі, але не конвертять через слабкий офер — це продукт/CRO/контент. Якщо в індексі й конвертять, але мало попиту покрито — семантика й контент-план.
Оновлення ядра, тем і плагінів без SEO-регресій
Регламент оновлень — частина технічного SEO. Оновлення «всіх плагінів у пʼятницю ввечері на проді» без бекапу — антипатерн.
- Бекап файлів і БД.
- Оновлення на staging.
- Чек money-URL: код відповіді, title, canonical, форма, LCP-герой.
- Оновлення на проді в низьке навантаження.
- Purge кешу + Inspection вибірки.
- Моніторинг 5xx/404 24 години.
Окремо тестуйте major-оновлення page builder і SEO-плагіна: саме вони найчастіше змінюють HTML head.
Definition of Done для технічних задач
Задача «виправити canonical» закрита не тоді, коли «закомітили», а коли:
- на проді в HTML бачимо очікуваний тег;
- кеш очищено;
- URL Inspection показує user-declared / Google-selected узгоджено (або зафіксовано розбіжність із поясненням);
- внутрішні лінки більше не ведуть на дубль;
- результат записаний у changelog SEO.
Такий DoD зменшує сірі зони між SEO і розробкою й накопичує інституційну памʼять команди.
FAQ
Чи достатньо Yoast/Rank Math для технічного SEO?
Плагін допомагає з title, sitemap і schema, але не замінює політику індексації, CWV, логі, міграції й контроль релізів. Це інструмент, не стратегія.
Чи потрібне технічне SEO маленькому сайту на 20 сторінок?
Так, але коротший цикл: індексація money-URL, коректні редіректи, швидкість шаблону з формою, гігієна релізів. Crawl budget тут рідко головна тема.
Elementor / page builder — це виророк для SEO?
Ні, якщо контент є в HTML, LCP контрольований, а зайві скрипти не вбивають INP. Проблема не в білдері «в принципі», а в важких віджетах і відсутності дисципліни шаблонів.
Коли робити повний технічний аудит?
Перед масштабуванням контенту, після просідання трафіку, перед/після міграції, при зміні теми чи білдера, коли GSC показує системні виключення.
Скільки триває впровадження P0/P1?
P0 часто 1–2 тижні при доступі до деву й хостингу. P1 — від 3–6 тижнів залежно від боргу й реліз-циклу. Точні терміни залежать від обсягу URL і якості середовища.
Як технічне SEO впливає на видимість у AI Overviews?
AI-системи теж потребують доступного, зрозумілого контенту й чистої структури. Технічний шар не замінює сутності й експертність, але без нього сторінку складніше коректно прочитати й процитувати.
Матриця пріоритетів: що робити першим
Коли backlog роздутий, матриця рішень рятує від хаосу. Оцінюйте задачу за двома осями: вплив на money-URL / ліди та складність впровадження.
| Тип задачі | Вплив | Складність | Пріоритет |
|---|---|---|---|
| Випадковий noindex на проді | Дуже високий | Низька | P0 зараз |
| Порожній HTML money-лендінгу | Дуже високий | Середня | P0 |
| Сміттєві фасети в індексі | Високий | Середня/висока | P1 |
| LCP hero на топ-послузі | Високий | Середня | P1 |
| Прибирання мертвих плагінів | Середній | Низька | P2 регулярно |
| Косметика PageSpeed на архіві тегів | Низький | Середня | Не робити першим |
Правило: не витрачайте спринт на задачі з низьким впливом, поки відкриті P0. Технічне SEO виграє не кількістю тікетів, а закриттям блокерів росту.
Висновок і наступний крок
Технічне SEO на WordPress — це керована система: discoverability → crawl → render → performance → release hygiene. Почніть з money-URL і GSC, закрийте P0, виміряйте baseline через 14 і 28 днів, і лише потім масштабуйте контент і лінкбілдінг.
Потрібна команда, яка закриє технічний шар під ключ: звʼяжіться з SEO-Studio — зробимо аудит і roadmap під ваш WordPress. Паралельно дивіться суміжні гайди у змісті та блоці повʼязаних матеріалів нижче та сусідні гайди з контенту й стратегії.