Це не рідкісна ситуація. Це стандартна поведінка WordPress.

WordPress вміє генерувати адаптивні зображення через srcset з 2015 року, а WebP, з 2022. Але <picture>, HTML-елемент, який дозволяє браузеру вибирати між форматами, досі не з’явився в ядрі. І це конкретна втрата: важчі файли, повільніший LCP, гірші позиції там, де конкурент з ідентичним контентом оптимізував зображення правильно.

У цій статті розберемо, в чому різниця між srcset і <picture>, чому WordPress досі не перейшов на <picture>, що ви втрачаєте без нього, і як виправити це без злому ядра, кількома рядками PHP або плагіном.

srcset і <picture>: в чому принципова різниця

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

srcset, атрибут тегу <img>, який дає браузеру список варіантів одного зображення різних розмірів:

<img src="photo-800w.jpg"
 srcset="photo-400w.jpg 400w, photo-800w.jpg 800w, photo-1200w.jpg 1200w"
 sizes="(max-width: 600px) 400px, 800px"
 alt="Опис зображення">

Браузер вибирає розмір залежно від ширини екрану і щільності пікселів, і завантажує відповідний файл. Але є обмеження: браузер вибирає між варіантами одного формату. Якщо в srcset тільки JPEG, він завантажить JPEG, незалежно від того, чи підтримує цей браузер WebP або AVIF.

<picture>, контейнер, який дозволяє задати кілька форматів з умовами вибору:

<picture>
 <source srcset="photo.avif" type="image/avif">
 <source srcset="photo.webp" type="image/webp">
 <img src="photo.jpg" alt="Опис зображення">
</picture>

Логіка проста: браузер перевіряє <source> зверху вниз. Підтримує AVIF, завантажує AVIF. Ні, перевіряє WebP. Ні, бере <img src> як fallback. Тег <img> завжди залишається і завжди є fallback для старих браузерів.

Коротко: srcset вирішує питання розміру, <picture> вирішує питання формату (і може вирішувати обидва одночасно). Детальна специфікація елемента доступна на MDN Web Docs.

Art direction: різні кадри для різних екранів

<picture> вирішує ще одну задачу, яку srcset не може, art direction. Це коли на мобільному і десктопі показується різне зображення, а не просто менший варіант того самого:

<picture>
 <source media="(max-width: 767px)" srcset="hero-mobile.webp" type="image/webp">
 <source media="(max-width: 767px)" srcset="hero-mobile.jpg">
 <source media="(min-width: 768px)" srcset="hero-desktop.webp" type="image/webp">
 <img src="hero-desktop.jpg" alt="Головна сторінка">
</picture>

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

Чому WordPress досі не використовує <picture>

WordPress додав підтримку srcset у версії 4.4 (грудень 2015). Генерацію WebP при завантаженні, у 6.1 (листопад 2022). Але <picture> в ядрі досі немає. Причини реальні.

Зворотна сумісність. Мільйони тем і плагінів стилізують напряму через CSS-селектори типу .content img, figure img, article img. Якщо WordPress раптово почне обгортати кожен img у <picture>, частина цих стилів перестане працювати. Selectors перестануть збігатися. Layouts поламаються. Це ризик, на який ядро не готове без довгого перехідного періоду.

Складність генерації файлів. <picture> з кількома форматами вимагає, щоб на сервері існували JPEG, WebP і AVIF версії кожного зображення. WordPress вже генерує кілька розмірів при завантаженні, додати ще кілька форматів означає суттєво збільшити навантаження на CPU і дисковий простір при кожному upload.

AVIF нерівномірний. Хоча більшість сучасних браузерів підтримують AVIF, час декодування на старих або слабких пристроях може бути гіршим ніж WebP. WordPress ядро консервативне в таких рішеннях.

Результат: WordPress генерує WebP (якщо сервер підтримує GD або Imagick з WebP), але обгортає зображення тільки у <img> з srcset. Браузер отримує набір розмірів одного формату, і ніколи не дізнається, що є WebP або AVIF версія, бо їх ніхто не пропонує.

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

Що ви втрачаєте без адаптивних зображень у сучасних форматах

Перейдемо до цифр, щоб зрозуміти реальний масштаб проблеми.

Різниця у вазі файлів

Типове фото 1200×800px у різних форматах:

• JPEG (якість 80%): 180–230 KB
• WebP: 80–120 KB
• AVIF: 45–75 KB

Різниця між JPEG і AVIF, в 3–4 рази. Якщо на сторінці 6–8 зображень, це 600–900 KB зайвого трафіку для кожного відвідувача з браузером, що підтримує AVIF, Chrome, Firefox, Safari 16+. А це більше 90% вашої аудиторії вже сьогодні — перевірити підтримку конкретних браузерів можна на caniuse.com.

Важливий нюанс: AVIF підтримується у браузерах, але не кожен сервер вміє його генерувати. PHP-функція imageavif() з’явилась у PHP 8.1 і вимагає libavif. Якщо ваш хостинг на PHP 7.x або старому GD — AVIF недоступний без плагіна. У такому випадку WebP вже дає суттєву перевагу порівняно з JPEG: зменшення ваги на 25–35% без втрати якості.

Вплив на LCP і ранжування

LCP (Largest Contentful Paint), у більшості випадків це завантаження головного зображення сторінки. Hero-блок, featured image, продуктова фотографія. Якщо воно важить 230 KB замість 65 KB, різниця у часі завантаження на 4G мобільному може становити 2–3 секунди.

Google використовує Core Web Vitals як сигнал ранжування. Пороговий LCP для “доброго” результату, 2.5 секунди. Сайти з LCP 5+ секунд конкурують з суттєвою невигодою навіть при однаковій якості контенту. Детально про те, що означають ці метрики для вашого бізнесу, у нашій статті про Core Web Vitals.

Іванна запустила інтернет-магазин одягу на WordPress у 2024 році. Фотографії товарів, в середньому 280 KB у JPEG, бо фотограф здавав файли “як є”. PageSpeed на мобільному, 47. Після масової конвертації в WebP і AVIF через Imagify і додавання <picture> через плагін: середня вага фото впала до 72 KB, LCP, з 6.1 до 2.4 секунди, PageSpeed, з 47 до 79. За два місяці органічний трафік виріс на 28%, а bounce rate на мобільному знизився з 74% до 51%.

Мобільний трафік і ліміти даних

В Україні мобільний трафік складає 55–65% для більшості сайтів. Мобільні користувачі, особливо ті, хто дбає про витрати трафіку, відчувають різницю між сайтом, що завантажує 1.5 MB зображень, і сайтом з 400 KB. Частина просто закриє вкладку.

Адаптивні зображення WordPress у форматі AVIF через <picture> — це не тільки про SEO. Це про те, скільки мегабайт мобільного трафіку ваш сайт “з’їдає” у кожного відвідувача. Для ecommerce-сайтів з десятками фото на сторінці каталогу різниця між JPEG і AVIF — це різниця між 3 MB і 700 KB на один перегляд.

Які зображення оптимізувати першими

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

1. Hero-зображення і featured images — зазвичай найважчі і найчастіше є LCP-елементом. Пріоритет максимальний.
2. Зображення вище fold — все, що видно без прокрутки. Завантажуються першими і безпосередньо впливають на FCP і LCP.
3. Зображення в картках товарів або постів — особливо на сторінках категорій з 20+ зображеннями.
4. Зображення нижче fold — менш критичні для Core Web Vitals, але все одно впливають на загальний розмір сторінки.

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

Як виправити: <picture> на WordPress

Є два шляхи, PHP-хук для точного контролю або плагін для швидкого старту.

Спосіб 1: PHP-хук (без плагінів)

З WordPress 6.0 є фільтр wp_content_img_tag, він перехоплює кожен в контенті перед рендерингом. Додайте у functions.php вашої теми або в mu-plugin:

add_filter( 'wp_content_img_tag', function( $filtered_image, $context, $attachment_id ) {
 if (! $attachment_id ) {
 return $filtered_image;
 }

 $upload_dir = wp_upload_dir();
 $src = wp_get_attachment_url( $attachment_id );
 $path = str_replace( $upload_dir['baseurl'], $upload_dir['basedir'], $src );

 $avif_path = preg_replace( '/\.(jpe?g|png)$/i', '.avif', $path );
 $webp_path = preg_replace( '/\.(jpe?g|png)$/i', '.webp', $path );

 $avif_url = file_exists( $avif_path ) ? str_replace( $upload_dir['basedir'], $upload_dir['baseurl'], $avif_path ): null;
 $webp_url = file_exists( $webp_path ) ? str_replace( $upload_dir['basedir'], $upload_dir['baseurl'], $webp_path ): null;

 if (! $avif_url && ! $webp_url ) {
 return $filtered_image;
 }

 $sources = '';
 if ( $avif_url ) {
 $sources .= sprintf( '<source srcset="%s" type="image/avif">', esc_url( $avif_url ) );
 }
 if ( $webp_url ) {
 $sources .= sprintf( '<source srcset="%s" type="image/webp">', esc_url( $webp_url ) );
 }

 return sprintf( '<picture>%s%s</picture>', $sources, $filtered_image );
}, 10, 3 );

Логіка проста: якщо поруч з оригінальним файлом є .avif або .webp версія, обгортаємо в <picture> з відповідними <source>. Якщо немає, повертаємо <img> без змін. Fallback завжди є.

Генерація WebP і AVIF при завантаженні

Щоб хук мав що обгортати, потрібні WebP і AVIF файли. WordPress 6.1+ генерує WebP автоматично при наявності відповідної підтримки у GD або Imagick. Для AVIF, потрібен Imagick 7+ з підтримкою libavif. Додайте у functions.php:

add_filter( 'wp_upload_image_mime_transforms', function( $transforms ) {
 foreach ( $transforms as &$mime_transforms ) {
 $mime_transforms[] = [
 'output_format' => 'image/avif',
 'quality' => 75,
 ];
 }
 return $transforms;
} );

Важливо: генерація AVIF CPU-інтенсивна. На слабкому хостингу завантаження великих зображень може займати кілька секунд. Якщо ваш хостинг не справляється, розгляньте варіанти: або зовнішній сервіс оптимізації, або перехід на кращий сервер. Що враховувати при виборі WordPress-хостингу, розглядаємо окремо.

Спосіб 2: Плагін

Якщо PHP, не ваша зона, є плагіни:

• Imagify, конвертує в WebP і AVIF, є опція “Use <picture> tag”. Безкоштовний ліміт 20 MB на місяць, потім від $4.99/міс.
• ShortPixel, аналогічний функціонал, безкоштовно 100 зображень на місяць.
• Optimole, хмарна оптимізація і CDN, автоматично подає правильний формат через свій проксі.

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

Art direction для hero-блоків

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

function smtv_picture( $desktop_id, $mobile_id, $alt = '', $class = '' ) {
 $desktop_url = wp_get_attachment_url( $desktop_id );
 $mobile_url = wp_get_attachment_url( $mobile_id );

 return sprintf(
 '<picture class="%s">
 <source media="(max-width: 767px)" srcset="%s" type="image/webp">
 <source media="(max-width: 767px)" srcset="%s">
 <img src="%s" alt="%s" loading="lazy" decoding="async">
 </picture>',
 esc_attr( $class ),
 esc_url( preg_replace( '/\.(jpe?g|png)$/i', '.webp', $mobile_url ) ),
 esc_url( $mobile_url ),
 esc_url( $desktop_url ),
 esc_attr( $alt )
 );
}

Викликайте у шаблоні теми, передаючи ID десктопного і мобільного зображення окремо.

Підводні камені при впровадженні

Кілька речей, які варто перевірити після додавання <picture>.

CSS-стилі. Якщо тема стилізує article img { max-width: 100%; }, після обгортання в <picture> стилі залишаться на <img>, все буде добре. Але якщо є селектор article > img (прямий нащадок), він перестане збігатися, бо тепер між article і img стоїть picture. Перевірте стилі теми.

Lazy loading. Атрибут loading="lazy" треба ставити на <img> всередині <picture>, не на <source>. WordPress автоматично додає loading="lazy" до <img>, переконайтесь, що він зберігається після обгортання хуком.

Кешування. Після змін обов’язково очистіть кеш (WP Rocket, LiteSpeed Cache, або серверний кеш) і перевірте кілька сторінок, що кешовані версії теж показують <picture>.

Перевірка в DevTools. Network → Images, перевірте, що тип файлів у колонці Type показує image/avif або image/webp, а не image/jpeg. Якщо все ще JPEG, або файли не згенеровані, або хук не спрацьовує.

fetchpriority для LCP-зображення. Якщо головне зображення сторінки (hero) є LCP-елементом, додайте fetchpriority="high" до тегу <img> всередині <picture>. Це підказує браузеру завантажити його першочергово, ще до завершення парсингу DOM. Без цього атрибута браузер може відкласти завантаження hero-зображення на кілька сотень мілісекунд, навіть якщо воно знаходиться вгорі сторінки.

Результати: що очікувати

За нашим досвідом оптимізації WordPress-сайтів після впровадження <picture> з WebP/AVIF:

• Середня вага зображень знижується на 40–65%
• LCP покращується на 1.5–3.5 секунди (залежно від початкового стану і ваги hero-зображення)
• PageSpeed Insights перестає показувати попередження “Serve images in next-gen formats”
• Мобільний bounce rate знижується на 10–25% (при умові, що зображення були основним гальмом)

Варто розуміти, що адаптивні зображення WordPress — це не срібна куля. Якщо LCP-елемент — це текст або кнопка, а не зображення, ефект буде мінімальним. Але якщо основна гальмівна точка — саме завантаження зображень (що трапляється у 70–80% сайтів на WordPress з нативними темами), <picture> з AVIF/WebP — це найшвидший шлях до помітного результату.

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

Висновок

WordPress застряг між 2015 роком (srcset) і можливостями сучасних браузерів (AVIF, art direction). <picture> закриває цей розрив: браузер отримує вибір формату і завантажує зображення в 3–4 рази менше за розміром без видимої різниці у якості.

Для бізнесу, це конкретні числа: швидший LCP, краще ранжування в Google, менше відмов на мобільному. Для розробника, кілька годин роботи: налаштування генерації WebP/AVIF і один PHP-хук або плагін.

Якщо хочете перевірити стан зображень на вашому сайті або впровадити <picture> як частину технічної SEO-оптимізації, зв’яжіться з нами. Розберемо конкретно, що гальмує ваш сайт і що дасть найбільший ефект першим кроком.

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

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

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

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

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

Чому вибір хостингу критичний для WordPress-сайту

Як хостинг впливає на швидкість і Core Web Vitals

TTFB (Time to First Byte) — перший байт, який ваш сервер відправляє браузеру користувача. Google враховує його в Core Web Vitals, а Core Web Vitals — у ранжуванні. Хороший показник: до 200 мс. Поганий: 800+ мс — і у вас вже проблема незалежно від того, скільки плагінів оптимізації ви встановили.

Хостинг визначає базовий TTFB. Кешування, LiteSpeed, локація дата-центру — все це безпосередньо впливає на першу цифру, яку бачить Google. Ніякий WP Rocket не врятує сайт на повільному shared-сервері з Apache і переповненим пулом PHP-процесів. Якщо ви хочете дізнатись більше про те, як технічні параметри впливають на ранжування, читайте мій матеріал Чому WordPress-сайт вантажиться повільно — і як це виправити.

Ризики дешевого хостингу для бізнесу

Клієнтська історія №1. До мене звернулася власниця невеликого інтернет-магазину одягу. Хостинг коштував 40 грн/міс — здавалося, вдале рішення. Але сайт вантажився 6–8 секунд, а раз на тиждень падав на 15–20 хвилин. Вона не знала, що втрачає покупців: аналітика показувала відмови понад 70% на сторінках товарів. Після міграції на нормальний хостинг для WordPress сайту Україна TTFB впав з 1,4 с до 280 мс. Конверсія зросла на 34% за перший місяць.

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

Що шукати в хостингу для WordPress — 7 ключових критеріїв

1. Тип веб-сервера: LiteSpeed vs Apache/Nginx

