Первый год был хаосом. Потом мы всё записали.

Три сборки одного агентства — и ни одна не похожа на другую

В самом начале, пока ничего из этого не было записано, сайты одного и того же агентства собирались тремя разными способами.

Один разработчик ставил Elementor Forms — они уже были в макете. Другой менял их на Gravity Forms. Третий не трогал то, что есть, по принципу «работает — не лезь». Это было самое начало: стандарта не было ещё ни у нас, ни у агентства. Три разные сборки. Три разных поведения форм. Три разные ветки обсуждения по одному и тому же вопросу.

И это было ещё самое простое из разногласий.

Был ещё вопрос, какие единицы CSS брать. Удалять ли страницу-образец WordPress в первый же день или оставить. Писать заголовки с каждого слова с большой буквы — Title Case (Personal Injury) — или только с первого, sentence case (Personal injury). Нужна ли hero-блоку главной своя точка адаптации или хватит стандартных точек адаптации Elementor. Ставить ли плагин кэширования на WP Engine. (У WP Engine кэш встроенный. Плагин его удваивает. В первые полгода это в команде знали не все.)

У каждого вопроса был один правильный ответ — и в начале по нескольку неправильных, одновременно работающих на разных сайтах.

Замечало это и агентство. Всплывало нечасто — может, пару раз за всё время, — но разговор всегда шёл по одному сценарию: этот сайт делает X, предыдущий делал Y; можно свести к одному? И, честно говоря, своего стандарта у агентства тоже не было. Ту самую одну колею мы в итоге выбрали вместе.

Указать на одну колею мы и не могли — её ещё не существовало. Каждый разработчик пришёл к своему набору решений по умолчанию: отчасти из привычки, отчасти подсмотрев, как уже сделано в проекте, отчасти из догадок о том, чего хочет агентство. Ни один набор не сходился с другими. На выходе — качество, технически приемлемое на каждом отдельном сайте и заметно разнородное по всему портфелю.

Это и была боль. Лечилась она не обучением. Лечилась тем, что мы это записали.

Что значит «записать» на самом деле

Когда у команды разнобой на выходе, первым делом тянет назначить встречу. Собрать всех, пройтись по правилам, договориться, идти дальше. Мы пробовали. Работает неделю. Ко второй неделе половина договорённостей растворяется обратно в «ну, на этом проекте я подумал…», а другая распадается на конкурирующие толкования.

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

Нынешняя внутренняя версия документа начинается так:

# xpro · WordPress build conventions
# v17 — 2026-04-30

stack:
  page-builder:  elementor-pro-only
  forms:         gravity-forms          # не Elementor Forms
  seo:           rank-math
  caching:       none                   # у WP Engine встроенный кэш
  hosting:       wp-engine-standard     # среда, предоставленная агентством

content:
  heading-case:  title-case             # "Personal Injury", не "Personal injury"
  h1-per-page:   1
  units:         px-only                # без vw, без clamp без обоснования
  breakpoints:   elementor-defaults     # свои точки адаптации отключены

phone-numbers:
  format:                  tel:+1XXXXXXXXXX
  always-clickable:        true
  always-include-country:  true

За каждой строкой — закрытый спор. На большинство ушло по проекту.

Несколько примеров — со скрытой историей каждого:

«Всю вёрстку — на Elementor Pro.»
Мы всё собираем на Elementor — на нашей стороне это никогда особо не обсуждалось. Правило всё равно записано: «очевидно для нас» — не то же самое, что «зафиксировано». Не раз сборка выглядела так, будто её делали двумя разными способами, — и если размотать, разнобой шёл из того, как проект настроили до того, как он попал к нам, а не из того, что разработчик посреди работы менял конструктор. Записанное правило сделало ожидание явным, а не подразумеваемым — и для нас, и для агентства.

«Только Gravity Forms. Elementor Forms не использовать.»
На Gravity Forms у агентства уже была налажена доставка писем, нужная им условная логика и интеграции с аналитикой, которые собирали данные в их отчётность. Elementor Forms — вполне нормальный плагин для проекта другого рода. Но на этих проектах смешивать оба означало: у одних форм есть аналитика, у других нет; у одних защита от спама, у других нет; и агентству приходилось выяснять это заново на каждом новом сайте. Правило не про то, какой плагин лучше. Оно про то, чтобы у одного вопроса не было двух ответов.

