CI/CD для WordPress под affiliate-сайты: как не ломать трафик на каждом деплое

CI/CD для WordPress под affiliate-сайты: как не ломать трафик на каждом деплое

Пайплайн для WP нужен не ради красоты, а чтобы правки шли повторяемо: код, плагины, темы, конфиги — отдельно, контент и база — отдельно. На практике это снижает риск «задеплоили и сайт лег»: меньше ручных кликов, меньше сюрпризов от кэша и меньше шансов забыть .htaccess или wp-config.php.

Базовая схема такая:
— git хранит тему, mu-plugins и часть конфигов;
— в релиз попадает только то, что можно откатить без боли;
— перед выкладкой прогоняются lint и проверка синтаксиса PHP;
— после деплоя очищается только нужный кэш, а не весь сайт;
— база и uploads не перетираются из репозитория.

Для affiliate-сеток критично разделять окружения. Staging нужен не «для галочки», а чтобы проверить редиректы, noindex, каноникалы, формы, трекинг и блоки монетизации. Если на staging нет пароля и запрета индексации, он быстро превращается в мусорный дубль. Если нет бэкапа перед релизом — это не CI/CD, а ускоренная лотерея.

Самая частая ошибка — тащить в репозиторий всё подряд: кэш-папки, медиа, дампы базы, секреты API. Правильнее держать секреты в переменных окружения, а медиа — в отдельном бакете или на хранилище. Тогда можно откатить код за минуты, не трогая контент и не ломая статистику.

Если у вас WP кормит трафик и лиды, цель пайплайна простая: один источник правды для кода, один staging, один rollback. Всё остальное — ручной труд, который рано или поздно бьёт по конверсии.