LiteSpeed — це не маркетинговий слоган, а реальна технічна перевага. Він обробляє статичні файли у 5–6 разів швидше за Apache і має вбудований кеш LSCache, який чудово інтегрується з WordPress. Якщо хостинг пропонує LiteSpeed — це великий плюс.

Apache без caching layer — ознака застарілої інфраструктури. Nginx сам по собі швидкий, але потребує правильного конфігурування, якого на дешевому shared-хостингу зазвичай немає.

2. Локація сервера — Україна чи Польща?

Для UA-аудиторії найкраще підходять сервери в Україні, Польщі або Нідерландах. Різниця в латентності між Україна→Польща і Україна→США — від 30 мс до 120+ мс. Для TTFB це суттєво.

Після 2022 року деякі провайдери перенесли частину інфраструктури з України до ЄС — це виправдане рішення з точки зору надійності. Польща і Франкфурт — оптимальні локації для українських бізнесів, які хочуть стабільність і швидкість одночасно.

3. Uptime-гарантії та SLA

Мінімально прийнятний рівень — 99,9% (≈ 8,7 годин простою на рік). Хороший — 99,95%+. Відмінний — 99,98–99,99% (≈ 1,7–8 хвилин/рік).

Але важливо не лише число на сайті, а реальний моніторинг. Перевірте historичний uptime провайдера на UptimeRobot або StatusPage — деякі компанії публікують відкриті статус-сторінки.

4. Щоденні резервні копії

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

5. Підтримка українською — швидкість і якість

Для бізнесу важлива підтримка 24/7 з відповіддю до 5 хвилин і розумінням WordPress-специфіки. Питання “чому мій плагін не бачить .htaccess” не повинно закінчуватись відповіддю “встановіть інший плагін”.

6. Ціна та прозорість тарифів

Дивіться на ціну renewal, а не лише на акційну. Деякі міжнародні провайдери пропонують $2,99/міс на рік, а на другий рік виставляють $12–14/міс. Читайте дрібний шрифт.

7. WP-специфічні функції

• Автоматична установка WordPress (Softaculous або власний інсталятор)
• Staging-середовище для тестування оновлень
• LSCache або вбудована WP-оптимізація
• Підтримка PHP 8.1–8.3 (PHP 7.x — застаріла версія, яка не отримує патчів безпеки)
• PHP RAM від 256 МБ (для WooCommerce — від 512 МБ)

Детальніше про безпеку і захист WordPress-сайту читайте в статті WordPress безпека для бізнесу: захист сайту від зламу.

Огляд хостинг-провайдерів для WordPress в Україні

HOSTiQ — лідер ринку

HOSTiQ заснований у 2013 році і на сьогодні має понад 80 000 клієнтів. Це найвідоміший бренд у категорії WordPress хостинг Україна — і не без підстав.

Технічно: LiteSpeed + LSCache активований автоматично для WordPress, сервери в Україні (Львів) і Нідерландах (Роттердам), Imunify360 для захисту, безкоштовний SSL. Підтримка відповідає в чаті приблизно за 60 секунд — це вище за середній показник по ринку.

Тарифи WordPress (березень 2026):

• WordPress20: 189 грн/міс — 10 сайтів, 20 ГБ SSD
• WordPress30: ~237 грн/міс — 20 сайтів, 30 ГБ SSD, безкоштовний домен + SSL
• WordPress60: ~266 грн/міс — 30 сайтів, 60 ГБ SSD + виділений IP

Включено: Rank Math SEO, щоденні бекапи, безкоштовна міграція, 30-денна гарантія повернення коштів. Рейтинг 9,68/10 на основі 3 287 відгуків.

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

HostPro — надійний для бізнесу

HostPro демонструє один з найвищих показників uptime на ринку — 99,98%. Технологічний стек: LiteSpeed, cPanel, PHP 5.2–8.4 (широкий діапазон — плюс для спадкових проектів), MariaDB і PostgreSQL.

Тарифи WordPress (березень 2026):

• Старт: $6,95/міс — 5 сайтів, 20 ГБ SSD, 512 МБ PHP RAM
• Про: $9,95/міс — 15 сайтів, 30 ГБ SSD, 1024 МБ PHP RAM
• Бізнес: $11,20/міс — 30 сайтів, 60 ГБ SSD, 1536 МБ PHP RAM

Включено: безкоштовний SSL (Certum Commercial), безкоштовний домен .com.ua, щоденні бекапи. Підтримка відповідає за 3–5 хвилин.

Висновок: Найкращий вибір для WooCommerce і корпоративних сайтів, де критичний uptime і потрібний великий PHP RAM.

Hostenko — спеціалізований WordPress-хостинг

Hostenko існує з 2011 року і займається виключно WordPress — жодних спільних серверів з “усіма підряд”. Це означає оптимізовану інфраструктуру і команду підтримки, яка знає WP глибоко. Є також WPcafe — навчальна платформа для тих, хто тільки починає з WordPress.

Тарифи (березень 2026):

• Single: 175 грн/міс (2100 грн/рік) — 5 сайтів, 20 ГБ SSD
• Triple: ~292 грн/міс (3500 грн/рік) — 15 сайтів, 40 ГБ SSD
• Lucky: 375 грн/міс (4500 грн/рік) — 30 сайтів, 60 ГБ SSD

Включено: безкоштовний SSL, 30-денні бекапи, 14-денний безкоштовний trial.

Висновок: Трохи дорожчий за конкурентів при схожих характеристиках, але ідеальний для новачків у WordPress завдяки зрозумілому онбордингу.

WPHost.me — нішевий піонер

WPHost.me заснований у 2010 році — перший спеціалізований WordPress/CMS-хостинг в Україні. Рейтинг 9,8/10 на whtop.com. Технологічний стек: SSD + LiteSpeed. Тарифи стартують від 88 грн/міс (березень 2026).

Висновок: Хороший варіант з довгою WP-специфікою і доступною ціною. Менша маркетингова присутність, але якісна технічна основа.

CityHost — доступний варіант

CityHost на ринку з 2005 року. Тарифи WordPress стартують від ~72 грн/міс при річній оплаті (березень 2026) — найнижча ціна серед основних гравців. 10-денний тестовий період.

Висновок: Для бюджетних проектів і сайтів із невеликим трафіком. Не рекомендую для WooCommerce або сайтів із більш ніж 500 відвідувачами на день.

Міжнародні альтернативи: SiteGround та Kinsta

SiteGround ($3,99/міс старт, березень 2026) — чудова технологічна платформа: 11 дата-центрів, CDN, staging, автооновлення WP. Найближчий ДЦ до України — Польща. Мінус: підтримка англійською, оплата в USD/EUR, renewal-ціна значно вища.

Kinsta (від $35/міс, березень 2026) — managed WordPress хостинг на Google Cloud з Cloudflare Enterprise CDN. Для серйозних проектів із великим трафіком це benchmark якості. Але $35/міс за один сайт — не рівень більшості українських бізнесів.

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

Порівняльна таблиця WordPress хостингів Україна 2026

Нижче — зведена таблиця актуальних тарифів і характеристик станом на березень 2026. Вона є основою для вибору найкращого хостингу для WordPress Україна під конкретний сценарій.

Ціни актуальні станом на березень 2026 при річній оплаті. Курс UAH/USD може змінюватись.

Який хостинг обрати — рекомендації за сценарієм

Бюджетний сайт-візитка або блог

Рекомендація: CityHost або WPHost.me (від 72–88 грн/міс)

Якщо у вас сайт-портфоліо, блог або проста сторінка компанії з трафіком до 500 відвідувачів на день — немає сенсу переплачувати. CityHost і WPHost.me забезпечать достатній рівень стабільності за мінімальну ціну.

Корпоративний сайт або Landing Page

Рекомендація: HOSTiQ WordPress30 (~237 грн/міс)

Оптимальне співвідношення ціна/якість. LiteSpeed + LSCache, підтримка українською, 20 сайтів на одному плані, безкоштовна міграція. Для більшості бізнес-сайтів — це “найкращий вибір без зайвих питань”.

Інтернет-магазин на WooCommerce

Рекомендація: HostPro Pro або Бізнес ($9,95–$11,20/міс)

WooCommerce потребує більше PHP RAM (від 512 МБ), стабільного uptime і надійних бекапів. HostPro дає uptime 99,98% і 1024–1536 МБ PHP RAM — це саме те, що потрібно для транзакційного сайту.

Альтернатива: HOSTiQ WordPress60 (~266 грн/міс) з виділеним IP — хороший варіант, якщо хочете залишитись у гривні.

Клієнтська історія №2. Власник магазину автозапчастин мав постійні тайм-аути під час пікового навантаження (п’ятниця-субота). Проблема — PHP RAM 128 МБ на дешевому тарифі. Перейшли на HostPro Про з 1024 МБ RAM. Тайм-аути зникли, сторінки почали відкриватись за 1,2 с замість 4–6 с. Через місяць клієнт написав: “не уявляю, як ми так довго жили з тим хостингом”.

Кілька WP-сайтів (агентство або фрілансер)

Рекомендація: HOSTiQ WordPress60 або HostPro Бізнес (30 сайтів на плані)

Обидва дають 30 сайтів на одному обліковому записі. HOSTiQ зручніший для роботи в гривні та з локальною підтримкою. HostPro — якщо потрібен cPanel і вищий uptime.

Для серйозного масштабу (50+ сайтів або великий трафік) — час переходити на VPS. Після міграції до нового провайдера обов’язково прочитайте покроковий гайд з міграції сайту на WordPress, щоб уникнути простоїв.

Коли переходити на VPS або Managed WordPress

VPS варто розглянути, якщо:

• Ваш сайт отримує понад 5 000 унікальних відвідувачів на день
• Shared-хостинг регулярно обмежує PHP-процеси під час навантаження
• Вам потрібна кастомна конфігурація сервера
• Ви керуєте 20+ сайтами з різними вимогами

Managed WordPress (Kinsta, WP Engine) — для проектів з понад 10 000 відвідувачів/день або де downtime коштує сотні доларів на годину.

Де розміщувати сервер для UA-аудиторії

Якщо 90%+ вашої аудиторії — в Україні, ієрархія вибору локації:

1. Україна (якщо провайдер гарантує надійність) — мінімальний TTFB
2. Польща (Варшава) — 20–30 мс затримки, ідеально для Ukrainian traffic
3. Нідерланди / Франкфурт — 35–50 мс, стандарт для більшості EU-хостингів
4. Лондон / Париж — 50–70 мс, прийнятно
5. США — 100–150+ мс, не рекомендую для UA-аудиторії

Після 2022 року розміщення на серверах у ЄС стало розумним компромісом між швидкістю та надійністю. HOSTiQ пропонує вибір між Україною і Нідерландами — для більшості клієнтів я рекомендую Нідерланди як більш стабільний варіант сьогодні.

Висновок — підсумок і фінальна рекомендація

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

Моя фінальна рекомендаційна карта:

• Бюджетний старт → CityHost або WPHost.me (72–88 грн/міс)
• Оптимальний для бізнесу → HOSTiQ WordPress30 (~237 грн/міс)
• E-commerce / максимум → HostPro Pro/Бізнес ($9,95–$11,20/міс)
• Кілька сайтів → HOSTiQ WordPress60 або HostPro Бізнес
• Міжнародні проекти → SiteGround або Kinsta

І ще раз: я не маю афіліатних угод з жодним хостингом. Саме це дозволяє мені писати те, що я справді думаю — а не те, за що мені заплатили.

Не знаєте, який хостинг обрати для вашого проекту?

Я консультую українські бізнеси щодо вибору хостингу та WordPress-інфраструктури. За 30 хвилин ми розберемо ваш конкретний сценарій — тип сайту, трафік, бюджет — і ви отримаєте чітку відповідь без маркетингу.

Записатись на безкоштовну консультацію → smtv.studio

Пов’язані матеріали: Чому WordPress-сайт вантажиться повільно · WordPress безпека для бізнесу · Міграція сайту на WordPress

Джерела: HOSTiQ WordPress Hosting · HostPro WordPress · Hostenko Pricing · HostAdvice Ukraine

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

У цьому гіді ви отримаєте:

• покрокову інструкцію міграції з Tilda на WordPress та Wix на WordPress окремо для кожної платформи;
• таблицю SEO-ризиків і конкретні рішення для кожного з них;
• чекліст з 32 пунктів — до, під час і після міграції;
• реалістичний таймлайн залежно від розміру вашого сайту.

Чому бізнес переходить з конструктора на WordPress

Обмеження Tilda та Wix для зростання

Конструктори сайтів — чудовий старт. Але є момент, коли вони починають стримувати розвиток.

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

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

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

Фінансовий аргумент: Tilda Business проти хостингу WordPress

Tilda Business коштує від $15 на місяць, а версія з доступом до API та HTML-експорту — від $25. За рік це $180–$300 лише за платформу.

Якісний WordPress-хостинг в Україні — наприклад, HOSTiQ або HostPro — обходиться від $3–5 на місяць при оплаті за рік. Детальне порівняння варіантів — у нашому гайді по WordPress хостингу в Україні. Різниця до $200 на рік залишається у вас, а можливостей стає незрівнянно більше.

Безпека: чому Tilda — це ризик для українського бізнесу

Tilda Publishing — компанія, заснована в Росії, з юридичною адресою на момент заснування там само. Навіть якщо платформа технічно перемістила інфраструктуру, репутаційні та правові ризики для українського бізнесу залишаються. Законопроєкт, зареєстрований у Раді в 2025 році, лише посилює необхідність діяти вже зараз, а не чекати до примусового відключення. Аналіз присутності Tilda на українському ринку від cases.media підтверджує масштаб проблеми.

Перед тим як обирати між платформами, корисно ознайомитись з детальним порівнянням у статті WordPress vs Tilda vs Wix: що обрати для бізнесу.

Коли точно варто виконати міграцію з Tilda на WordPress прямо зараз:

• Ваш сайт потребує функцій, яких немає у конструктора (інтернет-магазин, LMS, CRM-інтеграції);
• Щомісячна вартість платформи вища за хостинг WordPress;
• Ви хочете повну SEO-свободу: схема-розмітка, технічні редиректи, Core Web Vitals;
• Ви усвідомлюєте ризик Tilda як Russian-owned платформи та хочете перестрахуватись.

Що потрібно підготувати до міграції з Tilda на WordPress

Хаотична міграція — головна причина втрати SEO-позицій. Два-три дні підготовки заощадять вам місяць відновлення.

Аудит поточного сайту

Перед тим як щось переносити, зафіксуйте стан «до»:

1. Вивантажте всі URL через Google Search Console (Перформанс → Сторінки → Експорт). Це ваша базова карта, яку нічим не замінити.
2. Зробіть скріншот або відео кожної ключової сторінки — щоб мати зразок для відтворення дизайну.
3. Збережіть усі мета-теги (title, description) для кожного URL — вручну або через Screaming Frog, запустивши краулінг по поточному сайту.
4. Зафіксуйте поточні позиції у пошуку через Ahrefs або GSC-звіт. Це ваша точка відліку.

Складіть redirect map

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

Вибір хостингу та встановлення WordPress

Мінімальні вимоги до хостингу: PHP 8.2+, MySQL 8.0+, SSL-сертифікат. Важливо: спочатку встановлюйте WordPress на staging-сервер або тимчасовий піддомен (наприклад, staging.yourdomain.com). Ніколи не проводьте міграцію наживо — це великий ризик для поточних позицій.

Як перенести сайт з Tilda на WordPress — покрокова інструкція

Крок 1 — Експорт контенту з Tilda: ручний метод проти Business API

Є два шляхи, і вибір залежить від вашого тарифу Tilda.

Метод 1 — Ручний (працює на будь-якому тарифі):

Це найнадійніший метод з точки зору якості результату. Ви переносите кожну сторінку свідомо, одразу прибираючи зайве і відтворюючи структуру нативними Gutenberg-блоками або Elementor.

Послідовність:

1. Скопіюйте всі тексти у Google Docs або Notion — по одному документу на сторінку.
2. Завантажте всі зображення (не покладайтесь на CDN Tilda — після закриття аккаунту вони зникнуть).
3. Відтворіть сторінки у WordPress через обраний page builder.