«У WP Engine кэш встроенный. Плагины кэширования не ставить.»
Это стоило полдня отладки на тестовой среде, которая после деплоя упорно отдавала старые ресурсы. Причина — плагин кэширования, поставленный по привычке, поверх собственного слоя кэша WP Engine. Два кэша наперегонки. Лечение — снять плагин. Правило — в следующий раз его не ставить.

«Телефоны — в формате tel:+1XXXXXXXXXX. Код страны — всегда.»
Какое-то время телефоны попадали на страницы вразнобой: где-то обычным текстом без ссылки tel:, где-то без кода страны, где-то правильно. Номер обычным текстом не вызовет набор, когда посетитель нажмёт на него на телефоне. Проблемой был именно разнобой, а не какой-то один способ вывода. Лечение — выбрать один формат и держать его всегда. Правило — эти несколько символов, записанные так, чтобы вопрос больше не открывался.

«Заголовки и пункты меню — Title Case, каждое слово с большой.»
Деталь, которая кажется придиркой, пока не отсмотришь стопку сайтов за неделю. На одних Personal Injury, на других Personal injury. Оба варианта по-своему защитимы. Вместе — не защитимы никак. Мы просто упустили это из виду; ничьим осознанным решением это не было — поэтому закрыть это могло только записанное правило.

«Только пиксели. Никаких vw и clamp без явной необходимости.»
Похоже на ограничение творчества. Это не оно — это правило про предсказуемость. Сайт, собранный на clamp и vw, нормально выглядит на мониторе разработчика — и непредсказуем во всём остальном. Проверяющие агентства сидели на разных ноутбуках, планшетах и внешних экранах с разным масштабированием. Пиксельная вёрстка у всех одинаковая. Вёрстка на адаптивных единицах — это несколько разных вёрсток. Правило не про вкус в CSS. Оно про то, чтобы проверяющий видел тот же сайт, что мы собрали.

«Один <h1> на страницу. Соблюдать иерархию заголовков.»
Агентство раз за разом отмечало одно и то же: страницы с более чем одним <h1>. Так выходило, потому что разработчик ставил hero-виджет, настроенный как <h1>, потом заголовок секции — тоже <h1>, потому что визуально так выглядело правильно. Браузеру всё равно; аудиту — нет. Правило не про теорию SEO. Оно про то, чтобы не переделывать иерархию заголовков каждый раз, когда на это укажут.

«Свои точки адаптации Elementor отключить. Только стандартные.»
Это пришло из рассогласования, а не из одного инцидента. Мы тестировали сборки на одном наборе точек адаптации, агентство проверяло на другом. То, что у нас выглядело правильно, у них выглядело сломанным, и наоборот — притом что по сути никто не был неправ. Лечение было не в споре, чьи точки адаптации лучше, — а в том, чтобы согласовать один общий набор, а остальное отключить. Стандартные точки адаптации задокументированы, предсказуемы и одинаковы по обе стороны проверки.

Можно продолжать. Есть правила, какие шрифты грузить через TypeKit, а какие никогда не заливать вручную. Какие записи карты сайта включать, какие подавлять. Как помечать target="_blank" на исходящих ссылках. Удалять страницу-образец WordPress в первый же день. UpdraftPlus — только на время разработки.

Ни одно из них не хитрое. Все — закрытые.

Что изменилось, когда документ появился

Чего мы не предвидели — это где на самом деле оказалась выгода. Не столько на нашей стороне. На стороне агентства.

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

В этом и вся история того, что изменилось: нагрузка по проверкам ушла с агентства. Не потому, что нам стали больше доверять вообще, а потому что единообразие проверяемо, а разнобой — нет. Записанный стандарт и сделал сборки проверяемыми в принципе.

Урок для агентства

Если вы маркетинговое агентство, которое отдаёт WordPress-разработку на подряд — одной студии или нескольким, — отсутствие письменного руководства — это налог, который вы платите каждую неделю. Налогом вы его не видите. Вы видите «обычную цену работы с разработчиками». Это не обычная цена. Это цена того, что каждый разработчик заново изобретает правила вашего портфеля, а вы потом гасите получившийся разнобой временем своих проверяющих.

Два практических наблюдения с нашей стороны.

Первый год работы без правил неизбежен — в первый раз. Во второй раз это уже выбор.

Мы выбрали записать правила. Большая часть того, что мы как студия делаем сейчас, выросла из этого одного решения.