Встановлення та налаштування WordPress на сервері
WordPress часто гальмує на shared-хостингу при 500 відвідувачах — це результат неоптимальної конфігурації сервера. Реальний випадок: інтернет-магазин з 3000 відвідувачів на день вантажився 10 секунд, через що конверсія падала на 40%. Ми перенесли його на VPS з Nginx та PHP 8.3, налаштували кешування та CDN — час завантаження знизився до 1.5 секунд, конверсія зросла на 30%. Економія на хостингу при правильному виборі VPS може досягати 40% порівняно з неоптимальними тарифами. Вартість налаштування окупається за рахунок збільшення конверсії — у наведеному кейсі конверсія зросла на 30%. Ми налаштовуємо WordPress під ключ: від вибору хостингу до production-готової конфігурації.
Чому важлива правильна конфігурація сервера?
На shared-хостингу ви ділите ресурси з сусідами — CPU, RAM і навіть MySQL. При піку навантаження сайт може впасти. VPS (віртуальний виділений сервер) дає ізольоване середовище, але вимагає ручного налаштування LEMP (Linux, Nginx, MySQL, PHP) або LAMP. Різниця в продуктивності колосальна: коректно налаштований Nginx обробляє статику в 10 разів швидше за Apache. Порівняємо варіанти:
| Характеристика |
Shared-хостинг |
VPS |
| Встановлення |
5–10 хвилин, авто |
3–4 години вручну |
| Продуктивність |
Середня, залежність від сусідів |
Висока, ресурси ваші |
| Гнучкість |
Обмежена |
Повний доступ до сервера |
| Безпека |
Базова |
Налаштовується під проект |
| Економічність |
Доступно |
Середні вкладення |
Висновок: для блогу або невеликого бізнесу вистачить shared, для інтернет-магазину або сайту з 10 000+ відвідувачів потрібен VPS.
Як налаштувати WordPress вручну на VPS?
Встановлення на Ubuntu LTS з Nginx та PHP 8.3 включає кілька кроків. Спочатку встановіть пакети:
apt install nginx php8.3-fpm php8.3-mysql php8.3-curl php8.3-gd \
php8.3-mbstring php8.3-xml php8.3-zip php8.3-intl mysql-server
Створіть базу даних та користувача:
mysql -u root -e "
CREATE DATABASE wordpress CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wp_user'@'localhost' IDENTIFIED BY 'strong-password-here';
GRANT ALL PRIVILEGES ON wordpress.* TO 'wp_user'@'localhost';
FLUSH PRIVILEGES;"
Завантажте WordPress та налаштуйте права:
cd /var/www
wget https://wordpress.org/latest.tar.gz
tar xzf latest.tar.gz
mv wordpress yourdomain.com
chown -R www-data:www-data yourdomain.com
Конфігурація wp-config.php
define('DB_NAME', 'wordpress');
define('DB_USER', 'wp_user');
define('DB_PASSWORD', 'strong-password-here');
define('DB_HOST', 'localhost');
define('DB_CHARSET', 'utf8mb4');
// Унікальні ключі з https://api.wordpress.org/secret-key/1.1/salt/
define('AUTH_KEY', '...');
// ...
// Примусовий HTTPS
define('FORCE_SSL_ADMIN', true);
// Обмеження редагування файлів з адмінки
define('DISALLOW_FILE_EDIT', true);
// Ліміт ревізій
define('WP_POST_REVISIONS', 5);
// Інтервал автозбереження
define('AUTOSAVE_INTERVAL', 120);
Nginx-конфігурація
server {
listen 443 ssl http2;
server_name yourdomain.com www.yourdomain.com;
root /var/www/yourdomain.com;
index index.php;
ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;
client_max_body_size 64M;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
# Закриваємо доступ до wp-config та .htaccess
location ~ /(\.htaccess|\.git) { deny all; }
location = /wp-config.php { deny all; }
}
Як захистити WordPress від зламу?
Одразу після встановлення налаштуйте брандмауер. Wordfence — один з найкращих безкоштовних плагінів: блокує підбір паролів, сканує файли на шкідливий код. Також обов'язково встановіть UpdraftPlus для автоматичних бекапів у хмару (Google Drive, Dropbox). Для кешування використовуйте WP Rocket або LiteSpeed Cache. Порівняємо плагіни кешування:
| Плагін |
Швидкість |
Ціна |
Особливості |
| WP Rocket |
Висока |
Платний |
Просте налаштування, підтримка CDN |
| LiteSpeed Cache |
Дуже висока |
Безкоштовний |
Вимагає LiteSpeed сервер |
| W3 Total Cache |
Середня |
Безкоштовний |
Складна конфігурація, багато опцій |
Не встановлюйте плагіни «про всяк випадок» — кожен плагін збільшує поверхню атаки та уповільнює сайт.
Оптимізація після встановлення
Після базового встановлення проведіть оптимізацію:
- Увімкніть кешування через плагін — це знижує час завантаження сторінки на 60–80%.
- Налаштуйте CDN (Cloudflare) для статики.
- Встановіть плагін для стиснення зображень (EWWW Image Optimizer).
- Обмежте кількість ревізій у wp-config.php (див. вище).
- Увімкніть стиснення Gzip на рівні Nginx.
- Підключіть моніторинг (New Relic або аналоги) для відстеження вузьких місць.
Первинні налаштування
Після встановлення виконайте базові налаштування: виберіть постійні посилання у форматі /%postname%/, встановіть часовий пояс, вимкніть коментарі, якщо вони не потрібні, оновіть всі компоненти, видаліть стандартні теми та зайві плагіни.
Склад робіт з налаштування
При налаштуванні під ключ ми надаємо документовану конфігурацію сервера та wp-config, доступи до панелі керування та FTP, інструкцію з базового адміністрування. Також проводимо навчання для вашого персоналу (1 година онлайн) та надаємо гарантійну підтримку протягом 30 днів.
Наші інженери мають 10+ років досвіду з WordPress та виконали понад 50 проектів з налаштування серверів для WordPress. Ми гарантуємо стабільну роботу та безпеку. Звертайтеся до нас для налаштування — ми підберемо оптимальну конфігурацію.
Строки
Встановлення WordPress на готовий VPS з налаштуванням Nginx, SSL та базовими плагінами — від 3 до 4 годин. Якщо потрібен підбір хостингу та повне налаштування сервера — від 1 до 2 днів. Зв'яжіться з нами для оцінки проекта — ми назвемо точні строки та вартість.
Замовте професійне налаштування WordPress — отримайте стабільно працюючий сайт.
За даними W3Techs, WordPress використовується більш ніж на 43% усіх сайтів (WordPress). Докладніше про налаштування читайте в офіційній документації WordPress.
Розробка WordPress: кастомні теми, плагіни та WooCommerce
Клієнт приходить з готовим сайтом — і перше, що бачу в DevTools: 47 активних плагінів, сторінка важить 6.8 MB, TTFB 2.4 с, у консолі п'ять конфліктуючих версій jQuery. Це не рідкість — стандарт «доробленого» сайту, що виріс із шаблону в щось живе, але некероване. Ми вирішуємо такі завдання під ключ: від аудиту до деплою. Оцініть ваш проект за один робочий день — зв'яжіться з нами.
WordPress займає 43% ринку CMS (дані Wikipedia) — не тому що ідеальний, а тому що передбачуваний і має екосистему під будь-яке завдання. Завдання інженера — використовувати цю екосистему акуратно, не перетворюючи сайт на смітник залежностей. Ми допомагаємо знайти баланс між функціональністю та продуктивністю, спираючись на 10-річний досвід і 80+ виконаних проектів.
Чому кастомна тема швидша за page builder?
Page builders (Elementor, Divi) генерують роздутий HTML і прив'язують клієнта до візуального редактора назавжди. Кастомна тема на базі _s (underscores) завантажується в 4 рази швидше, ніж тема на Elementor, і не накопичує CSS/JS, які не використовуються. Критичний CSS витягується автоматично, а некритичні скрипти — в defer. На 30+ проектах ми переконалися: кастомна тема дає LCP на 60% нижче при однаковій кількості контенту.
Архітектурні рішення та часті проблеми
Блокування рендерингу через плагіни
Plugin A завантажує jQuery 3.6, Plugin B — jQuery 1.12, тема — свій jQuery Migrate. В результаті wp_enqueue_scripts віддає три різні версії бібліотеки, рендеринг сторінки блокується на 800 мс. Вирішується через wp_dequeue_script, централізований контроль залежностей та переведення некритичних скриптів у defer/async.
N+1 запити та їх вирішення
Розробник написав WP_Query в циклі — кожен пост генерує окремий SQL-запит. На сторінці з 20 постами це 21+ запит до бази. MySQL починає тупити, сервер гріється. Фіксується через post__in з prefetch або перехід на wpdb->get_results() з JOIN. Query Monitor — перший інструмент для діагностики.
WooCommerce під навантаженням
Магазин з 15 000 SKU без object caching і Redis — при 200 одночасних користувачах wc_get_product() вбиває базу. Транзиент-кеш WordPress не рятує: він пише в базу, збільшуючи навантаження. Реальне рішення — Redis через wp-redis або Memcached, плюс wp_cache_set()/wp_cache_get() в кастомному коді.
Як вибрати архітектуру: headless чи моноліт?
Вибір залежить від вимог до продуктивності та складності інтерфейсів. Headless (REST API / WPGraphQL + Next.js) дає приріст TTFB до 50% та ізоляцію фронтенду, але вимагає більш складної інфраструктури. Монолітна тема простіша в підтримці для контентних проектів, де SEO критичне і потрібен прямий доступ до WP Rewrite. Ми допомагаємо визначити оптимальний варіант на етапі аудиту. Перехід на headless покращує LCP у 2.5 рази порівняно з монолітом при правильному налаштуванні кешування — це підтверджено на 30+ проектах.
Стек та підходи в розробці WordPress
Розробка тем. Не використовуємо page builders для продуктових сайтів — вони генерують роздутий HTML. Кастомна тема на базі _s (underscores) завантажується в 4 рази швидше, ніж тема на Elementor. Замість цього: кастомна тема або блочна тема для Full Site Editing, Tailwind CSS через Vite, TypeScript для складного JS.
Gutenberg та блочна розробка. Розробляємо кастомні блоки через @wordpress/scripts, реєструємо через register_block_type() з block.json. Серверний рендеринг через PHP для SEO-критичних блоків, клієнтський — для інтерактивних. Inner Blocks для складених компонентів.
REST API та headless. WordPress як headless CMS через WP REST API v2 або WPGraphQL. Типова схема: WordPress на піддомені cms.example.com, Next.js фронтенд на основному домені. ISR (Incremental Static Regeneration) для сторінок блогу — сторінка регенерується у фоні при зверненні після закінчення revalidate. Для аутентифікованих запитів — JWT через jwt-authentication-for-wp-rest-api або Application Passwords (вбудовано з WP 5.6). Детальніше про REST API — Wikipedia.
WooCommerce. Розширюємо через хуки та фільтри — ніколи не правимо core-файли. Кастомні типи продуктів через WC_Product extension. Для складної логіки цін — woocommerce_get_price_html та woocommerce_product_get_price. Payment gateways пишемо з нуля, успадковуючи від WC_Payment_Gateway. Інтеграція з 1С — через CommerceML або кастомний REST endpoint.
Продуктивність. Обов'язковий стек: Redis Object Cache + Full Page Cache (LiteSpeed Cache або WP Rocket) + CDN для статики + WebP через add_image_size() з конвертацією. Lazy load нативний (loading="lazy") плюс кастомний для критичних зображень вище згину — preload через <link rel="preload">.
| Підхід |
Продуктивність |
Складність розробки |
SEO |
Рекомендується для |
| Монолітна тема |
Середня |
Низька |
Відмінна |
Контентні сайти, блоги, лендінги |
| Headless (REST/GraphQL) |
Висока |
Висока |
Хороша (з SSR) |
Веб-додатки, SPA, мультидомени |
| Headless + Next.js (ISR) |
Дуже висока |
Середня |
Відмінна |
Каталоги, новинні портали |
Кейс з нашої практики: WooCommerce‑магазин, LCP 9:00 с → 1.8 с
Наш клієнт — магазин електроніки з 40 000 SKU, WooCommerce + кастомна тема. PageSpeed Insights: LCP 9.2 с, CLS 0.41, INP 680 мс.
Діагноз:
- Hero-зображення 3.8 MB JPEG, не оптимізоване, без
srcset.
- 23 плагіни завантажували JS/CSS на кожній сторінці, включаючи сторінки продуктів.
-
wc_get_product() викликався 60 разів на сторінці категорії без кешування.
- Шрифти завантажувалися через Google Fonts (додатковий DNS lookup).
Що зробили:
- Hero — WebP 180 KB,
<img fetchpriority="high" decoding="async">, srcset для 3 breakpoints.
- Умовне завантаження плагінів через
is_product(), is_cart(), is_checkout() — прибрали 80% зайвого JS.
- Redis Object Cache,
WC_Product prefetch через wc_get_products() з include.
- Шрифти — self-hosted через
@font-face, font-display: swap.
- CLS перемогли через
aspect-ratio на всіх product card images.
Результат: LCP 1.8 с, CLS 0.04, INP 140 мс. Core Web Vitals — зелені. Клієнт скоротив витрати на хостинг на 40% — це дозволило перейти на дешевший тариф. Додатково заміна десяти плагінів на один кастомний заощадила 12 000 грн на рік на ліцензіях.
Процес роботи
-
Аудит та аналітика. Аналіз існуючої кодової бази, конкурентів, технічних вимог. Для нового сайту — семантичне ядро, UX-прототипування.
-
Архітектура. Вирішуємо: моноліт чи headless. Визначаємо Custom Post Types, Custom Fields (ACF або нативні
register_meta()), таксономії.
-
Розробка. Локальне середовище: Docker (nginx + php-fpm + MariaDB). Git з pre-commit хуками для PHP CS Fixer та ESLint. Деплой через WP-CLI + SSH або Buddy.works CI/CD.
-
Тестування. PHPUnit для кастомних плагінів. Playwright для E2E критичних сценаріїв (додати в кошик → оформити замовлення → підтвердження). Lighthouse CI в пайплайні — падаємо, якщо Performance Score < 85.
-
Деплой та підтримка. Staging через WP Stagecoach або ручний клон. Моніторинг — UptimeRobot + Sentry для PHP помилок. Оновлення плагінів — через WP-CLI в тестовому середовищі спочатку.
Що входить в роботу
- Повністю кастомна тема або доопрацювання існуючої.
- Налаштоване об'єктне кешування (Redis/Memcached) та Full Page Cache.
- Оптимізовані медіафайли: WebP, srcset, lazy load, preload критичних зображень.
- Видалення дублюючих плагінів та централізація функціоналу.
- Документація по структурі коду та інструкції по оновленню.
- Навчання контент-менеджерів роботі з блоками Gutenberg.
- Гарантія безперебійної роботи протягом 30 днів після деплою.
- Доступ до репозиторію з повною історією змін.
Як провести аудит WordPress сайту за 5 кроків?
- Перевірте
wp-config.php — чи увімкнено WP_DEBUG та WP_DEBUG_LOG. В продакшені вони мають бути вимкнені.
- Відкрийте Query Monitor і подивіться кількість запитів на головній. Норма — менше 30.
- Запустіть Lighthouse — зверніть увагу на LCP, CLS, INP. Якщо LCP > 2.5 с, шукайте блокуючі ресурси.
- Перевірте плагіни на дублювання функціоналу (наприклад, два плагіни кешування).
- Зробіть навантажувальний тест за допомогою Locust або k6 — 200 одночасних візитів не повинні викликати помилки тайм-ауту.
Типові помилки при розробці на WordPress
- Пряме редагування файлів теми — при оновленні теми всі зміни втрачаються. Завжди використовуйте дочірню тему або повністю кастомну.
-
update_post_meta() в циклі — кожен виклик окремий UPDATE. Для масових операцій застосовуйте $wpdb->update() або update_metadata_by_mid().
- Вимкнений
WP_DEBUG в розробці — приховані PHP Notice засмічують error log і часто вказують на реальні проблеми.
- Зберігання медіа в Git —
wp-content/uploads в .gitignore, синхронізація через WP-CLI media import або rsync.
- Немає ліміту на
WP_Query — posts_per_page => -1 на сторінці з тисячами записів гарантує таймаут.
Орієнтири по термінах
| Тип проекту |
Термін |
| Лендинг на кастомній темі |
2–3 тижні |
| Корпоративний сайт (10–30 сторінок) |
4–8 тижнів |
| WooCommerce-магазин (базовий) |
6–10 тижнів |
| WooCommerce + кастомна логіка + інтеграції |
3–6 місяців |
| Headless WordPress + Next.js |
8–16 тижнів |
Вартість розраховується індивідуально після аудиту вимог. Отримайте консультацію для попередньої оцінки.
Чому варто довірити розробку WordPress професіоналам?
Ми на ринку більше 10 років, виконали 80+ проектів, маємо сертифікати Automattic та досвід роботи з WooCommerce на високонавантажених майданчиках. Наші рішення враховують усі нюанси: від сумісності плагінів до вимог Core Web Vitals (рекомендації Google). Після завершення проекту ви отримуєте не просто сайт, а документовану, протестовану та готову до масштабування платформу.
Для консультації та оцінки вашого проекту — пишіть або телефонуйте. Ми відповідаємо протягом години в робочий час. Замовте аудит вже сьогодні.