Метод 2 — Через Tilda Business API (тільки для тарифу Personal від $15 або Business від $25):

Tilda Business дозволяє:

• Експортувати HTML + CSS + JS сайту одним архівом через Site Settings → Export.
• Підключити офіційний Tilda Publishing Plugin для WordPress, який зв’язується через API.

Для підключення плагіна: Site Settings → Export → API Integration → скопіюйте Public Key та Secret Key.

Критично важливе застереження щодо Tilda Publishing Plugin: плагін переносить сторінки як HTML-ембеди, а не як нативні блоки Gutenberg. Ви отримаєте технічно функціонуючі сторінки, але без можливості зручно редагувати контент у стандартному WordPress-редакторі. Для довгострокового використання все одно доведеться переробляти сторінки нативно. API-метод доцільний, якщо у вас великий сайт і вам потрібно швидко перенести контент, а чищення планується поступово — але плануйте цей другий етап одразу.

Крок 2 — Відтворення структури сторінок у WordPress

Встановіть легку тему: Kadence, Astra або GeneratePress — вони не навантажують сайт зайвим кодом і добре впливають на Core Web Vitals. Уникайте важких преміум-тем з десятками вбудованих функцій — вони уповільнюють сайт. Детальніше про вплив теми на швидкість — у статті Core Web Vitals для WordPress: що потрібно знати власнику бізнесу.

Відтворюйте сторінки у тій самій послідовності, що й у redirect map — від головної до посадкових сторінок і далі до блогу.

Крок 3 — Перенос медіафайлів та оптимізація зображень

Не переносьте зображення «як є». Це момент, коли варто одразу провести оптимізацію:

• Конвертуйте PNG/JPG у WebP (плагін ShortPixel або Converter for Media).
• Стискайте до розумних розмірів — зображення для блогу не повинні перевищувати 150–200 КБ.
• Заповнюйте alt-теги для кожного зображення.

Крок 4 — Налаштування мета-тегів

Встановіть Yoast SEO або Rank Math (обидва безкоштовні в базовій версії). Перенесіть title та description з вашої таблиці для кожної сторінки. Не залишайте жодної сторінки без мета-опису — це пряма втрата CTR у пошуковій видачі.

Крок 5 — Налаштування 301-редиректів

Встановіть плагін Redirection (більше 2 млн активних установок, безкоштовний). Завантажте вашу redirect map як CSV або додайте правила вручну.

Правило просте: кожен старий URL повинен повертати відповідь 301 і вести на відповідний новий URL. Якщо ви зберегли ідентичну URL-структуру — редиректи все одно потрібні на перехідний період.

Крок 6 — XML sitemap та robots.txt

Yoast SEO і Rank Math генерують XML sitemap автоматично. Перевірте, що файл доступний за адресою yourdomain.com/sitemap.xml і містить усі ключові сторінки.

Перевірте robots.txt: він не повинен блокувати індексування потрібних розділів. Типова помилка — staging-налаштування потрапляє на production. Детальне налаштування технічного SEO після міграції на WordPress — у нашому повному гайді по технічному SEO для WordPress.

Як перенести сайт з Wix на WordPress — ключові відмінності

Wix — принципово інша платформа з іншими обмеженнями при міграції.

Експорт RSS-фіду з Wix та імпорт у WordPress

Єдине, що Wix дає для автоматичного переносу, — це RSS-фід блогу. Він доступний за адресою yourdomain.com/blog-feed.xml.

Як імпортувати:

1. Завантажте RSS-файл на комп’ютер.
2. У WordPress: Інструменти → Імпорт → RSS → завантажте файл.

Критичне обмеження Wix: RSS-фід містить лише 20 останніх публікацій. Якщо у вашому блозі більше 20 статей — решта не потрапить в автоматичний імпорт. Вихід: або ручний перенос кожної статті, або сторонні інструменти на кшталт CMS2CMS (платний сервіс міграції).

Що не можна автоматично перенести з Wix

Практично все, крім блогу:

• Сторінки послуг, продуктів, лендінги — HTML Wix несумісний з WordPress.
• Зображення — вони не включені в RSS, тільки посилання на CDN Wix.
• Мета-теги — title і description потребують ручного перенесення для кожної сторінки.
• Форми, галереї, відеоблоки — доведеться відтворювати через плагіни WordPress.

Збереження URL-структури

Wix часто генерує URL вигляду /page-name або /blog/post-name. WordPress дозволяє налаштувати ідентичну структуру через Налаштування → Постійні посилання. Якщо зберегти структуру неможливо — обов’язкові 301-редиректи.

SEO-ризики при міграції з Tilda на WordPress та як їх уникнути

Міграція — це найризикованіший момент для SEO. Ось що найчастіше йде не так і як це виправити.

Реальний кейс: як втрачають позиції при неправильній міграції

Один київський онлайн-магазин органічної косметики вирішив самостійно перенести сайт з Tilda на WordPress. Розробник налаштував новий сайт, переніс контент, змінив DNS — і через три тижні органічний трафік впав на 60%. Причина: жоден зі старих URL не мав 301-редиректу. Google побачив 404-помилки на 47 сторінках і почав виключати їх з індексу. Відновлення позицій зайняло майже три місяці після того, як редиректи були налаштовані ретроактивно.

Важливо про дублювання контенту: поки обидва сайти (старий на Tilda/Wix і новий на WordPress) доступні пошуковикам одночасно, Google бачить задублений контент. Вирішення: або закривайте старий сайт від індексування через robots.txt одразу після переносу DNS, або використовуйте canonical теги, що вказують на новий сайт.

Реальний кейс: успішна міграція з Wix на WordPress

Маркетингова агенція зі Львова мігрувала 34-сторінковий сайт з Wix на WordPress протягом двох тижнів. Ключове рішення — вони почали з повного краулінгу старого сайту через Screaming Frog, отримали всі URL та мета-теги, склали redirect map, і лише потім почали перенос. Через 45 днів після міграції органічний трафік виріс на 23% — нова тема завантажувалась удвічі швидше, ніж Wix, і Core Web Vitals значно покращились. Детально про технічне SEO після переїзду — у нашому гайді по технічному SEO WordPress.

Таймлайн міграції: скільки часу займає переїзд з Tilda на WordPress

Одне з найчастіших запитань: «Скільки триватиме міграція з Tilda на WordPress?» Чесна відповідь залежить від розміру сайту та ресурсів.

Реалістичний розклад для бізнес-сайту (5–20 сторінок):

• День 1–2: Аудит поточного сайту, збір усіх URL та мета-даних, складання redirect map, вибір хостингу.
• День 3–4: Встановлення WordPress на staging, налаштування теми та базових плагінів.
• День 5–8: Перенос контенту — сторінки, зображення, мета-теги.
• День 9–10: Налаштування 301-редиректів, XML sitemap, robots.txt. Повний краулінг staging через Screaming Frog.
• День 11: Переключення DNS. Перевірка всіх редиректів і доступності сторінок.
• День 12–30: Моніторинг GSC (Coverage, 404s), перевірка Core Web Vitals, порівняння трафіку в GA4.

Хочете прискорити міграцію з Tilda на WordPress та убезпечити SEO? Я займаюся переносом сайтів з Tilda та Wix на WordPress з повним збереженням позицій у Google — правильні 301-редиректи, технічне SEO та налаштування під ключ. Замовити міграцію на smtv.studio →

Чекліст міграції з Tilda на WordPress: 32 пункти

Роздрукуйте або скопіюйте цей чекліст — і відзначайте кожен пункт по мірі виконання. Це повний перелік дій для безпечної міграції з Tilda на WordPress або Wix на WordPress.

До міграції (pre-migration)

• [ ] Зробити повний скріншот або відеозапис поточного сайту
• [ ] Вивантажити всі URL через Google Search Console (Перформанс → Сторінки → Експорт)
• [ ] Записати всі мета-теги (title, description) для кожної сторінки
• [ ] Зберегти всі медіафайли: зображення, відео, документи (не покладайтесь на CDN Tilda)
• [ ] Зафіксувати поточні позиції у пошуку (Ahrefs або GSC-знімок)
• [ ] Зробити краулінг поточного сайту через Screaming Frog — зафіксувати всі посилання
• [ ] Скласти таблицю redirect map: старий URL → новий URL
• [ ] Вибрати та підключити хостинг (PHP 8.2+, MySQL 8.0+, SSL)
• [ ] Встановити WordPress на staging-сервер (не на основний домен)
• [ ] Налаштувати GA4 та GSC для нового домену або property
• [ ] Підтвердити право власності на домен у GSC (заздалегідь)

Під час міграції

• [ ] Встановити та налаштувати тему (Kadence / Astra / GeneratePress)
• [ ] Встановити та налаштувати SEO-плагін (Yoast SEO або Rank Math)
• [ ] Перенести всі сторінки: текст, зображення, форматування
• [ ] Заповнити мета-теги (title, description) для кожної сторінки через SEO-плагін
• [ ] Оптимізувати зображення: конвертувати у WebP, стиснути через ShortPixel
• [ ] Заповнити alt-теги для всіх зображень
• [ ] Налаштувати внутрішні посилання відповідно до нової структури
• [ ] Встановити плагін Redirection → додати всі 301-редиректи з redirect map
• [ ] Згенерувати XML sitemap через SEO-плагін і перевірити її вміст
• [ ] Налаштувати robots.txt — індексування дозволене для всіх потрібних розділів
• [ ] Провести повний краулінг staging-сайту через Screaming Frog
• [ ] Виправити всі знайдені 404, зламані посилання, відсутні alt-теги
• [ ] Перевірити коректність canonical-тегів на всіх сторінках
• [ ] Перевірити мобільну версію (Google Mobile-Friendly Test або DevTools)
• [ ] Перевірити швидкість завантаження (PageSpeed Insights) — мета: LCP < 2.5 с
• [ ] Додати schema-розмітку (Article, LocalBusiness, FAQPage — залежно від типу сторінок)

Після запуску (post-migration)

• [ ] Переключити DNS на новий хостинг
• [ ] Дочекатися поширення DNS (зазвичай 1–24 години) і перевірити доступність сайту
• [ ] Перевірити, що всі 301-редиректи працюють: через Screaming Frog або httpstatus.io
• [ ] Сабмітити XML sitemap у Google Search Console
• [ ] Запросити повторну індексацію ключових сторінок через GSC (URL Inspection → Request Indexing)
• [ ] Перевірити Core Web Vitals: PageSpeed Insights та CrUX-звіт у GSC
• [ ] Моніторити GSC протягом 2–4 тижнів: Coverage → 404s, Index → кількість проіндексованих сторінок
• [ ] Перевірити мобільну адаптацію через Mobile Usability у GSC
• [ ] Закрити або redirect старий сайт на Tilda/Wix після стабілізації трафіку (не раніше ніж через 30 днів)
• [ ] Порівняти трафік через GA4: до vs. після міграції (через 30 та 60 днів)
• [ ] Перевірити, що GA4 та GSC отримують дані з нового сайту
• [ ] Перевірити schema-розмітку через Rich Results Test від Google

Замовити міграцію з конструктора на WordPress

Якщо після прочитання цієї статті у вас виникло відчуття, що «тут багато чого може піти не так» — ви праві. Міграція з Tilda на WordPress — це технічна операція, де кожна деталь важлива. Відсутній редирект, неправильний robots.txt або продубльований контент можуть коштувати місяців відновлення позицій.

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

Що входить у послугу міграції з Tilda на WordPress від smtv.studio:

• Повний аудит поточного сайту та складання redirect map
• Встановлення та налаштування WordPress на вашому хостингу
• Перенос контенту: тексти, зображення, мета-теги
• Налаштування 301-редиректів для кожного URL
• SEO-налаштування: Yoast/Rank Math, sitemap, robots.txt, schema
• Перевірка після запуску: Screaming Frog + GSC моніторинг
• Фіксована вартість залежно від розміру сайту
• Безкоштовна консультація + аудит поточного сайту перед початком роботи

Потрібна допомога з переїздом з Tilda на WordPress? Перенесіть сайт без ризику втратити позиції у Google. Замовити міграцію на smtv.studio →

Підсумки: план дій на сьогодні

Міграція з Tilda на WordPress — це інвестиція в незалежність і масштабованість вашого сайту. Але вона вимагає ретельної підготовки і чіткого порядку кроків.

Три речі, які варто зробити прямо зараз:

1. Вивантажте всі URL з Google Search Console — це нічого не коштує та займе 5 хвилин, а без цього ніяка міграція неможлива.
2. Перевірте тариф Tilda: якщо ви на Business — у вас є доступ до API-експорту, що спростить перенос. Але пам’ятайте про обмеження Tilda Publishing Plugin (HTML-ембеди замість Gutenberg-блоків).
3. Оціните розмір сайту та оберіть реалістичний дедлайн за таблицею таймлайну вище.

Якщо хочете зробити це правильно — зверніться до smtv.studio. Міграцію з Tilda або Wix на WordPress ми виконаємо без втрати ваших SEO-позицій.

Міграція лендінгу або сайту-візитівки (1–5 сторінок) займає 1–3 дні. Бізнес-сайт (5–20 сторінок) — 1–2 тижні. Блог середнього розміру (20–50 статей) — 2–4 тижні. Інтернет-магазин (50+ продуктів) — 4–8 тижнів.

Чи можна виконати міграцію з Tilda на WordPress без втрати SEO?

Так, якщо правильно налаштувати 301-редиректи для кожного URL, перенести мета-теги, зберегти структуру URL і відстежувати Google Search Console протягом 30–60 днів після міграції.

Що таке Tilda Publishing Plugin і чи варто його використовувати?

Tilda Publishing Plugin — офіційний плагін, який імпортує сторінки Tilda до WordPress через API. Головне обмеження: він переносить сторінки як HTML-ембеди, а не нативні блоки Gutenberg. Це означає, що ви не зможете зручно редагувати контент у WordPress-редакторі. Плагін підходить для швидкого переносу великого сайту, але потребує подальшого доопрацювання кожної сторінки.

Додаткові ресурси: Посібник Search Engine Land з міграції сайтів та аналіз ринку Tilda в Україні від cases.media.

Ви платите $15–25 на місяць за Tilda. За рік — $180–300. За три роки — до $900. І ваш сайт досі належить не вам.

Цей матеріал — про вибір між WordPress, Tilda і Wix: три платформи, три різні обіцянки, три різні ціни.

А тепер — ще один факт, який більшість статей про вибір платформи обходять стороною: Tilda — це російська компанія. Засновник Нікіта Обухов, юридична реєстрація в Росії, публічної позиції щодо повномасштабного вторгнення компанія так і не зайняла. За даними розслідування dev.ua, близько 8 000 українських інтернет-магазинів досі переводять туди гроші щомісяця.

Питання «WordPress чи Tilda» після 2022 року в Україні отримало додатковий вимір — і саме про нього найменше пишуть.

Я — Сергій, WordPress-розробник зі smtv.studio. Я заробляю на WordPress, тому скажу одразу: я не нейтральний. Але я постараюся бути чесним. Для деяких завдань Tilda або Wix — прийнятний вибір. Проте є речі, які ці сервіси в своїй рекламі замовчують — і саме їх ми зараз розберемо.

Коротко про кожну платформу

WordPress: гнучкість без меж

WordPress — відкрите програмне забезпечення, яким користується 43% всіх сайтів у світі. Ви встановлюєте його на власний хостинг, маєте повний доступ до коду, бази даних і файлів. Понад 59 000 плагінів розширюють функціонал під будь-яке завдання — від інтернет-магазину до маркетплейсу.

Головна особливість: WordPress не є сервісом з підпискою. Сама CMS безкоштовна. Ви платите лише за хостинг і домен — і контролюєте все.

Tilda: красиво, але є нюанс

Tilda — конструктор сайтів із красивими шаблонами і простим редактором блоків. Ідеально підходить для лендингів, портфоліо та невеликих сайтів, якщо не йти в деталі. Старт справді простий: обрав шаблон, заповнив текст, опублікував.

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

Wix: для старту, не для зростання

