This is the abridged developer documentation for База знаний WPC
----------
# LLMs.txt для AI-агентов
> Что такое llms.txt, зачем он нужен AI-агентам и как подключать базу знаний или документацию к ChatGPT, Claude, Copilot и другим LLM-инструментам.
## Что такое llms.txt
`llms.txt` — это специальный markdown-файл в корне сайта или раздела, который даёт AI-агентам короткое и структурированное описание проекта, а также ссылки на основные материалы в LLM-friendly формате.
Для базы знаний он выполняет ту же роль, что `robots.txt` для краулеров и `sitemap.xml` для поисковиков, но ориентирован именно на inference-сценарии: когда агенту нужно быстро понять структуру сайта и подтянуть релевантный контекст в промпт или RAG-пайплайн.
## Зачем это AI-агентам
Обычная HTML-страница неудобна для агента:
* в ней есть навигация, боковые панели, служебные блоки и лишний шум
* контент разбит на десятки URL
* агенту трудно понять, какие страницы главные, а какие второстепенные
`llms.txt` решает эту задачу так:
* даёт краткое описание проекта в одном месте
* показывает канонические ссылки на ключевые материалы
* помогает начать с сокращённого контекста и только потом расширяться
* упрощает подключение документации к IDE-агентам, чат-ботам и RAG-ассистентам
## Какие файлы обычно используются
В типовой схеме встречаются три уровня контекста:
* `llms.txt` — обзорный индекс: что это за проект и какие материалы читать дальше
* `llms-small.txt` — короткий контекст для быстрого ответа или первичной маршрутизации
* `llms-full.txt` — полный контекст, когда агенту нужен максимум деталей
Для этой базы знаний доступны:
* [llms.txt](https://wpcraft.ru/kb/llms.txt) — обзор и основные наборы документации
* [llms-small.txt](https://wpcraft.ru/kb/llms-small.txt) — сокращённая версия для быстрых сценариев
* [llms-full.txt](https://wpcraft.ru/kb/llms-full.txt) — полный контекст по базе знаний
## Как подключать к AI-агентам
### Вариант 1. Подключать URL как внешний источник контекста
Подходит для агентов и чатов, которые умеют читать URL напрямую.
Практика:
* сначала передавайте агенту `https://wpcraft.ru/kb/llms.txt`
* если ответа недостаточно, переключайте его на `llms-small.txt`
* для глубоких технических вопросов передавайте `llms-full.txt`
Это даёт контролируемую эскалацию контекста: от дешёвого и короткого к полному и дорогому.
### Вариант 2. Использовать в RAG или knowledge ingestion
Подходит для внутренних AI-ассистентов, support-ботов и агентов в IDE.
Рекомендуемый поток:
1. Забрать `llms.txt` как entrypoint.
2. Извлечь из него ключевые ссылки на нужные разделы.
3. При необходимости догружать `llms-small.txt` или `llms-full.txt`.
4. Индексировать полученный контекст в локальное хранилище, vector store или knowledge cache.
Такой подход лучше, чем слепо индексировать весь сайт, потому что `llms.txt` уже задаёт curated-структуру материалов.
### Вариант 3. Использовать в system prompt или инструкциях агента
Если агент работает по инструкции, можно явно прописать источник:
```text
Если вопрос касается базы знаний WPC, сначала прочитай https://wpcraft.ru/kb/llms.txt.
Если нужны детали по конкретной теме, используй llms-small.txt или llms-full.txt.
Отдавай приоритет этим файлам перед случайным HTML-скрапингом сайта.
```
Это особенно полезно для:
* кастомных GPT/assistants
* Claude Projects
* Copilot/Cursor workflows
* агентных пайплайнов с retrieval step
## Как подключить llms.txt в Starlight
Для сайтов на Astro Starlight удобнее всего генерировать эти файлы автоматически через плагин `starlight-llms-txt`.
Базовая схема:
```js
import { defineConfig } from "astro/config";
import starlight from "@astrojs/starlight";
import starlightLlmsTxt from "starlight-llms-txt";
export default defineConfig({
site: "https://example.com/",
integrations: [
starlight({
title: "My Docs",
plugins: [starlightLlmsTxt()],
}),
],
});
```
После сборки сайт получает маршруты `llms.txt`, `llms-small.txt` и `llms-full.txt` автоматически.
## Практические рекомендации
* Используйте `llms.txt` как точку входа, а не как замену всей документации.
* Давайте агенту короткий контекст первым, полный — только по необходимости.
* Держите названия разделов и описания страниц ясными: это напрямую влияет на качество навигации агента.
* Если сайт русскоязычный, проверьте корректную UTF-8-выдачу для `.txt` файлов на проде.
* Не путайте `llms.txt` с `robots.txt`: первый помогает понять контент, второй регулирует поведение ботов.
## Когда llms.txt особенно полезен
* документация продукта
* база знаний
* developer portal
* support center
* сайт со сложной архитектурой разделов
* контентный проект, где агенту нужно быстро находить authoritative pages
## Управление llms.txt на WordPress
На self-hosted WordPress файл можно вести через AI-агента: плагин [Enable Abilities for MCP](../../wordpress/ai/enable-abilities-for-mcp) даёт две abilities — `ewpa/get-llms-txt` (чтение, определение источника файла и валидация по спецификации llmstxt.org) и `ewpa/update-llms-txt` (запись с авто-маршрутизацией через SEOPress Pro или виртуальный `/llms.txt`). Это позволяет агенту проверять и обновлять файл без доступа к файловой системе.
## Материалы и источники
* [The /llms.txt file — llmstxt.org](https://llmstxt.org/)
* [starlight-llms-txt: Getting Started](https://delucis.github.io/starlight-llms-txt/getting-started/)
* [LLMs.txt базы знаний WPC](https://wpcraft.ru/kb/llms.txt)
----------
# AI в веб-продакшене и WordPress
> Обзор AI-подходов в веб-продакшене: архитектура, процессы и инструменты, где WordPress — одно из ключевых направлений.
## Что происходит с AI в веб-продакшене
К 2026 году искусственный интеллект перестал быть хайпом и стал фундаментальной частью веб-продакшена: от исследований и контента до инженерии, QA и эксплуатации. В этом разделе основной фокус на WordPress-направлении как на одном из самых востребованных стеков внедрения AI в production-проекты.
Вот ключевые направления:
* [**LLMs.txt для AI-агентов**](./llms-txt-for-ai-agents) — Что это за файл, как его публиковать и как подключать документацию к AI-агентам
* [**AI-архитектура WordPress**](./wp-ai-architecture) — Abilities API, MCP Adapter, WP AI Client, Agent Skills
* [**WordPress MCP Adapter: практический запуск**](./wordpress-mcp-adapter) — Установка, публикация Abilities, конфиги MCP-клиентов и безопасность
* [**AI-инструменты для создания сайтов**](./ai-tools-wordpress) — От WordPress.com AI Builder до opensource-альтернатив
* [**ИИ-инструменты для веб-разработки**](./ai-dev-tools) — Cursor, Copilot, v0, Claude Code и другие
* [**ИИ-команда агентов**](./ai-agent-team) — Многоагентные системы для автоматизации контент-маркетинга
* [**Тренды AI в WordPress**](./ai-trends) — 7 ключевых трендов и прогнозы на будущее
* [**Интеграция AI в WordPress**](./ai-integration) — Практическое руководство: с чего начать, плагины, риски
* [**Каталог AI-плагинов и инструментов**](./ai-plugins-and-tools) — Полный обзор по категориям
* [**Реальные примеры AI на WordPress**](./ai-real-world) — 20 сайтов, использующих AI в production
## Ключевой принцип
WordPress не делает ставку на «своего» агента. Платформа создаёт **инфраструктуру** — единые протоколы и API, через которые любые AI-системы могут работать с WordPress. Это как с базами данных: никто не проверяет «а есть ли MySQL», прежде чем использовать `get_post_meta()`. AI должен стать таким же фундаментальным слоем.
## Связанные разделы
* [MARKETING.md: протокол AI-маркетинга](../marketing/marketing-md) — AI-агенты в маркетинге: контракт, автономные циклы и правила исполнения
* [Claude Code и AI-инструменты для маркетологов](../marketing/claude-code-for-marketers) — Практические кейсы использования Claude Code в маркетинге
* [Автоматизация маркетинга в WordPress](../marketing/wordpress-marketing-automation) — Uncanny Automator, FluentCRM, WooCommerce-автоматизация
## Материалы и источники
* [wpcraft.ru/ai — обзорная страница](https://wpcraft.ru/ai)
----------
# Инфраструктура
> Домен, хостинг, CDN, S3 и окружения разработки для стабильной и масштабируемой работы вебсайта.
## Что входит в инфраструктуру
* Домен и DNS.
* Хостинг и серверная конфигурация.
* CDN для ускорения и разгрузки origin.
* Объектное хранилище для медиа и бэкапов.
* Staging и процессы деплоя.
## Логика выбора
1. Отталкивайтесь от типа проекта и нагрузки.
2. Проверяйте ограничения по безопасности и хранению данных.
3. Планируйте масштабирование до запуска, а не после инцидентов.
## Минимальный набор для запуска
1. Домен с корректной DNS-конфигурацией.
2. Хостинг с резервным копированием и мониторингом.
3. CDN с правилами кэширования.
4. План релиза через staging-окружение.
## Связанные материалы
* [Оптимизация WordPress](../websites/performance/optimization)
* [Базовая безопасность WordPress](../websites/security/wordpress-security-basics)
* [Типы проектов](../websites/project-types/)
* [Сервисы](../services/)
## Материалы и источники
* [Домен и DNS](./domain/)
* [Хостинг](./hosting/)
* [Типы хостинга](./hosting/hosting-types)
* [CDN](./cdn/)
* [Сплит трафика РФ / мир через GeoDNS и CDN](./cdn/geodns-split-ru-world)
* [S3-провайдеры для WordPress](../services/saas/s3-providers)
----------
# CDN
> CDN в инфраструктуре сайта: зачем нужен, как раздаёт статику и HTML, как разделить трафик между регионами.
## Что делает CDN в инфраструктуре
CDN принимает запрос посетителя на ближайшем к нему узле (PoP), отдаёт из кэша то, что уже там лежит, и ходит на origin-сервер только при промахе. Два эффекта:
* **скорость** — RTT до PoP в разы меньше, чем до одного сервера на другом континенте;
* **разгрузка origin** — закэшированный трафик до PHP и базы не доходит вообще.
Для сайта с аудиторией в одной стране выигрыш умеренный. Он становится критичным, когда часть аудитории (или зарубежные сервисы вроде ботов превью ссылок) находится далеко от origin.
## Страницы раздела
* [Сплит трафика РФ / мир через GeoDNS и CDN](./geodns-split-ru-world) — почему Telegram не показывает превью ссылки на сайт в РФ и как это чинится географическим разделением DNS.
## Связанные материалы
* [CDN и производительность — сервисы](../../services/saas/cdn-performance) — сравнение провайдеров: Cloudflare, Bunny.net, Yandex Cloud CDN, Selectel, VK Cloud.
* [Сервисы веб-защиты](../../websites/security/web-protection-services) — CDN как слой защиты и ограничения зарубежных сетей в РФ.
* [Кэширование WordPress](../../wordpress/cache/) — уровни кэша на стороне сайта.
* [Инфраструктурный уровень кэша](../../wordpress/cache/server-level-cache).
## Материалы и источники
* [Bunny.net](https://bunny.net)
* [Cloudflare](https://cloudflare.com)
----------
# Сплит трафика РФ / мир через GeoDNS и CDN
> Telegram не показывает превью ссылки, зарубежные посетители ждут ответа секунду — потому что сайт живёт на одном сервере в РФ. Разбор решения через географическое разделение DNS и edge-кэш Bunny.
## Симптомы
Сайт работает. Из России открывается быстро. Но:
* **Telegram не показывает превью ссылки.** Кидаете ссылку в чат — вместо карточки с заголовком и картинкой просто синий текст. Иногда превью появляется через раз или только со второй попытки.
* **То же самое в других мессенджерах.** WhatsApp, Slack, Discord, LinkedIn — карточка либо пустая, либо без картинки.
* **Видео и тяжёлые медиа не проигрываются** у зарубежных зрителей или стартуют с задержкой в несколько секунд.
* **Зарубежные посетители жалуются на «тормозит»**, хотя в РФ метрики зелёные.
* **Google Search Console показывает высокое время ответа** при обходе, хотя сервер не нагружен.
Общий признак: всё, что приходит **из-за пределов РФ**, работает хуже, чем то, что приходит изнутри.
## Причина
Сайт лежит на одном сервере в России. Это нормально для аудитории в РФ и обязательно, если вы работаете с персональными данными по 152-ФЗ. Но каждый зарубежный запрос — это трансатлантический round-trip до Москвы и обратно.
Для человека это «медленно». Для бота — это **отказ**.
Боты превью ссылок не ждут долго. У краулера Telegram, Slack, Discord жёсткий таймаут на получение HTML: не уложились — карточка не строится, и повторной попытки чаще всего не будет. Складываются три задержки:
1. TCP + TLS handshake через полмира — это уже 2–3 RTT до первого байта запроса;
2. генерация страницы на origin, если она не в кэше;
3. деградация транзита — зарубежные маршруты в РФ нестабильны, потери и всплески latency обычное дело.
При RTT 250–350 мс и холодном кэше вы легко упираетесь в секунду-полторы до первого байта. Бот отваливается. Пользователь видит голую ссылку.
Вторая часть проблемы — медиа. Картинка для og-превью и видео качаются с того же origin. Даже если HTML успел отдаться, картинка может не успеть.
## Почему «просто поставить CDN на весь сайт» — плохое решение
Очевидный ход: завернуть весь домен в зарубежный CDN. Это чинит зарубежных посетителей и ломает основную аудиторию.
Диапазоны зарубежных CDN у российских операторов периодически деградируют или попадают под фильтрацию. Показательный пример — [проблемы Cloudflare в РФ с июня 2025 года](../../../websites/security/web-protection-services): соединения обрываются после первых 16 КБ ответа, то есть сайт «открывается наполовину».
Поставив весь трафик за зарубежный CDN, вы меняете понятную проблему (медленно для 5% аудитории) на непредсказуемую (сайт может лечь для 95%).
## Решение: разделить трафик на уровне DNS
Идея простая: пусть **DNS отвечает разными адресами в зависимости от того, откуда пришёл запрос**.
```plaintext
запрос wpcraft.ru
│
┌────────┴────────┐
│ GeoDNS-зона │
└────────┬────────┘
│
┌──────────────────┴──────────────────┐
│ │
резолвер в РФ резолвер вне РФ
│ │
▼ ▼
A → origin в РФ Pull Zone → ближайший PoP CDN
(прямое соединение, (edge-кэш HTML и статики)
CDN в пути нет) │
│ │ промах кэша
▼ ▼
┌───────────────────────────────────────────────────┐
│ origin.example.ru → тот же сервер │
└───────────────────────────────────────────────────┘
```
Что получаем:
| Кто | Маршрут | Эффект |
| ------------------------- | ----------------------------- | ----------------------------------------------- |
| Посетитель из РФ | прямое соединение с origin | ничего не изменилось, CDN не в критическом пути |
| Посетитель из-за рубежа | ближайший PoP, отдача из кэша | TTFB падает с \~1 с до десятков мс |
| Бот превью Telegram/Slack | ближайший PoP | укладывается в таймаут, превью строится |
| Поисковый краулер | ближайший PoP | быстрый обход, меньше нагрузка на origin |
Второй origin не нужен, данные никуда не переезжают, 152-ФЗ не затрагивается: сервер один и он в РФ, а edge кэширует только анонимные GET-ответы.
Мы используем для этого **Bunny.net** — у него есть и DNS с географическими record set, и CDN, и pay-as-you-go тариф без абонентки. Схема не привязана к вендору: любой GeoDNS + pull-CDN подойдёт.
## Как это настраивается
### 1. Отдельный хостнейм для origin
Это первое, что нужно сделать, и самая частая ошибка, если этого не сделать.
Нельзя указывать pull zone на `example.ru`. Edge-нода при промахе кэша резолвит этот домен через публичный DNS — и, находясь за рубежом, получает «мировую» ветку, то есть саму себя. Петля. Сайт за границей ложится ровно в момент включения гео-сплита.
Решение — отдельная A-запись, которая **не участвует в гео-сплите** и всегда указывает на реальный сервер:
```plaintext
origin.example.ru. 300 IN A
```
Pull zone смотрит на `https://origin.example.ru`, а заголовок Host подменяет на канонический `example.ru`, чтобы WordPress не начал генерировать ссылки на origin-хостнейм.
На этот хостнейм нужен валидный TLS-сертификат на стороне хостинга — иначе origin придётся опрашивать по HTTP, что для сайта с авторизацией недопустимо.
### 2. Настройки pull zone, которые ломают WordPress по умолчанию
Bunny (и не он один) даёт дефолты, рассчитанные на раздачу статики. На динамическом WordPress каждый из них по отдельности достаточен, чтобы уронить сайт.
| Параметр | Дефолт | Нужно | Что ломается на дефолте |
| ------------------------ | ----------- | --------------------------- | ------------------------------------------------------------------------------------------- |
| `Origin URL` | домен сайта | `https://origin.example.ru` | петля `CDN-Loop` |
| `Origin Host Header` | пусто | `example.ru` | WordPress видит не тот домен, ломаются редиректы и канонические ссылки |
| `Disable cookies` | включено | **выключить** | режет `Set-Cookie` от origin — не работает вход и гостевая корзина |
| `Ignore query strings` | включено | **выключить** | `?page=2`, UTM и фильтры схлопываются в один ключ кэша — посетитель получает чужую страницу |
| `Cache-Control override` | — | не задавать | заголовки origin должны остаться единственным источником правды |
| TLS 1.0 / 1.1 | включено | выключить | легаси-протоколы |
Отдельно проверьте `Verify origin SSL` — его стоит включить после того, как на origin-хостнейме появится валидный сертификат.
### 3. Что не кэшировать
Решение о кэшируемости принимаем по **методу и пути**, а не по кукам:
* метод не `GET`/`HEAD` → не кэшируем;
* путь начинается с `/wp-admin`, `/wp-login.php`, `/wp-cron.php`, `/wp-json`, `/cart`, `/checkout`, личный кабинет → не кэшируем;
* всё остальное — по заголовкам origin.
Почему не по кукам: если сайт уже отдаёт залогиненным пользователям тот же публичный HTML, что и гостям (обычная практика для контентных сайтов с page cache), то bypass по `wordpress_logged_in_*` отправит каждого авторизованного на PHP и обнулит смысл кэша. Персональные страницы отделяются путём, а не кукой.
Важно: этот список путей обычно дублирует правила кэш-плагина на origin. Это единственная точка рассинхрона в схеме — **меняете список на сервере, меняйте и на edge**.
### 4. Заголовки как источник правды
Edge должен слушать `Cache-Control` от origin, а не иметь собственный TTL. Тогда время жизни кэша задаётся в одном месте — в коде сайта.
Здесь ждёт неочевидная ловушка. Если на origin стоит кэш-плагин в режиме статических файлов (WP Super Cache в expert-режиме, LiteSpeed, любой вариант с отдачей `.html` через rewrite), то при попадании в кэш **PHP не стартует**, файл отдаёт веб-сервер напрямую — и заголовка `Cache-Control` в ответе нет, только `ETag` и `Last-Modified`.
То есть на большинстве ответов edge не получит никакой инструкции. Проверяется в одну команду:
```sh
curl -I https://example.ru/ # попадание в статический кэш
curl -I 'https://example.ru/?nocache=1' # промах, отвечает PHP
```
Если в первом случае `Cache-Control` нет, а во втором есть — вы поймали именно это. Чинится на origin: добавить заголовок для отдачи из каталога статического кэша, вне маркеров, которые перезаписывает плагин.
```apache
Header always set Cache-Control "public, max-age=604800" "expr=%{REQUEST_FILENAME} =~ m#/wp-content/cache/supercache/#"
```
Запасной вариант — задать TTL прямо на pull zone. Проще, но переопределяет заголовки глобально: страницы, которые кэшировать нельзя, тоже попадут под общее правило.
### 5. Сброс кэша при публикации
Edge будет держать страницу столько, сколько сказано в `Cache-Control`. Без принудительного сброса правка текста доедет до зарубежной аудитории через недели.
Минимальный mu-plugin на `save_post`, `edited_term` и обновление меню, дёргающий Purge API провайдера, закрывает вопрос. Разумный ориентир — обновление видно за границей в пределах минуты.
### 6. Реальный IP посетителя
С мировой ветки origin увидит IP edge-ноды, а не посетителя. Клиентский адрес приезжает в `X-Forwarded-For`.
Доверять этому заголовку можно **только для запросов из диапазонов вашего CDN**. Иначе любой желающий подставит произвольный IP в комментарии, логи и антиспам.
### 7. Геопривязка записей
Географические DNS-записи работают по принципу «ближайшая точка», а не по правилу «страна == RU». Поэтому мало завести две ветки — нужны геоякоря:
* ветка РФ — якорь в Москве;
* ветка мира — несколько якорей: Франкфурт, Нью-Йорк, Сингапур, Сан-Паулу.
Без мировых якорей посетители из Финляндии, Польши, Турции окажутся географически «ближе» к Москве и уйдут на origin в обход CDN. Абсолютной точности здесь не будет — это принципиальное ограничение GeoDNS, и его надо принять заранее.
### 8. Переезд зоны
Порядок, который экономит нервы:
1. Создать зону у нового DNS-провайдера как **точную копию** текущей — гео-сплит выключен, все ветки отдают origin.
2. Сверить записи один в один, запрашивая напрямую у новых NS.
3. Сменить NS у регистратора.
4. Дождаться распространения.
5. И только потом включать гео-сплит.
Два момента, о которых узнают поздно:
**TTL делегирования в зоне `.RU` — 345 600 секунд (4 суток)**, он задан реестром и не понижается:
```sh
dig NS example.ru @a.dns.ripn.net
```
Значит после смены NS резолверы до четырёх суток продолжат ходить на старого провайдера. Столько же займёт и откат. Старую зону всё это время держим живой и неизменной — это и есть кнопка отката.
**CAA-записи могут не переехать.** Cloudflare, например, синтезирует их на лету и не хранит в зоне: в экспорте их нет, а после переезда они просто исчезнут. Как минимум нужно завести:
```plaintext
example.ru. 300 IN CAA 0 issue "letsencrypt.org"
```
Без этого CDN не выпустит сертификат для вашего домена, а хостинг — для origin-хостнейма.
### 9. Сертификат для домена на CDN
CDN обычно валидирует ваш домен по HTTP-01, а для этого домен уже должен указывать на pull zone. Возникает окно: NS переехали, сертификата ещё нет, а поставить домен на CDN без сертификата — TLS-ошибка у всех посетителей.
Чище выпустить сертификат заранее через DNS-01 (валидация TXT-записью, домен при этом никуда указывать не должен) и загрузить его в pull zone вручную. Окна без сертификата не возникает вовсе.
## Как проверить, что заработало
**Резолв из разных точек** — из РФ должен приходить origin, извне адреса CDN:
```sh
dig example.ru @77.88.8.8 # резолвер в РФ → IP origin
dig example.ru @8.8.8.8 # резолвер вовне → IP PoP CDN
dig origin.example.ru # везде → IP origin
```
**Кэш отрабатывает** — второе обращение из-за рубежа должно дать `HIT`:
```sh
curl -sI https://example.ru/ | grep -i 'cdn-cache\|cache-control'
```
**Исключения не кэшируются:**
```sh
for p in /cart /checkout /wp-json/wp/v2/posts /wp-login.php; do
printf '%-28s ' "$p"
curl -sI "https://example.ru$p" | grep -i 'cdn-cache' || echo 'нет заголовка'
done
```
**Превью ссылки.** Самая честная проверка исходной проблемы — кинуть ссылку в Telegram и посмотреть, собралась ли карточка. Проверять на ссылке, которую раньше не отправляли: у мессенджеров есть собственный кэш превью, и старая ссылка может отдаться из него.
**Функциональные сценарии, которые ломаются чаще всего:**
* вход в админку из-за рубежа;
* гостевая корзина переживает переход между страницами;
* пагинация и фильтры отдают разные страницы, а не одну и ту же;
* публикация записи видна за границей в пределах минуты;
* в логах origin виден реальный IP, а не адрес edge-ноды.
## Чем за это платим
Схема не бесплатная с точки зрения сложности:
* **Два слоя кэша с частично дублирующейся конфигурацией** — правила на origin и на edge надо держать синхронными вручную.
* **Гео-мисроутинг приграничных стран** — часть европейской аудитории может уходить на origin в обход CDN.
* **Откат не мгновенный** — 4 суток TTL делегирования в `.RU`.
* **Диагностика усложняется** — на вопрос «почему у клиента не открывается» теперь два разных ответа в зависимости от его геолокации.
Если зарубежная аудитория и превью ссылок для вас не критичны — не начинайте. Если критичны — это дешевле, чем второй origin за рубежом с репликацией данных.
## Связанные материалы
* [CDN в инфраструктуре](../)
* [CDN и производительность — сервисы](../../../services/saas/cdn-performance)
* [Сервисы веб-защиты](../../../websites/security/web-protection-services)
* [Кэш страниц WordPress](../../../wordpress/cache/page-cache)
* [Инфраструктурный уровень кэша](../../../wordpress/cache/server-level-cache)
* [Домен и DNS](../../domain/)
## Материалы и источники
* Практика внедрения на wpcraft.ru, 2026
* [Bunny.net](https://bunny.net)
* [Документация Bunny](https://docs.bunny.net)
----------
# Домен
> Домены для WordPress: выбор, регистрация, настройка DNS.
## Страницы раздела
* [Регистраторы доменов: сравнение](./domain-registrars) — Сравнение международных и российских регистраторов: цены, WHOIS Privacy, DNS, перенос доменов.
## Связанные материалы
* [Сплит трафика РФ / мир через GeoDNS и CDN](../cdn/geodns-split-ru-world) — географические DNS-записи, переезд зоны и TTL делегирования `.RU`.
----------
# Регистраторы доменов: сравнение
> Сравнение регистраторов доменов для WordPress: цены, WHOIS Privacy, DNS, дополнительные услуги. Международные и российские регистраторы.
## Зачем выбирать регистратора отдельно
Регистратор доменов — это ICANN-аккредитованная компания, через которую вы покупаете и продлеваете доменное имя. Многие хостинг-провайдеры также предлагают регистрацию доменов, но часто выгоднее разделять эти услуги:
* Проще перенести сайт на другой хостинг — домен остаётся у регистратора
* Прозрачнее цены на продление
* Лучше контроль над DNS и WHOIS
## Ключевые критерии выбора
### Аккредитация ICANN
Только ICANN-аккредитованные регистраторы имеют право регистрировать домены в gTLD (`.com`, `.org`, `.net`). Для национальных зон (`.ru`, `.рф`) требуется аккредитация Координационного центра.
### Цена первого года vs продление
Промо-цена первого года может быть $1-3, но renewal — $15-20. Считайте стоимость на 3-5 лет.
### WHOIS Privacy
Защита личных данных в публичной базе WHOIS. Должна быть **бесплатной** (у некоторых — отдельная плата $10/год, например GoDaddy).
### DNS-инфраструктура
* Anycast-сеть для минимальной задержки
* DNSSEC для защиты от подмены DNS
* Быстрое propagation (распространение) записей
## Сравнение регистраторов .com (2025-2026)
| Регистратор | .com 1-й год | .com Renewal | WHOIS Privacy | Бесплатная почта |
| ----------- | ------------ | ------------ | ---------------------- | ---------------- |
| Cloudflare | \~$10.44 | \~$10.44 | Бесплатно | Email routing |
| Namecheap | $6.49 | $13.98 | Бесплатно | Переадресация |
| Porkbun | $4.08 | $10.37 | Бесплатно | Нет |
| Dynadot | $7.99 | $10.99 | Бесплатно | 1 ГБ |
| IONOS | $1.00 | $15.00 | Бесплатно | 2 ГБ |
| NameSilo | $8.99 | $9.95 | Бесплатно (пожизненно) | Нет |
| GoDaddy | $11.99 | $19.99 | $9.99/год | Нет |
| Spaceship | $8.48 | \~$10 | Бесплатно | Нет |
### Cloudflare — домены по себестоимости
Продаёт домены без наценки (cost price). Не предоставляет хостинг — только DNS, CDN и защиту. Идеально, если хостинг уже есть.
### Namecheap — лучший баланс
* \~550 TLD, бесплатный WHOIS Privacy
* Бесплатный DNS, CDN, email-переадресация
* Собственный VPN от $0.99/мес
* Поддержка: тикеты и live chat 24/7
### Porkbun — для стартапов
* Низкая цена первого года ($4.08)
* Умеренный renewal ($10.37)
* Простая панель управления
* Нет бесплатной почты
### GoDaddy — крупнейший, но дорогой
* 11.53% мирового рынка
* \~550 TLD, брокер доменов, аукционы
* AI-инструмент GoDaddy Airo™
* **Минус:** WHOIS Privacy $9.99/год отдельно, renewal $19.99
## Российские регистраторы
Для зон `.ru` и `.рф` нужна аккредитация Координационного центра. Основные игроки:
* **REG.RU** — крупнейший в РФ, домены + хостинг в одном окне
* **RU-CENTER (nic.ru)** — старейший регистратор, для бизнеса
* **R01** — надёжный, минималистичный интерфейс
Цены на `.ru`: \~500-1500 ₽/год в зависимости от регистратора и акций.
## Что нужно для привязки домена к хостингу
1. **Купить домен** у регистратора
2. **Узнать NS-серверы хостинга** (обычно `ns1.hoster.ru`, `ns2.hoster.ru`)
3. **Прописать NS** в панели управления доменом у регистратора
4. **Подождать propagation** — от нескольких минут до 24 часов
5. **Добавить домен** в панели хостинга (Alias/Parked Domain)
## Перенос домена к другому регистратору
1. Убедиться, что домен не заблокирован (60 дней после регистрации)
2. Снять блокировку трансфера (unlock)
3. Получить код авторизации (auth code / EPP)
4. Понизить TTL до 300 сек за 24 часа до переноса
5. Инициировать трансфер у нового регистратора
6. Подтвердить по email
7. Процесс занимает 5-7 дней
## Рекомендации
* **РФ-аудитория:** REG.RU или RU-CENTER
* **Минимальная цена на годы:** Cloudflare (cost price)
* **Бюджет и простота:** Namecheap или Porkbun
* **Нужна бесплатная почта:** IONOS (2 ГБ) или Dynadot (1 ГБ)
* **Инвестор доменов:** Dynadot, NameSilo (инструменты для bulk-операций)
## Материалы и источники
* [10 Best Domain Registrars — Themeisle](https://themeisle.com/blog/best-domain-registrars/)
* [10 Best Domain Registrars 2026 — Weblish](https://weblish.io/blog/best-domain-registrar-ranking-2026/)
* [6 Best Domain Name Registrars — Elegant Themes](https://www.elegantthemes.com/blog/wordpress/best-domain-name-registrars)
## Связанные страницы
* [Домен и хостинг: в чём разница](../domain-vs-hosting) — базовое объяснение
* [Хостинг-провайдеры: сравнение](../../hosting/hosting-providers) — выбор хостинга под домен
----------
# Домен и хостинг: что это и зачем?
> Простое объяснение разницы между доменным именем (адресом сайта) и хостингом (местом хранения файлов). Как они работают вместе.
## Два компонента любого сайта
Для работы любого сайта нужны две вещи:
1. **Доменное имя** — адрес, по которому посетители находят ваш сайт (например, `mysite.ru`)
2. **Хостинг** — место на сервере, где хранятся файлы, изображения и контент сайта
Без домена сайт нельзя найти. Без хостинга сайту негде «жить». Это разные услуги, которые часто приобретаются у одного провайдера, но могут быть и у разных.
## Доменное имя — подробнее
Доменное имя — это то, что отображается в адресной строке браузера. Это ваш уникальный адрес в интернете.
### Бесплатный поддомен vs свой домен
* **Бесплатный поддомен** (например, `mysite.wordpress.com`) — выдаётся WordPress.com. Не подходит для бизнеса и серьёзного бренда.
* **Собственный домен** (`mysite.ru`) — регистрируется у регистратора. Обязателен для self-hosted WordPress.
### Регистрация домена
Домен регистрируется на 1 год с ежегодным продлением (\~500-1500 ₽/год в зоне .ru). Популярные регистраторы: nic.ru, reg.ru, r01.ru.
## Хостинг — подробнее
Хостинг — это аренда места на сервере. Когда посетитель вводит ваш домен в браузере, DNS направляет его на ваш хостинг-сервер, и тот отдаёт страницы сайта.
### Типы хостинга
* **Shared (виртуальный)** — дешёвый, для старта
* **VPS** — выделенные ресурсы, для растущих проектов
* **Облачный** — масштабируемый, для высоких нагрузок
* **Managed WordPress** — полностью обслуживаемый провайдером
Подробнее — в статье [Хостинг для WordPress: как выбрать](../../../wordpress/faq/how-to/wordpress-hosting).
## Как зарегистрировать домен
Домен регистрируется у ICANN-аккредитованного регистратора. Подробный обзор и сравнение регистраторов — в разделе [Регистраторы доменов: сравнение](../domain-registrars).
## Как они работают вместе
```plaintext
Пользователь → вводит mysite.ru → DNS → IP-адрес хостинга → сервер отдаёт сайт
```
1. Пользователь вводит домен в браузере
2. DNS-сервер преобразует домен в IP-адрес хостинга
3. Браузер получает страницу с сервера хостинга
## Что нужно для запуска сайта
* Домен (зарегистрировать у регистратора)
* Хостинг (выбрать тариф и оплатить)
* SSL-сертификат (обычно бесплатный Let’s Encrypt)
* Привязать домен к хостингу (указать NS-серверы в панели регистратора)
## PHP пример: определение домена текущего сайта
```php
$current_domain = wp_parse_url(home_url(), PHP_URL_HOST);
if (str_contains($current_domain, 'staging')) {
// мы на staging-окружении
error_reporting(E_ALL);
} else {
// production
error_reporting(0);
}
```
Что делает код:
* Получает текущий домен из настроек WordPress.
* Включает полный вывод ошибок только на staging-домене.
## Материалы и источники
* [Domain name vs. website hosting — оригинальная статья](https://wordpress.com/support/domain-vs-website/)
## Связанные страницы
* [Регистраторы доменов: сравнение](../domain-registrars) — международные и российские регистраторы, цены, WHOIS Privacy
* [Типы хостинга](../../hosting/hosting-types) — Shared, VPS, облачный и managed WordPress-хостинг
* [Критерии выбора хостинга](../../hosting/hosting-criteria) — метрики и чек-лист оценки
* [Хостинг-провайдеры: сравнение](../../hosting/hosting-providers) — провайдеры с ценами и тестами
----------
# Хостинг
> Хостинг для WordPress: типы, критерии выбора, настройка.
## Страницы раздела
* [Типы хостинга](./hosting-types) — Shared, VPS, облачный и managed WordPress-хостинг: сравнение, плюсы и минусы, для каких проектов.
* [Критерии выбора хостинга](./hosting-criteria) — TTFB, uptime, технологии сервера, безопасность, поддержка и прозрачность цен.
* [Хостинг-провайдеры: сравнение](./hosting-providers) — Международные и российские провайдеры: цены, скорость, аптайм, рекомендации по типам проектов.
----------
# CI/CD для WordPress с GitHub Actions
> Автоматизация тестирования и деплоя WordPress: CI/CD пайплайны через GitHub Actions, WP-CLI, матричное тестирование и деплой без FTP.
## CI/CD для WordPress
**Continuous Integration (CI):** автоматическое тестирование при каждом push — проверка кода, security, совместимость с версиями PHP/WP.
**Continuous Deployment (CD):** автоматический деплой после прохождения тестов — на staging или production.
## Структура репозитория
```plaintext
wordpress-project/
├── .github/workflows/
│ ├── ci.yml # Тестирование при PR и push
│ └── deploy.yml # Деплой на staging/production
├── wp-content/
│ ├── themes/my-theme/
│ └── plugins/my-plugin/
├── scripts/
│ ├── deploy.sh
│ ├── test.sh
│ └── migrate.sh
├── tests/
│ └── test-wordpress.php
├── composer.json
└── .env.example
```
### Что версионировать (✅) и что нет (❌)
* ✅ Кастомные темы, плагины, mu-plugins
* ✅ Конфигурационные файлы, скрипты деплоя
* ❌ Ядро WordPress (подключать через Composer)
* ❌ Сторонние плагины (управлять через Composer или отдельно)
* ❌ `wp-config.php`, `.env` (в каждом окружении свои)
* ❌ `uploads/` (медиафайлы)
## Простой деплой темы (без FTP)
Минимальный workflow: пуш в main → деплой на сервер:
.github/workflows/deploy.yml
```yaml
name: Deploy WordPress Theme
on:
push:
branches:
- main
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Build assets
run: |
npm ci
npm run build
- name: Deploy Theme to Server
uses: SamKirkland/FTP-Deploy-Action@4.3.3
with:
server: ${{ secrets.FTP_SERVER }}
username: ${{ secrets.FTP_USERNAME }}
password: ${{ secrets.FTP_PASSWORD }}
server-dir: /wp-content/themes/my-theme/
```
**GitHub Secrets** (Settings → Secrets and variables → Actions):
* `FTP_SERVER` — адрес сервера
* `FTP_USERNAME` — FTP/SFTP пользователь
* `FTP_PASSWORD` — пароль
## Полноценный CI с wp-env
.github/workflows/ci.yml
```yaml
name: CI - WordPress Tests
on:
pull_request:
push:
branches: [main, develop]
jobs:
test:
runs-on: ubuntu-latest
strategy:
matrix:
php: ['7.4', '8.0', '8.1', '8.2']
wordpress: ['6.3', '6.4', '6.5']
services:
mysql:
image: mysql:8.0
env:
MYSQL_ROOT_PASSWORD: root
MYSQL_DATABASE: wordpress_test
ports:
- 3306:3306
options: >-
--health-cmd="mysqladmin ping --silent"
--health-interval=10s
--health-timeout=5s
--health-retries=3
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Setup PHP
uses: shivammathur/setup-php@v2
with:
php-version: ${{ matrix.php }}
extensions: mysql, xml, mbstring
- name: Setup WP-CLI
run: |
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp
- name: Install WordPress
run: |
wp core download --path=/tmp/wordpress --version=${{ matrix.wordpress }}
wp config create --dbname=wordpress_test --dbuser=root --dbpass=root --dbhost=127.0.0.1 --path=/tmp/wordpress
wp core install --url=http://localhost --title=Test --admin_user=admin --admin_password=password --admin_email=test@test.com --path=/tmp/wordpress
- name: Copy & Activate Plugin
run: |
cp -r wp-content/plugins/my-plugin /tmp/wordpress/wp-content/plugins/
wp plugin activate my-plugin --path=/tmp/wordpress
- name: Run Tests
run: bash scripts/test.sh
```
### Матричное тестирование
Матрица `php × wordpress` тестирует код на 16 комбинациях (4 PHP × 4 WP) параллельно. Это находит проблемы совместимости до того, как они попадут к пользователям.
### Тесты: что проверять
scripts/test.sh
```bash
#!/bin/bash
# Sanity: WordPress установлен
wp core is-installed --path=/tmp/wordpress || exit 1
# Плагин активен
wp plugin is-active my-plugin --path=/tmp/wordpress || exit 1
# Проверка целостности ядра
wp core verify-checksums --path=/tmp/wordpress
# PHP CodeSniffer
vendor/bin/phpcs --standard=WordPress wp-content/plugins/my-plugin/
# PHPUnit (если есть)
vendor/bin/phpunit
```
## Деплой по SSH
Более безопасный, чем FTP-деплой — SSH с ключами:
.github/workflows/deploy-ssh.yml
```yaml
name: Deploy via SSH
on:
push:
branches: [production]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Deploy via rsync
uses: burnett01/rsync-deployments@6.0.0
with:
switches: -avzr --delete
path: wp-content/themes/my-theme/
remote_path: /var/www/site/wp-content/themes/my-theme/
remote_host: ${{ secrets.DEPLOY_HOST }}
remote_user: ${{ secrets.DEPLOY_USER }}
remote_key: ${{ secrets.DEPLOY_SSH_KEY }}
```
## Staging и Production окружения
```yaml
name: Deploy
on:
push:
branches:
- staging
- production
jobs:
deploy-staging:
if: github.ref == 'refs/heads/staging'
# ... deploy to staging server
deploy-production:
if: github.ref == 'refs/heads/production'
# ... manual approval, then deploy
environment: production
```
Staging деплоится автоматически, production — через environment protection rules (manual approval).
## Преимущества CI/CD перед ручным FTP
| Ручной FTP | CI/CD |
| ------------------------------------- | ----------------------------- |
| Минуты на загрузку | Секунды |
| Человеческий фактор, ошибки | Идентичный процесс каждый раз |
| «Я забыл какие файлы менял» | Вся история в Git |
| Откат = загрузка старых файлов наугад | Откат = revert commit |
| Нет тестов | Автоматическое тестирование |
## Материалы и источники
* [WP-CLI Mastery: CI/CD Pipeline with GitHub Actions](https://wpclimastery.com/blog/wordpress-ci-cd-pipeline-with-github-actions-and-wp-cli/)
* [Mark Ward Design: Stop Using FTP — WordPress CI/CD with GitHub Actions](https://markwarddesign.com/2025/08/04/stop-using-ftp-a-guide-to-wordpress-ci-cd-with-github-actions/)
* [Automattic: DevOps for WordPress](https://automattic.com/for-agencies/blog/wordpress-devops/)
----------
# cPanel и WordPress: что доступно на self-hosted
> Объяснение: на WordPress.com нет cPanel, а на self-hosted WordPress cPanel — стандартный инструмент управления хостингом.
## Что такое cPanel
cPanel — панель управления хостингом, предоставляемая большинством shared-хостингов. Через cPanel управляют:
* Файлами сайта (File Manager).
* Базами данных (MySQL Databases, phpMyAdmin).
* Доменами и поддоменами.
* Почтовыми ящиками.
* SSL-сертификатами.
* Резервными копиями.
## Есть ли cPanel на WordPress.com?
**Нет.** WordPress.com — managed-платформа, использующая собственную панель управления. Все хостинговые задачи (SSL, бэкапы, БД) выполняются автоматически или через их интерфейс.
## cPanel на self-hosted WordPress
На self-hosted WordPress cPanel — стандартный инструмент, доступный на большинстве хостингов. Типичные задачи:
### Доступ к cPanel
URL обычно: `https://ваш-домен.com/cpanel` или через портал хостинг-провайдера.
### Управление файлами
* **File Manager** — аналог графического FTP-клиента прямо в браузере.
* Загрузка/редактирование файлов тем, плагинов, `wp-config.php`.
### Базы данных
* Создание БД через **MySQL Database Wizard**.
* Управление через **phpMyAdmin** — веб-интерфейс для SQL-запросов.
* Создание пользователей БД и назначение прав.
### FTP и SFTP
cPanel предоставляет FTP-аккаунты для доступа к файлам через FTP-клиенты (FileZilla, Cyberduck).
> WordPress.com предлагает SFTP/SSH на платных тарифах. На self-hosted — доступен всегда, зависит от тарифа хостинга.
### SSH-доступ
На многих хостингах SSH включается в cPanel → **SSH Access**. Позволяет использовать WP-CLI и другие инструменты командной строки.
### SSL-сертификаты
* **Let’s Encrypt** — бесплатный SSL, часто активируется в один клик.
* Покупные сертификаты — загрузка через **SSL/TLS** раздел.
### Резервные копии
В cPanel можно создавать и скачивать полные бэкапы сайта (файлы + БД). На WordPress.com бэкапы автоматические и не требуют действий.
## Альтернативы cPanel
Не все хостинги используют cPanel. Другие панели:
| Панель | Особенности |
| ---------------------- | --------------------------------------------- |
| **Plesk** | Для Windows-хостинга, реже для Linux |
| **DirectAdmin** | Лёгкая альтернатива, дешевле в лицензировании |
| **ISPmanager** | Российская панель управления |
| **VestaCP / HestiaCP** | Бесплатные opensource-панели для VPS |
Если у вас VPS или выделенный сервер без панели — все задачи выполняются через SSH: `mysql`, `rsync`, `cron`, `certbot`.
## Связанные страницы
* [Хостинг для WordPress: как выбрать](../../../wordpress/faq/how-to/wordpress-hosting)
* [Как установить WordPress?](../../../wordpress/faq/how-to/how-to-install-wordpress)
* [WordPress.com vs WordPress.org: сравнение](../../../wordpress/faq/wordpress-com-vs-org)
## Материалы и источники
* [WordPress.com: cPanel](https://wordpress.com/support/cpanel/)
----------
# Docker для WordPress
> Локальная разработка и production-развёртывание WordPress через Docker Compose: Nginx, PHP-FPM, MySQL, Redis, HTTPS, бэкапы и best practices.
## Локальная разработка: WordPress + WooCommerce
Для разработки плагинов и тем WordPress с WooCommerce — один `docker-compose.yml`:
```yaml
services:
db:
image: mysql:8.0
volumes:
- db_data:/var/lib/mysql
restart: unless-stopped
environment:
MYSQL_ROOT_PASSWORD: somewordpress
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD: wordpress
wordpress:
depends_on:
- db
image: wordpress:latest
volumes:
- ./wp-content:/var/www/html/wp-content
ports:
- "8000:80"
restart: unless-stopped
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpress
WORDPRESS_DB_NAME: wordpress
WORDPRESS_CONFIG_EXTRA: |
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
volumes:
db_data:
```
**После старта** (`docker compose up -d`) — установить WooCommerce через Plugins → Add New → «WooCommerce», активировать тему Storefront.
## Production-архитектура
Четыре сервиса с сетевой изоляцией:
```plaintext
┌──────────────────────┐
│ Nginx Reverse │
│ Proxy (80/443) │ ← единственная точка входа
└──────┬───────────────┘
│
┌─────────┴───────────────┐ приватная сеть
│ │ │
┌───▼────┐ ┌──▼──────┐ ┌─────▼──────┐
│ PHP-FPM│ │ MySQL │ │ Redis │
│ WP │ │ │ │ (опционально)│
└────────┘ └─────────┘ └────────────┘
```
## Production docker-compose.yml
```yaml
services:
proxy:
image: nginx:alpine
ports:
- "80:80"
- "443:443"
volumes:
- ./nginx/nginx.conf:/etc/nginx/nginx.conf:ro
- ./nginx/snippets:/etc/nginx/snippets:ro
- certbot_www:/var/www/certbot
- certbot_conf:/etc/letsencrypt
depends_on:
- wordpress
restart: unless-stopped
networks:
- public
- private
wordpress:
image: wordpress:6.4-php8.2-fpm-alpine
volumes:
- wordpress_data:/var/www/html
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: ${WORDPRESS_DB_USER}
WORDPRESS_DB_PASSWORD: ${WORDPRESS_DB_PASSWORD}
WORDPRESS_DB_NAME: ${WORDPRESS_DB_NAME}
WORDPRESS_CONFIG_EXTRA: |
define('WP_CACHE_KEY_SALT', '${SITE_DOMAIN}');
restart: unless-stopped
networks:
- private
db:
image: mysql:8.0
volumes:
- db_data:/var/lib/mysql
environment:
MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
MYSQL_DATABASE: ${WORDPRESS_DB_NAME}
MYSQL_USER: ${WORDPRESS_DB_USER}
MYSQL_PASSWORD: ${WORDPRESS_DB_PASSWORD}
restart: unless-stopped
networks:
- private
redis:
image: redis:7-alpine
volumes:
- redis_data:/data
restart: unless-stopped
networks:
- private
networks:
public:
private:
internal: true
```
### .env (не коммитить в Git!)
```bash
MYSQL_ROOT_PASSWORD=strong_root_pass_here
WORDPRESS_DB_NAME=wordpress
WORDPRESS_DB_USER=wordpress
WORDPRESS_DB_PASSWORD=strong_user_pass_here
SITE_DOMAIN=example.com
```
## HTTPS с Let’s Encrypt
Nginx конфигурация с TLS-termination и автоматическим получением сертификатов через Certbot:
```nginx
server {
listen 80;
server_name example.com;
location /.well-known/acme-challenge/ {
root /var/www/certbot;
}
location / {
return 301 https://$host$request_uri;
}
}
server {
listen 443 ssl http2;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
# Security headers
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
root /var/www/html;
index index.php;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
fastcgi_pass wordpress:9000;
fastcgi_index index.php;
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";
}
}
```
## Управление секретами
* **`.env` файл** — чувствительные значения, исключён из Git (`.gitignore`)
* **Docker Secrets** — для Docker Swarm
* **Сильные уникальные пароли** — не `wordpress`/`wordpress`
## PHP-FPM оптимизация
```ini
; php.ini (кастомный или через environment)
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.revalidate_freq=2
memory_limit=256M
max_execution_time=300
upload_max_filesize=64M
post_max_size=64M
```
## Кеширование
| Уровень | Инструмент | Что кеширует |
| ---------- | -------------------- | ------------------------------- |
| Страничное | Nginx fastcgi\_cache | HTML-страницы |
| Объектное | Redis | Результаты запросов к БД, опции |
| Статика | Nginx expires | CSS, JS, изображения |
| OPcache | PHP OPcache | Скомпилированный PHP-код |
## Бэкапы
* **Named volumes** для БД и wp-content (безопаснее bind mounts)
* Ежедневные бэкапы базы: `mysqldump` по cron + загрузка в S3
* **Не хранить бэкапы на том же сервере** — использовать внешнее S3-хранилище
* Тестировать восстановление из бэкапов регулярно
## Pre-production чек-лист
* [ ] HTTPS активен и форсирован
* [ ] Только proxy-порты (80/443) публично доступны
* [ ] `.env` исключён из Git
* [ ] Persistent volumes для БД и wp-content
* [ ] Автоматические бэкапы настроены и протестированы
* [ ] Staging-окружение зеркалит production
* [ ] План отката задокументирован
* [ ] Resource limits на контейнеры проставлены
* [ ] Health checks на все сервисы
## Частые ошибки
* **Публичный доступ к портам БД** — MySQL не должен быть открыт наружу
* **Тег `latest`** — внезапные обновления ломают сайт, используйте конкретную версию
* **Dev-настройки в production** — `WP_DEBUG=true`, `display_errors=on`
* **Пропуск тестов восстановления** — бэкап без проверки восстановления — не бэкап
* **Бэкапы на том же диске** — при сбое хостинга теряется всё
## Материалы и источники
* [dev.to: WordPress + WooCommerce Locally with Docker](https://dev.to/daniloab/how-to-run-wordpress-woocommerce-locally-with-docker-42cd)
* [Docker Compose WordPress production best practices (web search, 2026)](https://docs.docker.com/compose/wordpress/)
* [DDpa: Infrastructure as Code](https://ddpa.ru/kb/it/devops/infrastructure-as-code/)
----------
# Критерии выбора хостинга для WordPress
> Метрики и критерии выбора хостинга: TTFB, uptime, технологии сервера, безопасность, поддержка и прозрачность цен.
## Скорость: TTFB (Time To First Byte)
Главная метрика производительности сервера. TTFB — время от запроса браузера до первого байта ответа.
* **<400 мс** — отлично, посетитель не замечает задержки
* **400-600 мс** — приемлемо
* **>600 мс** — посетитель ощущает задержку, SEO страдает
TTFB зависит от:
* Географической близости сервера к посетителю
* Технологий веб-сервера (LiteSpeed vs Apache)
* Кэширования (серверного и объектного)
* Нагрузки на сервер
## Аптайм (доступность)
Процент времени, когда сайт доступен. Измеряется за месяц.
| Аптайм | Простой в месяц | Оценка |
| ------ | --------------- | ------- |
| 99.5% | \~3.5 часа | Плохо |
| 99.9% | \~43 минуты | Хорошо |
| 99.95% | \~22 минуты | Отлично |
| 99.99% | \~4 минуты | Премиум |
* Минимальный стандарт: **≥99.9%**
* Лучшие провайдеры дают гарантию 99.95-99.99%
* Некоторые (Liquid Web) компенсируют простой — до 1000% от стоимости
## Технологии сервера
### Диски: NVMe > SSD > HDD
* **NVMe** — современный стандарт. Пропускная способность до 7 ГБ/с
* **SSD** — приемлемо, но медленнее NVMe
* **HDD** — не должно использоваться в 2026 году
### Веб-сервер: LiteSpeed > Nginx > Apache
* **LiteSpeed** — лучшая производительность для WordPress «из коробки». Встроенный LSCache, совместимость с .htaccess
* **Nginx** — быстро обрабатывает статику, но требует тонкой настройки
* **Apache** — медленнее, но традиционная совместимость
### PHP
* Минимум: 8.0
* Рекомендуется: 8.2 или 8.3
* Важно: возможность переключать версию PHP в панели управления
### База данных
* MariaDB 10.6+ или MySQL 8.0+
* InnoDB как движок по умолчанию
### Кэширование
* Серверное: LiteSpeed Cache (LSCache), Varnish
* Объектное: Redis, Memcached
* OPcache для PHP
## Безопасность
### Что должно быть включено в тариф
* **SSL-сертификаты:** бесплатный Let’s Encrypt — стандарт в 2026
* **WAF (Web Application Firewall):** фильтрация вредоносных запросов
* **DDoS-защита:** базовый уровень на уровне сети
* **Автоматические ежедневные бэкапы:** с возможностью скачать или восстановить
* **Изоляция аккаунтов:** CloudLinux (для shared) — исключает влияние соседей
* **Защита от вредоносного ПО:** сканирование файлов
### Дополнительные меры безопасности
* Автообновление ядра WordPress
* Двухфакторная аутентификация в панели хостинга
* Защита от брутфорса
## Панель управления
* **cPanel** — индустриальный стандарт, интуитивно понятный
* **Plesk** — альтернатива cPanel, чаще на Windows
* **ISPmanager** — популярен у российских провайдеров
* **Собственная панель** (Beget, Timeweb) — может быть удобнее, но нет стандартизации
Что должно быть в панели:
* Управление файлами (файловый менеджер)
* Управление базами данных (phpMyAdmin)
* Управление доменами и поддоменами
* Управление почтовыми ящиками
* Установщик WordPress в 1 клик
* Переключение версии PHP
* Просмотр логов ошибок
## Техподдержка
* **24/7** — сайт может упасть в любое время
* **Каналы:** чат, тикет-система, телефон (чем больше, тем лучше)
* **Компетентность:** поддержка должна разбираться именно в WordPress, а не только в хостинге
* **Русскоязычная поддержка** для РФ-аудитории обязательна
> Перед покупкой — напишите в поддержку с тестовым вопросом. Оцените скорость и качество ответа.
## География дата-центров
Близость сервера к аудитории снижает TTFB:
* **РФ-аудитория:** Москва, Санкт-Петербург (соблюдение ФЗ-152)
* **СНГ:** Германия, Нидерланды, Польша, Финляндия
* **Европа:** Германия, Нидерланды, Франция, Великобритания
* **США/Глобально:** восточное или западное побережье США
* **Азия:** Сингапур, Токио
Некоторые провайдеры (Timeweb, REG.RU) позволяют выбрать дата-центр.
## Ценовая политика
### На что обратить внимание
* **Цена первого периода** обычно ниже в 2-4 раза цены продления
* Считайте **TCO за 3-5 лет**, а не только первый год
* **Пробный период** или гарантия возврата (7-30 дней)
* **Скрытые платежи:** плата за SSL, бэкапы, миграцию
### Пример расчёта на 5 лет
| Провайдер | Промо (1-й год) | Renewal (год) | TCO за 5 лет |
| --------- | --------------- | ------------- | ------------ |
| Bluehost | $2.99/мес | $8.99/мес | $467 |
| Kinsta | $29.17/мес | $29.17/мес | $1,750 |
| Timeweb | 164 ₽/мес | \~350 ₽/мес | \~18 700 ₽ |
> Хостинг за 100 ₽/мес может оказаться дороже за 500 ₽/мес, если renewal в 5 раз выше.
## SEO-влияние хостинга
* **Скорость загрузки** — прямой фактор ранжирования (Core Web Vitals)
* **Аптайм** — если сайт недоступен, поисковики не могут его индексировать
* **Геолокация сервера** — влияет на региональную выдачу
* **Безопасность** — взломанный сайт получает санкции поисковиков
* **IP-адрес** — shared-хостинг может делить IP с «плохими соседями»
## Чек-лист оценки хостинга
Перед выбором проверьте:
* [ ] TTFB < 500 мс с целевого региона
* [ ] Аптайм ≥ 99.9% (подтверждённый тестами)
* [ ] NVMe или SSD-диски
* [ ] LiteSpeed или Nginx
* [ ] Бесплатный SSL (Let’s Encrypt)
* [ ] Ежедневные автоматические бэкапы
* [ ] Поддержка 24/7 на русском языке
* [ ] Прозрачные renewal-цены
* [ ] Пробный период или гарантия возврата
* [ ] Сервер в нужной геолокации
* [ ] PHP 8.2+ с возможностью переключения
* [ ] MariaDB 10.6+ или MySQL 8.0+
## Материалы и источники
* [Рейтинг хостингов для WordPress](https://wpcraft.ru/hosting-wordpress-woocommerce)
* [How to Choose the Best WordPress Hosting — GreenGeeks](https://www.greengeeks.com/tutorials/how-to-choose-the-best-wordpress-hosting/)
* [How to Choose the Best WordPress Hosting — WPBeginner](https://www.wpbeginner.com/wordpress-hosting/)
* [Best WordPress Hosting 2026 — RSHosting](https://www.rshosting.com/blog/best-wordpress-hosting-2026-ultimate-guide-to-fast-secure-reliable-wordpress-hosting/)
* [Best WordPress Hosting — Themeisle](https://themeisle.com/blog/best-wordpress-hosting/)
* [Best WordPress Hosting — CNET](https://www.cnet.com/tech/services-and-software/best-wordpress-hosting/)
## Связанные страницы
* [Типы хостинга](../hosting-types) — какой тип выбрать для вашего проекта
* [Хостинг-провайдеры: сравнение](../hosting-providers) — конкретные провайдеры с ценами и тестами
* [Хостинг для WordPress: как выбрать](../../../wordpress/faq/how-to/wordpress-hosting) — быстрый обзор для новичков
* [Оптимизация WordPress](../../performance/optimization) — ускорение после выбора хостинга
----------
# Хостинг-провайдеры: сравнение
> Сравнение хостинг-провайдеров для WordPress: международные и российские, цены, скорость, аптайм и особенности каждого.
## Российские провайдеры
### Сводная таблица
| Провайдер | От | Тип | Тест-период | Лучшее для |
| ---------- | -------- | ---------- | ----------- | --------------------- |
| Timeweb | 164 ₽ | Shared/VPS | 10 дн | Быстрый старт |
| Beget | 169 ₽ | Shared | 30 дн | Стабильность, новички |
| REG.RU | 164 ₽ | Shared/VPS | 14 дн | Домены + хостинг |
| Sprinthost | 99 ₽ | Shared/VPS | 30 дн | Низкая цена |
| AdminVPS | 69 ₽ | VPS | 7 дн | VPS для растущих |
| Fornex | 390 ₽ | VPS | — | Европейские серверы |
| FirstVDS | от 300 ₽ | VPS | — | Тонкая настройка |
| VDSina | от 30 ₽ | VPS | 3 дн | Минимальная цена VPS |
| SpaceWeb | 199 ₽ | Shared | 14 дн | Надёжность |
| Cloud4Box | 88 ₽ | Cloud | 1 мес/1₽ | Облачные решения |
***
### Timeweb — для быстрого старта
* **Цена:** от 164 ₽/мес
* NVMe-диски, HTTP/2/3, бесплатный SSL
* Автоустановка WP в 1 клик, автообновления, автобэкапы
* Удобная панель, быстрая поддержка
* **Дата-центры:** Москва, СПб, Европа
* **Оценка:** 9.8/10 (HostingHub) | 4.5/5 (Hostings.info)
* **Для кого:** блоги, лендинги, корпоративные сайты, небольшие магазины
### Beget — стабильность и безопасность
* **Цена:** от 169 ₽/мес
* Бесплатный SSL (Let’s Encrypt), ISPmanager
* Автобэкапы, антивирус, изоляция аккаунтов
* **Тест-период:** 30 дней
* **Оценка:** 9.8/10 (HostingHub) | 4.6/5 (Hostings.info)
* **Для кого:** новички, небольшие коммерческие сайты
### REG.RU — домены + хостинг в одном окне
* **Цена:** от 164 ₽/мес
* Крупнейший регистратор доменов в РФ
* Удобная панель управления
* **Дата-центры:** выбор локации
* **Для кого:** начинающие, кто хочет домен и хостинг у одного провайдера
### Sprinthost — дружелюбный и доступный
* **Цена:** от 99 ₽/мес
* Автоустановка WP, бесплатный SSL, ежедневные бэкапы
* Мониторинг 24/7, отзывчивая поддержка
* **Тест-период:** 30 дней
* **Оценка:** 9.5/10 (HostingHub) | 4.7/5 (Hostings.info)
* **Для кого:** блогеры, локальный бизнес
### AdminVPS — когда тесно на shared
* **Цена:** от 69 ₽/мес (VPS)
* NVMe-диски, гибкие конфигурации
* Помощь с администрированием
* **Для кого:** интернет-магазины, СМИ, растущие проекты
### VDSina — бюджетный VPS
* **Цена:** от 30 ₽/мес (поминутная тарификация)
* NVMe-диски, современные ядра Linux
* Быстрое масштабирование
* **Для кого:** важны скорость и полный контроль при минимальной цене
### Fornex — европейские серверы
* **Цена:** от 390 ₽/мес (VPS)
* VDS и выделенные серверы в разных геолокациях
* **Оценка:** 4.8/5 (Hostings.info)
* **Для кого:** интернет-магазины, медиа, контентные порталы с европейской аудиторией
### Cloud4Box — для высоких нагрузок
* **Цена:** от 88 ₽/мес (облачная платформа)
* High Availability, масштабирование
* **Для кого:** корпоративные сайты, e-commerce со строгими SLA
***
## Международные провайдеры
### Сводная таблица (2025-2026)
| Провайдер | От | TTFB | Аптайм | Тип | Лучшее для |
| ----------- | ---------- | ------ | ------ | -------------- | ----------------------------- |
| Hostinger | $2.69/мес | 374 мс | 100% | Shared/Managed | Бюджет, малый бизнес |
| SiteGround | $2.99/мес | 397 мс | 100% | Managed | Производительность |
| Bluehost | $2.99/мес | 1.2 с | 99.98% | Shared | Новички (рекомендован WP.org) |
| Kinsta | $29.17/мес | 640 мс | 100% | Managed | Высокая производительность |
| WP Engine | $23/мес | 720 мс | 99.98% | Managed | Разработчики |
| Rocket.net | $25/мес | 340 мс | 100% | Managed | Максимальная скорость |
| Cloudways | $11/мес | 910 мс | 100% | Cloud | Гибкость, агентства |
| GreenGeeks | $1.95/мес | 1.95 с | 99.83% | Shared | Эко-хостинг, новички |
| InterServer | $2.50/мес | — | — | VPS/Shared | Бюджетный VPS |
| Liquid Web | $17.60/мес | — | 99.99% | Managed | Премиум, WooCommerce |
> TTFB и аптайм — по данным тестов Themeisle, WPBeginner и CNET (2025-2026). Реальные значения зависят от тарифа и локации.
***
### Hostinger — лучший бюджетный
* **Цена:** от $2.69/мес (промо), renewal \~$11/мес
* **Серверы:** LiteSpeed, hPanel (собственная панель)
* **TTFB:** 374 мс | **Аптайм:** 100%
* Бесплатный домен, миграция, CDN
* AI-инструменты: контент, Kodee AI agent
* Официально рекомендован WordPress.org
### SiteGround — лучшая производительность
* **Цена:** от $2.99/мес (промо), renewal \~$18/мес
* **Инфраструктура:** Google Cloud
* **TTFB:** 397 мс | **Аптайм:** 100%
* Speed Optimizer — собственный плагин кэширования
* Ежедневные бэкапы, автообновления
* WP-эксперты в поддержке
### Bluehost — рекомендован WordPress.org
* **Цена:** от $2.99/мес (промо), renewal \~$8.99/мес
* Бесплатный домен на первый год
* AI-инструменты создания сайта
* **TTFB:** 1.2 с — медленнее конкурентов
* 24/7 поддержка: телефон, чат, email
### Kinsta — премиум managed
* **Цена:** от $29.17/мес, renewal без повышения
* **Инфраструктура:** Google Cloud C3D VMs
* **TTFB:** 640 мс | **Аптайм:** 100%
* 10-250 ГБ, 25K-3M посетителей/мес
* Собственный плагин кэширования, staging-зоны
* Гарантия устранения взломов
* 14-дневное хранение бэкапов
### WP Engine — для разработчиков
* **Цена:** от $23/мес
* Genesis Framework + 36 тем StudioPress бесплатно
* Staging в 1 клик, Git-интеграция
* Передача права собственности клиенту
* Собственный EverCache
* ISO 27001:2022 сертификация
### Rocket.net — максимальная скорость
* **Цена:** от $25/мес
* **TTFB:** 340 мс (один из лучших показателей)
* Встроенный глобальный CDN
* Сильный файрвол, автообновления
* Приобретён Hosting.com в 2025
***
## Сравнение международных vs российских
| Критерий | Международные | Российские |
| ----------------------- | ----------------------- | ------------------------ |
| Цена | От $2-3/мес | От 100-200 ₽/мес |
| Дата-центры в РФ | Редко | Есть (Москва, СПб) |
| Русскоязычная поддержка | Не всегда | Всегда |
| Оплата | Карты РФ — сложности | РФ-карты, QIWI, ЮMoney |
| Серверные технологии | LiteSpeed, Google Cloud | NVMe, ISPmanager, cPanel |
| ФЗ-152 | Не учитывают | Соответствуют |
> При выборе между международным и российским хостингом главный фактор — география аудитории и способ оплаты. Для РФ-аудитории российские провайдеры дают лучший TTFB.
## Рекомендации по типам проектов
* **Блог / визитка** → Timeweb, Beget, Hostinger
* **Интернет-магазин (WooCommerce)** → AdminVPS, FirstVDS, Kinsta, Liquid Web
* **Высоконагруженный проект** → Cloud4Box, Kinsta, WP Engine
* **Бюджетный старт** → Sprinthost, Hostinger, InterServer
* **Максимальная скорость** → Rocket.net, SiteGround
* **Эко-хостинг** → GreenGeeks (300% match возобновляемой энергии)
## Материалы и источники
* [Best WordPress Hosting 2026 — RSHosting](https://www.rshosting.com/blog/best-wordpress-hosting-2026-ultimate-guide-to-fast-secure-reliable-wordpress-hosting/)
* [Best WordPress Hosting — ZDNET](https://www.zdnet.com/article/best-wordpress-hosting/)
* [Best WordPress Hosting — CNET](https://www.cnet.com/tech/services-and-software/best-wordpress-hosting/)
* [Best WordPress Hosting — Bit Integrations](https://bit-integrations.com/blog/best-wordpress-hosting/)
* [Best WordPress Hosting — Themeisle](https://themeisle.com/blog/best-wordpress-hosting/)
* [How to Choose WP Hosting — WPBeginner](https://www.wpbeginner.com/wordpress-hosting/)
* [Рейтинг хостингов для WordPress — VC.ru](https://vc.ru/dev/2420793-reiting-hostingov-dlya-wordpress-chto-vybrat-v-2025-2026-godu-top-na-dekabr-2025)
* [Рейтинг лучших хостингов — DTF](https://dtf.ru/new_microloans_05_2026/3221330-reiting-luchshih-hostingov-dlya-wordpress-na-2025-god)
* [25 хостинг-провайдеров — РБК](https://companies.rbc.ru/useful/podborka-25-proverennyh-hosting-provajderov-wordpress-v-2025-godu/)
* [Лучшие хостинги для WordPress в РФ — VC.ru](https://vc.ru/top-raiting/1819779-luchshie-hostingi-dlya-wordpress-v-2026-godu-v-rossii)
* [Хостинг для WordPress 2026 — HostingHub](https://hostinghub.ru/top/cms/wordpress)
* [10 лучших хостингов — Hostings.info](https://ru.hostings.info/hostings/rating/wordpress-hosting)
## Связанные страницы
* [Типы хостинга](../hosting-types) — какой тип выбрать для вашего проекта
* [Критерии выбора хостинга](../hosting-criteria) — метрики и чек-лист оценки
* [Регистраторы доменов: сравнение](../../domain/domain-registrars) — выбор домена под хостинг
* [Хостинг для WordPress: как выбрать](../../../wordpress/faq/how-to/wordpress-hosting) — быстрый обзор для новичков
----------
# Типы хостинга для WordPress
> Shared, VPS, облачный и managed WordPress-хостинг: сравнение типов, плюсы и минусы, для каких проектов подходит каждый.
## Обзор типов хостинга
Под self-hosted WordPress доступны четыре основных типа хостинга. Выбор зависит от трафика, бюджета и технических навыков.
### Сводная таблица
| Тип | Цена (мес) | Трафик (чел/сут) | Администрирование | Масштабируемость |
| ---------------------- | ---------- | ---------------- | ----------------- | ------------------- |
| Shared (виртуальный) | 150-500 ₽ | до 2 500 | Минимальное | Низкая |
| VPS/VDS | 500-3000 ₽ | 3 000-5 000 | Среднее | Средняя |
| Облачный (кластер) | от 3000 ₽ | 10 000+ | Высокое | Высокая (stateless) |
| Облачный | от 1000 ₽ | 10 000+ | Высокое | Высокая |
| Managed/Specialized WP | от 800 ₽ | до 250 000 | Не требуется | Зависит от тарифа |
***
## Shared-хостинг (виртуальный)
Несколько сайтов на одном сервере делят процессор, память и диск. \~34% пользователей WordPress используют shared.
**Плюсы:**
* Самая низкая цена (150-500 ₽/мес)
* Автоустановка WordPress в 1 клик
* Не нужно администрировать сервер
**Минусы:**
* Ресурсы делятся с «соседями» — чужой всплеск трафика замедляет вас
* Ограничения по inodes, CPU, RAM
* При превышении лимитов — блокировка или замедление
**Для кого:** блоги, визитки, лендинги, небольшие проекты с трафиком до 2 500 чел/сутки.
### Скрытые лимиты shared-хостинга
* **Inodes** — максимальное количество файлов на аккаунте. Кэш плагинов быстро расходует лимит
* **CPU и RAM** — не гарантированы, делятся динамически
* **I/O** — скорость дисковых операций ограничена
> Перед покупкой shared-тарифа уточните лимиты в поддержке. Низкая цена может означать жёсткие ограничения.
***
## VPS/VDS (виртуальный выделенный сервер)
Виртуальная машина с гарантированными ресурсами и root-доступом.
**Плюсы:**
* Изолированная среда — соседи не влияют
* Root-доступ — полный контроль над сервером
* Возможность установить Redis, настроить Nginx, выбрать версию PHP
**Минусы:**
* Требует навыков администрирования Linux
* Дороже shared (500-3000 ₽/мес)
* Ответственность за безопасность сервера лежит на вас
**Для кого:** растущие проекты, интернет-магазины, сайты с 3 000-5 000 чел/сутки.
### Минимальный VPS для WooCommerce
* 2 vCPU
* 2-4 ГБ RAM
* NVMe-диск
* Redis для объектного кэширования
***
## Облачный хостинг (Cloud)
Сайт работает на кластере серверов, а не на одной машине. При росте нагрузки подключаются дополнительные ресурсы.
**Плюсы:**
* Отказоустойчивость — выход одного сервера не роняет сайт
* Горизонтальное масштабирование
* Оплата по факту использования (pay-as-you-go)
**Минусы:**
* Сложная ценовая модель
* Требует высокой технической квалификации
* Требует [stateless-архитектуры](../../../wordpress/plugins/s3-plugins) (медиа — в S3, а не на локальном диске)
* Дороже VPS при стабильной нагрузке
**Для кого:** высоконагруженные проекты, SaaS, корпоративные сайты со строгими SLA.
***
## Специализированный WordPress-хостинг
Среда полностью заточена под WordPress: серверное кэширование, автообновления, проактивная безопасность.
**Что даёт специализированный хостинг:**
* Серверное кэширование (LiteSpeed Cache, Varnish, Redis)
* Тонкая настройка PHP и MySQL/MariaDB под WP
* Автообновления ядра, плагинов и тем
* Staging-среда для тестирования
* WP-эксперты в техподдержке
* Проактивная защита от типичных WP-уязвимостей
**Плюсы:**
* Не нужно думать о технических деталях
* 99.9% меньше downtime, до 37% быстрее обычного shared (по данным GreenGeeks)
* Экспертная поддержка
**Минусы:**
* Дороже обычного хостинга
* Могут быть ограничения по плагинам (например, запрет на некоторые плагины кэширования)
**Для кого:** те, кто хочет «как WordPress.com, но self-hosted» — полный контроль без необходимости администрировать сервер.
***
## Бесплатный хостинг — не рекомендуется
Бесплатный хостинг имеет критические ограничения:
* Принудительная реклама провайдера
* Мало места, слабые ресурсы
* Часто нет SSL
* Слабая или отсутствующая поддержка
* Риск удаления сайта без предупреждения
> Для self-hosted WordPress бесплатный хостинг не подходит. Минимальный shared-тариф (150-200 ₽/мес) решает все эти проблемы.
***
## Какой тип выбрать: шпаргалка
* **Начинающий блогер** → Shared (Timeweb, Beget, Sprinthost)
* **Растущий проект** → Специализированный WP или VPS
* **Интернет-магазин (WooCommerce)** → Минимум VPS (2 vCPU, 2-4 ГБ RAM)
* **Высокий трафик (10 000+)** → Облако или Managed WP (Kinsta, WP Engine)
* **Разработчик/агентство** → VPS или облако (полный контроль)
## Материалы и источники
* [How to Choose the Best WordPress Hosting — GreenGeeks](https://www.greengeeks.com/tutorials/how-to-choose-the-best-wordpress-hosting/)
* [How to Choose the Best WordPress Hosting — WPBeginner](https://www.wpbeginner.com/wordpress-hosting/)
* [Рейтинг хостингов для WordPress — VC.ru](https://vc.ru/dev/2420793-reiting-hostingov-dlya-wordpress-chto-vybrat-v-2025-2026-godu-top-na-dekabr-2025)
* [Рейтинг хостингов для WordPress (v2) — VC.ru](https://vc.ru/dev/2282297-reiting-hostingov-dlya-wordpress-chto-vybrat-v-2025-2026-godu-top-na-dekabr-2025)
* [Лучшие хостинги для WordPress в РФ — VC.ru](https://vc.ru/top-raiting/1819779-luchshie-hostingi-dlya-wordpress-v-2026-godu-v-rossii)
## Связанные страницы
* [Критерии выбора хостинга](../hosting-criteria) — метрики и чек-лист оценки
* [Хостинг-провайдеры: сравнение](../hosting-providers) — конкретные провайдеры с ценами
* [Infrastructure as Code для WordPress](../iac-wordpress) — Terraform, Pulumi, Ansible для автоматизации инфраструктуры
* [Хостинг для WordPress: как выбрать](../../../wordpress/faq/how-to/wordpress-hosting) — быстрый обзор для новичков
* [Домен и хостинг: в чём разница](../../domain/domain-vs-hosting) — базовое объяснение
----------
# Infrastructure as Code для WordPress
> IaC для WordPress: Terraform, Pulumi, Ansible, Docker, Kubernetes — обзор инструментов, архитектурных шаблонов и российских облаков.
## Что такое Infrastructure as Code (IaC)
Подход, при котором серверы, базы данных, сети и балансировщики описываются в конфигурационных файлах и разворачиваются автоматически. Для WordPress: инфраструктура под сайт создаётся одной командой.
**Ключевые свойства:** декларативность, идемпотентность, воспроизводимость (dev = staging = prod), весь код в Git.
## Типы IaC
| Тип | Суть | Инструменты |
| ------------------- | ------------------------------ | ----------------------------------------------- |
| **Декларативный** | Описывается желаемое состояние | Terraform, OpenTofu, CloudFormation, Crossplane |
| **Императивный** | Пошаговые инструкции | Ansible, Chef, SaltStack |
| **Программируемый** | На Python, TS, Go | Pulumi, AWS CDK, CDK for Terraform |
## Инструменты для WordPress
| Инструмент | Язык | Для WordPress |
| ------------------------ | --------------- | ---------------------------------------------------------- |
| **Terraform / OpenTofu** | HCL | AWS (EC2+RDS+EFS+Redis+CloudFront), Yandex Cloud, VK Cloud |
| **Pulumi** | Python/TS/Go/C# | Команды разработчиков, мульти-стек |
| **Ansible** | YAML | Установка WP, PHP, Nginx на готовых VM |
| **Docker Compose** | YAML | Локальная разработка и простой продакшен |
| **Helm / kubectl** | Charts / YAML | WordPress в Kubernetes |
## Terraform на AWS: архитектура (тезисно)
Production-grade схема для тысяч одновременных пользователей:
```plaintext
CloudFront → ALB → ECS Fargate (WordPress, Auto Scaling 2–10)
├── EFS (общее wp-content)
├── RDS Aurora MySQL Serverless v2
└── ElastiCache Redis
```
**Ключевые компоненты:**
* **VPC** — 3 AZ, public (ALB) + private (приложение, БД, кеш) подсети
* **RDS Aurora Serverless v2** — 0.5–16 ACU, writer + reader, 7 дней бэкапов, encrypted
* **EFS** — общее хранилище `wp-content/uploads` для всех контейнеров (иначе загрузка на одном не видна на других)
* **ElastiCache Redis** — 2 ноды multi-AZ, объектное кеширование (ускорение ×10–100)
* **ECS Fargate** — WordPress 6.4 + PHP 8.2 FPM, Secrets Manager для паролей
* **Auto Scaling** — по CPU (60%), 2–10 контейнеров
* **CloudFront** — перед ALB, не кеширует `/wp-admin/*`
**Стоимость (ориентир):** \~$300–400/мес. Упрощённый вариант — один EC2 + RDS MySQL (не Aurora) — \~$55/мес.
## Docker Compose: локально и продакшен
**Локальная разработка:** MySQL + WordPress (официальные образы), `/wp-content` в локальный volume, `WP_DEBUG=true`.
**Production-архитектура:** Nginx reverse proxy (единственная точка входа) → PHP-FPM WordPress + MySQL + Redis. Приватная сеть — только proxy наружу.
**Обязательно:** HTTPS (Let’s Encrypt + Certbot), `.env` в `.gitignore`, named volumes для БД и wp-content, health checks, resource limits, конкретные теги образов (не `latest`).
**Pre-production чек-лист:**
* HTTPS активен, только 80/443 публично
* Persistent volumes, автоматические бэкапы (внешнее S3)
* Staging = production, план отката задокументирован
## Kubernetes: когда и как
**Когда оправдан:** десятки тысяч посетителей/день, горизонтальное масштабирование, zero-downtime деплой. Для типовых сайтов — избыточен.
**Архитектура:** Ingress (Nginx) → Service → Deployment (WordPress pods, 2–10) + PVC (RWX через OpenEBS NFS) ← MySQL StatefulSet + Redis StatefulSet.
**Ключевые объекты:** Namespace, Secret, ConfigMap, PVC, StatefulSet (MySQL), Deployment (WP), Service, Ingress + Cert-Manager.
**Проблема RWX:** несколько реплик WordPress должны видеть одни `wp-content/uploads`. Стандартное блочное хранилище (RWO) монтируется только к одному поду. Решение: OpenEBS NFS Provisioner или AWS EFS CSI driver.
**Helm (Bitnami):** `helm install my-wp bitnami/wordpress --set externalDatabase.host=... --set persistence.storageClass=rwx-storage`
**Стоимость (DigitalOcean):** \~$220–315/мес (DOKS 3×4cpu/8gb + Managed MySQL + Redis + LB).
## Связка Pulumi + Ansible
Pulumi создаёт облачную инфраструктуру (VPC, RDS, EC2), Ansible настраивает серверы (установка WP, PHP, Nginx). Всё одной командой `pulumi up`.
## Российские облака
| Платформа | Terraform | Pulumi | Ansible | Особенности |
| --------------------- | :--------: | :----: | :-----: | ----------------------------- |
| **Yandex Cloud** | ✓ | ✓ | ✓ | Crossplane |
| **VK Cloud** | ✓ | ✓ | ✓ | Packer, зрелая документация |
| **Selectel** | ✓ | — | ✓ | Выделенные серверы |
| **Cloud.ru (Сбер)** | ✓ | — | — | ФСТЭК |
| **Timeweb Cloud** | ✓ | — | — | Простой вход |
| **Deckhouse (Флант)** | K8s-native | — | — | Российская K8s, GitOps, ФСТЭК |
## Best Practices
* Весь код в Git, изменения через PR
* Модульность, переиспользуемые компоненты
* GitOps, тестирование (Checkov, Terratest)
* Drift detection, минимальные IAM-привилегии
## Когда IaC, а когда PaaS
| IaC | PaaS (Managed WP) |
| ------------------------ | ----------------------- |
| Полный контроль | Управление приложением |
| Нужны DevOps-компетенции | Минимальный порог входа |
| High-load, compliance | Типовые сайты |
Для большинства проектов на старте PaaS практичнее. IaC оправдан при: 5+ серверов, high-load, мульти-региональный деплой, compliance.
## Материалы и источники
* [DDpa: Infrastructure as Code](https://ddpa.ru/kb/it/devops/infrastructure-as-code/)
* [OneUptime: WordPress Infrastructure with Terraform on AWS](https://oneuptime.com/blog/post/2026-02-23-how-to-build-a-wordpress-infrastructure-with-terraform/view)
* [CloudThat: Scalable WordPress on AWS with Terraform](https://www.cloudthat.com/resources/blog/building-a-scalable-wordpress-infrastructure-on-aws-with-terraform/)
* [Pulumi: Deploy WordPress to AWS](https://www.pulumi.com/blog/deploy-wordpress-aws-pulumi-ansible/)
* [DevOpsCube: Deploy WordPress on Kubernetes](https://devopscube.com/deploy-wordpress-on-kubernetes/)
* [DigitalOcean: WordPress on K8s with Helm](https://www.digitalocean.com/community/developer-center/deploying-a-wordpress-website-on-a-kubernetes-cluster-using-helm)
* [Automattic: DevOps for WordPress](https://automattic.com/for-agencies/blog/wordpress-devops/)