Wix — американський конструктор із великою бібліотекою шаблонів і App Market. Простіший за WordPress у налаштуванні, дорожчий за WordPress у довгостроковій перспективі. Має серйозні обмеження для SEO (про них — далі) і «технічну стелю», яку бізнес дуже швидко відчуває при масштабуванні.

Порівняльна таблиця: WordPress vs Tilda vs Wix у 2026

Ось повне порівняння трьох платформ по ключових критеріях:

Ціна: скільки насправді коштує кожна платформа

Tilda: схована підписка

Tilda виглядає доступно на старті. Але рахуймо чесно.

Tilda Personal — $15/міс або $10/міс при оплаті за рік ($120/рік). Один сайт, базові функції. Tilda Business — $25/міс або $20/міс за рік ($240/рік). Потрібен для інтернет-магазину, форм збору даних та повноцінного SEO-налаштування.

За 3 роки на Business-тарифі: $720. І ваш сайт усе ще не ваш — зупинили оплату, сайт зник.

Wix: низький старт, але вартість зростає

Wix Light — $17/міс. Core — $29/міс. Business — $39/міс. Щорічне зростання тарифів на 10–15% — задокументована практика.

Для повноцінного бізнес-сайту з е-commerce реально потрібен план за $29–39/міс. За 3 роки: $1 044–1 404.

WordPress: дешевше, якщо рахувати правильно

Хостинг в Україні (RX-Name, Hostpro): від $2–3/міс, тобто $27–36 на рік. Домен: $10–15/рік. Разом: від $40–50/рік.

За 3 роки: $120–150 на хостинг і домен. Плюс одноразова вартість розробки та налаштування — якщо залучати фахівця. Але навіть з вартістю розробки за 2–3 роки WordPress часто виходить дешевшим, ніж безперервна підписка на Tilda Business.

Потрібна допомога з вибором хостингу та запуском WordPress-сайту? Я допомагаю бізнесу налаштувати WordPress правильно з першого разу — без зайвих витрат і плутанини. Дивіться послуги smtv.studio →

SEO: де ваш сайт ранжуватиметься краще

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

WordPress vs Tilda vs Wix: технічне SEO

WordPress дає повний контроль над усіма технічними елементами SEO:

• Meta title і description — необмежена кастомізація (Yoast SEO, RankMath)
• Schema markup — будь-яка кількість типів на сторінку, будь-яка вкладеність
• robots.txt і .htaccess — повний доступ
• XML sitemap — автоматично генерується і налаштовується
• Canonical URLs — гнучко під будь-яку архітектуру
• Кешування і швидкість — WP Rocket, LiteSpeed Cache, Cloudflare

Tilda має базові SEO-інструменти: можна задати meta title, description, є автоматичний sitemap. Але є обмеження: schema markup — лише 1 тип на сторінку, немає доступу до серверної конфігурації, неможливо тонко налаштувати .htaccess. Для простого сайту цього може вистачати. Для амбітного SEO-просування — ні.

Wix має окрему проблему: URL-структура містить незмінні префікси /post/ для блогу і /product/ для товарів, які неможливо прибрати. Для Google це технічно прийнятно, але нестандартно. Також: schema markup — 1 тип на сторінку з лімітом 7 000 символів, ситemap не кастомізується.

Core Web Vitals: де WordPress програє і як це вирішити

Ось де WordPress має реальну проблему — і я не збираюся її приховувати.

За даними HTTP Archive / Chrome UX Report (2024), WordPress із дефолтними налаштуваннями показує лише 45% pass rate на мобільних пристроях — найнижчий серед великих CMS. Wix — близько 75%. Tilda — приблизно 60–70%.

Звучить погано для WordPress? Тільки доки не дізнаєтесь, чому так.

WordPress-сайти часто встановлюють на дешевий спільний хостинг, без кешування, з важкими темами і десятками плагінів. Саме це тягне цифру вниз. Правильно налаштований WordPress на нормальному хостингу з WP Rocket або LiteSpeed Cache легко досягає 85–95% pass rate — вище за Wix і Tilda за замовчуванням.

Tilda і Wix мають кращі дефолтні показники, але ви не можете їх суттєво покращити — платформа контролює серверну частину.

Висновок по SEO

WordPress — найбільший SEO-потенціал, але він реалізується лише при правильному налаштуванні. «З коробки» без фахівця Tilda і Wix можуть показати кращі результати. Але з фахівцем — WordPress виграє з великим відривом.

Хочете знати, як WordPress-сайт виглядає після правильного SEO-налаштування? Перегляньте кейси smtv.studio — реальні проекти з цифрами трафіку і позицій.

Гнучкість і масштабування

Що буде через 3 роки?

Бізнес росте. Сайт теж має рости разом із ним.

Кейс 1. Катерина відкрила салон краси і зробила сайт на Tilda — швидко, дешево, красиво. Через рік вирішила додати онлайн-запис через CRM, інтегрувати бонусну програму і запустити блог для SEO. Tilda не потягнула: онлайн-запис — тільки через обмежені сторонні сервіси без глибокої інтеграції, блог з повноцінним SEO — складно, CRM-інтеграція — взагалі не передбачена. Переїзд на WordPress зайняв 3 тижні і коштував як два сайти.

Кейс 2. Дмитро запустив невеликий інтернет-магазин на Wix — 30 товарів, все окей. За рік — 500 товарів, потрібна складна фільтрація, оптова ціна для B2B-клієнтів і інтеграція з 1С. Wix технічно не може цього зробити. Міграція — болюча і дорога.

Кейс 3. Юлія одразу обрала WordPress для свого освітнього проекту. Через 2 роки — інтернет-магазин курсів, партнерська програма, кабінет студента, інтеграція з Zoom. Все додавалось плагінами без переробки архітектури.

Чи зможете ви додати функціонал?

• WordPress: 59 000+ плагінів. Якщо немає готового рішення — розробляється кастомно. Без обмежень. Для сучасних сайтів рекомендуємо Block Theme архітектуру — вона значно спрощує подальший розвиток.
• Tilda: 550+ блоків для верстки. Бекенд закритий, сторонніх плагінів немає.
• Wix: App Market є, але платформа закрита. Складна кастомізація — через Velo (власна мова на JS), що потребує розробника і все одно має ліміти.

Підтримка і контроль: хто насправді власник вашого сайту

Це питання, яке рідко задають перед вибором платформи — і дуже часто шкодують після.

WordPress: повна власність

При роботі з WordPress всі файли, база даних і хостинг — ваші. Ви можете переїхати на інший хостинг за кілька годин, передати сайт іншому розробнику, зробити резервну копію і зберегти локально. Ніхто не може заблокувати ваш сайт — крім вас самих.

Tilda і Wix: ви орендуєте, а не власник

Зупинили підписку — сайт зник. Порушили правила використання (навіть невмисно) — акаунт заблокований. Платформа змінила тарифи або закрилась — ваш сайт під загрозою.

З Tilda вийти ще складніше: експорт даних доступний лише на Business-тарифі ($240/рік). На Personal-тарифі ви взагалі не можете завантажити свій контент у повному обсязі.

Це секція, якої немає в жодній іншій статті на цю тему — і саме тому вона тут.

Tilda — російська компанія

Tilda Publishing заснована Нікітою Обуховим. Компанія юридично зареєстрована в Росії. Після 24 лютого 2022 року Tilda не зробила жодної публічної заяви про підтримку України, не зупинила роботу на російському ринку і не дистанціювалась від країни-агресора.

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

Реальний масштаб: 8 000 українських бізнесів

За даними розслідування dev.ua, станом на момент публікації близько 8 000 українських інтернет-магазинів продовжували платити Tilda. Це не абстрактна цифра — це тисячі малих бізнесів, які або не знали про походження платформи, або вирішили не переїжджати через складність міграції.

Репутаційний ризик — це реальність

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

Це не моральний тиск — це ринкова реальність. Ваші клієнти можуть побачити «Made on Tilda» або дізнатись, що ваш сайт побудований на російській платформі. Для B2B в Україні у 2026 році це вже репутаційне питання.

Що використовувати замість Tilda?

Якщо вам подобається простота конструктора — зверніть увагу на Webflow (США, потужний, але дорожчий), Framer (Нідерланди, для дизайнерських сайтів) або вітчизняні UA-рішення. Але для більшості бізнес-завдань і тривалої перспективи — WordPress лишається найкращим вибором. Якщо хочете дізнатись більше про технічне налаштування WordPress — дивіться послуги smtv.studio.

Міграція: що буде, якщо захочете перейти

З Tilda на WordPress: реально, але потребує фахівця

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

Технічно: Tilda дозволяє експортувати сторінки у HTML лише на Business-тарифі. Динамічний контент (каталог товарів, форми, CRM-дані) переноситься вручну. Важливо: без правильних 301-редиректів ви ризикуєте втратити SEO-позиції, які накопичувались роками. Перехід без досвідченого фахівця часто призводить до 3–7 днів простою і просідання трафіку на 30–50%.

З Wix на WordPress: обмежена сумісність

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

Я допомагаю переносити сайти з Tilda та Wix на WordPress без втрати SEO. Мігрую контент, налаштовую редиректи, перевіряю технічний стан після переїзду. Дізнатись про послугу міграції →

Кому що підходить: практичні сценарії

Я обіцяв чесність — тому ця секція без фанатизму.

Хто має обирати WordPress

• Бізнес із SEO-амбіціями. Якщо органічний трафік — важлива частина вашої стратегії, WordPress дає інструменти, яких немає в конкурентів.
• Інтернет-магазин від 50+ позицій. WooCommerce — найпотужніше безкоштовне рішення для e-commerce з гнучкими можливостями масштабування.
• Довгострокова перспектива. Якщо плануєте розвивати сайт 3–5+ років, WordPress дешевший і гнучкіший.
• Компанії, яким важлива репутація на українському ринку. Після 2022 року використання Tilda — це ризик, якого можна уникнути.
• Потрібна кастомна функціональність. CRM-інтеграція, кабінет клієнта, партнерська програма — WordPress це робить.

Коли Tilda або Wix може бути виправданим

Я скажу чесно: є ситуації, де конструктори мають сенс.

• Лендинг або промо-сторінка на 1–3 місяці. Якщо сайт потрібен швидко, на короткий термін і без SEO-задач — Wix або Tilda (якщо вас не турбує питання походження) можуть бути раціональнішими.
• Портфоліо фотографа / дизайнера без бюджету на розробника. Якщо ви самостійно оновлюєте контент, не маєте технічного досвіду і вам потрібен красивий, але простий сайт — конструктор справляється.
• Тестування MVP. Перевірити гіпотезу і зібрати перші заявки — для цього не потрібен WordPress. Але якщо MVP спрацює — краще одразу думати про перехід.

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

Висновок

WordPress vs Tilda vs Wix — це не просто технічне питання. Це питання про те, кому належить ваш сайт, скільки ви реально платите і яких цінностей дотримується ваш бізнес.

WordPress вимагає більше зусиль на старті — але дає повний контроль, найкращий SEO-потенціал і відсутність будь-яких обмежень у розвитку. Wix зручний, але дорогий у довгостроковій перспективі і технічно обмежений. Tilda красива — але це рос. продукт, і в 2026 році цей факт не можна ігнорувати.

Якщо ви — український бізнес і шукаєте надійну платформу для довгострокового розвитку — WordPress із правильним налаштуванням є найкращим вибором.

Я — Сергій, WordPress-розробник зі smtv.studio. Допомагаю бізнесу запустити WordPress-сайти, перенести проекти з Tilda та Wix і налаштувати технічне SEO для WordPress. Також раджу ознайомитись з моїм підходом до розробки WordPress-сайтів — щоб розуміти, як я працюю. Консультація безкоштовна — розберемось разом, що підходить саме вашому проекту.

Зв’язатися зі мною →

Проблема рідко в самому розробнику. Проблема в тому, що бізнес не знав, на що звертати увагу ще до підписання договору.

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

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

Хто такий WordPress розробник і які навички він повинен мати

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

Хтось вміє встановити тему і налаштувати конструктор Elementor за вихідні. Хтось пише власні плагіни, інтегрує платіжні системи та знає, як оптимізувати WordPress під навантаження 50 000 відвідувачів на місяць.

Обов’язкові технічні навички

Хороший WordPress-розробник повинен впевнено орієнтуватись у:

• PHP та JavaScript, це основні мови, на яких побудований WordPress
• HTML та CSS, без них неможливе жодне нормальне верстання
• WordPress Core, розуміння хуків, фільтрів, архітектури тем і плагінів
• Gutenberg, сучасний редактор блоків, який замінив класичний WYSIWYG
• Безпека WordPress, захист від брутфорсу, SQL-ін’єкцій, XSS, налаштування HTTPS
• Оптимізація швидкості, кешування, оптимізація зображень, Core Web Vitals
• Адаптивна верстка, сайт повинен коректно відображатись на всіх пристроях
• Резервне копіювання та відновлення, вміння налаштувати бекапи та відновити сайт після збою

Якщо проект передбачає інтернет-магазин, обов’язковим є досвід з WooCommerce. Якщо сайт багатомовний, потрібне знання WPML або Polylang. Якщо потрібні складні форми або CRM-інтеграції, варто запитати про досвід з Advanced Custom Fields (ACF) та REST API.

На які soft skills звертати увагу

Технічні навички важливі, але не єдине, що має значення. Хороший розробник також:

• Задає питання до початку роботи, а не просто бере завдання і зникає
• Пояснює рішення, чому обрано саме цей підхід, а не інший
• Реагує на повідомлення протягом дня, навіть якщо лише підтвердить, що бачить запит
• Документує виконану роботу, особливо якщо передає сайт клієнту або іншому розробнику
• Говорить “ні” нереалістичним дедлайнам, замість того щоб взяти завдання і не здати вчасно

Фрілансер, агенція або сервіс підтримки: що обрати

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

Коли обирати фрілансера

Фрілансер, це хороший вибір, якщо:

• Потрібен невеликий сайт-візитка або лендінг
• Бюджет обмежений і ви готові взяти на себе частину ризиків
• Є конкретне технічне завдання і ви вмієте контролювати роботу
• Потрібна швидка точкова допомога, наприклад, виправити баг або налаштувати плагін

Для пошуку: Upwork, Freelancehunt, LinkedIn, рекомендації у профільних спільнотах.

Коли обирати агенцію

Агенція виправдовує вищу ціну, якщо:

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

Коли варто обрати сервіс технічної підтримки

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

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

Саме для цього існують сервіси технічної підтримки WordPress, як-от smtv.studio. Ви платите фіксовану щомісячну суму і отримуєте регулярне обслуговування, моніторинг і швидке реагування на проблеми, без потреби кожного разу шукати нового виконавця.

Якщо у вас вже є WordPress сайт і він потребує регулярного обслуговування, замовте безкоштовну перевірку стану сайту.

7 ключових критеріїв вибору WordPress розробника

Це список питань і факторів, на які варто звернути увагу ще до підписання будь-якого договору.

1. Портфоліо з реальними WordPress проектами

Попросіть посилання на живі сайти, які розробник створив або підтримував. Зайдіть на ці сайти і перевірте: як вони завантажуються на мобільному, чи немає зламаних елементів, чи відчувається якість роботи. Можна також скористатись сервісом BuiltWith або Wappalyzer, щоб перевірити, чи справді сайт побудований на WordPress.

2. Досвід саме з вашим типом проекту

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

3. Знання WordPress-екосистеми

Запитайте про досвід з конкретними інструментами: Gutenberg, Advanced Custom Fields, WooCommerce, Yoast SEO або Rank Math, WP Rocket або LiteSpeed Cache. Хороший розробник не просто назве плагіни, а пояснить, коли і чому їх використовує.

4. Відгуки та рекомендації

Попросіть контакти двох-трьох попередніх клієнтів і поспілкуйтесь з ними. Запитайте не тільки “чи задоволені результатом”, але і “як розробник поводився, коли виникали проблеми або треба було щось змінити після здачі”.

5. Прозоре ціноутворення

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

6. Готовність підписати договір

Договір захищає обидві сторони. У ньому мають бути прописані: обсяг робіт (scope), терміни, умови оплати, що відбувається при затримці з боку замовника або виконавця, права на готовий сайт. Відмова від договору або пропозиція “зробимо на довірі” – серйозний червоний прапор.

7. Підтримка та обслуговування після запуску

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

Роздрукуйте цей список і використайте його на першій зустрічі або в листуванні.

1. Покажіть три останніх живих WordPress сайти, які ви зробили.
2. Чи мали ви досвід із [WooCommerce / Gutenberg / ACF / тим, що потрібне вам]?
3. Як ви зберігаєте резервні копії сайту під час розробки?
4. Як виглядатиме процес роботи: які етапи, де я буду бачити прогрес?
5. Чи надаєте ви технічне завдання або чекаєте його від мене?
6. Скільки часу займатиме відповідь на мій запит під час розробки?
7. Що відбувається, якщо після здачі виявиться баг?
8. Чи передаєте ви всі доступи (хостинг, адмін WordPress, FTP) після завершення?
9. Чи надаєте підтримку після запуску і що в неї входить?
10. Чи є у вас стандартний договір і чи можемо ми його переглянути до початку роботи?

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

Скільки коштує WordPress розробник в Україні

Ціни суттєво різняться залежно від досвіду, типу виконавця та складності проекту.

Фрілансери

На Upwork українські WordPress-розробники виставляють від $20 до $60 на годину, залежно від рівня та досвіду.

Агенції та веб-студії

• Проста посадкова сторінка: 15 000-35 000 грн
• Корпоративний сайт: 30 000-80 000 грн
• Інтернет-магазин на WooCommerce: 50 000-150 000 грн+

Що входить у ціну

Завжди уточнюйте, що саме включено в озвучену суму. Стандартно має входити:

• Верстка і налаштування WordPress
• Наповнення контентом (або ні, уточніть окремо)
• Налаштування SEO-плагіна
• Адаптивна версія для мобільних
• Базове налаштування безпеки
• Тестування перед запуском

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

Типові помилки при виборі розробника

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

Вибір за найнижчою ціною. Олег, власник невеликого інтернет-магазину дитячого одягу, обрав розробника за принципом “найдешевше”. За 8 000 грн отримав сайт, який відкривається 12 секунд, не адаптований під мобільні та зроблений на піратській темі з вбудованим шкідливим кодом. Виправлення коштувало дорожче, ніж первинна розробка.

Відмова від договору. “Ми ж домовились усно” – так починається більшість конфліктів. Без договору немає чіткого обсягу робіт, терміни розмиті, і виконавець може безкінечно додавати нові умови або зникнути на півшляху.

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

Ігнорування питання підтримки. Більшість замовників думають про сайт як про разовий проект: зробили, запустили, забули. Насправді WordPress вимагає регулярного обслуговування: оновлення, бекапи, перевірка безпеки. Сайт без підтримки за рік перетворюється на вразливий до злому застарілий ресурс. Якщо розробник вже перестав відповідати на повідомлення, діяти треба негайно.

Вибір без перевірки рекомендацій. Портфоліо можна нагламурити. Відгуки в Telegram-спільноті або LinkedIn від реальних клієнтів, значно надійніший сигнал.

Що робити після запуску сайту: технічна підтримка WordPress

Запуск сайту, це початок, а не кінець. WordPress, як і будь-яка складна платформа, потребує регулярної уваги. Без неї навіть добре зроблений сайт деградує.

Що потрібно робити регулярно

• Оновлення WordPress Core, тем і плагінів, щомінімум раз на місяць. За даними Sucuri, застарілі плагіни та теми є причиною більш ніж половини зламаних WordPress сайтів.
• Резервне копіювання, бекапи мають зберігатись автоматично і в зовнішньому сховищі, не тільки на хостингу.
• Моніторинг безпеки, сканування на предмет шкідливого коду, перевірка підозрілих дій.
• Перевірка швидкості, Core Web Vitals безпосередньо впливають на позиції в Google.
• Дрібні правки та виправлення, щось завжди потребує коригування після запуску.

Деякі бізнеси для цього наймають окремого фрілансера “за годину”. Інші платять агенції за підтримку. Але і те, і інше часто виявляється дорогим і непередбачуваним.

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

Хочете знати, в якому стані ваш сайт зараз? Отримайте безкоштовну технічну перевірку WordPress сайту від команди smtv.studio.

Висновок

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

Що варто пам’ятати:

1. Перевіряйте живі сайти з портфоліо, а не скриншоти
2. Задавайте конкретні технічні питання, хороший розробник не злякається
3. Вимагайте договір і технічне завдання до початку будь-якої роботи
4. Уточніть умови підтримки після запуску ще на старті
5. Найдешевше рішення майже ніколи не є найвигіднішим

І ще одне: якщо у вас вже є WordPress сайт, який “просто стоїть” без регулярного обслуговування, це вже ризик. Оновлення, безпека, бекапи, не менш важливі, ніж сама розробка.

Якщо вам потрібна не розробка нового сайту, а надійна технічна підтримка вже наявного, дізнайтесь про послуги smtv.studio.

Block Theme WordPress: що це і навіщо вам потрібно знати у 2026

Block Theme WordPress, це нова архітектура тем, яка з 2022 року є офіційним стандартом платформи. Якщо ваш сайт досі живе на класичній темі з Customizer-ом, Widgets і PHP-шаблонами, ви користуєтесь архітектурою 2015 року. І поки в Україні про це майже ніхто не пише, ваш розробник вже точно про це знає.

Ви, мабуть, вже чули слова “Gutenberg”, “блоки”, “Full Site Editing”, і, можливо, просто ігнорували їх як чергову технічну моду. Насправді це не мода, це фундаментальна зміна того, як будуються сайти на WordPress.

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

Потрібна консультація? Якщо хочете зрозуміти, чи підходить block theme для вашого конкретного сайту, напишіть мені. Безкоштовна оцінка за 24 години.

Що таке Block Theme WordPress, простою мовою

Block Theme WordPress, це тип теми оформлення для WordPress, в якій увесь сайт (включно з хедером, футером і шаблонами сторінок) побудований із блоків і керується через вбудований Site Editor, а не через Customizer чи PHP-шаблони.

Якщо звичайна класична тема, це будинок, де ремонт роблять тільки “через стіни” (тобто через PHP-файли), то Block Theme, це будинок із повністю прозорими панелями: ви бачите кожен елемент і можете його переставити мишкою.

В каталозі WordPress.org вже понад 1 500 block themes. Офіційні теми WordPress, починаючи з Twenty Twenty-Two (2022), усі block themes. Це не альтернатива, це новий стандарт.

Block Theme vs класична тема, ключова різниця

Ключова відмінність, яку варто запам’ятати: у класичній темі розробник контролює структуру через PHP-код, а клієнт, тільки контент. У Block Theme і структура, і контент доступні через один редактор.

Коли з’явились block themes і де ми зараз

Хронологія коротко:

• WordPress 5.0 (2018), з’явився редактор Gutenberg, блоки для контенту
• WordPress 5.9 (січень 2022), перша офіційна block theme Twenty Twenty-Two, запуск Full Site Editing
• WordPress 6.4 (2023), Site Editor отримав повноцінний інтерфейс з навігацією по розділах
• WordPress 6.7 (листопад 2024), Twenty Twenty-Five з функцією Zoom Out для перегляду всього сайту
• WordPress 7.0 (2026), block-first архітектура стає основою для всіх нових функцій

Зараз ми в точці, де block themes, це не “щось нове і ризиковане”. Це те, куди WordPress інвестує 100% своїх ресурсів.

Як виглядає Site Editor зсередини

Олена, маркетолог невеликої юридичної фірми у Харкові. Вона кілька разів просила розробника змінити текст у хедері сайту, щоразу це коштувало 500–800 грн і займало 2–3 дні. Після переходу на block theme вона навчилась робити це сама за 5 хвилин через Site Editor. Тепер зміни в шапці сайту, більше не задача для розробника.

Саме для таких випадків і існує Site Editor.

5 розділів Site Editor (WordPress 6.4+)

Site Editor, це окремий інтерфейс у адмін-панелі WordPress (Зовнішній вигляд → Редактор). Він має 5 основних розділів:

1. Navigation, керування меню сайту прямо в контексті сторінки
2. Styles, глобальні кольори, шрифти, розміри для всього сайту
3. Pages, перегляд і редагування сторінок з урахуванням шаблону
4. Templates, шаблони для різних типів сторінок (головна, пост, категорія, 404)
5. Patterns, бібліотека готових дизайн-блоків, синхронізованих між сторінками

Що таке Template Parts

Template Parts, це “шматки” шаблону, які повторюються на різних сторінках. Найчастіше це:

• Header, шапка сайту з логотипом і навігацією
• Footer, підвал з контактами і копірайтом
• Sidebar, бічна панель (якщо є)

Важлива відмінність від класичного підходу: Template Parts редагуються як звичайні блоки, без жодного рядка PHP чи CSS. Змінили хедер один раз, він оновився на всіх сторінках автоматично.

Block Patterns, готові дизайн-блоки

Block Patterns, це готові комбінації блоків: секції hero, картки послуг, блоки відгуків, форми підписки тощо. Вони бувають двох типів:

• Синхронізовані (Synced Patterns), зміна в одному місці оновлює всі вставки. Ідеально для CTA-блоків або банерів акцій.
• Несинхронізовані, копія вставляється незалежно. Підходить для унікальних секцій на різних сторінках.

theme.json, серце block theme (без страху)

Михайло, власник агентства з продажу нерухомості у Дніпрі. Коли я розповів йому про theme.json, перша реакція була: “Це звучить як щось для програмістів.” Я пояснив йому так: уявіть, що у вашому офісі є один документ “Дизайн-стандарт компанії”, де записано які кольори використовувати, які шрифти, скільки відступів між блоками. Всі дизайнери та підрядники працюють за цим документом. theme.json, це саме такий документ, тільки для вашого сайту.

theme.json, це JSON-файл у корені теми, який визначає глобальні параметри дизайну: кольорову палітру, типографіку, відступи, ширину контенту. Він є “єдиним джерелом правди” для всього оформлення сайту.

Що контролює theme.json:

• Кольори, палітра бренду, кольори фону, тексту, посилань
• Шрифти, які шрифти доступні, їх розміри (fluid typography автоматично адаптує розміри під екран)
• Відступи, padding, margin, gap між елементами
• Ширина контенту, наприклад, contentSize: 840px, wideSize: 1200px
• Тіні, border-radius, фонові зображення, через theme.json версії 3 (WordPress 6.5+)

Для власника бізнесу практичне значення таке: будь-який розробник, який отримає ваш сайт на підтримку, одразу розуміє дизайн-систему, вона задокументована в одному файлі. Менше непорозумінь, менше “чому тут інший синій”.

Переваги Block Theme для вашого сайту

Швидкість і Core Web Vitals

Ось факт, який варто знати: тільки 44% WordPress-сайтів проходять Core Web Vitals на мобільному (дослідження Jetpack Boost). Один з головних винуватців, важкі теми та page builders, які завантажують тисячі рядків CSS і JS, навіть якщо 80% з них не використовуються на конкретній сторінці.

Block themes вирішують цю проблему на архітектурному рівні. Вони генерують тільки той CSS, який потрібен для конкретної сторінки, це називають block-level CSS. Порівняйте:

• Класична тема з Elementor: 400–600 KB CSS на завантаження
• Twenty Twenty-Three (block theme): CSS під конкретну сторінку, загальний CSS < 30 KB
• GeneratePress (block theme): розмір сторінки 45 KB, час завантаження 0.8 секунди

Twenty Twenty-Three показав 100/100 у PageSpeed Insights на мобільному і десктопному тестуванні (тест NitroPack). Сучасні block themes стабільно тримають LCP < 2.5 секунди, що є вимогою Google для “хорошої” оцінки Core Web Vitals.

Якщо вас турбує, чому ваш сайт повільний і як це впливає на позиції в Google, читайте детальніше в статті чому WordPress гальмує і що таке Core Web Vitals.

Хочете дізнатись, чи є у вашому сайті проблеми зі швидкістю? Замовте безкоштовний технічний аудит, перевірю за 24 години.

Більше контролю без програмування

Drag-and-drop у Site Editor дозволяє редагувати буквально кожен елемент сайту, не тільки вміст сторінок, а й хедер, футер, сайдбар, шаблони постів. Це те, що раніше вимагало або плагіну типу Elementor, або PHP-розробника.

WordPress 6.7 додав функцію Zoom Out, можна “відлетіти” від сторінки і бачити весь сайт як єдиний дизайн, перетягувати секції між сторінками і оцінювати загальне враження.

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

SEO переваги

Block themes генерують чистіший і компактніший HTML-код. Немає зайвих div-обгорток від page builder’а, немає “сміттєвого” CSS і JS. Це прямо впливає на:

• Час завантаження → кращий LCP, менший FID
• Структуру HTML → більш читабельна розмітка для Google-краулерів
• Менша залежність від важких плагінів, Elementor, WPBakery, DIVI додають від 200 до 600 KB коду на кожну сторінку

Native block rendering означає, що контент рендериться на стороні сервера у стандартний HTML без JavaScript-залежності, пошукові роботи краще його індексують.

Підводні камені, що треба знати заздалегідь

Я не буду продавати вам ідеальну картину. Block themes, це справжній прогрес, але є нюанси, про які не пишуть у маркетингових статтях.

Крива навчання для клієнтів. Site Editor суттєво відрізняється від класичного WordPress. Якщо ваші контент-менеджери звикли до старого інтерфейсу, дайте їм 2–4 тижні на адаптацію. Для багатьох він виявляється зручнішим, але перехідний період реальний.

Сумісність зі старими плагінами. Близько 97% вразливостей WordPress зосереджені в темах і плагінах (дані WPScan). Частина старих плагінів, особливо ті, що завязані на Widget Areas або специфічних хуках класичних тем, можуть не працювати коректно з block theme. Перед міграцією обов’язково перевірте кожен встановлений плагін. Детальніше про безпеку плагінів, в статті безпека WordPress сайту.

Міграція, це не одна кнопка. Якщо хтось обіцяє вам “перейти на block theme за 10 хвилин”, він або спрощує, або говорить про новий порожній сайт. Реальна міграція з класичної теми (особливо Divi, Avada, Flatsome), це 1–3 робочі дні із staging-середовищем, тестуванням і поступовим переносом елементів.

Widgets більше не працюють як раніше. Якщо у вас є sidebar з класичними Widget Areas, їх треба переробити на блоки. Зазвичай це не складно, але потребує часу.

Як перейти з класичної теми на Block Theme, покрокова інструкція

1. Зробіть резервну копію сайту, повний backup файлів і бази даних (UpdraftPlus або Duplicator)
2. Налаштуйте staging-середовище, ніколи не тестуйте зміни теми на production-сайті
3. Оберіть підходящу block theme, рекомендації нижче в статті
4. Встановіть theme на staging, Зовнішній вигляд → Теми → Додати нову
5. Ознайомтесь з Site Editor, пройдіться по всіх 5 розділах, не поспішайте
6. Перенесіть меню та навігацію, у Site Editor → Navigation відтворіть структуру меню
7. Відтворіть header і footer, через Template Parts, використовуючи блоки
8. Перевірте класичний контент, старі пости та сторінки автоматично загортаються у Classic Block, вміст зберігається
9. Конвертуйте widgets до блоків, через Зовнішній вигляд → Widgets або вручну в Template Parts
10. Перевірте сумісність плагінів, активуйте кожен і перевірте чи він працює
11. Протестуйте на різних пристроях, мобільний, планшет, десктоп (60–70% e-commerce трафіку, мобільний)
12. Публікуйте на production, після того як staging-версія стабільна мінімум 48 годин

Найпоширеніша помилка, пропустити staging і тестувати одразу на живому сайті. Не робіть так.

Які Block Themes вибрати, рекомендації для UA бізнесу

Безкоштовні, офіційні теми WordPress

Twenty Twenty-Five (WordPress 6.7), найсвіжіша офіційна block theme. Мінімалістичний дизайн, чудово підходить для блогів, портфоліо, медіа-видань. Включає функцію Zoom Out. Безкоштовна, регулярно оновлюється командою WordPress.

Twenty Twenty-Four, стабільна і добре протестована. Три набори патернів для різних типів бізнесу: блог, портфоліо, корпоративний сайт. Якщо не знаєте з чого почати, починайте з неї.

Для бізнес-сайтів

GeneratePress, найшвидша block theme в категорії. Розмір сторінки 45 KB, час завантаження 0.8 секунди. Мінімалістична, але з потужними налаштуваннями. Ідеальна якщо Core Web Vitals, пріоритет.

Kadence, хороший баланс між функціями та швидкістю. Гнучкіша за Twenty-* теми, але важча за GeneratePress. Підходить для бізнес-сайтів де потрібно більше кастомізації без плагінів.

Коли краще замовити розробку

Стандартні block themes підходять для більшості випадків. Але є ситуації, коли краще кастомна розробка:

• Специфічні вимоги до дизайну з фірмовим стилем
• Складна функціональність (інтеграції, калькулятори, кастомні типи контенту)
• Потрібен кастомний theme.json під брендбук компанії
• Міграція складного сайту на Divi або Avada з десятками шаблонів

Якщо ваш випадок схожий на один з цих, я як WordPress-розробник smtv.studio можу оцінити обсяг і запропонувати рішення. Переглянути послуги WordPress-розробки, або напишіть мені безпосередньо.

Висновок, Block Themes це сьогодення, не майбутнє

Андрій, власник невеликої студії дизайну інтер’єрів у Києві, відкладав перехід на block theme два роки поспіль. “Навіщо чіпати те, що працює?” Торік він нарешті зважився. Після міграції час завантаження сайту впав з 4.2 до 1.8 секунди, заявки через сайт зросли на 23% за перший квартал, і він більше не телефонує розробнику кожного разу, коли хоче змінити банер на головній.

Block Theme WordPress, це не черговий WordPress-тренд, який зникне через рік. Це нова архітектурна основа платформи, якою користується 43% всього інтернету. WordPress 7.0 у 2026 продовжує цей курс. Питання не “чи переходити”, а “коли і як зробити це правильно”.

Якщо ваш сайт повільний, залежить від важкого page builder’а, або ви платите розробнику за кожну дрібну зміну дизайну, block theme вирішує всі ці проблеми одночасно.

Плануєте перейти на block theme? Зв’яжіться зі мною, проконсультую безкоштовно і розкажу, що конкретно потрібно для вашого сайту.

Коротка відповідь: так, варто. Google використовує ці три показники як прямий сигнал ранжування. Це означає, що два сайти з однаково якісним контентом можуть займати різні позиції в пошуку, і Core Web Vitals часто є тією різницею.

Кілька цифр для розуміння масштабу:

• 53% мобільних користувачів залишають сайт, якщо він завантажується довше 3 секунд (Google Research)
• 44% WordPress-сайтів не проходять Core Web Vitals на мобільних пристроях (corewebvitals.io, 2025)
• Погані показники CLS збільшують показник відмов на 20–25%, особливо в інтернет-магазинах

Хороша новина: розібратись у цих метриках і зрозуміти, що з ними робити, не так складно, як здається.

Навіщо Google придумав ці три числа

До 2021 року Google ранжував сайти переважно за якістю контенту та посиланнями. Але виявилось, що навіть ідеальна стаття не допомагає бізнесу, якщо сайт відкривається 8 секунд або кнопка “Замовити” стрибає в останній момент.

Google хоче показувати в пошуку сайти, якими зручно користуватись. Тому у 2021 році ці три метрики стали офіційними факторами ранжування.

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

Таблиця порогових значень

Саме ці пороги Google використовує для оцінки. Якщо всі три показники в зеленій зоні, сайт вважається таким, що “проходить” Core Web Vitals.

LCP: перше враження про ваш сайт у секундах

LCP (Largest Contentful Paint), це час, за який на екрані з’являється основний контент сторінки: великий заголовок, фото товару, банер.

Уявіть: потенційний клієнт відкриває ваш сайт у ліфті з нестабільним 4G. Ліфт їде 4 поверхи. Якщо за цей час він бачить лише білий екран, він закриває вкладку.

Ціль: LCP менше 2.5 секунди.

Чому LCP буває поганим

Найчастіші причини поганого LCP на WordPress:

• Великі незоптимізовані зображення, PNG замість WebP, розмір 3–5 МБ замість 200–400 КБ
• Зображення без атрибуту fetchpriority="high", браузер не знає, що грузити першим
• Повільний хостинг, час відповіді сервера > 0.6 с сам по собі “з’їдає” LCP
• Рендер-блокуючі скрипти, JavaScript, який завантажується перед контентом

Як виправити LCP

Видаліть або відкладіть скрипти, які не потрібні при першому завантаженні

Конвертуйте головне зображення у формат WebP і стисніть до < 200 КБ

Переконайтесь, що хостинг знаходиться в Україні або країні вашої аудиторії

Увімкніть кешування сторінок (плагін WP Rocket або LiteSpeed Cache)

INP: чи реагує сайт коли клієнт щось натискає

INP (Interaction to Next Paint), це час між тим, як користувач натискає на щось (кнопку, посилання, форму), і моментом, коли браузер це відображає.

Реальний кейс: клієнт заповнює форму замовлення і натискає “Відправити”. Нічого не відбувається 2 секунди. Він натискає ще раз. І ще. В результаті, три дублікати заявки або скасована покупка.

Ціль: INP менше 200 мілісекунд.

Важливо: INP замінив старий показник FID у березні 2024 року. Якщо ви читали про Core Web Vitals раніше, орієнтуйтесь саме на INP.

Як виправити INP

Проблеми з INP майже завжди пов’язані з JavaScript:

Використовуйте оптимізатор JS, WP Rocket або Perfmatters вміють відкладати виконання скриптів до взаємодії користувача

Видаліть невикористовувані плагіни, кожен плагін WordPress додає свій JS, навіть там, де він не потрібен

Відкладіть сторонні скрипти (Google Tag Manager, чат-боти, пікселі реклами), вони не повинні блокувати взаємодію

CLS: чи «стрибає» сторінка поки ви читаєте

CLS (Cumulative Layout Shift), це оцінка стабільності сторінки. Чи стрибають елементи, поки ви читаєте?

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

Ціль: CLS менше 0.1.

Три типові причини CLS на WordPress

1. Зображення без заданих розмірів, браузер не знає, скільки місця зарезервувати, поки фото не завантажиться
2. Шрифти без fallback, поки завантажується кастомний шрифт, текст відображається в іншому, і при заміні “стрибає”
3. Динамічні банери і чат-боти, вставляються після завантаження основного контенту і зміщують все навколо

Як виправити CLS

Відкладіть завантаження чат-ботів (вони рідко потрібні при першому рендері)

Завжди вказуйте width і height для всіх зображень у HTML

Використовуйте font-display: swap або попередньо завантажуйте шрифти

Для банерів і реклами резервуйте місце заздалегідь через CSS

Як перевірити Core Web Vitals свого сайту: три способи

Спосіб 1: PageSpeed Insights (найшвидший)

1. Зайдіть на pagespeed.web.dev
2. Введіть URL свого сайту
3. Зачекайте 30–60 секунд
4. Подивіться секцію “Core Web Vitals Assessment”

Важливо: перевіряйте мобільну версію (вкладка “Mobile”), Google індексує сайти саме за мобільною версією.

Спосіб 2: Google Search Console (найточніший)

PageSpeed Insights показує лабораторні дані, тест з одного підключення. Google Search Console показує реальні дані від реальних відвідувачів вашого сайту за останні 28 днів.

Щоб знайти:

1. Зайдіть в Google Search Console
2. Розділ “Experience” → “Core Web Vitals”
3. Там будуть реальні сторінки, розділені на “Добре”, “Потребує покращення”, “Погано”

Якщо у вас є доступ до Search Console, починайте саме звідти. Це реальна картина, а не синтетичний тест.

Спосіб 3: GTmetrix (детальна діагностика)

GTmetrix (gtmetrix.com) дає детальний звіт з waterfall-діаграмою: видно, які саме файли завантажуються довго і в якому порядку. Зручно для діагностики конкретних проблем.

Що означають результати: що терміново, а що може зачекати

Коли отримаєте результати, орієнтуйтесь так:

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

🟡 Жовте, заплануйте найближчі 1–2 місяці. Показники прийнятні, але є куди рости. Не критично, але варто виправити.

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

Що виправляти першим:

Якщо у вас обмежений час і ресурси, починайте з LCP і CLS. Вони найбільше впливають на першe враження і мають чіткі технічні рішення. INP складніший у виправленні і потребує більше технічних знань.

WordPress і Core Web Vitals: конкретні плагіни

WordPress, найпопулярніша CMS, але саме через це на ньому легко “накопичити” десятки плагінів і тем, які сповільнюють сайт. Лише 44% WordPress-сайтів успішно проходять Core Web Vitals на мобільних, проти 65% Shopify і 60% Wix.

Ось що реально допомагає:

Для LCP і загальної швидкості

• WP Rocket, найпопулярніший преміум-плагін оптимізації. Кешування, відкладання JS, оптимізація зображень. Вирішує більшість проблем “в один клік”.
• LiteSpeed Cache, безкоштовний і дуже потужний, але потребує хостинг на LiteSpeed-сервері.
• WP-Optimize, безкоштовна альтернатива для кешування та очищення бази даних.

Для зображень (LCP і загальний розмір)

• Imagify або ShortPixel, автоматично конвертують зображення у WebP і стискають без втрати якості.
• EWWW Image Optimizer, безкоштовний варіант з базовою оптимізацією.

Для CLS

• Perfmatters, дозволяє точково вимикати скрипти на конкретних сторінках, де вони не потрібні.

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

Детальніше про те, чому WordPress-сайти сповільнюються і як це виправити, читайте у статті 5 причин чому сайт завантажується повільно.

Висновок

Core Web Vitals, це не страшна технічна абревіатура, а три зрозумілих питання про ваш сайт:

1. LCP: Як швидко завантажується головний контент? (Ціль: < 2.5 с)
2. INP: Чи реагує сайт на дії користувача? (Ціль: < 200 мс)
3. CLS: Чи стабільна сторінка під час читання? (Ціль: < 0.1)

Почніть з перевірки в PageSpeed Insights або Google Search Console, це займе 5 хвилин. Якщо побачите червоні показники, це точки де ваш сайт втрачає клієнтів прямо зараз.

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

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

Чому фрілансер перестав відповідати, і це не завжди про вас

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

Зупиніться. Найчастіше зникнення розробника не має нічого спільного з вашим проєктом.

Ось реальні причини, чому фрілансер перестав відповідати:

• Вигорання. Фріланс без чіткого графіку і меж призводить до емоційного виснаження. Людина просто перестає тягнути.
• Перевантаження. Взяли занадто багато клієнтів одночасно. Замість того щоб сказати “я не встигаю”, просто зникають.
• Особисті обставини. Хвороба, родина, переїзд, або ж що завгодно інше, що виводить людину з ладу на тиждень, а потім на місяць.
• Фінансові проблеми. Почали інший проект, де краще платять, і ваш відійшов на другий план.
• Страх складного діалогу. Якщо щось пішло не так технічно, частина розробників вважає за краще просто зникнути, ніж пояснювати.

Жодна з цих причин не виправдовує непрофесійну поведінку. Але розуміння цього знімає зайву тривогу і дозволяє зосередитись на тому, що важливо.

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

Крок 0: Інвентаризація доступів, що у вас є прямо зараз

Перш ніж щось робити, складіть список. Відкрийте нотатник або таблицю і дайте відповіді на п’ять запитань.

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

Друге: домен. Хто реєстрував домен? Чи є у вас доступ до акаунту реєстратора? Коли закінчується термін дії домену?

Третє: WordPress. Чи є у вас логін і пароль до адмінки? Чи пам’ятаєте адресу входу (зазвичай yoursite.com/wp-admin)?

Четверте: FTP або файловий менеджер. Чи є доступ до файлів сайту напряму? Це може знадобитись, якщо щось піде не так під час оновлень.

П’яте: пошта. Яка електронна адреса прив’язана до хостингу, домену і WordPress? Чи є у вас доступ до цієї поштової скриньки?

Що повинно бути у вашому списку доступів

Складіть таблицю з такими колонками:

• Хостинг: назва провайдера, URL панелі, логін, пароль, електронна адреса облікового запису
• Домен: назва реєстратора, URL, логін, пароль, дата закінчення реєстрації
• WordPress адмінка: URL входу, логін адміністратора, пароль
• FTP/SSH: хост, порт, логін, пароль
• База даних: назва, логін, пароль (є в cPanel або в файлі wp-config.php)
• Google Analytics: чи є у вас доступ власника до GA4-властивості вашого сайту
• Google Search Console: чи підтверджений ваш сайт і чи є у вас доступ власника

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

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

Крок 1: Що робити, якщо домен або хостинг оформлені на розробника ⏱ 1-3 дні

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

Як перевірити, хто власник домену

Перший крок, WHOIS-пошук. Зайдіть на who.is і введіть ваш домен. Ви побачите:

• Registrant Name, ім’я власника домену
• Registrant Email, контактна пошта власника
• Registrar, реєстратор, у якого зареєстровано домен
• Expiry Date, дата закінчення реєстрації

Якщо ваше ім’я або назва вашої компанії стоїть у полі Registrant, домен формально ваш. Просто потрібно відновити доступ до акаунту реєстратора. Зверніться до підтримки реєстратора і поясніть ситуацію.

Якщо там ім’я розробника, ситуація складніша, але вирішувана.

Домен зареєстрований на розробника, алгоритм дій

Не панікуйте. Ось що робити по кроках:

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

Другий крок. Зверніться до підтримки реєстратора домену. Поясніть ситуацію: ви замовник, розробник не відповідає, домен зареєстровано на його ім’я. Надайте докази.

Третій крок. Для доменів у зоні .UA є окрема процедура через nic.ua. Може знадобитись надати документи, що підтверджують вашу особу або право на домен. Детальна інструкція є на сторінці ukraine.com.ua.

Строки: зазвичай 3-10 робочих днів для перенесення домену. Це небистро, але вирішувано.

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

Хостинг на акаунті розробника, що робити

Хостинг-провайдери стикаються з цією ситуацією регулярно. Вони розуміють, що трапляється, і мають процедури для таких випадків.

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

Що знадобиться надати:

• Підтвердження оплати хостингу або розробки (банківська виписка, квитанції)
• Назва домену і URL сайту
• Ваші контактні дані і документ, що підтверджує особу

Більшість провайдерів вирішують це питання протягом 24-48 годин. Хостинг-провайдери розуміють цю ситуацію, вона трапляється часто.

Якщо хостинг і домен у вас є, або щойно відновлені, рухайтесь далі.

Крок 2: Аудит стану без паніки ⏱ 30 хвилин

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

Перше, відкрийте Dashboard → Updates. Подивіться, скільки оновлень чекає. Запишіть: поточна версія WordPress, кількість плагінів з оновленнями, кількість тем з оновленнями. Якщо версія WordPress нижче 6.x, це пріоритет номер один.

Друге, перевірте версію PHP. Зайдіть в Tools → Site Health (документація). Там вказано поточну версію PHP і чи є критичні проблеми. PHP 7.4 і нижче вже не підтримується і є ризиком безпеки. Актуальна версія для WordPress, PHP 8.1 або 8.2.

Site Health показує не тільки PHP. Там є розділ “Critical Issues” і “Recommended Improvements”. Критичні проблеми, це те, що потрібно вирішити в першу чергу. Рекомендовані, потім.

Третє, подивіться на список плагінів у Plugins → Installed Plugins. Чи всі знайомі? Чи є щось, що ви не встановлювали? Активні плагіни, яких ви не впізнаєте, можуть бути ознакою злому або просто залишками роботи попереднього розробника. Не видаляйте їх ще, але зафіксуйте.

Четверте, перевірте наявність SSL-сертифіката. Сайт відкривається через https:// (замок у браузері) чи через http://? Без SSL Google вже рік як понижує сайти в пошуку. Якщо сертифіката немає, зверніться до хостинг-провайдера. Більшість надають Let’s Encrypt безплатно через cPanel.

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

Крок 3: Безпека, перш ніж що-небудь оновлювати ⏱ 20 хвилин

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

Перше: змініть пароль адміністратора WordPress. Зайдіть в Users → All Users. Знайдіть свій акаунт (роль Administrator) і встановіть новий складний пароль. Мінімум 16 символів, комбінація літер, цифр і спецсимволів. WordPress має вбудований генератор паролів, використайте його.

Друге: перевірте список користувачів. Подивіться на всіх адміністраторів. Чи є акаунти, яких ви не впізнаєте? Якщо є підозрілі користувачі з роллю Administrator, видаліть їх негайно.

Третє: змініть пароль до хостингу. Якщо розробник мав доступ до cPanel або панелі хостингу, змініть пароль там теж.

Четверте: перевірте FTP-акаунти. В cPanel або аналогічній панелі знайдіть список FTP-акаунтів. Видаліть або деактивуйте ті, що більше не потрібні.

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

Крок 4: Бекап, до того, як щось чіпати ⏱ 30-60 хвилин

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

Встановіть плагін UpdraftPlus. Це безплатний і надійний інструмент для резервного копіювання, яким користуються мільйони сайтів.

Після встановлення зайдіть в Settings → UpdraftPlus Backups і налаштуйте:

• Куди зберігати: Google Drive або Dropbox. Не на сервер хостингу, інакше бекап і сайт загинуть разом.
• Частота: хоча б раз на тиждень для файлів, раз на тиждень для бази даних.
• Кількість копій: зберігайте мінімум 3 останніх бекапи.

Зробіть ручний бекап прямо зараз, натиснувши “Backup Now”. Дочекайтесь завершення. Зазвичай це займає від 5 до 30 хвилин залежно від розміру сайту. Перевірте, що файли з’явились у вашому Google Drive або Dropbox.

Після бекапу у вас є “точка відновлення”. Навіть якщо щось піде не так під час оновлень, ви зможете повернутись до стану “до” буквально за кілька кліків. Це знімає 90% тривоги, яка заважає починати.

Тільки після цього, до оновлень.

Крок 5: Оновлення, по одному, не всі одразу ⏱ 1-2 години

Якщо у вас 40+ оновлень, спокуса натиснути “Update All” велика. Не робіть цього.

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

Порядок оновлень такий:

Перший: WordPress core. Оновіть саму платформу. Якщо є перехід між мажорними версіями (наприклад, з 5.x на 6.x), прочитайте release notes на wordpress.org, там завжди вказані зміни, що можуть вплинути на сумісність.

Другий: плагіни по одному. Починайте з найважливіших: плагіни безпеки (Wordfence, iThemes Security), кешування (WP Rocket, W3 Total Cache), SEO (Yoast, Rank Math). Після кожного оновлення перевіряйте сайт: головна сторінка, одна з внутрішніх, форма контакту або кошик (якщо є).

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

Третій: теми. Теми оновлюйте в останню чергу. Якщо ви використовуєте дочірню тему (child theme), батьківська тема оновлюється безпечно. Якщо дочірньої немає, оновлення теми може перезаписати ваші зміни у CSS і PHP-файлах. Перед оновленням теми уточніть у нового підрядника, чи є дочірня тема.

Після кожного блоку оновлень знову перевіряйте сайт. Якщо щось зламалося, UpdraftPlus дозволить відкотитись до попередньої версії за кілька хвилин.

Що далі: як не потрапити в ситуацію “фрілансер перестав відповідати” знову

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

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

Червоні прапорці при виборі наступного розробника

Це ознаки, які мають насторожити ще на старті:

• Не передає доступи на початку роботи. Якщо через тиждень після початку проекту у вас нема доступу до хостингу і адмінки, це проблема.
• Не пояснює, що робить. Якщо на питання “що ви змінили на сайті?” у відповідь тільки мовчання або технічний жаргон, це погана ознака.
• Немає відповіді більше 48 годин. Не 48 хвилин, а 48 годин. Навіть у вихідні. Хоча б коротке “бачу, відповім у понеділок”.
• Ніколи не ініціює зустрічі або дзвінки. Хороший підрядник хоче розуміти ваш бізнес, а не просто виконувати технічні задачі.
• Немає договору або рахунків. Робота без договору, це ризик для обох сторін, але особливо для вас.

Зелені прапорці

Ознаки надійного підрядника:

• Передає всі доступи в перший тиждень. Без зайвих запитань і затягувань.
• Є договір з переліком зобов’язань. Де написано, що входить у підтримку, яка реакція на звернення, що відбувається при розірванні.
• Реагує протягом 24 годин. Навіть якщо не може вирішити одразу, дає знати, що побачив і коли буде відповідь.
• Пояснює рішення простою мовою. Можливо не завжди у деталях, але хоча б на рівні “оновив плагін безпеки, бо була вразливість”.
• Є план регулярної технічної підтримки. Планові оновлення, перевірки безпеки, бекапи за розкладом.

Якщо ви пройшли всі кроки самостійно, добре. Ваш сайт у значно кращому стані, ніж був. Якщо хочете, щоб хтось взяв це на себе і побудував нормальний процес підтримки, зв’яжіться з нами. Без зникань і без нерозуміння.

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

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

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

Чому WordPress є мішенню для зломів

Перш ніж перейти до практичних кроків, варто зрозуміти, чому WordPress безпека для бізнесу є такою критично важливою темою. WordPress – найпопулярніша CMS у світі. Це одночасно і перевага, і слабке місце. Велика популярність означає велику кількість потенційних цілей, що робить платформу привабливою для зловмисників.

Відкрита екосистема плагінів і тем – основне джерело вразливостей. На сьогодні в офіційному репозиторії WordPress доступно понад 59,000 плагінів. Якість і підтримка цих плагінів суттєво відрізняється. Деякі з них місяцями не оновлюються, містять відомі вразливості, але продовжують використовуватися на сотнях тисяч сайтів.

Автоматизовані боти постійно сканують інтернет у пошуку конкретних ознак WordPress: стандартний URL входу /wp-admin, стандартні префікси таблиць бази даних wp_, відомі шляхи до файлів. Ці ознаки видно без будь-якого злому, просто через звичайний HTTP-запит.

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

1. Регулярно оновлюйте WordPress, теми і плагіни ⏱ 10 хвилин

Чому оновлення критичні

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

За даними досліджень, понад 56% зламаних WordPress-сайтів мали застарілі компоненти на момент злому. Оновлення – це найпростіший і найефективніший захід безпеки. Він нічого не коштує і займає хвилини.

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

Як налаштувати автоматичні оновлення

WordPress дозволяє налаштувати автоматичні оновлення прямо в адмін-панелі. Перейдіть до розділу “Панель керування” > “Оновлення”. Тут можна увімкнути автоматичне оновлення ядра WordPress. Для плагінів і тем перейдіть до відповідних розділів і увімкніть автоматичні оновлення для кожного елемента окремо.

Альтернативно, якщо ви хочете більш гнучке управління, плагін Easy Updates Manager дозволяє централізовано контролювати всі оновлення. Налаштуйте автоматичне оновлення хоча б для плагінів безпеки та відомих великих плагінів. Перевіряйте сайт щотижня і вручну оновлюйте решту компонентів.

Якщо ви не хочете стежити за оновленнями самостійно, технічна підтримка WordPress від SMTV Studio включає щомісячне обслуговування сайту: оновлення, бекапи та моніторинг безпеки.

2. Використовуйте надійні унікальні паролі ⏱ 5 хвилин

Які паролі вважаються надійними

Надійний пароль у 2026 році – це не “Password123!” і не ваш день народження. Мінімальні вимоги: не менше 16 символів, поєднання великих і малих літер, цифр і спеціальних символів. Паролі типу “qwerty”, “admin”, “123456” зламуються ботами в першу чергу, бо вони входять до стандартних словників для brute force атак.

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

Не намагайтесь придумувати і запам’ятовувати складні паролі вручну. Для цього існують менеджери паролів. Вони генерують криптографічно стійкі паролі і безпечно зберігають їх.

Менеджери паролів: 1Password, Bitwarden

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

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

3. Увімкніть двофакторну аутентифікацію (2FA) ⏱ 10 хвилин

Що таке 2FA і навіщо вона потрібна

Двофакторна аутентифікація (2FA) додає другий рівень захисту при вході на сайт. Навіть якщо зловмисник якимось чином дізнався ваш пароль, він не зможе увійти без другого фактора, яким зазвичай є одноразовий код з мобільного додатку.

Статистика говорить сама за себе: за даними Microsoft, 2FA блокує 99.9% атак на облікові записи, пов’язаних з компрометацією паролів. Це один з найефективніших захисних заходів, що існують. При цьому він додає лише 10-15 секунд до процесу входу.

Для WordPress рекомендовані додатки-аутентифікатори: Google Authenticator, Authy або Microsoft Authenticator. Всі вони безкоштовні і доступні для iOS та Android. Вони генерують одноразові коди, які змінюються кожні 30 секунд.

Плагін WP 2FA: покрокове налаштування

Встановіть плагін WP 2FA з офіційного репозиторію WordPress. Після активації плагін запустіть майстер налаштування.

Покрокове налаштування:

1. встановіть плагін;
2. у налаштуваннях оберіть метод аутентифікації (TOTP – одноразові коди з додатку);
3. налаштуйте 2FA як обов’язковий для всіх адміністраторів;
4. відскануйте QR-код у своєму додатку-аутентифікаторі;
5. введіть тестовий код для підтвердження.

Важливо: збережіть резервні коди відновлення в безпечному місці. Якщо ви втратите доступ до телефону, ці коди дозволять увійти на сайт.

4. Змініть стандартний URL сторінки входу ⏱ 5 хвилин

Чому /wp-admin є проблемою

За замовчуванням сторінка входу WordPress доступна за адресою yoursite.com/wp-admin або yoursite.com/wp-login.php. Це знають всі: і розробники, і боти. Автоматизовані скрипти щодня надсилають тисячі запитів на ці стандартні URL, намагаючись підібрати паролі.

Зміна URL входу не є абсолютним захистом (це “безпека через невідомість”), але вона ефективно відсіює весь автоматизований трафік. Боти шукають стандартні URL, не знаходять їх і переходять до наступного сайту. Це суттєво зменшує навантаження на сайт і кількість записів у журналах безпеки.

За даними власників сайтів, які змінили URL входу, кількість спроб несанкціонованого входу падає на 95-99% відразу після зміни. Простий крок з величезним ефектом.

Плагін WPS Hide Login

Встановіть плагін WPS Hide Login. Він простий і надійний. Після активації перейдіть до “Налаштування” > “WPS Hide Login”. Введіть новий URL для сторінки входу, наприклад yoursite.com/my-panel або будь-який інший. Збережіть зміни.

Одразу запишіть новий URL у безпечному місці, наприклад у менеджері паролів. Якщо ви забудете власний URL входу, доступ до адмін-панелі буде заблокований, і відновлення вимагатиме втручання через FTP або phpMyAdmin.

5. Обмежте кількість невдалих спроб входу ⏱ 5 хвилин

Що таке brute force атака

Brute force (“груба сила”) – це метод злому, при якому бот автоматично перебирає тисячі комбінацій логінів і паролів, поки не знайде правильну. За замовчуванням WordPress не обмежує кількість спроб входу, тобто бот може робити 1,000 спроб за хвилину без будь-яких наслідків.

Саме тому слабкі паролі так небезпечні: при необмежених спробах навіть відносно складний пароль з 8 символів зламується за лічені години. Але навіть найнадійніший пароль не замінить захист від brute force, бо це два різних рівні захисту.

Обмеження кількості спроб входу повністю зупиняє brute force атаки. Після 3-5 невдалих спроб IP-адреса блокується на певний час. Бот не може продовжувати перебір і відступає.

Плагін Limit Login Attempts Reloaded або AIOS

Два хороші варіанти для захисту від brute force: Limit Login Attempts Reloaded і All In One Security (AIOS). Перший спеціалізується саме на обмеженні входів. Другий є комплексним рішенням безпеки, яке включає цю функцію серед багатьох інших.

All In One WP Security and Firewall (AIOS) є одним з найпопулярніших безкоштовних плагінів безпеки. Після встановлення перейдіть до “WP Security” > “Brute Force” і активуйте захист. Рекомендовані налаштування: 5 невдалих спроб перед блокуванням, блокування на 60 хвилин.

6. Налаштуйте автоматичний бекап ⏱ 15 хвилин

Правило бекапів 3-2-1

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

Золоте правило бекапів – 3-2-1: три копії даних, на двох різних носіях, одна копія поза офісом (або хмарно). Для WordPress це означає: локальна копія на хостингу, копія на Google Drive або Dropbox, і архів на окремому пристрої.

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

UpdraftPlus: налаштування щоденного бекапу на Google Drive

UpdraftPlus – найпопулярніший плагін бекапів для WordPress з понад 3 мільйонами активних установок. Безкоштовна версія включає всі необхідні функції.

Налаштування:

1. встановіть і активуйте UpdraftPlus;
2. перейдіть до “Налаштування” > “UpdraftPlus Backups”;
3. у розділі “Розклад” встановіть щоденний бекап файлів і бази даних;
4. у розділі “Хмарне сховище” оберіть Google Drive і авторизуйте доступ;
5. встановіть зберігання останніх 7 бекапів;
6. натисніть “Зберегти зміни” і одразу зробіть перший ручний бекап для перевірки.

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

7. Видаліть все невикористовуване ⏱ 10 хвилин

Неактивні плагіни і теми як ризик

Деактивований плагін все ще містить файли на сервері. Якщо ці файли мають вразливості, зловмисник може їх використати, навіть якщо плагін неактивний. Те саме стосується тем: більшість WordPress-сайтів мають 2-3 теми, але використовують лише одну. Решта залишаються як невидимий ризик.

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

Також видаліть стандартні плагіни, які WordPress встановлює за замовчуванням, але якими ви не користуєтесь: Hello Dolly, Akismet (якщо не налаштований), стандартні теми Twenty Twenty-One, Twenty Twenty-Two тощо.

Як провести аудит встановлених плагінів

Перейдіть до розділу “Плагіни” > “Усі плагіни” в адмін-панелі. Для кожного плагіна задайте собі три питання: чи використовується цей плагін? Коли він востаннє оновлювався? Чи є кращий альтернативний плагін з активною підтримкою?

Плагін, який не оновлювався більше 2 років, є потенційним ризиком. Перевірте на wordpress.org, чи є він у статусі “abandoned” (покинутий). Якщо так, знайдіть альтернативу або відмовтесь від цього функціоналу. Не забудьте також видалити (а не просто деактивувати) все, що вирішили не використовувати.

8. Заблокуйте редагування файлів через адмін-панель ⏱ 2 хвилини

Чому редактор файлів небезпечний

WordPress має вбудований редактор файлів, доступний через “Зовнішній вигляд” > “Редактор тем” і “Плагіни” > “Редактор”. Ця функція дозволяє редагувати PHP-файли прямо з браузера. Зручно для розробника, але дуже небезпечно для власника бізнесу.

Якщо зловмисник отримує доступ до облікового запису адміністратора з будь-яким паролем (наприклад, через фішинг або витік даних), він може використати редактор файлів для вставки шкідливого коду в теми або плагіни. Такий backdoor дає постійний доступ до сайту, навіть після зміни паролів.

Вимкнення редактора файлів не впливає на роботу сайту для відвідувачів. Ви все одно можете редагувати файли через FTP або файловий менеджер хостингу. Але зловмисник через адмін-панель цього зробити не зможе.

Один рядок у wp-config.php

Щоб вимкнути редактор файлів, відкрийте файл wp-config.php через FTP-клієнт або файловий менеджер хостингу. Знайдіть рядок /* That's all, stop editing! Happy publishing. */ і перед ним додайте:

define('DISALLOW_FILE_EDIT', true);

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

9. Встановіть SSL-сертифікат та перейдіть на HTTPS ⏱ 15 хвилин

Що таке SSL і чому без нього не можна

SSL (Secure Sockets Layer) – це протокол шифрування, який захищає передачу даних між браузером користувача і вашим сервером. Сайт з SSL-сертифікатом відображається як https://, без нього – http://. Браузери позначають сайти без SSL як “небезпечні” прямо в адресному рядку.

Відсутність SSL – це не лише технічна проблема. За даними Google та Nielsen, 85% користувачів не здійснюють покупки на сайтах без HTTPS. Google офіційно підтвердив, що HTTPS є фактором ранжування: сайти без SSL отримують нижчі позиції в пошуковій видачі. Для бізнесу, який хоче залучати клієнтів через інтернет, SSL є обов’язковим.

Хороша новина: SSL більше не коштує грошей. Let’s Encrypt надає безкоштовні SSL-сертифікати, і більшість сучасних хостинг-провайдерів (SiteGround, Hostinger, Bluehost, GoDaddy та інші) дозволяють активувати їх в один клік через хостинг-панель. Зайдіть в cPanel або аналогічну панель вашого хостингу, знайдіть розділ SSL/TLS або Let’s Encrypt і активуйте сертифікат для вашого домену.

Плагін Really Simple SSL для переключення

Після активації SSL-сертифіката на хостингу сайт може залишатися на HTTP через внутрішні посилання і змішаний контент. Плагін Really Simple SSL автоматично виправляє ці проблеми і переключає весь сайт на HTTPS.

Встановіть і активуйте плагін. Він автоматично виявить SSL-сертифікат і запропонує перейти на HTTPS. Натисніть “Активувати SSL”. Плагін налаштує редиректи з HTTP на HTTPS і виправить посилання на змішаний контент. Після цього перевірте сайт через онлайн-інструмент “SSL Checker”, щоб переконатися, що все працює коректно.

10. Захистіть базу даних WordPress ⏱ 10 хвилин

Зміна префікса таблиць бази даних

За замовчуванням всі таблиці бази даних WordPress мають префікс wp_. Це відомо кожному, хто знайомий з WordPress, включно з авторами SQL-ін’єкцій. SQL-ін’єкція – це тип атаки, де зловмисник намагається виконати шкідливий SQL-запит через вразливу форму або URL. Знаючи стандартний префікс wp_, атаку простіше здійснити.

Зміна префікса на унікальний (наприклад, xk7m_) ускладнює такі атаки. Це не панацея, але додатковий рівень захисту. Важливо: якщо ваш сайт вже функціонує, зміна префікса є складнішою операцією і вимагає обережності. Обов’язково зробіть повний бекап перед будь-якими змінами в базі даних.

Плагін AIOS (All In One Security) має функцію зміни префікса таблиць у розділі “Безпека бази даних”. Він автоматично обробляє всі необхідні зміни. Однак, знову ж таки: спочатку бекап, потім зміни.

Регулярний бекап бази даних окремо від файлів

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

UpdraftPlus (описаний у кроці 6) робить бекапи бази даних окремо від файлів і дозволяє налаштувати різні розклади для кожного. Рекомендується робити бекап бази даних щоденно, навіть якщо файли бекапляться рідше. База даних змінюється при кожному новому записі, коментарі, замовленні – тобто постійно.

11. Підключіть Cloudflare для захисту від DDoS та ботів ⏱ 30 хвилин

Що таке Cloudflare і як він захищає WordPress

Cloudflare – це глобальна мережа, яка стоїть між відвідувачами і вашим сервером. Він фільтрує шкідливий трафік до того, як він досягне вашого сайту. Безкоштовний план Cloudflare включає: захист від DDoS-атак, фільтрацію ботів, CDN (прискорення сайту через кешування), базовий файрвол.

DDoS (Distributed Denial of Service) – це атака, при якій тисячі комп’ютерів одночасно надсилають запити на ваш сайт, щоб перевантажити сервер і вивести сайт з ладу. Cloudflare поглинає такі атаки завдяки своїй глобальній інфраструктурі. Безкоштовний план захищає від атак базового рівня, що є достатнім для більшості малих і середніх бізнесів.

Окрім безпеки, Cloudflare також пришвидшує завантаження сайту, кешуючи статичні файли на серверах по всьому світу. Якщо вас цікавить комплексне прискорення сайту, прочитайте нашу статтю про те, чому WordPress-сайт завантажується повільно і як це виправити.

Покрокове підключення Cloudflare до WordPress

Підключення Cloudflare:

1. зареєструйтесь на cloudflare.com;
2. додайте ваш домен і оберіть безкоштовний план;
3. Cloudflare просканує поточні DNS-записи;
4. перейдіть до вашого реєстратора доменів і змініть nameservers на ті, що надасть Cloudflare;
5. зачекайте до 48 годин для поширення DNS (зазвичай займає 1-4 години).

Після підключення: у налаштуваннях SSL в Cloudflare встановіть режим “Full (strict)”, якщо на вашому сервері вже є SSL-сертифікат. У розділі “Security” встановіть рівень безпеки “Medium” або “High”. Увімкніть “Bot Fight Mode” для блокування відомих ботів.

Firewall правила для WordPress в Cloudflare

Cloudflare дозволяє створювати власні правила файрволу. Для WordPress рекомендуються такі правила: заблокуйте запити до wp-login.php з країн, де у вас немає клієнтів; вимагайте проходження CAPTCHA для запитів до xmlrpc.php (часто використовується для атак); заблокуйте підозрілі User-Agent рядки, характерні для відомих сканерів вразливостей.

Ці правила можна налаштувати в розділі “Security” > “WAF” > “Custom rules”. Безкоштовний план Cloudflare дозволяє створити до 5 власних правил, що цілком достатньо для базового захисту WordPress.

12. Встановіть сканер безпеки ⏱ 10 хвилин

Wordfence Security: безкоштовний сканер

Wordfence Security – найпопулярніший плагін безпеки для WordPress з понад 4 мільйонами активних установок. Безкоштовна версія включає: файрвол, сканер шкідливого коду, захист від brute force, моніторинг трафіку в реальному часі.

Після встановлення запустіть повне сканування: “Wordfence” > “Scan” > “Start New Scan”. Перше сканування може тривати 5-15 хвилин. Wordfence порівнює всі ваші файли з оригінальними файлами WordPress, плагінів і тем. Будь-яке відхилення відображається у звіті.

Wordfence також надсилає email-сповіщення про підозрілу активність: масові спроби входу, виявлені шкідливі файли, застарілі компоненти. Налаштуйте email-сповіщення в розділі “Wordfence” > “All Options” > “Email Alert Preferences”.

Sucuri Security: альтернативний варіант

Sucuri Security – ще один надійний безкоштовний плагін безпеки. Його особлива цінність в аудиті активності: Sucuri детально логує всі дії в адмін-панелі, зміни файлів, входи користувачів. Це допомагає розслідувати інциденти після факту.

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

Як читати результати сканування: що критично, що можна ігнорувати

Результати сканування Wordfence поділяються на категорії: Critical (критично), Warning (попередження) і Notice (повідомлення). Critical вимагає негайної уваги: шкідливий код, підозрілі файли, компрометовані паролі. Warning зазвичай стосується застарілих компонентів і змінених файлів ядра. Notice – це інформаційні повідомлення, які не обов’язково є проблемами.

Не варто панікувати від великої кількості Notice-повідомлень. Наприклад, Wordfence може позначати кастомні модифікації теми як “змінені файли”, але якщо ви самі вносили ці зміни, це нормально. Фокусуйтесь на Critical і Warning, і вирішуйте їх один за одним.

Приховайте версію WordPress

Кожен WordPress-сайт за замовчуванням відображає свою версію у коді сторінки, мета-тегах і у посиланнях на CSS та JavaScript файли. Рядок виду ?ver=6.4.2 у URL статичних файлів та тег <meta name="generator" content="WordPress 6.4.2"> у <head> відкрито повідомляють ботам, яку саме версію CMS ви використовуєте.

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

Приховати версію WordPress просто. Додайте цей рядок у файл functions.php вашої активної теми:

remove_action('wp_head', 'wp_generator');

Цей код прибирає мета-тег з версією зі сторінок сайту. Додатково рекомендується видалити параметр версії з URL стилів і скриптів. Для цього у той самий файл functions.php додайте:

function remove_version_from_assets($src) {
    if (strpos($src, 'ver=') !== false) {
        $src = remove_query_arg('ver', $src);
    }
    return $src;
}
add_filter('style_loader_src', 'remove_version_from_assets', 9999);
add_filter('script_loader_src', 'remove_version_from_assets', 9999);

Якщо ви не хочете вручну редагувати файли теми, плагін Wordfence Security або AIOS також мають опцію приховання версії WordPress у своїх налаштуваннях безпеки. Один перемикач – і версія більше не видна стороннім.

Виберіть безпечний хостинг

Хостинг – це фундамент безпеки WordPress-сайту. Навіть якщо ви виконаєте всі 12 кроків з цього чек-листа ідеально, ненадійний хостинг залишається слабкою ланкою. Проблеми на рівні сервера – скомпрометований сусідній сайт на спільному хостингу, відсутність ізоляції між акаунтами, застаріле серверне програмне забезпечення – знаходяться поза вашим контролем і не вирішуються плагінами.

На що звертати увагу при виборі безпечного хостингу для WordPress:

Автоматичні бекапи – хостинг повинен робити щоденні бекапи і зберігати їх окремо від основного сервера. Це доповнює, а не замінює ваші власні бекапи через UpdraftPlus.

SSL у базовому плані – безкоштовний Let’s Encrypt або інший SSL-сертифікат має бути доступний з коробки, без доплат.

Файрвол і захист від DDoS – якісний хостинг має власний рівень захисту від зовнішніх атак ще до того, як трафік потрапляє на ваш сайт.

Сканування на шкідливий код – деякі хостинги автоматично сканують файли на сервері і попереджають про підозрілу активність.

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

Актуальні версії PHP – хостинг повинен підтримувати PHP 8.1+ і дозволяти вам вільно обирати версію.

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

Якщо ви не впевнені у надійності поточного хостингу або розглядаєте міграцію, команда SMTV Studio допоможе оцінити ваш хостинг і перенести сайт на безпечне середовище без простою.

Скільки коштує злом WordPress-сайту для бізнесу

Більшість власників бізнесу думають про безпеку WordPress абстрактно: “злом – це погано”. Але конкретні цифри набагато переконливіші. Розглянемо реальну вартість зламаного сайту – пряму і непряму.

Прямі витрати на усунення наслідків злому

Відновлення зламаного WordPress-сайту силами досвідченого розробника займає від 5 до 40 годин залежно від масштабу проблеми. За середньою ставкою $40-60 на годину це від $200 до $2,400 лише за технічну роботу. Якщо злом стався через вразливість у темі або плагіні, яку не закривали роками, відновлення може вимагати повної переробки частини сайту.

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

Непрямі втрати: Google і пошукові позиції

Google автоматично виявляє зламані сайти, що розповсюджують шкідливий код, і додає їх до чорного списку. Сайт отримує попередження “Цей сайт може завдати шкоди вашому комп’ютеру” у результатах пошуку. За середніми даними, відновлення пошукових позицій після потрапляння до чорного списку Google займає від 2 до 4 тижнів після очищення сайту і подання запиту на перегляд. Весь цей час органічний трафік фактично відсутній.

Для сайту, який отримував 500 відвідувачів на день через органічний пошук, тиждень простою – це ~3,500 втрачених відвідувачів. Якщо конверсія становила хоча б 1%, це 35 втрачених потенційних клієнтів за тиждень.

Витоки даних і юридична відповідальність

Якщо на вашому сайті зберігаються персональні дані клієнтів (імена, email, адреси, платіжна інформація), злом може спричинити витік цих даних. За регуляціями GDPR, яким підпадають українські компанії, що працюють з громадянами ЄС, штрафи за витік даних можуть сягати 4% річного обороту компанії або 20 мільйонів євро, залежно від того, що більше. Навіть без штрафів репутаційні наслідки витоку клієнтських даних можуть коштувати дорожче за будь-який технічний збиток.

Реальний сценарій

Інтернет-магазин з 500 відвідувачів на день і середнім чеком 800 гривень втрачає приблизно 50-150 замовлень за тиждень вимушеного простою. При конверсії 2% і середньому чеку 800 грн це 56,000 грн втраченого виторгу за один тиждень – і це без урахування вартості відновлення сайту.

Висновок

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

Що робити, якщо сайт вже зламали

Злом сайту – стресова ситуація, але не катастрофа, якщо діяти методично. Більшість зломів можна виправити за 24-48 годин при наявності свіжого бекапу. Ось покроковий план дій.

Крок 1: Не панікуйте. Зафіксуйте що сталось. Зробіть скріншоти або запишіть, що саме ви помітили: незнайомий контент на сайті, попередження від Google, блокування хостингом, сповіщення від Wordfence. Ця інформація допоможе при розслідуванні.

Крок 2: Ізолюйте сайт. Поставте сайт у режим технічного обслуговування (maintenance mode), щоб відвідувачі не бачили зламаний контент і не ставали жертвами шкідливого коду. Плагін WP Maintenance Mode або аналогічний допоможе це зробити швидко.

Крок 3: Запустіть сканер Wordfence або Sucuri. Повне сканування виявить шкідливі файли, backdoor-и і змінені компоненти. Збережіть звіт сканування. Видаліть всі виявлені шкідливі файли за рекомендацією сканера.

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

Крок 5: Змініть всі паролі. Після очищення або відновлення обов’язково змініть паролі до всього: WordPress-адміністратор, FTP-акаунт, хостинг-панель, база даних, email-акаунти, пов’язані з сайтом. Якщо злом стався через вкрадений пароль, зміна коду без зміни паролів не допоможе.

Після відновлення виконайте всі 12 кроків з цього чек-листа, якщо ви ще не зробили це раніше. І налаштуйте регулярні автоматичні бекапи, якщо їх не було. Більшість зломів можна виправити за 24-48 годин при наявності свіжого бекапу.

Чек-лист безпеки WordPress для бізнесу

Використовуйте цей чек-лист для систематичного покращення безпеки вашого сайту.

Зробіть сьогодні:

• Перевірте наявність SSL (https://) в адресному рядку вашого сайту
• Встановіть 2FA для облікового запису адміністратора
• Перевірте і оновіть всі плагіни, теми і WordPress до останніх версій
• Перевірте і вимкніть редагування файлів через wp-config.php

Цього тижня:

• Налаштуйте автоматичний бекап через UpdraftPlus на Google Drive
• Змініть URL сторінки входу за допомогою WPS Hide Login
• Встановіть сканер безпеки Wordfence і запустіть перше сканування
• Видаліть всі неактивні плагіни і теми
• Встановіть обмеження спроб входу через AIOS або Limit Login Attempts
• Підключіть Cloudflare для додаткового захисту і прискорення

Щомісяця:

• Перевірте журнал активності сайту в Wordfence або Sucuri
• Запустіть ручне сканування Wordfence
• Перевірте список всіх користувачів адмін-панелі, видаліть зайвих
• Переконайтесь, що бекапи зберігаються коректно і зробіть тестове відновлення

Висновок

Більше 43% сайтів у світі працюють на WordPress, і понад 90,000 атак відбувається щодня. Це не страшна статистика, а аргумент на користь дії. Автоматизовані боти атакують всі WordPress-сайти без винятку, але вони шукають легкі цілі: застарілі плагіни, слабкі паролі, стандартні URL входу, відсутній SSL. Сайт, що виконав базові заходи безпеки, автоматично стає набагато менш привабливою ціллю.

12 кроків, описаних у цій статті, покривають найважливіші аспекти захисту: оновлення, паролі, 2FA, зміна URL входу, обмеження brute force, бекапи, мінімалізм плагінів, захист файлів, SSL WordPress, безпека бази даних, Cloudflare і сканування. Більшість з них займає 5-15 хвилин і не потребує технічних знань.

Починайте з найважливішого: SSL, 2FA, оновлення, бекапи. Ці чотири кроки дають найбільший ефект за найменший час. Решту можна розподілити на кілька вечорів тижня. WordPress безпека для бізнесу без коду, за один вечір – це цілком реально.

Не маєте часу налаштовувати безпеку самостійно? Команда SMTV Studio проведе повний аудит безпеки WordPress та налаштує захист за вас. Замовити аудит безпеки →